From mark.mcgloin@ie.ibm.com Tue Jun 1 01:43:06 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33ABF28C128; Tue, 1 Jun 2010 01:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.958 X-Spam-Level: X-Spam-Status: No, score=-3.958 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MIME_BASE64_BLANKS=0.041, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lj-rLh9iNoX2; Tue, 1 Jun 2010 01:43:05 -0700 (PDT) Received: from mtagate6.uk.ibm.com (mtagate6.uk.ibm.com [194.196.100.166]) by core3.amsl.com (Postfix) with ESMTP id 16B043A67B7; Tue, 1 Jun 2010 01:43:03 -0700 (PDT) Received: from d06nrmr1806.portsmouth.uk.ibm.com (d06nrmr1806.portsmouth.uk.ibm.com [9.149.39.193]) by mtagate6.uk.ibm.com (8.13.1/8.13.1) with ESMTP id o518goYU012253; Tue, 1 Jun 2010 08:42:50 GMT Received: from d06av06.portsmouth.uk.ibm.com (d06av06.portsmouth.uk.ibm.com [9.149.37.217]) by d06nrmr1806.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o518gm6g1282200; Tue, 1 Jun 2010 09:42:50 +0100 Received: from d06av06.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av06.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o518gl7X008466; Tue, 1 Jun 2010 02:42:48 -0600 Received: from d06ml901.portsmouth.uk.ibm.com (d06ml901.portsmouth.uk.ibm.com [9.149.39.138]) by d06av06.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id o518glvj008461; Tue, 1 Jun 2010 02:42:47 -0600 In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11263BF36FD@WSMSG3153V.srv.dir.telstra.com> To: "Manger, James H" X-Mailer: Lotus Notes Release 7.0 HF400 February 20, 2008 Message-ID: From: Mark Mcgloin Date: Tue, 1 Jun 2010 09:42:50 +0100 X-MIMETrack: Serialize by Router on D06ML901/06/M/IBM(Release 8.0.2FP2|June 22, 2009) at 01/06/2010 09:42:47 MIME-Version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: base64 Cc: OAuth WG , oauth-bounces@ietf.org Subject: Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 2 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2010 08:43:06 -0000 SXQgbWFrZXMgbW9yZSBzZW5zZSB0byBtZSB0byBoYXZlIHRoZSBhdXRoIHNlcnZlciBkaWN0YXRl IHRvIHRoZSBjbGllbnQNCndoZXRoZXIgc2lnbmluZyBpcyByZXF1aXJlZC4gVGhlIGF1dGggc2Vy dmVyIGNvdWxkIGRlY2lkZSB0aGF0IGJhc2VkIG9uIHdobw0KdGhlIGNsaWVudCBpcyBmb3IgZXhh bXBsZS4gV2hhdCB3ZXJlIHRoZSB1c2UgY2FzZXMgb3IgcmF0aW9uYWxlIGZvciBoYXZpbmcNCml0 IHRoZSBvdGhlciB3YXkgYXJvdW5kPw0KDQpJZiBkaWN0YXRlZCBieSB0aGUgc2VydmVyLCB0aGVu IEphbWVzIHN1Z2dlc3Rpb24gZm9yIGFsdGVyaW5nIHRoZSB0b2tlbg0KcmVzcG9uc2UgaXMgYSBn b29kIHN1Z2dlc3Rpb24NCg0KDQpNYXJrIE1jR2xvaW4NCg0KPiBPbiAzMS8wNS8yMDEwIDA2OjU4 ICBKYW1lcyBNYW5nZXIgd3JvdGUNCg0KPj4uLi4gd2UncmUgZ29pbmcgdG8gaGF2ZSB0byBzcGxp dCBvdXQgcHJvZmlsZXMgdG8gZGVhbCB3aXRoIHRoZQ0KPj4gZGlmZmVyZW50IGtleSBkaXN0cmli dXRpb24gY2hhbGxlbmdlcy4NCg0KPkluc3RlYWQgb2Ygc3RhcnRpbmcgd2l0aCBwcm9maWxlcywg SSB0aGluayBhIGtleSB0byBhZGRyZXNzaW5nIHRoaXMgaXNzdWUNCmlzIHRvIG1ha2UgdGhlIHRv a2VuIHJlc3BvbnNlIGZvcm1hdCByaWNoZXIuIEl0IHNob3VsZCB0ZWxsIHRoZSBjbGllbnQgPmFw cA0KYWxsIGl0IG5lZWRzIHRvIGtub3cgdG8gYXV0aGVudGljYXRlIGl0cyBjYWxscyB0byBwcm90 ZWN0ZWQgcmVzb3VyY2VzLiBGcm9tDQphIHRva2VuIHJlc3BvbnNlLCBhIGNsaWVudCBhcHAgc2hv dWxkIGtub3cgdGhpcyBwYXJ0aWN1bGFyIHNlcnZpY2VzDQo+cmVxdWlyZW1lbnRzOiBiZWFyZXIg dG9rZW4gLyBjbGllbnQgc2VjcmV0IC8gdG9rZW4gc2VjcmV0OyBzaGFyZWQgc2VjcmV0IC8NCnB1 YmxpYyBrZXk7IHNob3J0LXRlcm0gLyBwZXJtYW5lbnQ7IC4uLi4NCg0KPk15IG1lbnRhbCBtb2Rl bCBvZiB0aGUgdG9rZW4gcmVzcG9uc2UgaGFzIGl0IHBlcmZvcm1pbmcgdHdvIHRhc2tzOg0KPjEu IEluZGljYXRpbmcgaG93IHRvIGF1dGhlbnRpY2F0ZSByZXF1ZXN0cyB0byBwcm90ZWN0ZWQgcmVz b3VyY2VzIC0tIG11Y2gNCmxpa2UgYSBXV1ctQXV0aGVudGljYXRlIHJlc3BvbnNlIGhlYWRlciBm b3IgYSAibm9ybWFsIiBhdXRoZW50aWNhdGlvbg0KPnNjaGVtZSAod2l0aG91dCB1c2VyIGRlbGVn YXRpb24pLg0KPjIuIFByb3ZpZGUgYWxsIG9yIHNvbWUgb2YgdGhlIHZhbHVlcyBuZWNlc3Nhcnkg dG8gbWFrZSB0aG9zZSBhdXRoZW50aWNhdGVkDQpyZXF1ZXN0cy4NCg0KPlRoZSB0b2tlbiByZXNw b25zZSBzaG91bGQgaW5jbHVkZSB0aGUgbmFtZSBvZiB0aGUgSFRUUCBhdXRoZW50aWNhdGlvbg0K c2NoZW1lIHRoYXQgd2lsbCBiZSB1c2VkIHRvIGFjY2VzcyBwcm90ZWN0ZWQgcmVzb3VyY2VzLg0K PkV4YW1wbGU6IHsgInNjaGVtZSI6IkJBU0lDIiAuLi59IG9yIHsic2NoZW1lIjoiVG9rZW4iIC4u Ln0NCg0KPkl0IG1ha2VzIGl0IGZhaXJseSBvYnZpb3VzIGhvdyB0byBpbnRlZ3JhdGUgb3RoZXIg YXV0aCBzY2hlbWVzIHdpdGggT0F1dGg6DQpqdXN0IGluY2x1ZGUgdGhlIHBhcmFtZXRlcnMgZnJv bSB0aGF0IHNjaGVtZeKAmXMgV1dXLUF1dGhlbnRpY2F0ZSBoZWFkZXIgPmluDQphIHRva2VuIHJl c3BvbnNlLg0KDQoNCj5JIHF1aXRlIGxpa2UgdGhlIGlkZWEgb2YgaW5kaWNhdGluZyB3aGV0aGVy IHN1YnNlcXVlbnQgcmVxdWVzdHMgYXJlIHNpZ25lZA0Kd2l0aCB0aGUgY2xpZW504oCZcyBzZWNy ZXQgb3IgYSB0b2tlbiBzZWNyZXQgYnkgc2ltcGx5IG9taXR0aW5nIG9yID5pbmNsdWRpbmcNCnN1 Y2ggYSBzZWNyZXQgaW4gdGhlIHRva2VuIHJlc3BvbnNlLg0KPltUaGlzIGRvZXMgYXNzdW1lIHRo YXQga25vd2luZyB0aGUgInNjaGVtZSIgaXMgc3VmZmljaWVudCB0byBkZXRlcm1pbmUgaWYNCmEg c2VjcmV0IGlzIHJlcXVpcmVkLCB3aGljaCBpcyBvbmUgbW9yZSByZWFzb24gd2h5IHJldXNpbmcg IlRva2VuIiBmb3INCj5iZWFyZXIsIE1BQyBhbmQgcHVibGljLWtleSBvcGVyYXRpb25zIGlzIGEg cG9vciBkZXNpZ24uXQ0KPkEgKGxlc3MgZGVzaXJhYmxlKSBhbHRlcm5hdGl2ZSBpcyBhIHNwZWNp ZmljICJjbGllbnRfYXV0aCI6W1RSVUV8RkFMU0VdDQpwYXJhbWV0ZXIgaW4gYSB0b2tlbiByZXNw b25zZS4NCg0KLS0NCkphbWVzIE1hbmdlcg0KDQoNCg0K From jricher@mitre.org Tue Jun 1 06:33:49 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 132293A68BF for ; Tue, 1 Jun 2010 06:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sjHxpB9kDYm3 for ; Tue, 1 Jun 2010 06:33:48 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 0F7413A6A11 for ; Tue, 1 Jun 2010 06:33:44 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o51DXVlf026953 for ; Tue, 1 Jun 2010 09:33:33 -0400 Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o51DXVBa026946; Tue, 1 Jun 2010 09:33:31 -0400 Received: from IMCMBX3.MITRE.ORG ([129.83.29.210]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Tue, 1 Jun 2010 09:33:31 -0400 From: "Richer, Justin P." To: William Mills , Eran Hammer-Lahav , Brian Eaton , "fielding@gbiv.com" Date: Tue, 1 Jun 2010 09:30:24 -0400 Thread-Topic: [OAUTH-WG] FW: Duplicating request component in an HTTP authentication scheme Thread-Index: Acr+BBuR0Dzqy8pmQGiubSLzImlEzAADj+7AABuiNoAAw2zInw== Message-ID: References: <90C41DD21FB7C64BB94121FBBC2E72343B3CC0C4DD@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3CC0C508@P3PW5EX1MB01.EX1.SECURESERVER.NET>, <012AB2B223CB3F4BB846962876F47217057953CE@SNV-EXVS08.ds.corp.yahoo.com> In-Reply-To: <012AB2B223CB3F4BB846962876F47217057953CE@SNV-EXVS08.ds.corp.yahoo.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] FW: Duplicating request component in an HTTP authentication scheme X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2010 13:33:49 -0000 What I like about Brian's solution (a lot) is that you can at least see wha= t the heck the client thought it was doing. When you're inside of a framewo= rk, your URL may get all kinds of munched up but you can usually tell if an= incoming one makes sense to you in your framework-specific validation code= . IE, "check all my inputs and see if they're someplace on that client url"= . Brian's approach makes checking that the signature is valid a separate ta= sk from checking that the url is valid, and I like that separation. Yes, th= ey are related from a security standpoint as has been discussed here (other= wise, what do you care what you're signing?), but I'm all for a security se= tup with a bit less voodoo than 1.0 had.=20 -- justin ________________________________________ From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of William = Mills [wmills@yahoo-inc.com] Sent: Friday, May 28, 2010 12:21 PM To: Eran Hammer-Lahav; Brian Eaton; fielding@gbiv.com Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] FW: Duplicating request component in an HTTP aut= hentication scheme I thought one of the fundamental ugly problems is that the client doesn't actually know the full URL authoritatively in all frameworks, because variables get appended to the query string in an unknown order in some cases? Solving that problem seems key. Oauth 1.0 had one solution, which it turns out people tend to get wrong. Brian's proposal solves it a different way with the problem that it makes for data duplication with those associated risks/problems. What other options do we have? > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] > On Behalf Of Eran Hammer-Lahav > Sent: Thursday, May 27, 2010 8:04 PM > To: Brian Eaton; fielding@gbiv.com > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] FW: Duplicating request component in > an HTTP authentication scheme > > > > > -----Original Message----- > > From: Brian Eaton [mailto:beaton@google.com] > > Sent: Thursday, May 27, 2010 6:21 PM > > > OAuth 1.0 was unusual in that it required that the server > match a hash > > of the URL, rather than the real URL. It's an extra layer of > > indirection and complexity. It doesn't improve security. > > The current draft signs the real URL. > > 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 igor.faynberg@alcatel-lucent.com Tue Jun 1 06:51:41 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F093E3A6807 for ; Tue, 1 Jun 2010 06:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.755 X-Spam-Level: X-Spam-Status: No, score=-0.755 tagged_above=-999 required=5 tests=[AWL=0.356, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GIn8xvwc1gfq for ; Tue, 1 Jun 2010 06:51:36 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 61D353A6A1A for ; Tue, 1 Jun 2010 06:51:02 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id o51DnTun016627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Jun 2010 08:49:29 -0500 (CDT) Received: from [135.244.8.0] (faynberg.lra.lucent.com [135.244.8.0]) by umail.lucent.com (8.13.8/TPES) with ESMTP id o51DnRsu027955; Tue, 1 Jun 2010 08:49:27 -0500 (CDT) Message-ID: <4C050FE4.4040800@alcatel-lucent.com> Date: Tue, 01 Jun 2010 09:49:24 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Richer, Justin P." References: <90C41DD21FB7C64BB94121FBBC2E72343B3CC0C4DD@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3CC0C508@P3PW5EX1MB01.EX1.SECURESERVER.NET>, <012AB2B223CB3F4BB846962876F47217057953CE@SNV-EXVS08.ds.corp.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "fielding@gbiv.com" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] FW: Duplicating request component in an HTTP authentication scheme X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 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: Tue, 01 Jun 2010 13:51:41 -0000 +1 Igor Richer, Justin P. wrote: > What I like about Brian's solution (a lot) is that you can at least see what the heck the client thought it was doing. When you're inside of a framework, your URL may get all kinds of munched up but you can usually tell if an incoming one makes sense to you in your framework-specific validation code. IE, "check all my inputs and see if they're someplace on that client url". Brian's approach makes checking that the signature is valid a separate task from checking that the url is valid, and I like that separation. Yes, they are related from a security standpoint as has been discussed here (otherwise, what do you care what you're signing?), but I'm all for a security setup with a bit less voodoo than 1.0 had. > > -- justin > > ________________________________________ > From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of William Mills [wmills@yahoo-inc.com] > Sent: Friday, May 28, 2010 12:21 PM > To: Eran Hammer-Lahav; Brian Eaton; fielding@gbiv.com > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] FW: Duplicating request component in an HTTP authentication scheme > > I thought one of the fundamental ugly problems is that the client > doesn't actually know the full URL authoritatively in all frameworks, > because variables get appended to the query string in an unknown order > in some cases? > > Solving that problem seems key. Oauth 1.0 had one solution, which it > turns out people tend to get wrong. Brian's proposal solves it a > different way with the problem that it makes for data duplication with > those associated risks/problems. > > What other options do we have? > > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] >> On Behalf Of Eran Hammer-Lahav >> Sent: Thursday, May 27, 2010 8:04 PM >> To: Brian Eaton; fielding@gbiv.com >> Cc: OAuth WG (oauth@ietf.org) >> Subject: Re: [OAUTH-WG] FW: Duplicating request component in >> an HTTP authentication scheme >> >> >> >> >>> -----Original Message----- >>> From: Brian Eaton [mailto:beaton@google.com] >>> Sent: Thursday, May 27, 2010 6:21 PM >>> >>> OAuth 1.0 was unusual in that it required that the server >>> >> match a hash >> >>> of the URL, rather than the real URL. It's an extra layer of >>> indirection and complexity. It doesn't improve security. >>> >> The current draft signs the real URL. >> >> 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 > From jricher@mitre.org Tue Jun 1 08:37:02 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A21F3A6A43; Tue, 1 Jun 2010 08:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.866 X-Spam-Level: X-Spam-Status: No, score=-4.866 tagged_above=-999 required=5 tests=[AWL=-0.867, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id giRXb-B2Wt+a; Tue, 1 Jun 2010 08:37:01 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 1FA3D3A6A40; Tue, 1 Jun 2010 08:37:01 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o51Fam7s013477; Tue, 1 Jun 2010 11:36:48 -0400 Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o51FamVN013458; Tue, 1 Jun 2010 11:36:48 -0400 Received: from IMCMBX3.MITRE.ORG ([129.83.29.210]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Tue, 1 Jun 2010 11:36:47 -0400 From: "Richer, Justin P." To: Mark Mcgloin , "Manger, James H" Date: Tue, 1 Jun 2010 11:32:29 -0400 Thread-Topic: [OAUTH-WG] proposal for factoring out request signing in OAuth 2 Thread-Index: AcsBZm+c62iQJMsgRm29HorRkHEoDAAOTYfx Message-ID: References: <255B9BB34FB7D647A506DC292726F6E11263BF36FD@WSMSG3153V.srv.dir.telstra.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="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG , "oauth-bounces@ietf.org" Subject: Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 2 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2010 15:37:02 -0000 I was going to bring up this point eventually, too. It seems backwards to m= e that the client should be the only one to dictate what kind of token a fl= ow is for. I get the rationale -- the client knows better what secrets it c= an resaonbly protect, right? But we've heard from plenty of people on the l= ist here that "oh, our servers are only going to use bearer tokens over ssl= " or "we're not going to use bearer tokens for anything". This is really a = server side (AS/PR) decision that so far is being made out-of-band.=20 I'm not sold on the token alteration quite yet though.=20 -- justin ________________________________________ From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Mark Mcg= loin [mark.mcgloin@ie.ibm.com] Sent: Tuesday, June 01, 2010 4:42 AM To: Manger, James H Cc: OAuth WG; oauth-bounces@ietf.org Subject: Re: [OAUTH-WG] proposal for factoring out request signing in OAuth= 2 It makes more sense to me to have the auth server dictate to the client whether signing is required. The auth server could decide that based on who the client is for example. What were the use cases or rationale for having it the other way around? If dictated by the server, then James suggestion for altering the token response is a good suggestion Mark McGloin > On 31/05/2010 06:58 James Manger wrote >>... we're going to have to split out profiles to deal with the >> different key distribution challenges. >Instead of starting with profiles, I think a key to addressing this issue is to make the token response format richer. It should tell the client >app all it needs to know to authenticate its calls to protected resources. From a token response, a client app should know this particular services >requirements: bearer token / client secret / token secret; shared secret / public key; short-term / permanent; .... >My mental model of the token response has it performing two tasks: >1. Indicating how to authenticate requests to protected resources -- much like a WWW-Authenticate response header for a "normal" authentication >scheme (without user delegation). >2. Provide all or some of the values necessary to make those authenticated requests. >The token response should include the name of the HTTP authentication scheme that will be used to access protected resources. >Example: { "scheme":"BASIC" ...} or {"scheme":"Token" ...} >It makes it fairly obvious how to integrate other auth schemes with OAuth: just include the parameters from that scheme=92s WWW-Authenticate header >i= n a token response. >I quite like the idea of indicating whether subsequent requests are signed with the client=92s secret or a token secret by simply omitting or >includi= ng such a secret in the token response. >[This does assume that knowing the "scheme" is sufficient to determine if a secret is required, which is one more reason why reusing "Token" for >bearer, MAC and public-key operations is a poor design.] >A (less desirable) alternative is a specific "client_auth":[TRUE|FALSE] parameter in a token response. -- James Manger _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth= From beaton@google.com Tue Jun 1 09:49:30 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 245B73A68C7 for ; Tue, 1 Jun 2010 09:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.818 X-Spam-Level: X-Spam-Status: No, score=-103.818 tagged_above=-999 required=5 tests=[AWL=-0.255, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dgw0nIq6+HHm for ; Tue, 1 Jun 2010 09:49:26 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id DF4CF3A6804 for ; Tue, 1 Jun 2010 09:49:24 -0700 (PDT) Received: from hpaq7.eem.corp.google.com (hpaq7.eem.corp.google.com [172.25.149.7]) by smtp-out.google.com with ESMTP id o51Gn7lt028987 for ; Tue, 1 Jun 2010 09:49:07 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1275410948; bh=WxfMncoROPTo6PazyV7+5AsTJ4Y=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=dQ74eeVl8/lXkh03bubPOmaikrfHCrXivov9W57QRfBYEABRe+ZIRFKwq3lz9FdyI whCAfcKgMRwMdIzYdeepA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=oKyDeJyholaj33yEteg/V6GXLb0ufF4mW9ajEXpOHiGgId1vwtrqWmgjeM+28rFlG ffFIQe/O3TFRFGSP2yS/g== Received: from pva4 (pva4.prod.google.com [10.241.209.4]) by hpaq7.eem.corp.google.com with ESMTP id o51Gmpil023841 for ; Tue, 1 Jun 2010 09:48:55 -0700 Received: by pva4 with SMTP id 4so836709pva.30 for ; Tue, 01 Jun 2010 09:48:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.249.19 with SMTP id w19mr4435602wfh.175.1275410931554; Tue, 01 Jun 2010 09:48:51 -0700 (PDT) Received: by 10.142.207.21 with HTTP; Tue, 1 Jun 2010 09:48:51 -0700 (PDT) In-Reply-To: References: Date: Tue, 1 Jun 2010 09:48:51 -0700 Message-ID: From: Brian Eaton To: Dick Hardt Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Should replay of access token request be allowed? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2010 16:49:30 -0000 On Sun, May 30, 2010 at 9:47 AM, Dick Hardt wrote: > I think so. In WRAP the verification code was RECOMMENDED one time use. Yep. Servers must enforce time-limits on verification codes. Servers may make verification codes single use tokens. Clients must not attempt to redeem a verification code more than once. From torsten@lodderstedt.net Tue Jun 1 11:46:41 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0980E3A68E9 for ; Tue, 1 Jun 2010 11:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.452 X-Spam-Level: X-Spam-Status: No, score=0.452 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hbFU2rhOQmD9 for ; Tue, 1 Jun 2010 11:46:40 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.40]) by core3.amsl.com (Postfix) with ESMTP id CC9083A680A for ; Tue, 1 Jun 2010 11:46:34 -0700 (PDT) Received: from p4fff229f.dip.t-dialin.net ([79.255.34.159] helo=[127.0.0.1]) by smtprelay02.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OJWTl-0004cR-8R for oauth@ietf.org; Tue, 01 Jun 2010 20:46:21 +0200 Message-ID: <4C05557C.6060201@lodderstedt.net> Date: Tue, 01 Jun 2010 20:46:20 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "OAuth WG (oauth@ietf.org)" References: <4C028AC7.5020102@lodderstedt.net> In-Reply-To: <4C028AC7.5020102@lodderstedt.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Subject: Re: [OAUTH-WG] Questions about scopes (section 6.1) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2010 18:46:41 -0000 Is there anyone who can answer my questions? Am 30.05.2010 17:56, schrieb Torsten Lodderstedt: > I have some questions regarding the WWW-Authenticate header's "scope" > attribute. > > The spec states > > "The "scope" attribute is a space-delimited list of URIs (relative or > absolute) indicating the required scope of the access token for > accessing the requested resource." > > Which of the scope URIs are required for accessing the resource > server, at least one or all of them? > > How is an interoperable OAuth2 client supposed to use this atttribute? > Shall the client copy the content into the scope parameter of a > subsequent authorization request? > > What is the envisioned behavior if a client seeks for access > authorization to different resources, which happen to rely on the same > authorization server? Is the client allowed to combine the scope > attributes from the WWW-Authenticate header of both resources in a > single authorization flow? This would allow the client to obtain > authorization with a single flow. From my point of view, reducing the > number of authorization flows would improve user experience. > > How is as equivalence of authorization servers determined (token-uri, > user-uri, both)? > > regards, > Torsten. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From stpeter@stpeter.im Tue Jun 1 11:47:55 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FB353A6A43 for ; Tue, 1 Jun 2010 11:47:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.601 X-Spam-Level: X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[AWL=0.509, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RrxeUQ925BDB for ; Tue, 1 Jun 2010 11:47:50 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 08CC328C0FF for ; Tue, 1 Jun 2010 11:47:46 -0700 (PDT) Received: from dhcp-64-101-72-121.cisco.com (dhcp-64-101-72-121.cisco.com [64.101.72.121]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 14F83403F3; Tue, 1 Jun 2010 12:47:30 -0600 (MDT) Message-ID: <4C0555C2.4090004@stpeter.im> Date: Tue, 01 Jun 2010 12:47:30 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Torsten Lodderstedt References: <4C028AC7.5020102@lodderstedt.net> <4C05557C.6060201@lodderstedt.net> In-Reply-To: <4C05557C.6060201@lodderstedt.net> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050401010502080107070005" Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Questions about scopes (section 6.1) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2010 18:47:55 -0000 This is a cryptographically signed message in MIME format. --------------ms050401010502080107070005 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable We discussed this a bit at the interim meeting, but I don't think we came to any consensus. On 6/1/10 12:46 PM, Torsten Lodderstedt wrote: > Is there anyone who can answer my questions? >=20 > Am 30.05.2010 17:56, schrieb Torsten Lodderstedt: >> I have some questions regarding the WWW-Authenticate header's "scope" >> attribute. >> >> The spec states >> >> "The "scope" attribute is a space-delimited list of URIs (relative or >> absolute) indicating the required scope of the access token for >> accessing the requested resource." >> >> Which of the scope URIs are required for accessing the resource >> server, at least one or all of them? >> >> How is an interoperable OAuth2 client supposed to use this atttribute?= >> Shall the client copy the content into the scope parameter of a >> subsequent authorization request? >> >> What is the envisioned behavior if a client seeks for access >> authorization to different resources, which happen to rely on the same= >> authorization server? Is the client allowed to combine the scope >> attributes from the WWW-Authenticate header of both resources in a >> single authorization flow? This would allow the client to obtain >> authorization with a single flow. From my point of view, reducing the >> number of authorization flows would improve user experience. >> >> How is as equivalence of authorization servers determined (token-uri, >> user-uri, both)? >> >> regards, --------------ms050401010502080107070005 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDYwMTE4NDczMFowIwYJKoZIhvcNAQkEMRYEFMhE0HgHge/qcxSqS+eo cHQOHDAWMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAEvfx4V2zOHeto4xCeY4bxf2SG3Ti+Pai33R3SPjb dUkXUdFrNFDERi159v/8fyMflUHvZP2yJtTESgQ3tyeMR24pTrPwusArcGJeo5w+C5aG01Ia b3IFHMwJWZt6fGYzxK+LA7CiXeux50n0YmbNPiXNcuDZxAGbQlUonnyk2VU/GKvK5fmPwH0a 9WNnW5MsuHtW7XwXikDoeK4sqwSLK3RwEQG6W88C6/MDTZElfWu3suxYiw4JkijNPkXJhslC 2a8rUt6y0imfNy7u1QCVr7HjlK2LR27o0WWa8e65FopuXVBOtW7x6Z6Oi3pqfHFzN7TrteGl fpmnseZU01h21AAAAAAAAA== --------------ms050401010502080107070005-- From torsten@lodderstedt.net Tue Jun 1 12:20:41 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA34F28C104 for ; Tue, 1 Jun 2010 12:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.441 X-Spam-Level: X-Spam-Status: No, score=0.441 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H+8nu1ZrLq5A for ; Tue, 1 Jun 2010 12:20:41 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.29.7]) by core3.amsl.com (Postfix) with ESMTP id 0C5B328C0FF for ; Tue, 1 Jun 2010 12:20:40 -0700 (PDT) Received: from p4fff229f.dip.t-dialin.net ([79.255.34.159] helo=[127.0.0.1]) by smtprelay03.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OJX0l-0002zc-FR; Tue, 01 Jun 2010 21:20:27 +0200 Message-ID: <4C055D77.3040400@lodderstedt.net> Date: Tue, 01 Jun 2010 21:20:23 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Peter Saint-Andre References: <4C028AC7.5020102@lodderstedt.net> <4C05557C.6060201@lodderstedt.net> <4C0555C2.4090004@stpeter.im> In-Reply-To: <4C0555C2.4090004@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Questions about scopes (section 6.1) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2010 19:20:42 -0000 is there a protocol of the interim meeting? Am 01.06.2010 20:47, schrieb Peter Saint-Andre: > We discussed this a bit at the interim meeting, but I don't think we > came to any consensus. > > On 6/1/10 12:46 PM, Torsten Lodderstedt wrote: > >> Is there anyone who can answer my questions? >> >> Am 30.05.2010 17:56, schrieb Torsten Lodderstedt: >> >>> I have some questions regarding the WWW-Authenticate header's "scope" >>> attribute. >>> >>> The spec states >>> >>> "The "scope" attribute is a space-delimited list of URIs (relative or >>> absolute) indicating the required scope of the access token for >>> accessing the requested resource." >>> >>> Which of the scope URIs are required for accessing the resource >>> server, at least one or all of them? >>> >>> How is an interoperable OAuth2 client supposed to use this atttribute? >>> Shall the client copy the content into the scope parameter of a >>> subsequent authorization request? >>> >>> What is the envisioned behavior if a client seeks for access >>> authorization to different resources, which happen to rely on the same >>> authorization server? Is the client allowed to combine the scope >>> attributes from the WWW-Authenticate header of both resources in a >>> single authorization flow? This would allow the client to obtain >>> authorization with a single flow. From my point of view, reducing the >>> number of authorization flows would improve user experience. >>> >>> How is as equivalence of authorization servers determined (token-uri, >>> user-uri, both)? >>> >>> regards, >>> > From stpeter@stpeter.im Tue Jun 1 12:29:38 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01D003A6A48 for ; Tue, 1 Jun 2010 12:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.515 X-Spam-Level: X-Spam-Status: No, score=-1.515 tagged_above=-999 required=5 tests=[AWL=1.084, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uxlIQkvFvljf for ; Tue, 1 Jun 2010 12:29:34 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 61BE43A68D8 for ; Tue, 1 Jun 2010 12:29:34 -0700 (PDT) Received: from dhcp-64-101-72-121.cisco.com (dhcp-64-101-72-121.cisco.com [64.101.72.121]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id EDD8B403F3; Tue, 1 Jun 2010 13:29:21 -0600 (MDT) Message-ID: <4C055F90.8050804@stpeter.im> Date: Tue, 01 Jun 2010 13:29:20 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Torsten Lodderstedt References: <4C028AC7.5020102@lodderstedt.net> <4C05557C.6060201@lodderstedt.net> <4C0555C2.4090004@stpeter.im> <4C055D77.3040400@lodderstedt.net> In-Reply-To: <4C055D77.3040400@lodderstedt.net> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090408050200040803030706" Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Questions about scopes (section 6.1) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2010 19:29:38 -0000 This is a cryptographically signed message in MIME format. --------------ms090408050200040803030706 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Do you mean minutes? The chairs are working on that, AFAIK. /psa On 6/1/10 1:20 PM, Torsten Lodderstedt wrote: > is there a protocol of the interim meeting? >=20 > Am 01.06.2010 20:47, schrieb Peter Saint-Andre: >> We discussed this a bit at the interim meeting, but I don't think we >> came to any consensus. >> >> On 6/1/10 12:46 PM, Torsten Lodderstedt wrote: >> =20 >>> Is there anyone who can answer my questions? >>> >>> Am 30.05.2010 17:56, schrieb Torsten Lodderstedt: >>> =20 >>>> I have some questions regarding the WWW-Authenticate header's "scope= " >>>> attribute. >>>> >>>> The spec states >>>> >>>> "The "scope" attribute is a space-delimited list of URIs (relative o= r >>>> absolute) indicating the required scope of the access token for >>>> accessing the requested resource." >>>> >>>> Which of the scope URIs are required for accessing the resource >>>> server, at least one or all of them? >>>> >>>> How is an interoperable OAuth2 client supposed to use this atttribut= e? >>>> Shall the client copy the content into the scope parameter of a >>>> subsequent authorization request? >>>> >>>> What is the envisioned behavior if a client seeks for access >>>> authorization to different resources, which happen to rely on the sa= me >>>> authorization server? Is the client allowed to combine the scope >>>> attributes from the WWW-Authenticate header of both resources in a >>>> single authorization flow? This would allow the client to obtain >>>> authorization with a single flow. From my point of view, reducing th= e >>>> number of authorization flows would improve user experience. >>>> >>>> How is as equivalence of authorization servers determined (token-uri= , >>>> user-uri, both)? >>>> >>>> regards, >>>> =20 >> =20 >=20 --------------ms090408050200040803030706 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDYwMTE5MjkyMFowIwYJKoZIhvcNAQkEMRYEFPki2KgdZ7UC0ur3ikyq knvgmV38MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEANlE9jiOEzcvVrd7Q9iTTgOBnQYZaMN1hQ+PiaX0N TQ8YHi4zzjCQ8KZ7h0jECpFBHIJvBGcKYtnMrBLTASr7b18Vye0b9+SffgKmGkcOuX29OJ6F cpHZqw2oggl+rq9Ui3rDewKNiD0j62qrkb5XrGr/LuPHHa973n4vjAaaZEx4uQrhq3ldjVNm SXv5Bj6lKGBT7Ua7SOreit0NNqAC5Q+P5fM5EiwblBcLUYHg7V/jOrp3wkrvgRZn10naq112 v1aE35C+UfQYOIVrsljCHrhuQdNTJjgHNldJmvsD6DAsfCmwq8RzDiJUqaIK76H4erTfXKgi uxQEETkgk35VHwAAAAAAAA== --------------ms090408050200040803030706-- From lshepard@facebook.com Tue Jun 1 13:47:02 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A34F3A6845 for ; Tue, 1 Jun 2010 13:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.098 X-Spam-Level: X-Spam-Status: No, score=-1.098 tagged_above=-999 required=5 tests=[AWL=-0.433, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4dJkcfrbMV70 for ; Tue, 1 Jun 2010 13:47:01 -0700 (PDT) Received: from mailout-snc1.facebook.com (mailout-snc1.facebook.com [69.63.179.25]) by core3.amsl.com (Postfix) with ESMTP id 220A828C114 for ; Tue, 1 Jun 2010 13:47:00 -0700 (PDT) Received: from mail.thefacebook.com ([192.168.18.105]) by pp01.snc1.tfbnw.net (8.14.3/8.14.3) with ESMTP id o51KkPdB027595 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 1 Jun 2010 13:46:25 -0700 Received: from SC-MBXC1.TheFacebook.com ([192.168.18.102]) by sc-hub02.TheFacebook.com ([192.168.18.105]) with mapi; Tue, 1 Jun 2010 13:46:45 -0700 From: Luke Shepard To: Murali VP Date: Tue, 1 Jun 2010 13:46:55 -0700 Thread-Topic: [OAUTH-WG] user agent flow Thread-Index: AcsBy4woO000EDPFQgCEvHjSN2/new== Message-ID: <4EA2408F-CA08-401A-B46C-FE91AD330A05@facebook.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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-06-01_02:2010-02-06, 2010-06-01, 2010-06-01 signatures=0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] user agent flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2010 20:47:02 -0000 Inline. On May 28, 2010, at 9:29 AM, Murali VP wrote: > OAuth 2.0 authors or anyone with authority on the draft, would appreciate= some response to the below items. >=20 > 3.5. User-Agent Flow >=20 > 1. It is not clear from the draft how a user agent flow would refresh > an access token. There are still some discussions about the best way to get a refresh token = from the user-agent flow. Currently it is just passed back, and then it is = up to the user-agent to pass it securely to the server. My preference is to= pass back a verification code and require the user to get it. The refresh = token would be used by the server to maintain long-lived access after the u= ser has stopped using the app. > As per section 4, client does a HTTP(S) POST to > authorization server which seems to return a 200 to user-agent if the > request was successful leaving the user-agent in authorization > server's domain with a JSON response data! If user-agent flow cannot > refresh access token, why did it send the refresh_token in the first > place in the fragment? If you are refreshing from within the user agent, the preferred method woul= d be to make an "immediate" request and get a new token that way. >=20 > 2. The draft doesn't seem to mention how a client in the user-agent > can make protected resource requests given that such requests would be > cross domain. The only viable option seems to be JSONP requests (eg. > Facebook). The specification should include some material describing > protected resource requests in the user-agent flow case. JSONP is the simplest cross domain technique, but there are others - for ex= ample, Flash, PostMessage, or using a fragment. The techniques vary based o= n browser and circumstance and they are outside the scope of the spec. I think the best supplemental material will come in the form of well-commen= ted libraries that implement the requests (for example, see http://github.c= om/facebook/connect-js/blob/master/src/core/api.js#L304 ) From dick.hardt@gmail.com Tue Jun 1 14:16:24 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B78CF28C1BB for ; Tue, 1 Jun 2010 14:16:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.391 X-Spam-Level: X-Spam-Status: No, score=-1.391 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NebyxFFNgrdU for ; Tue, 1 Jun 2010 14:16:19 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id 1C0363A6845 for ; Tue, 1 Jun 2010 14:16:15 -0700 (PDT) Received: by pxi19 with SMTP id 19so2452578pxi.31 for ; Tue, 01 Jun 2010 14:16:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=b/qeSpLRXgiR8iZmmaY5N6KQYf5/aeVYYiXV8L2GPUE=; b=JuiCVKjfrxhNpCOCiu0rUZqpmqK4W+78aBwOLuvUVbINl7IxMqynNzFXrUS5jX0p1w GVEzwm37x5fNpcq/1duWqOTxZD85uYxAtYPQ+LIJ+kJlzom7CumSNscs7vbS50V/PF+2 SlluBsxuF/83koVplM/anUrGr759NPk+6vKis= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ERXED1hOkV5Fd2k4rLHzhs7xETLAGdQCz8FMfijSGkdaZaIAQyhgrlpx1QAMzkmNAc Mnmc06UgwS2CVJnhGCv8zNfcPHeMktQEK8DymDCZvd+Qz2v45g54zi8atxXxv4xkr7u5 24eCiBy53slH7W8w37FPiOLAn5IznOfo14TEE= MIME-Version: 1.0 Received: by 10.141.89.8 with SMTP id r8mr5274806rvl.32.1275426960633; Tue, 01 Jun 2010 14:16:00 -0700 (PDT) Received: by 10.143.167.14 with HTTP; Tue, 1 Jun 2010 14:16:00 -0700 (PDT) In-Reply-To: <4C0555C2.4090004@stpeter.im> References: <4C028AC7.5020102@lodderstedt.net> <4C05557C.6060201@lodderstedt.net> <4C0555C2.4090004@stpeter.im> Date: Tue, 1 Jun 2010 14:16:00 -0700 Message-ID: From: Dick Hardt To: Peter Saint-Andre Content-Type: multipart/alternative; boundary=000e0cd138e0ecf0e20487fe7a53 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Questions about scopes (section 6.1) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2010 21:16:24 -0000 --000e0cd138e0ecf0e20487fe7a53 Content-Type: text/plain; charset=ISO-8859-1 I don't recall any discussion at the level of detail that Torsten is asking about. My inclination would be the Client would include the what was returned in WWW-Authenticate in the access request call. On Tue, Jun 1, 2010 at 11:47 AM, Peter Saint-Andre wrote: > We discussed this a bit at the interim meeting, but I don't think we > came to any consensus. > > On 6/1/10 12:46 PM, Torsten Lodderstedt wrote: > > Is there anyone who can answer my questions? > > > > Am 30.05.2010 17:56, schrieb Torsten Lodderstedt: > >> I have some questions regarding the WWW-Authenticate header's "scope" > >> attribute. > >> > >> The spec states > >> > >> "The "scope" attribute is a space-delimited list of URIs (relative or > >> absolute) indicating the required scope of the access token for > >> accessing the requested resource." > >> > >> Which of the scope URIs are required for accessing the resource > >> server, at least one or all of them? > >> > >> How is an interoperable OAuth2 client supposed to use this atttribute? > >> Shall the client copy the content into the scope parameter of a > >> subsequent authorization request? > >> > >> What is the envisioned behavior if a client seeks for access > >> authorization to different resources, which happen to rely on the same > >> authorization server? Is the client allowed to combine the scope > >> attributes from the WWW-Authenticate header of both resources in a > >> single authorization flow? This would allow the client to obtain > >> authorization with a single flow. From my point of view, reducing the > >> number of authorization flows would improve user experience. > >> > >> How is as equivalence of authorization servers determined (token-uri, > >> user-uri, both)? > >> > >> regards, > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --000e0cd138e0ecf0e20487fe7a53 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I don't recall any discussion at the level of detail that Torsten is as= king about.

My inclination would be the Client would inc= lude the what was returned in WWW-Authenticate in the access request call.<= br>
On Tue, Jun 1, 2010 at 11:47 AM, Peter Saint= -Andre <stpeter@= stpeter.im> wrote:
We discussed this a bit at the interim meeting, but I don't think we came to any consensus.

On 6/1/10 12:46 PM, Torsten Lodderstedt wrote:
> Is there anyone who can answer my questions?
>
> Am 30.05.2010 17:56, schrieb Torsten Lodderstedt:
>> I have some questions regarding the WWW-Authenticate header's = "scope"
>> attribute.
>>
>> The spec states
>>
>> "The "scope" attribute is a space-delimited list of= URIs (relative or
>> =A0 =A0absolute) indicating the required scope of the access token= for
>> =A0 =A0accessing the requested resource."
>>
>> Which of the scope URIs are required for accessing the resource >> server, at least one or all of them?
>>
>> How is an interoperable OAuth2 client supposed to use this atttrib= ute?
>> Shall the client copy the content into the scope parameter of a >> subsequent authorization request?
>>
>> What is the envisioned behavior if a client seeks for access
>> authorization to different resources, which happen to rely on the = same
>> authorization server? Is the client allowed to combine the scope >> attributes from the WWW-Authenticate header of both resources in a=
>> single authorization flow? This would allow the client to obtain >> authorization with a single flow. From my point of view, reducing = the
>> number of authorization flows would improve user experience.
>>
>> How is as equivalence of authorization servers determined (token-u= ri,
>> user-uri, both)?
>>
>> regards,


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


--000e0cd138e0ecf0e20487fe7a53-- From James.H.Manger@team.telstra.com Tue Jun 1 17:55:46 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE4233A690F for ; Tue, 1 Jun 2010 17:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.728 X-Spam-Level: * X-Spam-Status: No, score=1.728 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_50=0.001, FU_ENDS_2_WRDS=0.255, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ryedFtr2Ort3 for ; Tue, 1 Jun 2010 17:55:45 -0700 (PDT) Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by core3.amsl.com (Postfix) with ESMTP id 823F53A690D for ; Tue, 1 Jun 2010 17:55:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,343,1272808800"; d="scan'208";a="4637195" Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipoani.tcif.telstra.com.au with ESMTP; 02 Jun 2010 10:55:31 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6000"; a="2757797" Received: from wsmsg3754.srv.dir.telstra.com ([172.49.40.198]) by ipcbni.tcif.telstra.com.au with ESMTP; 02 Jun 2010 10:55:32 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3754.srv.dir.telstra.com ([172.49.40.198]) with mapi; Wed, 2 Jun 2010 10:55:32 +1000 From: "Manger, James H" To: Torsten Lodderstedt , "OAuth WG (oauth@ietf.org)" Date: Wed, 2 Jun 2010 10:55:30 +1000 Thread-Topic: [OAUTH-WG] Questions about scopes (section 6.1) Thread-Index: AcsBusL9WedgAvzgSv+k5Nkif8YvogAKl2yg Message-ID: <255B9BB34FB7D647A506DC292726F6E11263CF6E6B@WSMSG3153V.srv.dir.telstra.com> References: <4C028AC7.5020102@lodderstedt.net> <4C05557C.6060201@lodderstedt.net> In-Reply-To: <4C05557C.6060201@lodderstedt.net> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Questions about scopes (section 6.1) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2010 00:55:46 -0000 J3Njb3BlJyBzaG91bGRuJ3QgYmUgZGVmaW5lZCBhcyBhIDxVUkktUmVmZXJlbmNlPiAoYXMgaXQg aXMgaW4gc2VjdGlvbiA2LjEgV1dXLUF1dGggaGVhZGVyKS4gVGhhdCBpbXBsaWVzIHR3byAnc2Nv cGUnIHZhbHVlcyBzaG91bGQgYmUgY29tcGFyZWQgYXMgVVJJcyAtLSBieSBzZWVpbmcgaWYgdGhl eSBpZGVudGlmeSB0aGUgc2FtZSByZXNvdXJjZSAoaWUgcmVzb2x2ZSB0byB0aGUgc2FtZSBhYnNv bHV0ZSBVUkkpLiBJIGRvbid0IHRoaW5rIHRoaXMgd2FzIGludGVuZGVkLg0KDQpGYWNlYm9vaywg Zm9yIGluc3RhbmNlLCBoYXZlIGEgJ3Njb3BlJyBvZiAidXNlcl9waG90b3MiLiBJIGFtIHN1cmUg dGhleSBkb24ndCAoYW5kIHNob3VsZG4ndCBoYXZlIHRvKSBhY2NlcHQgIi4vdXNlcl9waG90b3Mi IG9yICJ1c2VyJTVGcGhvdG9zIiBvciAiaHR0cHM6Ly9ncmFwaC5mYWNlYm9vay5jb20vdXNlcl9w aG90b3MiIGFzIGVxdWl2YWxlbnQuDQoNCklmICdzY29wZScgaW4gYSBXV1ctQXV0aCByZXNwb25z ZSBoZWFkZXIgaXMgYSByZWxhdGl2ZSBVUkkgaXQgaXMgcHJlc3VtYWJseSByZWxhdGl2ZSB0byB0 aGUgcmVxdWVzdGVkIFVSSS4gSGVuY2UsIFdXVy1BdXRoIHJlc3BvbnNlcyBmb3IgcmVxdWVzdHMg dG8gaHR0cHM6Ly9hcGkuZXhhbXBsZS5jb20vMTIzIGFuZCBodHRwczovL2FwaS5leGFtcGxlLmNv bS8xMjMvYWxidW1zIHRoYXQgYm90aCBpbmNsdWRlIHNjb3BlPSJ1c2VyX3Bob3RvcyIgYWN0dWFs bHkgaW5kaWNhdGUgZGlmZmVyZW50IHNjb3Blcy4NCg0KDQpUaGVyZSBpcyBhbHNvIGFuIGltcG9y dGFudCB0eXBvIGluIDYuMTogMSNVUkktUmVmZXJlbmNlIG1lYW5zIGNvbW1hLXNlcGFyYXRlZCB2 YWx1ZXM7IGJ1dCB0aGUgdGV4dCBzYXlzIHNwYWNlLXNlcGFyYXRlZCB2YWx1ZXMuDQoNCg0KU3Vn Z2VzdGVkIHNvbHV0aW9uIDE6DQpSZW1vdmUgdGhlICJzY29wZSIgcGFyYW1ldGVyIGZyb20gdGhl IFdXVy1BdXRoIHJlc3BvbnNlLiBSZW1vdmUgdGhlIEFCTkYgZm9yIDxzY29wZT4gYW5kIHRoZSBw YXJhZ3JhcGggZGVzY3JpYmluZyBpdC4NCltOb3RlOiB0aGUgPHVzZXItdXJpPiBjYW4gc3RpbGwg aW5jbHVkZSBhICdzY29wZScgcXVlcnkgcGFyYW1ldGVyLl0NCg0KDQpTdWdnZXN0ZWQgc29sdXRp b24gMjogKHN1YmplY3QgdG8gZ2V0dGluZyBhIGFuc3dlciB0byBUb3JzdGVuJ3MgcXVlc3Rpb24g YWJvdXQgd2hhdCBhbiBPQXV0aDIgY2xpZW50IGRvZXMgd2l0aCAnc2NvcGUnIGluIFdXVy1BdXRo KQ0KQ2hhbmdlIDxzY29wZT4gdG8gYmUgYSBsaXN0IG9mIHN0cmluZ3MsIG5vdCA8VVJJLVJlZmVy ZW5jZT5zLCBhbmQgYWRqdXN0IHRoZSBwYXJhZ3JhcGggZGVzY3JpYmluZyBpdCBhY2NvcmRpbmds eS4NCg0KICBzY29wZSAgICA9ICJzY29wZSIgIj0iIDwiPiBzY29wZS12ICooIiAiIHNjb3BlLXYp IDwiPg0KICBzY29wZS12ICA9IDEqKHJlc2VydmVkIC8gdW5yZXNlcnZlZCAvIHBjdC1lbmNvZGVk KQ0KDQogVGhlICJzY29wZSIgYXR0cmlidXRlIGlzIGEgbGlzdCBvZiBzcGFjZS1kZWxpbWl0ZWQg c3RyaW5ncyBpbmRpY2F0aW5nIHRoZSByZXF1aXJlZCBzY29wZSBvZiB0aGUgYWNjZXNzIHRva2Vu IGZvciBhY2Nlc3NpbmcgdGhlIHJlcXVlc3RlZCByZXNvdXJjZS4gVGhlIG9yZGVyIG9mIHRoZSBz dHJpbmdzIGluIHRoZSBsaXN0IGRvZXMgbm90IG1hdHRlci4gRWFjaCBzdHJpbmcgY2FuIGNvbnRh aW4gdGhlIGNoYXJhY3RlcnMgYWxsb3dlZCBpbiBhIFVSSSBzbyBhbiBhdXRob3JpemF0aW9uIHNl cnZlciBjYW4gY2hvb3NlIHRvIHVzZSBVUklzIGZvciBzY29wZSBzdHJpbmdzLiBIb3dldmVyLCB0 aGUgc3RyaW5ncyBkbyBub3QgaGF2ZSB0byBiZSBVUklzIHNvIGNsaWVudCBhcHBzIE1VU1QgTk9U IGFzc3VtZSB0aGV5IGFyZSBVUklzLiBJbiBwYXJ0aWN1bGFyLCBpbmRpdmlkdWFsIHN0cmluZyB2 YWx1ZXMgTVVTVCBiZSBjb21wYXJlZCBjaGFyYWN0ZXItZm9yLWNoYXJhY3RlciB3aXRob3V0IGFu eSBVUkkgbm9ybWFsaXphdGlvbi4gQ29uc2VxdWVudGx5LCBhbiBhdXRob3JpemF0aW9uIHNlcnZl ciB0aGF0IGNob29zZXMgdG8gdXNlIFVSSXMgYXMgc2NvcGUgc3RyaW5ncyBuZWVkcyB0byBiZSBj YXJlZnVsIHRvIHVzZSBhIGNvbnNpc3RlbnQgbm9ybWFsaXphdGlvbiBldmVyeXdoZXJlLg0KDQoN Cg0KUC5TLiBUaGUgc3BlYyBkZWZpbmVzICdzY29wZScgaW4gOCBzZXBhcmF0ZSBwbGFjZXM6IDYg ZGVmaW5pdGlvbnMgYXJlIGlkZW50aWNhbDsgMSBpcyBhbG1vc3QgaWRlbnRpY2FsOyBhbmQgdGhl IGxhc3QgKGluIDYuMS4gVGhlIFdXVy1BdXRoZW50aWNhdGUgUmVzcG9uc2UgSGVhZGVyKSBpcyBk aWZmZXJlbnQuDQpXb3VsZG4ndCBpdCBiZSBiZXR0ZXIgdG8gZGVmaW5lIGl0IGp1c3Qgb25jZT8N Cg0KLS0gDQpKYW1lcyBNYW5nZXINCg0K From lisa.dusseault@gmail.com Wed Jun 2 10:32:48 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CF7428C0FE for ; Wed, 2 Jun 2010 10:32:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oFJPlrQwa3Tw for ; Wed, 2 Jun 2010 10:32:46 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id BB1E93A67E9 for ; Wed, 2 Jun 2010 10:32:46 -0700 (PDT) Received: by vws11 with SMTP id 11so2916118vws.31 for ; Wed, 02 Jun 2010 10:32:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=t3X4bBnuglyh+VqfG3NWH+rebmHoI5mbRUrVOz6vWv4=; b=lefQtVZo9GldOpGJ8C86ZbH/2i7faZY/USAm7hRYvhLv/JSfYpg9ByGK8sLNeg8Ok2 +vs/nLImrdmfP7F4BxFWxHx0XJGJDSVQ2+7I/xr28ik39Y5NroTVhN9yuelujIm+gkha 989zD20qkyIKTlV1tdjtwwkiyusDDj28oyyYs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=oCi8Yl5DLFCUFsTGW7DsiSewmDYyrDdV7oBBUWgRSGzWQ44JJnC+CE+tfDq6aD88hE gN1qxzfsJNw/I4OXNOXzDr0STG0JQA4k0y6bFeESaAogKYAzqO1tKG7kRPwseSU3S4m0 cHAaGMSIXZfVOxwaTCzFyvkdXU1qnZnglB10E= MIME-Version: 1.0 Received: by 10.220.124.144 with SMTP id u16mr5889104vcr.108.1275499951462; Wed, 02 Jun 2010 10:32:31 -0700 (PDT) Received: by 10.220.114.200 with HTTP; Wed, 2 Jun 2010 10:32:31 -0700 (PDT) Date: Wed, 2 Jun 2010 10:32:31 -0700 Message-ID: From: Lisa Dusseault To: oauth Content-Type: multipart/alternative; boundary=0016e6d26dc5849d6b04880f79bb Subject: [OAUTH-WG] Assertion flow and token bootstrapping X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2010 17:32:48 -0000 --0016e6d26dc5849d6b04880f79bb Content-Type: text/plain; charset=ISO-8859-1 I've been trying to understand the use case for the assertion flow ( http://tools.ietf.org/html/draft-ietf-oauth-v2-05#section-3.10) . Conversely, I have a use case for bootstrapping, and I'm trying to understand if the assertion flow is the right flow for that use case. The bootstrapping use case I have in mind is to allow a client to interact with a related set of services by bootstrapping from client secret to an access token, and then from that access token to other access tokens. For example, in a "login" interaction the client would get a generic access token. Later, to use various services -- access to personal data, access to friends' data, attempts to do uploads -- the client would ask the security token server for access to new resources by URI, and if access was granted, receive new access tokens which could be used on those services. The client secret is not reused very often, and policy is centralized. This seems similar to other use cases being discussed and so it's possible my main point of confusion is trying to tie this to the assertion flow instead of something else. The assertion flow has the right number of parties involved, and it could certainly be hacked/extended to do bootstrapping: instead of the client secret, the general session access token could be used, and the "assertion" field can contain anything including the URI of the service that the client now wants. However I wondered if something less generic could make this more interoperable. Any thoughts? Thanks, Lisa --0016e6d26dc5849d6b04880f79bb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I've been trying to understand the use case for the assertion flow = (http://tools.ietf.org/html/draft-ietf-oauth-v2-05#section-3.10) .=A0 C= onversely, I have a use case for bootstrapping, and I'm trying to under= stand if the assertion flow is the right flow for that use case.=A0

The bootstrapping use case I have in mind is to allow a client to inter= act with a related set of services by bootstrapping from client secret to a= n access token, and then from that access token to other access tokens.=A0 = For example, in a "login" interaction the client would get a gene= ric access token.=A0 Later, to use various services -- access to personal d= ata, access to friends' data, attempts to do uploads -- the client woul= d ask the security token server for access to new resources by URI, and if = access was granted, receive new access tokens which could be used on those = services.=A0 The client secret is not reused very often, and policy is cent= ralized.=A0

This seems similar to other use cases being discussed and so it's p= ossible my main point of confusion is trying to tie this to the assertion f= low instead of something else.

The assertion flow has the right num= ber of parties involved, and it could certainly be hacked/extended to do bo= otstrapping: instead of the client secret, the general session access token= could be used, and the "assertion" field can contain anything in= cluding the URI of the service that the client now wants.=A0 However I wond= ered if something less generic could make this more interoperable.

Any thoughts?

Thanks,
Lisa
--0016e6d26dc5849d6b04880f79bb-- From hardjono@mit.edu Wed Jun 2 11:57:19 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 513D928C17B for ; Wed, 2 Jun 2010 11:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.449 X-Spam-Level: X-Spam-Status: No, score=-0.449 tagged_above=-999 required=5 tests=[AWL=-0.451, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ByBxnuqQWwvq for ; Wed, 2 Jun 2010 11:57:13 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (DMZ-MAILSEC-SCANNER-2.MIT.EDU [18.9.25.13]) by core3.amsl.com (Postfix) with ESMTP id 90C2128C185 for ; Wed, 2 Jun 2010 11:57:13 -0700 (PDT) X-AuditID: 1209190d-b7bf0ae0000059a7-2b-4c06a97c9949 Received: from mailhub-auth-4.mit.edu (MAILHUB-AUTH-4.MIT.EDU [18.7.62.39]) by dmz-mailsec-scanner-2.mit.edu (Symantec Brightmail Gateway) with SMTP id 98.A4.22951.C79A60C4; Wed, 2 Jun 2010 14:57:00 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-EXCHANGE-2.MIT.EDU [18.9.28.16]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id o52Iv0Jd026777; Wed, 2 Jun 2010 14:57:00 -0400 Received: from w92exedge4.exchange.mit.edu (W92EXEDGE4.EXCHANGE.MIT.EDU [18.7.73.16]) ) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id o52IuxOK019481; Wed, 2 Jun 2010 14:57:00 -0400 Received: from oc11exhub4.exchange.mit.edu (18.9.3.14) by w92exedge4.exchange.mit.edu (18.7.73.16) with Microsoft SMTP Server (TLS) id 8.1.393.1; Wed, 2 Jun 2010 14:56:38 -0400 Received: from EXPO10.exchange.mit.edu ([18.9.4.15]) by oc11exhub4.exchange.mit.edu ([18.9.3.14]) with mapi; Wed, 2 Jun 2010 14:56:59 -0400 From: Thomas Hardjono To: Lisa Dusseault , oauth Date: Wed, 2 Jun 2010 14:56:56 -0400 Thread-Topic: [OAUTH-WG] Assertion flow and token bootstrapping Thread-Index: AcsCeZnu8HuageL1Rg651V/kvG5W5QACiFXQ 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: multipart/alternative; boundary="_000_DADD7EAD88AB484D8CCC328D40214CCD0179258AC0EXPO10exchang_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [OAUTH-WG] Assertion flow and token bootstrapping X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2010 18:57:19 -0000 --_000_DADD7EAD88AB484D8CCC328D40214CCD0179258AC0EXPO10exchang_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Lisa, I'm also looking at the assertion flow right now and wondering if I could use it to "swap" a Kerberos service-ticket for an OAuth Access-Token. In particular, I would like to: (1) Wrap the KRB AP_REQ message within a SAML-assertion (eg. using the existing WSS Token Profile standard), (2) Deliver it using the OAuth assertion flow to a special Kerberized-service (or IdP or OP), who then verifies the Authenticator and Service-Ticket within the AP_REQ message. (3) Obtain in return an OAuth Access-Token with the same lifetimes/expiration as defined in the original service-ticket (in the AP_REQ request). (4) Present the Access-Token to an OAuth Resource Server. (ps. Alternatively, I could use the Kerberos delegation feature but that may be more complicated). I think Section 3.10 needs more fleshing-out. /thomas/ __________________________________________ From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of L= isa Dusseault Sent: Wednesday, June 02, 2010 1:33 PM To: oauth Subject: [OAUTH-WG] Assertion flow and token bootstrapping I've been trying to understand the use case for the assertion flow (http://= tools.ietf.org/html/draft-ietf-oauth-v2-05#section-3.10) . Conversely, I h= ave a use case for bootstrapping, and I'm trying to understand if the asser= tion flow is the right flow for that use case. The bootstrapping use case I have in mind is to allow a client to interact = with a related set of services by bootstrapping from client secret to an ac= cess token, and then from that access token to other access tokens. For ex= ample, in a "login" interaction the client would get a generic access token= . Later, to use various services -- access to personal data, access to fri= ends' data, attempts to do uploads -- the client would ask the security tok= en server for access to new resources by URI, and if access was granted, re= ceive new access tokens which could be used on those services. The client = secret is not reused very often, and policy is centralized. This seems similar to other use cases being discussed and so it's possible = my main point of confusion is trying to tie this to the assertion flow inst= ead of something else. The assertion flow has the right number of parties involved, and it could c= ertainly be hacked/extended to do bootstrapping: instead of the client secr= et, the general session access token could be used, and the "assertion" fie= ld can contain anything including the URI of the service that the client no= w wants. However I wondered if something less generic could make this more= interoperable. Any thoughts? Thanks, Lisa --_000_DADD7EAD88AB484D8CCC328D40214CCD0179258AC0EXPO10exchang_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Lisa,

 

I’m also looking at the assertion flow right now<= /o:p>

and wondering if I could use it to  “swap” = a

Kerberos service-ticket for an OAuth Access-Token.

 

In particular, I would like to:

 

(1) Wrap the KRB AP_REQ message within a SAML-assertion

(eg. using the existing WSS Token Profile standard),

 

(2) Deliver it using the OAuth assertion flow to a special

Kerberized-service (or IdP or OP), who then verifies

the Authenticator and Service-Ticket within

the AP_REQ message.

 

(3) Obtain in return an OAuth Access-Token with

the same lifetimes/expiration as defined in the original

service-ticket (in the AP_REQ request).

 

(4) Present the Access-Token to an OAuth Resource Server.

 

(ps. Alternatively, I could use the Kerberos delegation feat= ure

but that may be more complicated).

 

 

I think Section 3.10 needs more fleshing-out.

 

/thomas/

 

 

__________________________________= ________

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of = Lisa Dusseault
Sent: Wednesday, June 02, 2010 1:33 PM
To: oauth
Subject: [OAUTH-WG] Assertion flow and token bootstrapping

 


I've been trying to understand the use case for the assertion flow (htt= p://tools.ietf.org/html/draft-ietf-oauth-v2-05#section-3.10) .  Conversely, I have a use case for bootstrapping, and I'm trying to understand if the assertion flow is the right flow for that use case. =

The bootstrapping use case I have in mind is to allow a client to interact = with a related set of services by bootstrapping from client secret to an access token, and then from that access token to other access tokens.  For example, in a "login" interaction the client would get a generic access token.  Later, to use various services -- access to personal da= ta, access to friends' data, attempts to do uploads -- the client would ask the security token server for access to new resources by URI, and if access was granted, receive new access tokens which could be used on those services.&n= bsp; The client secret is not reused very often, and policy is centralized. = ;

This seems similar to other use cases being discussed and so it's possible = my main point of confusion is trying to tie this to the assertion flow instead= of something else.

The assertion flow has the right number of parties involved, and it could certainly be hacked/extended to do bootstrapping: instead of the client sec= ret, the general session access token could be used, and the "assertion&quo= t; field can contain anything including the URI of the service that the client= now wants.  However I wondered if something less generic could make this m= ore interoperable.

Any thoughts?

Thanks,
Lisa

--_000_DADD7EAD88AB484D8CCC328D40214CCD0179258AC0EXPO10exchang_-- From davidrecordon@facebook.com Wed Jun 2 14:17:04 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D95B43A685E for ; Wed, 2 Jun 2010 14:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.775 X-Spam-Level: X-Spam-Status: No, score=-1.775 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kh78bnZiu8VN for ; Wed, 2 Jun 2010 14:17:04 -0700 (PDT) Received: from mailout-snc1.facebook.com (mailout-snc1.facebook.com [69.63.179.25]) by core3.amsl.com (Postfix) with ESMTP id F25D03A67FB for ; Wed, 2 Jun 2010 14:17:03 -0700 (PDT) Received: from mail.thefacebook.com ([192.168.18.104]) by pp01.snc1.tfbnw.net (8.14.3/8.14.3) with ESMTP id o52LGSKs005344 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 2 Jun 2010 14:16:28 -0700 Received: from sc-hub06.TheFacebook.com (192.168.18.83) by sc-hub01.TheFacebook.com (192.168.18.104) with Microsoft SMTP Server (TLS) id 8.2.213.0; Wed, 2 Jun 2010 14:16:49 -0700 Received: from SC-MBXC1.TheFacebook.com ([192.168.18.102]) by sc-hub06.TheFacebook.com ([192.168.18.83]) with mapi; Wed, 2 Jun 2010 14:16:49 -0700 From: David Recordon To: OAuth WG Date: Wed, 2 Jun 2010 14:16:45 -0700 Thread-Topic: Typo in 3.7.2 of OAuth2 Draft Thread-Index: AcsCmOl5i9Rbt6n7S/SOEQekhPLejg== Message-ID: <253E75B1-8030-4A17-A105-5EF1E6855776@facebook.com> References: 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_253E75B180304A17A1055EF1E6855776facebookcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-06-01_02:2010-02-06, 2010-06-01, 2010-06-01 signatures=0 Cc: Jim Brusstar Subject: [OAUTH-WG] Fwd: Typo in 3.7.2 of OAuth2 Draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2010 21:17:04 -0000 --_000_253E75B180304A17A1055EF1E6855776facebookcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Begin forwarded message: From: Jim Brusstar > Subject: [auth-protocols] Typo in OAuth2 Draft In =A73.7.2 Client Requests Access Token, the =91code=92 parameter is not l= isted as REQUIRED, when it in fact should be (otherwise it should be marked= OPTIONAL, but that doesn=92t seem to make sense). Just a heads-up. Thanks -Jim --_000_253E75B180304A17A1055EF1E6855776facebookcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Begin forwarded = message:
From: = Jim Bruss= tar <jimbru@facebook.com><= br>
Subject: [auth-protocols] Typo in OA= uth2 Draft

In =A73.7.2 Client Requests Access Token, the =91code=92 parameter is= not listed as REQUIRED, when it in fact should be (otherwise it should be = marked OPTIONAL, but that doesn=92t seem to make sense). Just a heads-up.
Thanks
-Jim
= --_000_253E75B180304A17A1055EF1E6855776facebookcom_-- From bcampbell@pingidentity.com Wed Jun 2 20:10:27 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 349A03A68B8 for ; Wed, 2 Jun 2010 20:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.377 X-Spam-Level: X-Spam-Status: No, score=-3.377 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUu+QJ2cA6l0 for ; Wed, 2 Jun 2010 20:10:26 -0700 (PDT) Received: from na3sys009aog107.obsmtp.com (na3sys009aog107.obsmtp.com [74.125.149.197]) by core3.amsl.com (Postfix) with SMTP id 487273A6881 for ; Wed, 2 Jun 2010 20:10:25 -0700 (PDT) Received: from source ([209.85.212.44]) by na3sys009aob107.postini.com ([74.125.148.12]) with SMTP ID DSNKTAcdDQGz0A48Xqrvif/9JNKUnH6LgHiy@postini.com; Wed, 02 Jun 2010 20:10:13 PDT Received: by mail-vw0-f44.google.com with SMTP id 11so3238236vws.3 for ; Wed, 02 Jun 2010 20:10:05 -0700 (PDT) Received: by 10.224.121.211 with SMTP id i19mr4027804qar.5.1275534605150; Wed, 02 Jun 2010 20:10:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.86.19 with HTTP; Wed, 2 Jun 2010 20:09:35 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Wed, 2 Jun 2010 21:09:35 -0600 Message-ID: To: Thomas Hardjono Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: oauth Subject: Re: [OAUTH-WG] Assertion flow and token bootstrapping X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 03:10:27 -0000 I'm still a newbie here so someone please correct me if I'm wrong, but I believe the Assertion Flow was intentionally left generic to serve as an extension point for profiling more specific types of assertions/tokens being exchanged for OAuth Access Tokens (or allowing for proprietary usage). The use of SAML 2 tokens is suggested in draft-ietf-oauth-v2-05 but one could imagine SAML 1.1, Kerberos (along the lines of what Thomas outlines though I don't know enough about Kerb to really comment), X.509, or whatever. Perhaps part of Lisa's use case could be addressed by profiling a flow that defines an Access Token being exchanged for a different Access Token? And the initial bootstrapping could maybe be accomplished via the Client Credentials Flow? On Wed, Jun 2, 2010 at 12:56 PM, Thomas Hardjono wrote: > > > Lisa, > > > > I=92m also looking at the assertion flow right now > > and wondering if I could use it to =A0=93swap=94 a > > Kerberos service-ticket for an OAuth Access-Token. > > > > In particular, I would like to: > > > > (1) Wrap the KRB AP_REQ message within a SAML-assertion > > (eg. using the existing WSS Token Profile standard), > > > > (2) Deliver it using the OAuth assertion flow to a special > > Kerberized-service (or IdP or OP), who then verifies > > the Authenticator and Service-Ticket within > > the AP_REQ message. > > > > (3) Obtain in return an OAuth Access-Token with > > the same lifetimes/expiration as defined in the original > > service-ticket (in the AP_REQ request). > > > > (4) Present the Access-Token to an OAuth Resource Server. > > > > (ps. Alternatively, I could use the Kerberos delegation feature > > but that may be more complicated). > > > > > > I think Section 3.10 needs more fleshing-out. > > > > /thomas/ > > > > > > __________________________________________ > > > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of > Lisa Dusseault > Sent: Wednesday, June 02, 2010 1:33 PM > To: oauth > Subject: [OAUTH-WG] Assertion flow and token bootstrapping > > > > I've been trying to understand the use case for the assertion flow > (http://tools.ietf.org/html/draft-ietf-oauth-v2-05#section-3.10) . > Conversely, I have a use case for bootstrapping, and I'm trying to > understand if the assertion flow is the right flow for that use case. > > The bootstrapping use case I have in mind is to allow a client to interac= t > with a related set of services by bootstrapping from client secret to an > access token, and then from that access token to other access tokens.=A0 = For > example, in a "login" interaction the client would get a generic access > token.=A0 Later, to use various services -- access to personal data, acce= ss to > friends' data, attempts to do uploads -- the client would ask the securit= y > token server for access to new resources by URI, and if access was grante= d, > receive new access tokens which could be used on those services.=A0 The c= lient > secret is not reused very often, and policy is centralized. > > This seems similar to other use cases being discussed and so it's possibl= e > my main point of confusion is trying to tie this to the assertion flow > instead of something else. > > The assertion flow has the right number of parties involved, and it could > certainly be hacked/extended to do bootstrapping: instead of the client > secret, the general session access token could be used, and the "assertio= n" > field can contain anything including the URI of the service that the clie= nt > now wants.=A0 However I wondered if something less generic could make thi= s > more interoperable. > > Any thoughts? > > Thanks, > Lisa > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From dick.hardt@gmail.com Wed Jun 2 22:53:29 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 433F428C138 for ; Wed, 2 Jun 2010 22:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.695 X-Spam-Level: X-Spam-Status: No, score=-0.695 tagged_above=-999 required=5 tests=[AWL=-0.697, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xXZWPhDfs7P1 for ; Wed, 2 Jun 2010 22:53:05 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id DBB3328C11C for ; Wed, 2 Jun 2010 22:52:08 -0700 (PDT) Received: by pwi8 with SMTP id 8so3248791pwi.31 for ; Wed, 02 Jun 2010 22:51:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=qJThoRoOlPSZQ7bpGd4ono+pgQJS9sjNujBDcaw0ywg=; b=H7bkhIJrRf9i/6hp1ba+7Op/TxuuL3mnAwjulPjh8NzxUiWCcSmkgiiTBIFV/Kliyt dc6A5FdoRStXOYpxioXOoNXN5Nh5umM5jQOvqt6s0S5WtBwdIA+hwq+XbPrlnR07NlDB aB837D2sMGJ3qlpupnYtPaRtHo89iBV547WFo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=wEtUYdysonSkbPB/SIaK1OoLzDaDpct1Z0Mv9xtP6op4MXdTReDPk9UbFzeKxzP+9b sOJdURjDz2uk22uhbGVp1mXQ+lsydTxGSjEqKQXZkaSkgfoTcUEHHUGMHiN87zzQvMrK TWc/MQf69D6TrTA8dxnfx1RjbishCvqpG3arc= MIME-Version: 1.0 Received: by 10.142.67.30 with SMTP id p30mr6235119wfa.154.1275544279007; Wed, 02 Jun 2010 22:51:19 -0700 (PDT) Received: by 10.143.167.14 with HTTP; Wed, 2 Jun 2010 22:51:18 -0700 (PDT) In-Reply-To: References: Date: Wed, 2 Jun 2010 22:51:18 -0700 Message-ID: From: Dick Hardt To: Brian Campbell Content-Type: multipart/alternative; boundary=001636e0a5e9a54c2c048819cbc2 Cc: oauth Subject: Re: [OAUTH-WG] Assertion flow and token bootstrapping X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 05:53:32 -0000 --001636e0a5e9a54c2c048819cbc2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable The Assertion Flow is for the AS to act as an STS where one token is exchanged for another. This allows the PR to not have to worry about different kinds of tokens and to only deal with tokens issued by an AS. Lisa: a real world example of your use case would make it easier for how yo= u got to the requirements you stated (ie. I am confused :) -- Dick On Wed, Jun 2, 2010 at 8:09 PM, Brian Campbell wrote: > I'm still a newbie here so someone please correct me if I'm wrong, but > I believe the Assertion Flow was intentionally left generic to serve > as an extension point for profiling more specific types of > assertions/tokens being exchanged for OAuth Access Tokens (or allowing > for proprietary usage). The use of SAML 2 tokens is suggested in > draft-ietf-oauth-v2-05 but one could imagine SAML 1.1, Kerberos (along > the lines of what Thomas outlines though I don't know enough about > Kerb to really comment), X.509, or whatever. Perhaps part of Lisa's > use case could be addressed by profiling a flow that defines an Access > Token being exchanged for a different Access Token? And the initial > bootstrapping could maybe be accomplished via the Client Credentials > Flow? > > On Wed, Jun 2, 2010 at 12:56 PM, Thomas Hardjono wrote= : > > > > > > Lisa, > > > > > > > > I=92m also looking at the assertion flow right now > > > > and wondering if I could use it to =93swap=94 a > > > > Kerberos service-ticket for an OAuth Access-Token. > > > > > > > > In particular, I would like to: > > > > > > > > (1) Wrap the KRB AP_REQ message within a SAML-assertion > > > > (eg. using the existing WSS Token Profile standard), > > > > > > > > (2) Deliver it using the OAuth assertion flow to a special > > > > Kerberized-service (or IdP or OP), who then verifies > > > > the Authenticator and Service-Ticket within > > > > the AP_REQ message. > > > > > > > > (3) Obtain in return an OAuth Access-Token with > > > > the same lifetimes/expiration as defined in the original > > > > service-ticket (in the AP_REQ request). > > > > > > > > (4) Present the Access-Token to an OAuth Resource Server. > > > > > > > > (ps. Alternatively, I could use the Kerberos delegation feature > > > > but that may be more complicated). > > > > > > > > > > > > I think Section 3.10 needs more fleshing-out. > > > > > > > > /thomas/ > > > > > > > > > > > > __________________________________________ > > > > > > > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of > > Lisa Dusseault > > Sent: Wednesday, June 02, 2010 1:33 PM > > To: oauth > > Subject: [OAUTH-WG] Assertion flow and token bootstrapping > > > > > > > > I've been trying to understand the use case for the assertion flow > > (http://tools.ietf.org/html/draft-ietf-oauth-v2-05#section-3.10) . > > Conversely, I have a use case for bootstrapping, and I'm trying to > > understand if the assertion flow is the right flow for that use case. > > > > The bootstrapping use case I have in mind is to allow a client to > interact > > with a related set of services by bootstrapping from client secret to a= n > > access token, and then from that access token to other access tokens. > For > > example, in a "login" interaction the client would get a generic access > > token. Later, to use various services -- access to personal data, acce= ss > to > > friends' data, attempts to do uploads -- the client would ask the > security > > token server for access to new resources by URI, and if access was > granted, > > receive new access tokens which could be used on those services. The > client > > secret is not reused very often, and policy is centralized. > > > > This seems similar to other use cases being discussed and so it's > possible > > my main point of confusion is trying to tie this to the assertion flow > > instead of something else. > > > > The assertion flow has the right number of parties involved, and it cou= ld > > certainly be hacked/extended to do bootstrapping: instead of the client > > secret, the general session access token could be used, and the > "assertion" > > field can contain anything including the URI of the service that the > client > > now wants. However I wondered if something less generic could make thi= s > > more interoperable. > > > > Any thoughts? > > > > Thanks, > > Lisa > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001636e0a5e9a54c2c048819cbc2 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable The Assertion Flow is for the AS to act as an STS where one token is exchan= ged for another. This allows the PR to not have to worry about different ki= nds of tokens and to only deal with tokens issued by an AS.

Lisa: a real world example of your use case would make it easier for h= ow you got to the requirements you stated (ie. I am confused :)
<= br>
-- Dick

On Wed, Jun 2, 2010= at 8:09 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:
I'm still a newbie here so someone plea= se correct me if I'm wrong, but
I believe the Assertion Flow was intentionally left generic to serve
as an extension point for profiling more specific types of
assertions/tokens being exchanged for OAuth Access Tokens (or allowing
for proprietary usage). =A0 The use of SAML 2 tokens is suggested in
draft-ietf-oauth-v2-05 but one could imagine SAML 1.1, Kerberos (along
the lines of what Thomas outlines though I don't know enough about
Kerb to really comment), X.509, or whatever. Perhaps part of Lisa's
use case could be addressed by profiling a flow that defines an Access
Token being exchanged for a different Access Token? =A0And the initial
bootstrapping could maybe be accomplished via the Client Credentials
Flow?

On Wed, Jun 2, 2010 at 12:56 PM, Thomas Hardjono <hardjono@mit.edu> wrote:
>
>
> Lisa,
>
>
>
> I=92m also looking at the assertion flow right now
>
> and wondering if I could use it to =A0=93swap=94 a
>
> Kerberos service-ticket for an OAuth Access-Token.
>
>
>
> In particular, I would like to:
>
>
>
> (1) Wrap the KRB AP_REQ message within a SAML-assertion
>
> (eg. using the existing WSS Token Profile standard),
>
>
>
> (2) Deliver it using the OAuth assertion flow to a special
>
> Kerberized-service (or IdP or OP), who then verifies
>
> the Authenticator and Service-Ticket within
>
> the AP_REQ message.
>
>
>
> (3) Obtain in return an OAuth Access-Token with
>
> the same lifetimes/expiration as defined in the original
>
> service-ticket (in the AP_REQ request).
>
>
>
> (4) Present the Access-Token to an OAuth Resource Server.
>
>
>
> (ps. Alternatively, I could use the Kerberos delegation feature
>
> but that may be more complicated).
>
>
>
>
>
> I think Section 3.10 needs more fleshing-out.
>
>
>
> /thomas/
>
>
>
>
>
> __________________________________________
>
>
>
> From: oauth-bounces@ietf.org= [mailto:oauth-bounces@ietf.o= rg] On Behalf Of
> Lisa Dusseault
> Sent: Wednesday, June 02, 2010 1:33 PM
> To: oauth
> Subject: [OAUTH-WG] Assertion flow and token bootstrapping
>
>
>
> I've been trying to understand the use case for the assertion flow=
> (http://tools.ietf.org/html/draft-ietf-oauth-v2-05#s= ection-3.10) .
> Conversely, I have a use case for bootstrapping, and I'm trying to=
> understand if the assertion flow is the right flow for that use case.<= br> >
> The bootstrapping use case I have in mind is to allow a client to inte= ract
> with a related set of services by bootstrapping from client secret to = an
> access token, and then from that access token to other access tokens.= =A0 For
> example, in a "login" interaction the client would get a gen= eric access
> token.=A0 Later, to use various services -- access to personal data, a= ccess to
> friends' data, attempts to do uploads -- the client would ask the = security
> token server for access to new resources by URI, and if access was gra= nted,
> receive new access tokens which could be used on those services.=A0 Th= e client
> secret is not reused very often, and policy is centralized.
>
> This seems similar to other use cases being discussed and so it's = possible
> my main point of confusion is trying to tie this to the assertion flow=
> instead of something else.
>
> The assertion flow has the right number of parties involved, and it co= uld
> certainly be hacked/extended to do bootstrapping: instead of the clien= t
> secret, the general session access token could be used, and the "= assertion"
> field can contain anything including the URI of the service that the c= lient
> now wants.=A0 However I wondered if something less generic could make = this
> more interoperable.
>
> Any thoughts?
>
> Thanks,
> Lisa
>
> _______________________________________________
> 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

--001636e0a5e9a54c2c048819cbc2-- From torsten@lodderstedt.net Thu Jun 3 03:22:42 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E05B28C151 for ; Thu, 3 Jun 2010 03:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.432 X-Spam-Level: X-Spam-Status: No, score=0.432 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_50=0.001, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XAqXR1pUc9df for ; Thu, 3 Jun 2010 03:22:40 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.18.15]) by core3.amsl.com (Postfix) with ESMTP id ECBE828C143 for ; Thu, 3 Jun 2010 03:22:39 -0700 (PDT) Received: from p4fff3c2c.dip.t-dialin.net ([79.255.60.44] helo=[127.0.0.1]) by smtprelay03.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OK7ZB-0000Iz-UL; Thu, 03 Jun 2010 12:22:26 +0200 Message-ID: <4C078260.5020701@lodderstedt.net> Date: Thu, 03 Jun 2010 12:22:24 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Lisa Dusseault References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------090301030900060101060504" X-Df-Sender: 141509 Cc: oauth Subject: Re: [OAUTH-WG] Assertion flow and token bootstrapping X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 10:22:42 -0000 This is a multi-part message in MIME format. --------------090301030900060101060504 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit If I understand you correct, then you could utilize the assertion flow as follows: Put the generic token into the assertion parameter, set the scopes parameter to the scope(s) of the service your client wants to interact with and use the client credentials as described. If the AS supports such a token swap, then it should respond with a new access token applicable for the target services. Pre-Requisite: The original token must have been authorized for the target service (scope). How do you want to achieve that? Which flow do you want to obtain the first access token? Alternatively, your client could also obtain all tokens required to access the target services in the initial authorization flow. Please take a look on the thread about multiple access tokens from one authorization flow (http://www.ietf.org/mail-archive/web/oauth/current/msg02688.html). regards, Torsten. Am 02.06.2010 19:32, schrieb Lisa Dusseault: > > I've been trying to understand the use case for the assertion flow > (http://tools.ietf.org/html/draft-ietf-oauth-v2-05#section-3.10) . > Conversely, I have a use case for bootstrapping, and I'm trying to > understand if the assertion flow is the right flow for that use case. > > The bootstrapping use case I have in mind is to allow a client to > interact with a related set of services by bootstrapping from client > secret to an access token, and then from that access token to other > access tokens. For example, in a "login" interaction the client would > get a generic access token. Later, to use various services -- access > to personal data, access to friends' data, attempts to do uploads -- > the client would ask the security token server for access to new > resources by URI, and if access was granted, receive new access tokens > which could be used on those services. The client secret is not > reused very often, and policy is centralized. > > This seems similar to other use cases being discussed and so it's > possible my main point of confusion is trying to tie this to the > assertion flow instead of something else. > > The assertion flow has the right number of parties involved, and it > could certainly be hacked/extended to do bootstrapping: instead of the > client secret, the general session access token could be used, and the > "assertion" field can contain anything including the URI of the > service that the client now wants. However I wondered if something > less generic could make this more interoperable. > > Any thoughts? > > Thanks, > Lisa > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --------------090301030900060101060504 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit If I understand you correct, then you could utilize the assertion flow as follows:

Put the generic token into the assertion parameter, set the scopes parameter to the scope(s) of the service your client wants to interact with and use the client credentials as described. If the AS supports such a token swap, then it should respond with a new access token applicable for the target services. Pre-Requisite: The original token must have been authorized for the target service (scope). How do you want to achieve that? Which flow do you want to obtain the first access token?

Alternatively, your client could also obtain all tokens required to access the target services in the initial authorization flow. Please take a look on the thread about multiple access tokens from one authorization flow (http://www.ietf.org/mail-archive/web/oauth/current/msg02688.html).

regards,
Torsten.

Am 02.06.2010 19:32, schrieb Lisa Dusseault:

I've been trying to understand the use case for the assertion flow (http://tools.ietf.org/html/draft-ietf-oauth-v2-05#section-3.10) .  Conversely, I have a use case for bootstrapping, and I'm trying to understand if the assertion flow is the right flow for that use case. 

The bootstrapping use case I have in mind is to allow a client to interact with a related set of services by bootstrapping from client secret to an access token, and then from that access token to other access tokens.  For example, in a "login" interaction the client would get a generic access token.  Later, to use various services -- access to personal data, access to friends' data, attempts to do uploads -- the client would ask the security token server for access to new resources by URI, and if access was granted, receive new access tokens which could be used on those services.  The client secret is not reused very often, and policy is centralized. 

This seems similar to other use cases being discussed and so it's possible my main point of confusion is trying to tie this to the assertion flow instead of something else.

The assertion flow has the right number of parties involved, and it could certainly be hacked/extended to do bootstrapping: instead of the client secret, the general session access token could be used, and the "assertion" field can contain anything including the URI of the service that the client now wants.  However I wondered if something less generic could make this more interoperable.

Any thoughts?

Thanks,
Lisa

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--------------090301030900060101060504-- From hardjono@mit.edu Thu Jun 3 07:55:16 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C62753A6839 for ; Thu, 3 Jun 2010 07:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.692 X-Spam-Level: X-Spam-Status: No, score=-1.692 tagged_above=-999 required=5 tests=[AWL=0.906, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2vkI+tDnJ7PI for ; Thu, 3 Jun 2010 07:55:13 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (DMZ-MAILSEC-SCANNER-6.MIT.EDU [18.7.68.35]) by core3.amsl.com (Postfix) with ESMTP id 0F6D13A67D4 for ; Thu, 3 Jun 2010 07:55:12 -0700 (PDT) X-AuditID: 12074423-b7c0bae0000030f0-af-4c07c2430f73 Received: from mailhub-auth-4.mit.edu (MAILHUB-AUTH-4.MIT.EDU [18.7.62.39]) by dmz-mailsec-scanner-6.mit.edu (Symantec Brightmail Gateway) with SMTP id AD.EF.12528.342C70C4; Thu, 3 Jun 2010 10:54:59 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-EXCHANGE-2.MIT.EDU [18.9.28.16]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id o53EswAo007318; Thu, 3 Jun 2010 10:54:58 -0400 Received: from oc11exedge2.exchange.mit.edu (OC11EXEDGE2.EXCHANGE.MIT.EDU [18.9.3.18]) ) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id o53EsvC5018533; Thu, 3 Jun 2010 10:54:58 -0400 Received: from w92exhub6.exchange.mit.edu (18.7.73.12) by oc11exedge2.exchange.mit.edu (18.9.3.18) with Microsoft SMTP Server (TLS) id 8.1.393.1; Thu, 3 Jun 2010 10:54:03 -0400 Received: from EXPO10.exchange.mit.edu ([18.9.4.15]) by w92exhub6.exchange.mit.edu ([18.7.73.12]) with mapi; Thu, 3 Jun 2010 10:54:56 -0400 From: Thomas Hardjono To: Dick Hardt , Brian Campbell Date: Thu, 3 Jun 2010 10:54:54 -0400 Thread-Topic: [OAUTH-WG] Assertion flow and token bootstrapping Thread-Index: AcsC4MtmoSe1TKLbQu21QQVu5sPt+gASzjoA 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: oauth Subject: Re: [OAUTH-WG] Assertion flow and token bootstrapping X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 14:55:16 -0000 Dick, Brian, Thanks for the clarification. - Is the Assertion Flow designed only for the STS, or can it be used with other "identity providers" (non-WSS). - Also, is it the expectation that a "profile" of OAuth2.0 be created to address certain use-cases. PS. Compared to the details of RFC4120 and even to the old ISAKMP in the IETF, the current OAuth2.0 draft-05 spec appear to be a high-level framework that needs to be instantiated/profiled. /thomas/ __________________________________________ -From: Dick Hardt [mailto:dick.hardt@gmail.com]=20 -Sent: Thursday, June 03, 2010 1:51 AM To: Brian Campbell Cc: Thomas Hardjono; oauth Subject: Re: [OAUTH-WG] Assertion flow and token bootstrapping The Assertion Flow is for the AS to act as an STS where one token is exchan= ged for another. This allows the PR to not have to worry about different ki= nds of tokens and to only deal with tokens issued by an AS. Lisa: a real world example of your use case would make it easier for how yo= u got to the requirements you stated (ie. I am confused :) -- Dick On Wed, Jun 2, 2010 at 8:09 PM, Brian Campbell = wrote: I'm still a newbie here so someone please correct me if I'm wrong, but I believe the Assertion Flow was intentionally left generic to serve as an extension point for profiling more specific types of assertions/tokens being exchanged for OAuth Access Tokens (or allowing for proprietary usage). =A0 The use of SAML 2 tokens is suggested in draft-ietf-oauth-v2-05 but one could imagine SAML 1.1, Kerberos (along the lines of what Thomas outlines though I don't know enough about Kerb to really comment), X.509, or whatever. Perhaps part of Lisa's use case could be addressed by profiling a flow that defines an Access Token being exchanged for a different Access Token? =A0And the initial bootstrapping could maybe be accomplished via the Client Credentials Flow? On Wed, Jun 2, 2010 at 12:56 PM, Thomas Hardjono wrote: > > > Lisa, > > > > I'm also looking at the assertion flow right now > > and wondering if I could use it to =A0"swap" a > > Kerberos service-ticket for an OAuth Access-Token. > > > > In particular, I would like to: > > > > (1) Wrap the KRB AP_REQ message within a SAML-assertion > > (eg. using the existing WSS Token Profile standard), > > > > (2) Deliver it using the OAuth assertion flow to a special > > Kerberized-service (or IdP or OP), who then verifies > > the Authenticator and Service-Ticket within > > the AP_REQ message. > > > > (3) Obtain in return an OAuth Access-Token with > > the same lifetimes/expiration as defined in the original > > service-ticket (in the AP_REQ request). > > > > (4) Present the Access-Token to an OAuth Resource Server. > > > > (ps. Alternatively, I could use the Kerberos delegation feature > > but that may be more complicated). > > > > > > I think Section 3.10 needs more fleshing-out. > > > > /thomas/ > > > > > > __________________________________________ > > > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of > Lisa Dusseault > Sent: Wednesday, June 02, 2010 1:33 PM > To: oauth > Subject: [OAUTH-WG] Assertion flow and token bootstrapping > > > > I've been trying to understand the use case for the assertion flow > (http://tools.ietf.org/html/draft-ietf-oauth-v2-05#section-3.10) . > Conversely, I have a use case for bootstrapping, and I'm trying to > understand if the assertion flow is the right flow for that use case. > > The bootstrapping use case I have in mind is to allow a client to interac= t > with a related set of services by bootstrapping from client secret to an > access token, and then from that access token to other access tokens.=A0 = For > example, in a "login" interaction the client would get a generic access > token.=A0 Later, to use various services -- access to personal data, acce= ss to > friends' data, attempts to do uploads -- the client would ask the securit= y > token server for access to new resources by URI, and if access was grante= d, > receive new access tokens which could be used on those services.=A0 The c= lient > secret is not reused very often, and policy is centralized. > > This seems similar to other use cases being discussed and so it's possibl= e > my main point of confusion is trying to tie this to the assertion flow > instead of something else. > > The assertion flow has the right number of parties involved, and it could > certainly be hacked/extended to do bootstrapping: instead of the client > secret, the general session access token could be used, and the "assertio= n" > field can contain anything including the URI of the service that the clie= nt > now wants.=A0 However I wondered if something less generic could make thi= s > more interoperable. > > Any thoughts? > > Thanks, > Lisa > > _______________________________________________ > OAuth mailing 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 stpeter@stpeter.im Thu Jun 3 08:21:03 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 105F93A698E for ; Thu, 3 Jun 2010 08:21:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.056 X-Spam-Level: X-Spam-Status: No, score=-2.056 tagged_above=-999 required=5 tests=[AWL=0.543, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sh64GALUszQt for ; Thu, 3 Jun 2010 08:20:59 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id CC1CC3A69E4 for ; Thu, 3 Jun 2010 08:20:58 -0700 (PDT) Received: from dhcp-64-101-72-121.cisco.com (dhcp-64-101-72-121.cisco.com [64.101.72.121]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 401EC40E14 for ; Thu, 3 Jun 2010 09:20:45 -0600 (MDT) Message-ID: <4C07C84C.9070705@stpeter.im> Date: Thu, 03 Jun 2010 09:20:44 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: oauth@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000303080802080204010006" Subject: Re: [OAUTH-WG] Assertion flow and token bootstrapping X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 15:21:03 -0000 This is a cryptographically signed message in MIME format. --------------ms000303080802080204010006 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 6/3/10 8:54 AM, Thomas Hardjono wrote: > PS. Compared to the details of RFC4120 and even > to the old ISAKMP in the IETF, the current > OAuth2.0 draft-05 spec appear to be a high-level framework > that needs to be instantiated/profiled. At least for the assertion flow, that's definitely true. At the interim meeting we had some discussion about perhaps pulling the assertion flow out of the base spec and into a separate document. Perhaps that's the best way to proceed. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms000303080802080204010006 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDYwMzE1MjA0NFowIwYJKoZIhvcNAQkEMRYEFMOEb9Dg1xIw2LTCu2dU BgZ6ThSpMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAPm3TsRaZJg+rGW3psWisQW39l1q/yGDPM/jNMBK8 wgfApRJfhjPOI1fZInHD66FFTNyiDxnJUjd4UYYRtKe7gWFd/QuYGVl+Y9sJGEZbOZZhy91R CzKwM2QRUp211lgi5FATlXToGoJe1kf3vfPFtl5ecWJOmWLOpPHsNjhEUBhD4ZjzxGDmjE4q tvISkJTbGboMQuovIYJbAuFi0ybY0vgsJnqpAi48Fqd2Wklhm8Kf1xgRpNwGwI7eDr7Eyg73 rnYg41ccQbLoQqQ4ehjnCwn624r3W4guc/4FULFd/JJdg3dn8wE76f4z0BKMWbTe4BY0Idmz HixGSG5VKAJiuwAAAAAAAA== --------------ms000303080802080204010006-- From paul.madsen@gmail.com Thu Jun 3 08:31:03 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1364E3A68BF for ; Thu, 3 Jun 2010 08:31:03 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-shw5ORlSy7 for ; Thu, 3 Jun 2010 08:30:40 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 4C8B83A69D6 for ; Thu, 3 Jun 2010 08:30:37 -0700 (PDT) Received: by vws11 with SMTP id 11so271031vws.31 for ; Thu, 03 Jun 2010 08:30:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=DQTGhM3mebB5BdWDqoGSA36MWsTOxPDrgW1y6EHlqLw=; b=cAA1EWPB/Jfgie9QTiHticDc5v4qeABAlWQ6d9rZQMnjwqN+GPVILSqBGAcnP8AQwU 85yjQny8fjmlB2enjLHbl/Tr+RdbZNSEcdwjXPoMGNyqWBbKYn90InIjpWzndul3Q0D2 M53Gnvr/Csv3NpR9J+cu2StZHz6boI6JG8ijA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=mdLbGF6iCEx2MyYtb+xL23P88k6bDm9pdbfbIa0XGHS+DgmV5fItZHDzWQkFfJODTQ BaDsz+erJB+mPojfkqrIxnPFrZzLzMULnD/XQSGSoRoCjLj5rruJsBqSt6ozflRg6ww/ E2Er6oH8uY0g558qgKV3rsFR4XMVDs+YhAHqw= Received: by 10.224.18.163 with SMTP id w35mr4782048qaa.70.1275579021174; Thu, 03 Jun 2010 08:30:21 -0700 (PDT) Received: from [192.168.0.168] (CPE0022b0cb82b4-CM0012256eb4b4.cpe.net.cable.rogers.com [99.224.152.177]) by mx.google.com with ESMTPS id i10sm115282qcb.11.2010.06.03.08.30.19 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 03 Jun 2010 08:30:20 -0700 (PDT) Message-ID: <4C07CA89.1020803@gmail.com> Date: Thu, 03 Jun 2010 11:30:17 -0400 From: Paul Madsen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: oauth@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [OAUTH-WG] Assertion flow and token bootstrapping X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 15:31:03 -0000 I think STS was used in the generic sense, ie token in, token out Although a SOAP-binding for the flow would be wonderfully perverse paul On 03/06/2010 10:54 AM, Thomas Hardjono wrote: > Dick, Brian, > > Thanks for the clarification. > > - Is the Assertion Flow designed only for the STS, > or can it be used with other "identity providers" (non-WSS). > > - Also, is it the expectation that a "profile" of OAuth2.0 > be created to address certain use-cases. > > PS. Compared to the details of RFC4120 and even > to the old ISAKMP in the IETF, the current > OAuth2.0 draft-05 spec appear to be a high-level framework > that needs to be instantiated/profiled. > > /thomas/ > > > > __________________________________________ > > -From: Dick Hardt [mailto:dick.hardt@gmail.com] > -Sent: Thursday, June 03, 2010 1:51 AM > To: Brian Campbell > Cc: Thomas Hardjono; oauth > Subject: Re: [OAUTH-WG] Assertion flow and token bootstrapping > > The Assertion Flow is for the AS to act as an STS where one token is exchanged for another. This allows the PR to not have to worry about different kinds of tokens and to only deal with tokens issued by an AS. > > Lisa: a real world example of your use case would make it easier for how you got to the requirements you stated (ie. I am confused :) > > -- Dick > On Wed, Jun 2, 2010 at 8:09 PM, Brian Campbell wrote: > I'm still a newbie here so someone please correct me if I'm wrong, but > I believe the Assertion Flow was intentionally left generic to serve > as an extension point for profiling more specific types of > assertions/tokens being exchanged for OAuth Access Tokens (or allowing > for proprietary usage). The use of SAML 2 tokens is suggested in > draft-ietf-oauth-v2-05 but one could imagine SAML 1.1, Kerberos (along > the lines of what Thomas outlines though I don't know enough about > Kerb to really comment), X.509, or whatever. Perhaps part of Lisa's > use case could be addressed by profiling a flow that defines an Access > Token being exchanged for a different Access Token? And the initial > bootstrapping could maybe be accomplished via the Client Credentials > Flow? > > On Wed, Jun 2, 2010 at 12:56 PM, Thomas Hardjono wrote: > >> >> Lisa, >> >> >> >> I'm also looking at the assertion flow right now >> >> and wondering if I could use it to "swap" a >> >> Kerberos service-ticket for an OAuth Access-Token. >> >> >> >> In particular, I would like to: >> >> >> >> (1) Wrap the KRB AP_REQ message within a SAML-assertion >> >> (eg. using the existing WSS Token Profile standard), >> >> >> >> (2) Deliver it using the OAuth assertion flow to a special >> >> Kerberized-service (or IdP or OP), who then verifies >> >> the Authenticator and Service-Ticket within >> >> the AP_REQ message. >> >> >> >> (3) Obtain in return an OAuth Access-Token with >> >> the same lifetimes/expiration as defined in the original >> >> service-ticket (in the AP_REQ request). >> >> >> >> (4) Present the Access-Token to an OAuth Resource Server. >> >> >> >> (ps. Alternatively, I could use the Kerberos delegation feature >> >> but that may be more complicated). >> >> >> >> >> >> I think Section 3.10 needs more fleshing-out. >> >> >> >> /thomas/ >> >> >> >> >> >> __________________________________________ >> >> >> >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of >> Lisa Dusseault >> Sent: Wednesday, June 02, 2010 1:33 PM >> To: oauth >> Subject: [OAUTH-WG] Assertion flow and token bootstrapping >> >> >> >> I've been trying to understand the use case for the assertion flow >> (http://tools.ietf.org/html/draft-ietf-oauth-v2-05#section-3.10) . >> Conversely, I have a use case for bootstrapping, and I'm trying to >> understand if the assertion flow is the right flow for that use case. >> >> The bootstrapping use case I have in mind is to allow a client to interact >> with a related set of services by bootstrapping from client secret to an >> access token, and then from that access token to other access tokens. For >> example, in a "login" interaction the client would get a generic access >> token. Later, to use various services -- access to personal data, access to >> friends' data, attempts to do uploads -- the client would ask the security >> token server for access to new resources by URI, and if access was granted, >> receive new access tokens which could be used on those services. The client >> secret is not reused very often, and policy is centralized. >> >> This seems similar to other use cases being discussed and so it's possible >> my main point of confusion is trying to tie this to the assertion flow >> instead of something else. >> >> The assertion flow has the right number of parties involved, and it could >> certainly be hacked/extended to do bootstrapping: instead of the client >> secret, the general session access token could be used, and the "assertion" >> field can contain anything including the URI of the service that the client >> now wants. However I wondered if something less generic could make this >> more interoperable. >> >> Any thoughts? >> >> Thanks, >> Lisa >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From dick.hardt@gmail.com Thu Jun 3 08:35:35 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27ACE3A6934 for ; Thu, 3 Jun 2010 08:35:08 -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=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I+1AVEJH3VCG for ; Thu, 3 Jun 2010 08:34:29 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 016E33A69D6 for ; Thu, 3 Jun 2010 08:33:59 -0700 (PDT) Received: by pvf33 with SMTP id 33so107241pvf.31 for ; Thu, 03 Jun 2010 08:32:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=OW6sQCam3Pm0QhhPdqmE4FseM6Abc6sljajVe/xnhTA=; b=HlMrusJLgtRGp0qAIJiT/lg1HoLsdoHH8XodSgNsuztZY7kx+NTEl7x9ZYaA6zlyGn 48/FdMJOVW8MgGunSON3sqzdmDz2noc5A9AC0ryPmCqnxVtcjm5OYm3Ca9O0+w+Act4Q HKSh9Up76xw2Rbl32blnpaXHBbCszxGOp/ioQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=q8tWEFV+9CtOFvaRK/yEXIUISotiBtUTwPU48vuusuLyGJiRC6+wuzgvRxtfJjOMtf j7mbhUwZzzBMBdM5mZyZt9FkyXkoA1DQMe4HCRg9WiCKRc//AL1dni4wKFxUVGRmCV9k YMIRgmQjwolI/z6AV+oz7+5bgF2Tf06PLO3z4= Received: by 10.142.247.28 with SMTP id u28mr6849732wfh.69.1275579159203; Thu, 03 Jun 2010 08:32:39 -0700 (PDT) Received: from [10.0.1.8] ([24.130.32.55]) by mx.google.com with ESMTPS id v41sm152660wfh.9.2010.06.03.08.32.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 03 Jun 2010 08:32:38 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Dick Hardt In-Reply-To: Date: Thu, 3 Jun 2010 08:32:36 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9A4A50E0-C83F-4066-BFAF-8578B34D2023@gmail.com> References: To: Thomas Hardjono X-Mailer: Apple Mail (2.1078) Cc: oauth Subject: Re: [OAUTH-WG] Assertion flow and token bootstrapping X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 15:35:37 -0000 On 2010-06-03, at 7:54 AM, Thomas Hardjono wrote: > Dick, Brian, >=20 > Thanks for the clarification. >=20 > - Is the Assertion Flow designed only for the STS, > or can it be used with other "identity providers" (non-WSS). It can be used with any tokens. I use the STS term to clarify the design = pattern. >=20 > - Also, is it the expectation that a "profile" of OAuth2.0 > be created to address certain use-cases. Such as? >=20 > PS. Compared to the details of RFC4120 and even > to the old ISAKMP in the IETF, the current > OAuth2.0 draft-05 spec appear to be a high-level framework > that needs to be instantiated/profiled. Agreed there are some aspects of OAuth that are left to other = documentation. Standardizing what can easily be standardized has proven = very useful to implementors. -- Dick From dick.hardt@gmail.com Thu Jun 3 08:35:41 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 480383A6934 for ; Thu, 3 Jun 2010 08:35:41 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l9+DSXenL0m9 for ; Thu, 3 Jun 2010 08:35:35 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 33CE93A68BF for ; Thu, 3 Jun 2010 08:34:41 -0700 (PDT) Received: by mail-pv0-f172.google.com with SMTP id 33so107241pvf.31 for ; Thu, 03 Jun 2010 08:34:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=dqOgPjvNUy1PRhb+8PBvc0XY+5j6sHroMmMcln7Wwig=; b=BDymKMkcgJoZZNvyAfC2A1m+JPonlzitaTQz+Z04Kkqs1I+MZ+ArJiJ51PYvVJtqXM Skv4Dtw1MOaY6uSifpEqyXr73Rx9vdBK9lb6qFj5v3U/xLi7R4xCY/9Eta/8ocyclVNt QKw+i30uXWh7+pFM80zCsdNZ0amk6lQFGP5zs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=dFVUX4ejIOcaKFCDsEfNIhctdKBkQQv3a9F3CR/o25QkI/UYZ1ThFESmrZvh8DcYlT uPuvXi8UHDOk1jtUU3fE/i+pK5MoGy+LedWjm3Mu4ahaO8KvubpKXZFGi84mvLWbEhsh giEAlVGr1IXG2FXfS0SRfC91A97Q7PgPBYDLY= Received: by 10.114.188.31 with SMTP id l31mr7154438waf.32.1275579268361; Thu, 03 Jun 2010 08:34:28 -0700 (PDT) Received: from [10.0.1.8] (c-24-130-32-55.hsd1.ca.comcast.net [24.130.32.55]) by mx.google.com with ESMTPS id c14sm9460waa.1.2010.06.03.08.34.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 03 Jun 2010 08:34:27 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Dick Hardt In-Reply-To: <4C07C84C.9070705@stpeter.im> Date: Thu, 3 Jun 2010 08:34:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C07C84C.9070705@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1078) Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Assertion flow and token bootstrapping X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 15:35:41 -0000 On 2010-06-03, at 8:20 AM, Peter Saint-Andre wrote: > On 6/3/10 8:54 AM, Thomas Hardjono wrote: >=20 >> PS. Compared to the details of RFC4120 and even >> to the old ISAKMP in the IETF, the current >> OAuth2.0 draft-05 spec appear to be a high-level framework >> that needs to be instantiated/profiled. >=20 > At least for the assertion flow, that's definitely true. At the = interim > meeting we had some discussion about perhaps pulling the assertion = flow > out of the base spec and into a separate document. Perhaps that's the > best way to proceed. I think all of the flows have some aspect that requires the developer = reading some context specific documentation to implement and that = standardizing what we can is useful. The assertions being passed around = are based on specs that themselves need to be profiled often.=20 From lr@lukasrosenstock.net Thu Jun 3 11:13:21 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D8BE28C0F2 for ; Thu, 3 Jun 2010 11:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.623 X-Spam-Level: X-Spam-Status: No, score=0.623 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PKLp4rA-y72e for ; Thu, 3 Jun 2010 11:13:20 -0700 (PDT) Received: from mail-yw0-f180.google.com (mail-yw0-f180.google.com [209.85.211.180]) by core3.amsl.com (Postfix) with ESMTP id 641F928C19C for ; Thu, 3 Jun 2010 11:11:14 -0700 (PDT) Received: by ywh10 with SMTP id 10so389541ywh.18 for ; Thu, 03 Jun 2010 11:10:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.46.228 with SMTP id k36mr5279918qaf.192.1275588654333; Thu, 03 Jun 2010 11:10:54 -0700 (PDT) Received: by 10.229.250.202 with HTTP; Thu, 3 Jun 2010 11:10:53 -0700 (PDT) In-Reply-To: <4BFC371A.5040109@lodderstedt.net> References: <4BFAA6AB.8040809@lodderstedt.net> <4BFC3142.6010506@lodderstedt.net> <4BFC371A.5040109@lodderstedt.net> Date: Thu, 3 Jun 2010 20:10:53 +0200 Message-ID: From: Lukas Rosenstock To: "OAuth WG (oauth@ietf.org)" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [OAUTH-WG] multiple access tokens from a single authorization flow? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 18:13:21 -0000 Hi! I'm curious why this is impossible. If access tokens are arbitrary handles which are generated by the authorization server and distributed to all resources, it doesn't make much difference whether one or multiple are generated and in this case it would be better to keep the load on the server rather complicating things for clients. In the scenario (as you have mentioned) where access tokens are self-contained and digitally signed, would it not be possible to generate a "super token" which contains signatures from all resources? I agree this token might be a bit lengthy, but is there any other concern?! Regards, Lukas 2010/5/25 Torsten Lodderstedt : > As I said, every service in our setup needs another access token, with > different content, signed and encrypted with another shared secret. It is > technically impossible to create the super access token. Refresh tokens are > just handles representing the user's authorization and are used by the authz > server only. They therefore can represent any scope. -- http://lukasrosenstock.net/ From torsten@lodderstedt.net Thu Jun 3 11:14:05 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDEAD28C199 for ; Thu, 3 Jun 2010 11:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.052 X-Spam-Level: * X-Spam-Status: No, score=1.052 tagged_above=-999 required=5 tests=[AWL=-0.554, BAYES_50=0.001, FU_ENDS_2_WRDS=0.255, HELO_EQ_DE=0.35, J_BACKHAIR_31=1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CUM4RVuxz2mV for ; Thu, 3 Jun 2010 11:14:03 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.35]) by core3.amsl.com (Postfix) with ESMTP id 8517428C159 for ; Thu, 3 Jun 2010 11:12:50 -0700 (PDT) Received: from p4fff3c2c.dip.t-dialin.net ([79.255.60.44] helo=[127.0.0.1]) by smtprelay01.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OKEu3-0000df-0q; Thu, 03 Jun 2010 20:12:27 +0200 Message-ID: <4C07F081.4060106@lodderstedt.net> Date: Thu, 03 Jun 2010 20:12:17 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Manger, James H" References: <4C028AC7.5020102@lodderstedt.net> <4C05557C.6060201@lodderstedt.net> <255B9BB34FB7D647A506DC292726F6E11263CF6E6B@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11263CF6E6B@WSMSG3153V.srv.dir.telstra.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Questions about scopes (section 6.1) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 18:14:05 -0000 +1 for solution 2 Regarding usage of the scope attribute: As Dick suggested, the spec should state that the client should pass the scope attributes content to the corresponding scope parameter in any authorization flow. Moreover, I would suggest, clients should be allowed to combine scopes from different resources into on authorization flow, if the tokens- and user-uri are the same (== same authz server). The resulting scope should be the union of all scopes, where scope equivalence is determined by a simple string compare. regards, Torsten. Am 02.06.2010 02:55, schrieb Manger, James H: > 'scope' shouldn't be defined as a (as it is in section 6.1 WWW-Auth header). That implies two 'scope' values should be compared as URIs -- by seeing if they identify the same resource (ie resolve to the same absolute URI). I don't think this was intended. > > Facebook, for instance, have a 'scope' of "user_photos". I am sure they don't (and shouldn't have to) accept "./user_photos" or "user%5Fphotos" or "https://graph.facebook.com/user_photos" as equivalent. > > If 'scope' in a WWW-Auth response header is a relative URI it is presumably relative to the requested URI. Hence, WWW-Auth responses for requests to https://api.example.com/123 and https://api.example.com/123/albums that both include scope="user_photos" actually indicate different scopes. > > > There is also an important typo in 6.1: 1#URI-Reference means comma-separated values; but the text says space-separated values. > > > Suggested solution 1: > Remove the "scope" parameter from the WWW-Auth response. Remove the ABNF for and the paragraph describing it. > [Note: the can still include a 'scope' query parameter.] > > > Suggested solution 2: (subject to getting a answer to Torsten's question about what an OAuth2 client does with 'scope' in WWW-Auth) > Change to be a list of strings, nots, and adjust the paragraph describing it accordingly. > > scope = "scope" "="<"> scope-v *(" " scope-v)<"> > scope-v = 1*(reserved / unreserved / pct-encoded) > > The "scope" attribute is a list of space-delimited strings indicating the required scope of the access token for accessing the requested resource. The order of the strings in the list does not matter. Each string can contain the characters allowed in a URI so an authorization server can choose to use URIs for scope strings. However, the strings do not have to be URIs so client apps MUST NOT assume they are URIs. In particular, individual string values MUST be compared character-for-character without any URI normalization. Consequently, an authorization server that chooses to use URIs as scope strings needs to be careful to use a consistent normalization everywhere. > > > > P.S. The spec defines 'scope' in 8 separate places: 6 definitions are identical; 1 is almost identical; and the last (in 6.1. The WWW-Authenticate Response Header) is different. > Wouldn't it be better to define it just once? > > From torsten@lodderstedt.net Thu Jun 3 11:27:37 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F8A13A68B7 for ; Thu, 3 Jun 2010 11:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.471 X-Spam-Level: X-Spam-Status: No, score=0.471 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IWPvVvAmUL-F for ; Thu, 3 Jun 2010 11:27:36 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.44]) by core3.amsl.com (Postfix) with ESMTP id 341653A6802 for ; Thu, 3 Jun 2010 11:27:36 -0700 (PDT) Received: from p4fff3c2c.dip.t-dialin.net ([79.255.60.44] helo=[127.0.0.1]) by smtprelay02.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OKF8T-0007Ec-NS; Thu, 03 Jun 2010 20:27:21 +0200 Message-ID: <4C07F407.4050305@lodderstedt.net> Date: Thu, 03 Jun 2010 20:27:19 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Lukas Rosenstock References: <4BFAA6AB.8040809@lodderstedt.net> <4BFC3142.6010506@lodderstedt.net> <4BFC371A.5040109@lodderstedt.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] multiple access tokens from a single authorization flow? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 18:27:37 -0000 I probably exaggerated a bit. It's not impossible but it is complex and insecure for several reasons: 1) Such a super token would need to contain the union of all data and permissions needed by all requested target services. 2) Not all services may by authorized to see all data contained in such a super token (privacy!). So, you would need to built different service-specific (encrypted) compartments within the token. 3) There are target-service-specific characteristics of such a token, such as the audience and the signature. You would need to have such attributes per service. Using public-key cryptography would relieve this point but slow down processing. 4) You have to (somehow) prevent a target service from _abusing_ this token to access another service for which the super token is valid for. The only way I see is the usage of the client secret. That's why I think, returning multiple tokens is much simpler. regards, Torsten. Am 03.06.2010 20:10, schrieb Lukas Rosenstock: > Hi! > I'm curious why this is impossible. If access tokens are arbitrary > handles which are generated by the authorization server and > distributed to all resources, it doesn't make much difference whether > one or multiple are generated and in this case it would be better to > keep the load on the server rather complicating things for clients. > In the scenario (as you have mentioned) where access tokens are > self-contained and digitally signed, would it not be possible to > generate a "super token" which contains signatures from all resources? > I agree this token might be a bit lengthy, but is there any other > concern?! > > Regards, > Lukas > > 2010/5/25 Torsten Lodderstedt: > >> As I said, every service in our setup needs another access token, with >> different content, signed and encrypted with another shared secret. It is >> technically impossible to create the super access token. Refresh tokens are >> just handles representing the user's authorization and are used by the authz >> server only. They therefore can represent any scope. >> > From sakimura@gmail.com Thu Jun 3 20:12:55 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BA453A68B1 for ; Thu, 3 Jun 2010 20:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.444 X-Spam-Level: X-Spam-Status: No, score=-0.444 tagged_above=-999 required=5 tests=[AWL=-0.446, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HOZMx4Y-Fhpd for ; Thu, 3 Jun 2010 20:12:51 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 50D3F3A6879 for ; Thu, 3 Jun 2010 20:12:51 -0700 (PDT) Received: by iwn42 with SMTP id 42so610602iwn.31 for ; Thu, 03 Jun 2010 20:12:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=hDNUZBolnJNRwUX80NYtIaIj36dQcX1pxJEKjl/F1ys=; b=nFf6WG0jFiJVdY60UW/+xzv3J3i0a8C6TwjbKX7KHa0jgStk1PHqn+a5E4m9blaMAu PSYaVZGiAJKnyMIzLKZvF9QPb7LVF5OL9k4zIgSYqNoLyt0XDIE7CU9Yqy3+H8OwZ5PT 3LYq6+MfTaVMH9C0kbGyiKgeIlmVPV/uwQ+wU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=btZ8Al/YLE2pP+9yGc5eD+tCz8TGH5Rn+LF/qY84uEHT6VQt+YznIoD/ZOG+NrfFhC JC4tkFOxhyY/7Mkz4ANpck01JpH/OKf97fZpCinK60WIvi6YHGKcee6AUgLYvDml3Z/f JmVkjgdVvMDLaBnvc9ELjxjzBZiPo7xvJ0zP4= MIME-Version: 1.0 Received: by 10.231.120.137 with SMTP id d9mr13034442ibr.97.1275621154700; Thu, 03 Jun 2010 20:12:34 -0700 (PDT) Received: by 10.231.15.133 with HTTP; Thu, 3 Jun 2010 20:12:34 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11263BF2F2E@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E11263AC0282@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E11263B6402C@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E11263BF2F2E@WSMSG3153V.srv.dir.telstra.com> Date: Fri, 4 Jun 2010 12:12:34 +0900 Message-ID: From: Nat Sakimura To: "Manger, James H" Content-Type: multipart/alternative; boundary=0016e6460578cb3dbe04882bb152 Cc: oauth Subject: Re: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 03:12:55 -0000 --0016e6460578cb3dbe04882bb152 Content-Type: text/plain; charset=ISO-8859-1 James, On Mon, May 31, 2010 at 10:17 AM, Manger, James H < James.H.Manger@team.telstra.com> wrote: > Nat, > > > All the request parameters MUST be provided through request file. > > "All" doesn't make much sense if params can still appear in the URI, and > override the file. > What about this: Request parameters SHOULD be provided through request file. > > > The "request_url" MUST be provided in the URL. > > This isn't really a "MUST", its just indicates if you are using this > feature (this "flow"). > It is a MUST. Without it, you just cannot obtain other required parameters. > > Would be good to say "A request_url param MUST NOT be provided in a request > file". Probably good to add "A request file MUST be rejected if it includes > a request_url param". > request_url param MAY be provided in a request file. It is just its identifier. It probably is best to be there. > > > I am still not sure if "type" MUST be provided in the URL. > > Conceptually, it need not be there. It depends on how implementors feel. > > > Any other parameters MAY be provided in the URL to override what is in > the request_file, > > I agree. > > > but the URL total length MUST NOT exceed 512 bytes. > > That is reasonable. > > -- > James Manger > -- Nat Sakimura (=nat) http://www.sakimura.org/en/ http://twitter.com/_nat_en --0016e6460578cb3dbe04882bb152 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable James,=A0

On Mon, May 31, 2010 at 10:17 A= M, Manger, James H <James.H.Manger@team.telstra.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex;"> Nat,

> All the request parameters MUST be provided through request file.

"All" doesn't make much sense if params can still appea= r in the URI, and override the file.

Wh= at about this:=A0

Request parameters SHOULD be pro= vided through request file.=A0
=A0

> The "request_url" MUST be provided in the URL.

This isn't really a "MUST", its just indicates if you a= re using this feature (this "flow").

It is a MUST. Without it, you just cannot obtain other required par= ameters.=A0
=A0

Would be good to say "A request_url param MUST NOT be provided in a re= quest file". Probably good to add "A request file MUST be rejecte= d if it includes a request_url param".

request_url param MAY be provided in a request file. It is just its id= entifier. It probably is best to be there.=A0
=A0

> I am still not sure if "type" MUST be provided in the URL. > Conceptually, it need not be there. It depends on how implementors fee= l.

> Any other parameters MAY be provided in the URL to override what is in= the request_file,

I agree.

> but the URL total length MUST NOT exceed 512 bytes.

That is reasonable.

--
James Manger



--
Nat Sakimura (= =3Dnat)
http://www.sakimura.org/= en/
http://twitter.com/_nat_e= n
--0016e6460578cb3dbe04882bb152-- From James.H.Manger@team.telstra.com Fri Jun 4 00:21:29 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 574A23A657C for ; Fri, 4 Jun 2010 00:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.629 X-Spam-Level: * X-Spam-Status: No, score=1.629 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wRGIJYQRoK2p for ; Fri, 4 Jun 2010 00:21:28 -0700 (PDT) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by core3.amsl.com (Postfix) with ESMTP id 2AAAF3A6926 for ; Fri, 4 Jun 2010 00:21:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,360,1272808800"; d="scan'208";a="3893355" Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipoavi.tcif.telstra.com.au with ESMTP; 04 Jun 2010 17:21:11 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6002"; a="2820435" Received: from wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) by ipcbvi.tcif.telstra.com.au with ESMTP; 04 Jun 2010 17:21:12 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) with mapi; Fri, 4 Jun 2010 17:21:11 +1000 From: "Manger, James H" To: Nat Sakimura Date: Fri, 4 Jun 2010 17:21:10 +1000 Thread-Topic: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow Thread-Index: AcsDk8i+EMactUM/Q/O3x2hlqfopBgAGTUEg Message-ID: <255B9BB34FB7D647A506DC292726F6E11263E5D01B@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E11263AC0282@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E11263B6402C@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E11263BF2F2E@WSMSG3153V.srv.dir.telstra.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: oauth Subject: Re: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 07:21:29 -0000 TmF0LA0KDQo+Pj4gQWxsIHRoZSByZXF1ZXN0IHBhcmFtZXRlcnMgTVVTVCBiZSBwcm92aWRlZCB0 aHJvdWdoIHJlcXVlc3QgZmlsZS4NCj4+IkFsbCIgZG9lc24ndCBtYWtlIG11Y2ggc2Vuc2UgaWYg cGFyYW1zIGNhbiBzdGlsbCBhcHBlYXIgaW4gdGhlIFVSSSwgYW5kIG92ZXJyaWRlIHRoZSBmaWxl Lg0KDQo+IFdoYXQgYWJvdXQgdGhpczrCoA0KPg0KPiBSZXF1ZXN0IHBhcmFtZXRlcnMgU0hPVUxE IGJlIHByb3ZpZGVkIHRocm91Z2ggcmVxdWVzdCBmaWxlLsKgDQoNCklmIGl0IGlzIHBlcmZlY3Rs eSBsZWdpdGltYXRlIHRvIGluY2x1ZGUgc29tZSBwYXJhbXMgaW4gdGhlIHVzZXItdXJsLCBhbmQg dGhvc2Ugb3ZlcnJpZGUgdGhlIHNhbWUgcGFyYW1zIGluIHRoZSBmaWxlLCB0aGVuIHRoZXJlIGlz IG5vIHBvaW50IHJlcXVpcmluZyB0aGUgb3ZlcnJpZGRlbiBwYXJhbXMgdG8gYmUgcHJlc2VudCBp biB0aGUgZmlsZSB3aXRoIGEgTVVTVCBvciBldmVuIGEgU0hPVUxELiBXaGF0IGFib3V0IHNheWlu ZzoNCiJBIHNob3J0ZXIgdXNlci11cmkgaXMgbW9yZSBsaWtlbHkgdG8gYXZvaWQgbW9iaWxlIGJy b3dzZXIgVVJJIGxlbmd0aCBsaW1pdHMsIGFuZCB0byByZWR1Y2UgYmFuZHdpZHRoIGFuZCBsYXRl bmN5IGZvciBtb2JpbGUgdHJhZmZpYy4gQ29uc2VxdWVudGx5LCBhcyBtYW55IHBhcmFtZXRlcnMg YXMgcHJhY3RpY2FsIHNob3VsZCBiZSBwcm92aWRlZCB0aHJvdWdoIHRoZSByZXF1ZXN0IGZpbGUs IGluc3RlYWQgb2YgZGlyZWN0bHkgaW4gdGhlIHVzZXItdXJpLiINCg0KDQoNCj4+PiBUaGUgInJl cXVlc3RfdXJsIiBNVVNUIGJlIHByb3ZpZGVkIGluIHRoZSBVUkwuDQo+PiBUaGlzIGlzbid0IHJl YWxseSBhICJNVVNUIiwgaXRzIGp1c3QgaW5kaWNhdGVzIGlmIHlvdSBhcmUgdXNpbmcgdGhpcyBm ZWF0dXJlICh0aGlzICJmbG93IikuDQoNCj4gSXQgaXMgYSBNVVNULiBXaXRob3V0IGl0LCB5b3Ug anVzdCBjYW5ub3Qgb2J0YWluIG90aGVyIHJlcXVpcmVkIHBhcmFtZXRlcnMuwqANCg0KV2l0aG91 dCBpdCB5b3UgYXJlIHVzaW5nICJub3JtYWwiIE9BdXRoMiAoYWxsIHRoZSBwYXJhbXMgaW4gdGhl IHVzZXItdXJpKSwgd2hpY2ggaXMgZmluZSBhbmQgc2hvdWxkbid0IHZpb2xhdGUgYSBNVVNULg0K SWYgdGhpcyBtZWNoYW5pc20gaXMgZGVmaW5lZCBpbiBhIHNlcGFyYXRlIHNwZWMgdGhlbiBJIGd1 ZXNzIGl0IGNvdWxkIGJlIGEgTVVTVCBmb3IgdGhhdCBzcGVjLiBFdmVuIGluIHRoYXQgY2FzZSwg dGhvdWdoLCBzZXJ2ZXJzIHRoYXQgc3VwcG9ydCByZXF1ZXN0X3VybCBzaG91bGRuJ3QgcmVqZWN0 IGludGVyYWN0aW9ucyB3aXRoIGFsbCB0aGUgcGFyYW1zIGRpcmVjdGx5IGluIHRoZSB1c2VyLXVy aS4NCg0KwqANCg0KPj4gV291bGQgYmUgZ29vZCB0byBzYXkgIkEgcmVxdWVzdF91cmwgcGFyYW0g TVVTVCBOT1QgYmUgcHJvdmlkZWQgaW4gYSByZXF1ZXN0IGZpbGUiLiBQcm9iYWJseSBnb29kIHRv IGFkZCAiQSByZXF1ZXN0IGZpbGUgTVVTVCBiZSByZWplY3RlZCBpZiBpdCBpbmNsdWRlcyBhIHJl cXVlc3RfdXJsIHBhcmFtIi4NCg0KPiByZXF1ZXN0X3VybCBwYXJhbSBNQVkgYmUgcHJvdmlkZWQg aW4gYSByZXF1ZXN0IGZpbGUuIEl0IGlzIGp1c3QgaXRzIGlkZW50aWZpZXIuIEl0IHByb2JhYmx5 IGlzIGJlc3QgdG8gYmUgdGhlcmUuwqANCg0KSXQgc291bmRzIGxpa2UgeW91IGFyZSBhc3N1bWlu ZyB0aGUgcmVxdWVzdF91cmwgaW4gdGhlIGZpbGUgaXMgdGhlIHNhbWUgYXMgdGhlIHJlcXVlc3Rf dXJsIGluIHVzZXItdXJpIHRoYXQgbGVkIHRvIHRoZSBmaWxlLiBUaGUgc2VydmVyIHRyZWF0cyBy ZXF1ZXN0X3VybCBpbiB1c2VyLXVyaSBhcyBhIHRyaWdnZXIgdG8gaW5jbHVkZSBtb3JlIHBhcmFt cywgYnV0IHRoZSBzZXJ2ZXIgdHJlYXRzIHJlcXVlc3RfdXJsIGluIHRoZSBmaWxlIGFzIG1lcmVs eSBhIG5hbWUgZm9yIHRoZSBmaWxlICh3aGljaCBpdCBpZ25vcmVzIGJlY2F1c2UgdGhlcmUgaXMg bm90aGluZyBmb3IgdGhlIHNlcnZlciB0byBkbyB3aXRoIHN1Y2ggYSBuYW1lKS4NCg0KVGhpcyBp cyBpbmNvbnNpc3RlbnQuDQoNCnJlcXVlc3RfdXJsIHNob3VsZCBiZSBhbiBpbmNsdWRlIG1lY2hh bmlzbSwgcmVnYXJkbGVzcyBvZiB3aGVyZSBpdCBhcHBlYXJzLiBJZiB3ZSBvbmx5IHdhbnQgdG8g c3VwcG9ydCBhbiBpbmNsdWRlIG1lY2hhbmlzbSBpbiB1c2VyLXVyaSwgYW5kIG5vdCBzdXBwb3J0 ZWQgbmVzdGVkIGluY2x1ZGVzLCB0aGVuIHdlIHNob3VsZCBleHBsaWNpdGx5IHNheSByZXF1ZXN0 X3VybCBNVVNUIE5PVCBhcHBlYXIgaW4gYSBmaWxlLg0KDQotLQ0KSmFtZXMgTWFuZ2VyDQo= From torsten@lodderstedt.net Fri Jun 4 00:27:27 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66A833A6961 for ; Fri, 4 Jun 2010 00:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.461 X-Spam-Level: X-Spam-Status: No, score=0.461 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GmsRWhd+L+0s for ; Fri, 4 Jun 2010 00:27:26 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.36]) by core3.amsl.com (Postfix) with ESMTP id 3DC2A3A6813 for ; Fri, 4 Jun 2010 00:27:26 -0700 (PDT) Received: from p4fff0aeb.dip.t-dialin.net ([79.255.10.235] helo=[127.0.0.1]) by smtprelay02.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OKRJ9-0007ei-1m; Fri, 04 Jun 2010 09:27:11 +0200 Message-ID: <4C08AACC.6050500@lodderstedt.net> Date: Fri, 04 Jun 2010 09:27:08 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Lukas Rosenstock References: <4BFAA6AB.8040809@lodderstedt.net> <4BFC3142.6010506@lodderstedt.net> <4BFC371A.5040109@lodderstedt.net> <4C07F407.4050305@lodderstedt.net> In-Reply-To: <4C07F407.4050305@lodderstedt.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] multiple access tokens from a single authorization flow? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 07:27:27 -0000 BTW: the security threat I described in point 4) not only holds for self-contained tokens but also for (super) handles. I consider it especially dangerous if abusing a service causes costs for the end-user. regards, Torsten. Am 03.06.2010 20:27, schrieb Torsten Lodderstedt: > I probably exaggerated a bit. It's not impossible but it is complex > and insecure for several reasons: > > 1) Such a super token would need to contain the union of all data and > permissions needed by all requested target services. > 2) Not all services may by authorized to see all data contained in > such a super token (privacy!). So, you would need to built different > service-specific (encrypted) compartments within the token. > 3) There are target-service-specific characteristics of such a token, > such as the audience and the signature. You would need to have such > attributes per service. Using public-key cryptography would relieve > this point but slow down processing. > 4) You have to (somehow) prevent a target service from _abusing_ this > token to access another service for which the super token is valid > for. The only way I see is the usage of the client secret. > > That's why I think, returning multiple tokens is much simpler. > > regards, > Torsten. > > Am 03.06.2010 20:10, schrieb Lukas Rosenstock: >> Hi! >> I'm curious why this is impossible. If access tokens are arbitrary >> handles which are generated by the authorization server and >> distributed to all resources, it doesn't make much difference whether >> one or multiple are generated and in this case it would be better to >> keep the load on the server rather complicating things for clients. >> In the scenario (as you have mentioned) where access tokens are >> self-contained and digitally signed, would it not be possible to >> generate a "super token" which contains signatures from all resources? >> I agree this token might be a bit lengthy, but is there any other >> concern?! >> >> Regards, >> Lukas >> >> 2010/5/25 Torsten Lodderstedt: >>> As I said, every service in our setup needs another access token, with >>> different content, signed and encrypted with another shared secret. >>> It is >>> technically impossible to create the super access token. Refresh >>> tokens are >>> just handles representing the user's authorization and are used by >>> the authz >>> server only. They therefore can represent any scope. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From Axel.Nennker@telekom.de Fri Jun 4 00:36:38 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36FC13A67DB for ; Fri, 4 Jun 2010 00:36:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XaXhIjIClARA for ; Fri, 4 Jun 2010 00:36:37 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by core3.amsl.com (Postfix) with ESMTP id E72B93A6928 for ; Fri, 4 Jun 2010 00:36:25 -0700 (PDT) Received: from s4de9jsaano.mgb.telekom.de (HELO S4DE9JSAANO.ost.t-com.de) ([10.125.177.105]) by tcmail51.telekom.de with ESMTP; 04 Jun 2010 09:36:05 +0200 Received: from S4DE9JSAAID.ost.t-com.de ([10.125.177.169]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Jun 2010 09:36:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 4 Jun 2010 09:36:01 +0200 Message-ID: <98B37F7D0484184B9DBDCC44B6C8EDA304B5283E@S4DE9JSAAID.ost.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] "3.4. Client Credentials" text change proposal Thread-Index: AcruaU1xpffKWVgsTs+Z2qdxzm4FjQVTzyMg References: From: To: , X-OriginalArrivalTime: 04 Jun 2010 07:36:03.0389 (UTC) FILETIME=[95E54ED0:01CB03B8] Subject: Re: [OAUTH-WG] "3.4. Client Credentials" text change proposal X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 07:36:38 -0000 +1=20 -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Nat Sakimura Sent: Saturday, May 08, 2010 6:45 AM To: oauth Subject: [OAUTH-WG] "3.4. Client Credentials" text change proposal 3.4. Client Credentials When requesting access from the authorization server, the client identifies itself using its authorization-server-issued client credentials. The Client Credentials does not necessarily be issued by the authorization server, but may be issued by the server that authorization server trusts. Thus, I would like to propose the text change as: 3.4. Client Credentials When requesting access from the authorization server, the client identifies itself using its authorization-server-verifiable client credentials. -- Nat Sakimura (=3Dnat) http://www.sakimura.org/en/ http://twitter.com/_nat_en _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From andrewarnott@gmail.com Fri Jun 4 05:56:24 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A9883A69B3 for ; Fri, 4 Jun 2010 05:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JoLnxHaZFm38 for ; Fri, 4 Jun 2010 05:56:23 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id E8EA33A699D for ; Fri, 4 Jun 2010 05:56:22 -0700 (PDT) Received: by gwb11 with SMTP id 11so805609gwb.31 for ; Fri, 04 Jun 2010 05:56:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=EFrFbyljbaUQ759pXEVeBVXwq3l39RH0jX7fC2HO9qY=; b=EkpmHW0rYFw5NYmqqXSNEuHMszPJuoXSiaLCUI+boliB0TrqcNpQVmPe9rIVqiemtg W4GeOCLxhgyQnz93ZJzypkT8MqLreymmgv7MsB9iF1YMTDyqxgH3S+RZ0aRH7s0cUJ2g b9EQ5oiCBeC2oiBzWdclVTR9nMGu3GxYS1DFA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=xgIVd3HnXghjxgPGvIlvNXs0+wfGnbr2VLPMIi+NPpTQY/HxZ6QkPx4GuoO5u6gH59 iHBsrHpBdvAIH80Gk9i5HCyVUWzoekrv0SfOeR4NFxY0yPfepi+drsD2EUDXkv97k2NR 6mrjif0qZDkq02s5+rCIJuhdhAwVSGpgpXSbg= MIME-Version: 1.0 Received: by 10.150.141.16 with SMTP id o16mr10227455ybd.207.1275656163492; Fri, 04 Jun 2010 05:56:03 -0700 (PDT) Received: by 10.151.26.19 with HTTP; Fri, 4 Jun 2010 05:56:03 -0700 (PDT) In-Reply-To: References: Date: Fri, 4 Jun 2010 05:56:03 -0700 Message-ID: From: Andrew Arnott To: "OAuth WG (oauth@ietf.org)" Content-Type: multipart/alternative; boundary=000e0cd7626a7b048b048833d82f Subject: Re: [OAUTH-WG] Definition of XML response format X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 12:56:24 -0000 --000e0cd7626a7b048b048833d82f Content-Type: text/plain; charset=ISO-8859-1 In the absence of anyone else volunteering an XML format, what would you say to this as a proposal (because the implementation of which happens to be simple for me): some access token some refresh token 235298298 So the main points here is: 1. no namespace 2. root tag is called "root" 3. each parameter is an element 4. each element has a type parameter that is either string, number, or object to assist the deserializer to understnad how to cast the contents. We may axe #4. In fact we may want to switch all the elements to attributes because it's slightly more compact which might help small devices. -- 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 Mon, May 31, 2010 at 9:12 AM, Andrew Arnott wrote: > Where is the definition of how a auth server response in XML format should > look? At the least we need an XML namespace and root node name. > > -- > 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 > --000e0cd7626a7b048b048833d82f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable In the absence of anyone else volunteering an XML format, what would you sa= y to this as a proposal (because the implementation of which happens to be = simple for me):

<root type=3D"object">
=A0=A0 <= ;access_token type=3D"string">some access token</access_tok= en>
=A0=A0 <refresh_token type=3D"string">some refresh token<= ;/refresh_token>
=A0=A0 <expires_in type=3D"number">2= 35298298</expires_in>
</root>

So the main points here= is:
  1. no namespace
  2. root tag is called "root"
  3. ea= ch parameter is an element
  4. each element has a type parameter that i= s either string, number, or object to assist the deserializer to understnad= how to cast the contents.
We may axe #4.=A0 In fact we may want to switch all the elements to at= tributes because it's slightly more compact which might help small devi= ces.

--
Andrew Arnott
"I [may] not agree wi= th what you have to say, but I'll defend to the death your right to say= it." - S. G. Tallentyre


On Mon, May 31, 2010 at 9:12 AM, Andrew = Arnott <andr= ewarnott@gmail.com> wrote:
Where is the definition of how a auth server response in XML format should = look?=A0 At the least we need an XML namespace and root node name.

--
Andrew Arnott
"I [may] n= ot agree with what you have to say, but I'll defend to the death your r= ight to say it." - S. G. Tallentyre

--000e0cd7626a7b048b048833d82f-- From gffletch@aol.com Fri Jun 4 06:35:31 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B343C3A6A5C for ; Fri, 4 Jun 2010 06:35:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.695 X-Spam-Level: X-Spam-Status: No, score=-0.695 tagged_above=-999 required=5 tests=[AWL=-0.697, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qWcyQYamCX1G for ; Fri, 4 Jun 2010 06:35:30 -0700 (PDT) Received: from imr-ma04.mx.aol.com (imr-ma04.mx.aol.com [64.12.206.42]) by core3.amsl.com (Postfix) with ESMTP id 6E4673A69BE for ; Fri, 4 Jun 2010 06:35:30 -0700 (PDT) Received: from mtaout-mb02.r1000.mx.aol.com (mtaout-mb02.r1000.mx.aol.com [172.29.41.66]) by imr-ma04.mx.aol.com (8.14.1/8.14.1) with ESMTP id o54DYtAx031681; Fri, 4 Jun 2010 09:34:55 -0400 Received: from palantir.local (unknown [10.181.183.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-mb02.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id E6905E0000BF; Fri, 4 Jun 2010 09:34:54 -0400 (EDT) Message-ID: <4C0900FD.3050904@aol.com> Date: Fri, 04 Jun 2010 09:34:53 -0400 From: George Fletcher Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Andrew Arnott References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------000100050203080707070300" x-aol-global-disposition: G X-AOL-SCOLL-SCORE: 0:2:450453792:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d29424c0900fe5f85 X-AOL-IP: 10.181.183.108 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Definition of XML response format X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 13:35:31 -0000 This is a multi-part message in MIME format. --------------000100050203080707070300 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I don't know if this is helpful or not... but there was a proposed extension for OAuth 1.0 dealing with encoding OAuth responses in different body formats... this can be found on the now extinct oauth-extensions google group. http://groups.google.com/group/oauth-extensions/browse_thread/thread/419ec4e986ff5cd8?hl=en# Thanks, George On 6/4/10 8:56 AM, Andrew Arnott wrote: > In the absence of anyone else volunteering an XML format, what would > you say to this as a proposal (because the implementation of which > happens to be simple for me): > > > some access token > some refresh token > 235298298 > > > So the main points here is: > > 1. no namespace > 2. root tag is called "root" > 3. each parameter is an element > 4. each element has a type parameter that is either string, number, > or object to assist the deserializer to understnad how to cast > the contents. > > We may axe #4. In fact we may want to switch all the elements to > attributes because it's slightly more compact which might help small > devices. > > -- > 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 Mon, May 31, 2010 at 9:12 AM, Andrew Arnott > wrote: > > Where is the definition of how a auth server response in XML > format should look? At the least we need an XML namespace and > root node name. > > -- > 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 > --------------000100050203080707070300 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I don't know if this is helpful or not... but there was a proposed extension for OAuth 1.0 dealing with encoding OAuth responses in different body formats... this can be found on the now extinct oauth-extensions google group.

http://groups.google.com/group/oauth-extensions/browse_thread/thread/419ec4e986ff5cd8?hl=en#

Thanks,
George

On 6/4/10 8:56 AM, Andrew Arnott wrote:
In the absence of anyone else volunteering an XML format, what would you say to this as a proposal (because the implementation of which happens to be simple for me):

<root type="object">
   <access_token type="string">some access token</access_token>
   <refresh_token type="string">some refresh token</refresh_token>
   <expires_in type="number">235298298</expires_in>
</root>

So the main points here is:
  1. no namespace
  2. root tag is called "root"
  3. each parameter is an element
  4. each element has a type parameter that is either string, number, or object to assist the deserializer to understnad how to cast the contents.
We may axe #4.  In fact we may want to switch all the elements to attributes because it's slightly more compact which might help small devices.

--
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 Mon, May 31, 2010 at 9:12 AM, Andrew Arnott <andrewarnott@gmail.com> wrote:
Where is the definition of how a auth server response in XML format should look?  At the least we need an XML namespace and root node name.

--
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
--------------000100050203080707070300-- From andrewarnott@gmail.com Fri Jun 4 06:38:02 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 622FB3A68D4 for ; Fri, 4 Jun 2010 06:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.648 X-Spam-Level: X-Spam-Status: No, score=-0.648 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lpWNNfwQb+iU for ; Fri, 4 Jun 2010 06:38:01 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 1EB853A6A68 for ; Fri, 4 Jun 2010 06:38:01 -0700 (PDT) Received: by gwb11 with SMTP id 11so849574gwb.31 for ; Fri, 04 Jun 2010 06:37:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=qmnby75rQiZlcbGjRA9SZcEDj17YS4kioKllBykYCIs=; b=H0ZTncE8x3F4k0spKeDd/7RJOs2l33tPExC0zPdQovaddPiiffcOdwWDU568oH8U7P o6akux+Sdu0SLAxFthQF6qSYNSIawal/ay7R5y4vdvZs32CG6x9N4QYO5TmECdh4skUK n9Q7Hh7owWeCr+ZdAfRheaGX2gAzj07eaOeNs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=HL+2K6EHImm1+Hs1JJLQJvo4dvvPTzH5rlNb1gSWq8Ut64l7H+eEaoiDxiK9mb3sXT xVWP++jiKLxGpNxmMAUgHqH9SLNQK66DxU5BlB28FjSe+kM1yk/3efAbK+LD8DNtYwr+ IMiLgyX75G5pI2y8eRqre8RUWKOoRc8B+gdrc= MIME-Version: 1.0 Received: by 10.150.249.6 with SMTP id w6mr10265893ybh.157.1275658663614; Fri, 04 Jun 2010 06:37:43 -0700 (PDT) Received: by 10.151.26.19 with HTTP; Fri, 4 Jun 2010 06:37:43 -0700 (PDT) Date: Fri, 4 Jun 2010 06:37:43 -0700 Message-ID: From: Andrew Arnott To: "OAuth WG (oauth@ietf.org)" Content-Type: multipart/alternative; boundary=000e0cd5cbf87fd8170488346d30 Subject: [OAUTH-WG] Partially standardized format for access tokens? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 13:38:02 -0000 --000e0cd5cbf87fd8170488346d30 Content-Type: text/plain; charset=ISO-8859-1 Having just implemented OAuth 2.0 web server flow, it was great to be able to issue an "opaque" access token to the client. This access token is in an encrypted format that only the resource server understands. I feel pretty good about this approach as it lends to high security and tokens that only the client needs to store (or not at all). But I'm wondering about the resource server that trusts multiple auth servers, which each have their own access token format. Without even a standardized way for an access token to express what format it is in, a resource server may have to just try decoding the token each known way until one "works". Proposal: perhaps the access token can be *mostly* opaque, but not quite. For instance: The access token is in the format: *format=URI&opaquevalue* Where URI is an arbitrary URI assigned by the auth server to assist the resource server in interpreting the *opaquevalue* part of the token. Feedback? -- 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 --000e0cd5cbf87fd8170488346d30 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Having just implemented OAuth 2.0 web server flow, it was great to be able = to issue an "opaque" access token to the client.=A0 This access t= oken is in an encrypted format that only the resource server understands.= =A0 I feel pretty good about this approach as it lends to high security and= tokens that only the client needs to store (or not at all).

But I'm wondering about the resource server that trusts multiple au= th servers, which each have their own access token format.=A0 Without even = a standardized way for an access token to express what format it is in, a r= esource server may have to just try decoding the token each known way until= one "works".=A0

Proposal: perhaps the access token can be mostly opaque, but not= quite.=A0 For instance:
The access t= oken is in the format:=A0 format=3DURI&opaquevalue
Where URI = is an arbitrary URI assigned by the auth server to assist the resource serv= er in interpreting the opaquevalue part of the token.

Feedback?

--
Andrew Arnott
"I [ma= y] not agree with what you have to say, but I'll defend to the death yo= ur right to say it." - S. G. Tallentyre
--000e0cd5cbf87fd8170488346d30-- From andrewarnott@gmail.com Fri Jun 4 06:43:06 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A428D28C125 for ; Fri, 4 Jun 2010 06:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.372 X-Spam-Level: X-Spam-Status: No, score=-0.372 tagged_above=-999 required=5 tests=[AWL=-0.374, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cTrjT+0ugdfE for ; Fri, 4 Jun 2010 06:43:05 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 6614928C124 for ; Fri, 4 Jun 2010 06:43:05 -0700 (PDT) Received: by yxt33 with SMTP id 33so557811yxt.31 for ; Fri, 04 Jun 2010 06:42:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=r6V+2MBO/3I2DQGwY4Hkbc/aQznPlkE8r4fgU19/acE=; b=EcUiS2rngmhlhMXb6yjvGg8gPxSr5u3lz0mI6x1/vZoGReMAjBNS0BOPgCTxg2hpQZ ukc2AakaPSYxBRvCy3FAzAxOwD328G8p/wxbAQXcVxGaHYkmezzkE6UYw9GWvik1lyL3 wBCq1h9SXC+rTmy/B6xepDqDhy2j4mRF5hQ5k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=kKNu10q8j0th0Ze9se7vmM97lz4MsQ4j83B7voLkLep9Bejj2kmDfM0Y7kuoCuS284 aJUVKte+Icqt7rQlwbrfznhNRoHhu0xKR6bYFoF2lp1FzwPGm1W5+wyND4mGOEJ4D7IF oUHfHrQ4xxpeSvtFo3FgUmrRSF7ReUJPoSq0I= MIME-Version: 1.0 Received: by 10.150.244.10 with SMTP id r10mr18174ybh.414.1275658969004; Fri, 04 Jun 2010 06:42:49 -0700 (PDT) Received: by 10.151.26.19 with HTTP; Fri, 4 Jun 2010 06:42:48 -0700 (PDT) In-Reply-To: <4C0900FD.3050904@aol.com> References: <4C0900FD.3050904@aol.com> Date: Fri, 4 Jun 2010 06:42:48 -0700 Message-ID: From: Andrew Arnott To: George Fletcher Content-Type: multipart/alternative; boundary=000e0cd28982b3bbf80488347fae Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Definition of XML response format X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 13:43:06 -0000 --000e0cd28982b3bbf80488347fae Content-Type: text/plain; charset=ISO-8859-1 Thanks, George. From that I get this: token secret >From the text around it, it sounds like SPs were permitted to add to this (presumably using their own element names). While this seems reasonable, it seems that SP-specific extensions that used alternate element names would then be incompatible with JSON and url-encoded responses since they cannot include this extra element metadata. (well JSON could, with some breaking changes to the format). So with that, it seems like we should eliminate the redundant oauth_parameter element name in favor of just using the name of the parameter as the element name. -- 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 Fri, Jun 4, 2010 at 6:34 AM, George Fletcher wrote: > I don't know if this is helpful or not... but there was a proposed > extension for OAuth 1.0 dealing with encoding OAuth responses in different > body formats... this can be found on the now extinct oauth-extensions google > group. > > > http://groups.google.com/group/oauth-extensions/browse_thread/thread/419ec4e986ff5cd8?hl=en# > > Thanks, > George > > On 6/4/10 8:56 AM, Andrew Arnott wrote: > > In the absence of anyone else volunteering an XML format, what would you > say to this as a proposal (because the implementation of which happens to be > simple for me): > > > some access token > some refresh token > 235298298 > > > So the main points here is: > > 1. no namespace > 2. root tag is called "root" > 3. each parameter is an element > 4. each element has a type parameter that is either string, number, or > object to assist the deserializer to understnad how to cast the contents. > > We may axe #4. In fact we may want to switch all the elements to > attributes because it's slightly more compact which might help small > devices. > > -- > 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 Mon, May 31, 2010 at 9:12 AM, Andrew Arnott wrote: > >> Where is the definition of how a auth server response in XML format should >> look? At the least we need an XML namespace and root node name. >> >> -- >> 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 listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > --000e0cd28982b3bbf80488347fae Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks, George.=A0 From that I get this:
<response>
	<o=
auth_parameter name=3D"oauth_token">token</oauth_parameter&=
gt;
	<oauth_parameter name=3D"oauth_token_secret">secret=
</oauth_parameter>

</response>
From the text around it, it sounds like SPs were= permitted to add to this (presumably using their own element names).=A0 Wh= ile this seems reasonable, it seems that SP-specific extensions that used a= lternate element names would then be incompatible with JSON and url-encoded= responses since they cannot include this extra element metadata.=A0 (well = JSON could, with some breaking changes to the format).

So with that, it seems like we should eliminate the redundant oauth_par= ameter element name in favor of just using the name of the parameter as the= element name.

--
Andrew Arnott
"I [may] no= t agree with what you have to say, but I'll defend to the death your ri= ght to say it." - S. G. Tallentyre


On Fri, Jun 4, 2010 at 6:34 AM, George F= letcher <gffletch@= aol.com> wrote:
=20
I don't know if this is helpful or not... but there was a proposed extension for OAuth 1.0 dealing with encoding OAuth responses in different body formats... this can be found on the now extinct oauth-extensions google group.

http://groups.google.com/= group/oauth-extensions/browse_thread/thread/419ec4e986ff5cd8?hl=3Den#
Thanks,
George

On 6/4/10 8:56 AM, Andrew Arnott wrote:
In = the absence of anyone else volunteering an XML format, what would you say to this as a proposal (because the implementation of which happens to be simple for me):

<root type=3D"object">
=A0=A0 <access_token type=3D"string">some access token</access_token>
=A0=A0 <refresh_token type=3D"string">some refresh token</refresh_token>
=A0=A0 <expires_in type=3D"number">235298298</expires_in= >
</root>

So the main points here is:
  1. no namespace
  2. root tag is called "root"
  3. each parameter is an element
  4. each element has a type parameter that is either string, number, or object to assist the deserializer to understnad how to cast the contents.
We may axe #4.=A0 In fact we may want to switch all the elements to attributes because it's slightly more compact which might help small devices.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to t= he death your right to say it." - S. G. Tallentyre


On Mon, May 31, 2010 at 9:12 AM, Andrew Arnott <andrewarnott@gmail.com> wrote:
Where is the definition of how a auth server response in XML format should look?=A0 At the least we need an XML namespace and root node name.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to t= he death your right to say it." - S. G. Tallentyre


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

--000e0cd28982b3bbf80488347fae-- From lshepard@facebook.com Fri Jun 4 06:54:13 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E94B28C121 for ; Fri, 4 Jun 2010 06:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.989 X-Spam-Level: X-Spam-Status: No, score=-0.989 tagged_above=-999 required=5 tests=[AWL=-0.325, BAYES_50=0.001, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XK9VwDfvnTUn for ; Fri, 4 Jun 2010 06:54:12 -0700 (PDT) Received: from mailout-snc1.facebook.com (mailout-snc1.facebook.com [69.63.179.25]) by core3.amsl.com (Postfix) with ESMTP id 944193A677E for ; Fri, 4 Jun 2010 06:54:12 -0700 (PDT) Received: from mail.thefacebook.com ([192.168.18.198]) by pp01.snc1.tfbnw.net (8.14.3/8.14.3) with ESMTP id o54DrUEc026629 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 4 Jun 2010 06:53:30 -0700 Received: from sc-hub01.TheFacebook.com (192.168.18.104) by sc-hub03.TheFacebook.com (192.168.18.198) with Microsoft SMTP Server (TLS) id 14.0.694.1; Fri, 4 Jun 2010 06:53:50 -0700 Received: from SC-MBXC1.TheFacebook.com ([192.168.18.102]) by sc-hub01.TheFacebook.com ([192.168.18.104]) with mapi; Fri, 4 Jun 2010 06:53:12 -0700 From: Luke Shepard To: Andrew Arnott Date: Fri, 4 Jun 2010 06:53:26 -0700 Thread-Topic: [OAUTH-WG] Partially standardized format for access tokens? Thread-Index: AcsD7UXcjjLOYcgYRJaUE5C8bsDvRQ== 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: multipart/alternative; boundary="_000_B549E6C4A24D40328A2689ED58EBAA34facebookcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-06-04_01:2010-02-06, 2010-06-04, 2010-06-04 signatures=0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Partially standardized format for access tokens? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 13:54:13 -0000 --_000_B549E6C4A24D40328A2689ED58EBAA34facebookcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Having a single resource server that works with multiple independent auth s= ervers is not in scope for OAuth. That said, there's nothing to stop multip= le servers to agree amongst themselves to have a standardized format for ac= cess token- and if necessary, to write that agreement as a separate spec (p= erhaps an extension). In particular, I wouldn't like your proposal because of the use of equals a= nd ampersand, both of which would need to be URL encoded so developers coul= dn't copy/paste the token as easily. For Facebook, it's important that the = access tokens are as short as possible; other sites may have different requ= irements. On Jun 4, 2010, at 6:37 AM, Andrew Arnott wrote: Having just implemented OAuth 2.0 web server flow, it was great to be able = to issue an "opaque" access token to the client. This access token is in a= n encrypted format that only the resource server understands. I feel prett= y good about this approach as it lends to high security and tokens that onl= y the client needs to store (or not at all). But I'm wondering about the resource server that trusts multiple auth serve= rs, which each have their own access token format. Without even a standard= ized way for an access token to express what format it is in, a resource se= rver may have to just try decoding the token each known way until one "work= s". Proposal: perhaps the access token can be mostly opaque, but not quite. Fo= r instance: The access token is in the format: format=3DURI&opaquevalue Where URI is an arbitrary URI assigned by the auth server to assist the res= ource server in interpreting the opaquevalue part of the token. Feedback? -- 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 --_000_B549E6C4A24D40328A2689ED58EBAA34facebookcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Having a single resou= rce server that works with multiple independent auth servers is not in scop= e for OAuth. That said, there's nothing to stop multiple servers to agree a= mongst themselves to have a standardized format for access token- and if ne= cessary, to write that agreement as a separate spec (perhaps an extension).=

In particular, I wouldn't like your proposal beca= use of the use of equals and ampersand, both of which would need to be URL = encoded so developers couldn't copy/paste the token as easily. For Facebook= , it's important that the access tokens are as short as possible; other sit= es may have different requirements.

On Jun 4, 2010, at 6= :37 AM, Andrew Arnott wrote:

<= blockquote type=3D"cite">Having just implemented OAuth 2.0 web server flow,= it was great to be able to issue an "opaque" access token to the client.&n= bsp; This access token is in an encrypted format that only the resource ser= ver understands.  I feel pretty good about this approach as it lends t= o high security and tokens that only the client needs to store (or not at a= ll).

But I'm wondering about the resource server that trusts multiple auth s= ervers, which each have their own access token format.  Without even a= standardized way for an access token to express what format it is in, a re= source server may have to just try decoding the token each known way until = one "works". 

Proposal: perhaps the access token can be mostly opaque, but not= quite.  For instance:
The acces= s token is in the format:  format=3DURI&opaquevalue
Wher= e URI is an arbitrary URI assigned by the auth server to assist the resourc= e server in interpreting the opaquevalue part of the token.

Feedback?

--
Andrew Arnott
"I [may] no= t agree with what you have to say, but I'll defend to the death your right = to say it." - S. G. Tallentyre
<ATT00001..txt>

= --_000_B549E6C4A24D40328A2689ED58EBAA34facebookcom_-- From torsten@lodderstedt.net Fri Jun 4 07:06:14 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAEFD3A6A69 for ; Fri, 4 Jun 2010 07:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.454 X-Spam-Level: X-Spam-Status: No, score=0.454 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_50=0.001, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9oxeAJTmPIqd for ; Fri, 4 Jun 2010 07:06:09 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.31]) by core3.amsl.com (Postfix) with ESMTP id 374023A68D4 for ; Fri, 4 Jun 2010 07:06:08 -0700 (PDT) Received: from p4fff0aeb.dip.t-dialin.net ([79.255.10.235] helo=[127.0.0.1]) by smtprelay04.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OKXX0-0001Oj-Dk; Fri, 04 Jun 2010 16:05:54 +0200 Message-ID: <4C090841.6050208@lodderstedt.net> Date: Fri, 04 Jun 2010 16:05:53 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Andrew Arnott References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------030609030104050904020703" X-Df-Sender: 141509 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Partially standardized format for access tokens? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 14:06:14 -0000 This is a multi-part message in MIME format. --------------030609030104050904020703 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit +1, but why only partially? I would like to add another use case for a standardized token format. Suppose a software vendor wants to built and sell a standard software component (service), e.g. an address book service, which is secured using OAuth2. Having a standardized token format would make the integration of that "standard software" within customer deployments easier. Indeed, the customers authorization server must "speak" that token format. SAML would be a natural candidate from my point of view, a more compact variant (based on JSON?) would be fine. I think, a standard token format should be covered in a separate specification. regards, Torsten. Am 04.06.2010 15:37, schrieb Andrew Arnott: > Having just implemented OAuth 2.0 web server flow, it was great to be > able to issue an "opaque" access token to the client. This access > token is in an encrypted format that only the resource server > understands. I feel pretty good about this approach as it lends to > high security and tokens that only the client needs to store (or not > at all). > > But I'm wondering about the resource server that trusts multiple auth > servers, which each have their own access token format. Without even > a standardized way for an access token to express what format it is > in, a resource server may have to just try decoding the token each > known way until one "works". > > Proposal: perhaps the access token can be /mostly/ opaque, but not > quite. For instance: > The access token is in the format: /format=URI&opaquevalue/ > Where URI is an arbitrary URI assigned by the auth server to assist > the resource server in interpreting the /opaquevalue/ part of the token. > > Feedback? > > -- > 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 > --------------030609030104050904020703 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit +1, but why only partially?

I would like to add another use case for a standardized token format. Suppose a software vendor wants to built and sell a standard software component (service), e.g. an address book service, which is secured using OAuth2.  Having a standardized token format would make the integration of that "standard software" within customer deployments easier. Indeed, the customers authorization server must "speak" that token format.

SAML would be a natural candidate from my point of view, a more compact variant (based on JSON?) would be fine.

I think, a standard token format should be covered in a separate specification.

regards,
Torsten.

Am 04.06.2010 15:37, schrieb Andrew Arnott:
Having just implemented OAuth 2.0 web server flow, it was great to be able to issue an "opaque" access token to the client.  This access token is in an encrypted format that only the resource server understands.  I feel pretty good about this approach as it lends to high security and tokens that only the client needs to store (or not at all).

But I'm wondering about the resource server that trusts multiple auth servers, which each have their own access token format.  Without even a standardized way for an access token to express what format it is in, a resource server may have to just try decoding the token each known way until one "works". 

Proposal: perhaps the access token can be mostly opaque, but not quite.  For instance:
The access token is in the format:  format=URI&opaquevalue
Where URI is an arbitrary URI assigned by the auth server to assist the resource server in interpreting the opaquevalue part of the token.

Feedback?

--
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
--------------030609030104050904020703-- From gffletch@aol.com Fri Jun 4 07:06:55 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E8413A6A01 for ; Fri, 4 Jun 2010 07:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7CnXcLGbJyTX for ; Fri, 4 Jun 2010 07:06:52 -0700 (PDT) Received: from imr-db01.mx.aol.com (imr-db01.mx.aol.com [205.188.91.95]) by core3.amsl.com (Postfix) with ESMTP id 6531B28C0F8 for ; Fri, 4 Jun 2010 07:06:51 -0700 (PDT) Received: from mtaout-ma03.r1000.mx.aol.com (mtaout-ma03.r1000.mx.aol.com [172.29.41.3]) by imr-db01.mx.aol.com (8.14.1/8.14.1) with ESMTP id o54E6NnQ025552; Fri, 4 Jun 2010 10:06:23 -0400 Received: from palantir.local (unknown [10.181.183.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-ma03.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 4FE31E0000A0; Fri, 4 Jun 2010 10:06:23 -0400 (EDT) Message-ID: <4C09085E.4020906@aol.com> Date: Fri, 04 Jun 2010 10:06:22 -0400 From: George Fletcher Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Andrew Arnott References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------040504040507080303000909" x-aol-global-disposition: G X-AOL-SCOLL-SCORE: 0:2:389101568:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d29034c09085f096d X-AOL-IP: 10.181.183.108 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Partially standardized format for access tokens? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 14:06:55 -0000 This is a multi-part message in MIME format. --------------040504040507080303000909 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit +1 to some standardization to the token The URI would also allow for discovery and the ability for the provider to define an endpoint in the XRD for the URI that allows "dumb mode" token validation. This way, even if the resource owner doesn't know how to "crack" the token locally, they could ask the provider to do it for them. Thanks, George On 6/4/10 9:37 AM, Andrew Arnott wrote: > Having just implemented OAuth 2.0 web server flow, it was great to be > able to issue an "opaque" access token to the client. This access > token is in an encrypted format that only the resource server > understands. I feel pretty good about this approach as it lends to > high security and tokens that only the client needs to store (or not > at all). > > But I'm wondering about the resource server that trusts multiple auth > servers, which each have their own access token format. Without even > a standardized way for an access token to express what format it is > in, a resource server may have to just try decoding the token each > known way until one "works". > > Proposal: perhaps the access token can be /mostly/ opaque, but not > quite. For instance: > The access token is in the format: /format=URI&opaquevalue/ > Where URI is an arbitrary URI assigned by the auth server to assist > the resource server in interpreting the /opaquevalue/ part of the token. > > Feedback? > > -- > 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 > --------------040504040507080303000909 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit +1 to some standardization to the token

The URI would also allow for discovery and the ability for the provider to define an endpoint in the XRD for the URI that allows "dumb mode" token validation. This way, even if the resource owner doesn't know how to "crack" the token locally, they could ask the provider to do it for them.

Thanks,
George

On 6/4/10 9:37 AM, Andrew Arnott wrote:
Having just implemented OAuth 2.0 web server flow, it was great to be able to issue an "opaque" access token to the client.  This access token is in an encrypted format that only the resource server understands.  I feel pretty good about this approach as it lends to high security and tokens that only the client needs to store (or not at all).

But I'm wondering about the resource server that trusts multiple auth servers, which each have their own access token format.  Without even a standardized way for an access token to express what format it is in, a resource server may have to just try decoding the token each known way until one "works". 

Proposal: perhaps the access token can be mostly opaque, but not quite.  For instance:
The access token is in the format:  format=URI&opaquevalue
Where URI is an arbitrary URI assigned by the auth server to assist the resource server in interpreting the opaquevalue part of the token.

Feedback?

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

--------------040504040507080303000909-- From gffletch@aol.com Fri Jun 4 07:15:00 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECEEC3A68D4 for ; Fri, 4 Jun 2010 07:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kCTDnLFVqyNi for ; Fri, 4 Jun 2010 07:14:53 -0700 (PDT) Received: from omr-d33.mx.aol.com (omr-d33.mx.aol.com [205.188.249.131]) by core3.amsl.com (Postfix) with ESMTP id AB19028C125 for ; Fri, 4 Jun 2010 07:14:52 -0700 (PDT) Received: from oms-db01.r1000.mx.aol.com (oms-db01.r1000.mx.aol.com [205.188.58.1]) by omr-d33.mx.aol.com (8.14.1/8.14.1) with ESMTP id o54ED58q017265; Fri, 4 Jun 2010 10:13:05 -0400 Received: from mtaout-ma03.r1000.mx.aol.com (mtaout-ma03.r1000.mx.aol.com [172.29.41.3]) by oms-db01.r1000.mx.aol.com (AOL Outbound OMS Interface) with ESMTP id D30E81C000082; Fri, 4 Jun 2010 10:13:05 -0400 (EDT) Received: from palantir.local (unknown [10.181.183.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-ma03.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 821DBE00010C; Fri, 4 Jun 2010 10:13:03 -0400 (EDT) Message-ID: <4C0909EF.50303@aol.com> Date: Fri, 04 Jun 2010 10:13:03 -0400 From: George Fletcher Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "OAuth WG (oauth@ietf.org)" References: <4C0900FD.3050904@aol.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090206050904080606040403" x-aol-global-disposition: S X-AOL-SCOLL-SCORE: 0:2:462975616:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d29034c0909ef1603 X-AOL-IP: 10.181.183.108 Subject: Re: [OAUTH-WG] Definition of XML response format X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 14:15:00 -0000 This is a multi-part message in MIME format. --------------090206050904080606040403 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit So, now that OAuth 2 is not solely SP-centric, it probably makes sense to change some of the encoding (this was written in 2008) :) Also, the interaction with the Authorization server is more constrained than the interaction with the resource owner so that also allows for simplification. I do think that even in the calls with the Authorization server there is going to be the need to add parameters via some profiling/extension mechanism. Is your thought that those documents would describe the XML and JSON structures as well? As an aside, we also support PHP and Flash serialization. Do we need separate docs for each format so that it can be native? I think the approach of the extension was to provide a generic container. Not as pretty but maybe transformable across formats. Thanks, George On 6/4/10 9:42 AM, Andrew Arnott wrote: > Thanks, George. From that I get this: > > token > secret > > > > From the text around it, it sounds like SPs were permitted to add to > this (presumably using their own element names). While this seems > reasonable, it seems that SP-specific extensions that used alternate > element names would then be incompatible with JSON and url-encoded > responses since they cannot include this extra element metadata. > (well JSON could, with some breaking changes to the format). > > So with that, it seems like we should eliminate the redundant > oauth_parameter element name in favor of just using the name of the > parameter as the element name. > > -- > 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 Fri, Jun 4, 2010 at 6:34 AM, George Fletcher > wrote: > > I don't know if this is helpful or not... but there was a proposed > extension for OAuth 1.0 dealing with encoding OAuth responses in > different body formats... this can be found on the now extinct > oauth-extensions google group. > > http://groups.google.com/group/oauth-extensions/browse_thread/thread/419ec4e986ff5cd8?hl=en# > > Thanks, > George > > On 6/4/10 8:56 AM, Andrew Arnott wrote: >> In the absence of anyone else volunteering an XML format, what >> would you say to this as a proposal (because the implementation >> of which happens to be simple for me): >> >> >> some access token >> some refresh token >> 235298298 >> >> >> So the main points here is: >> >> 1. no namespace >> 2. root tag is called "root" >> 3. each parameter is an element >> 4. each element has a type parameter that is either string, >> number, or object to assist the deserializer to understnad >> how to cast the contents. >> >> We may axe #4. In fact we may want to switch all the elements to >> attributes because it's slightly more compact which might help >> small devices. >> >> -- >> 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 Mon, May 31, 2010 at 9:12 AM, Andrew Arnott >> > wrote: >> >> Where is the definition of how a auth server response in XML >> format should look? At the least we need an XML namespace >> and root node name. >> >> -- >> 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 >> > > -- Chief Architect AIM: gffletch Identity Services Engineering Work: george.fletcher@corp.aol.com AOL Inc. Home: gffletch@aol.com Mobile: +1-703-462-3494 Blog: http://practicalid.blogspot.com Office: +1-703-265-2544 Twitter: http://twitter.com/gffletch --------------090206050904080606040403 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit So, now that OAuth 2 is not solely SP-centric, it probably makes sense to change some of the encoding (this was written in 2008) :)  Also, the interaction with the Authorization server is more constrained than the interaction with the resource owner so that also allows for simplification.

I do think that even in the calls with the Authorization server there is going to be the need to add parameters via some profiling/extension mechanism. Is your thought that those documents would describe the XML and JSON structures as well?

As an aside, we also support PHP and Flash serialization. Do we need separate docs for each format so that it can be native? I think the approach of the extension was to provide a generic container. Not as pretty but maybe transformable across formats.

Thanks,
George

On 6/4/10 9:42 AM, Andrew Arnott wrote:
Thanks, George.  From that I get this:
<response>
    <oauth_parameter name="oauth_token">token</oauth_parameter>
 <oauth_parameter name="oauth_token_secret">secret</oauth_parameter>

</response>
>From the text around it, it sounds like SPs were permitted to add to this (presumably using their own element names).  While this seems reasonable, it seems that SP-specific extensions that used alternate element names would then be incompatible with JSON and url-encoded responses since they cannot include this extra element metadata.  (well JSON could, with some breaking changes to the format).

So with that, it seems like we should eliminate the redundant oauth_parameter element name in favor of just using the name of the parameter as the element name.

--
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 Fri, Jun 4, 2010 at 6:34 AM, George Fletcher <gffletch@aol.com> wrote:
I don't know if this is helpful or not... but there was a proposed extension for OAuth 1.0 dealing with encoding OAuth responses in different body formats... this can be found on the now extinct oauth-extensions google group.

http://groups.google.com/group/oauth-extensions/browse_thread/thread/419ec4e986ff5cd8?hl=en#

Thanks,
George

On 6/4/10 8:56 AM, Andrew Arnott wrote:
In the absence of anyone else volunteering an XML format, what would you say to this as a proposal (because the implementation of which happens to be simple for me):

<root type="object">
   <access_token type="string">some access token</access_token>
   <refresh_token type="string">some refresh token</refresh_token>
   <expires_in type="number">235298298</expires_in>
</root>

So the main points here is:
  1. no namespace
  2. root tag is called "root"
  3. each parameter is an element
  4. each element has a type parameter that is either string, number, or object to assist the deserializer to understnad how to cast the contents.
We may axe #4.  In fact we may want to switch all the elements to attributes because it's slightly more compact which might help small devices.

--
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 Mon, May 31, 2010 at 9:12 AM, Andrew Arnott <andrewarnott@gmail.com> wrote:
Where is the definition of how a auth server response in XML format should look?  At the least we need an XML namespace and root node name.

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


-- 
Chief Architect                   AIM:  gffletch
Identity Services Engineering     Work: george.fletcher@corp.aol.com
AOL Inc.                          Home: gffletch@aol.com
Mobile: +1-703-462-3494           Blog: http://practicalid.blogspot.com
Office: +1-703-265-2544           Twitter: http://twitter.com/gffletch
--------------090206050904080606040403-- From gffletch@aol.com Fri Jun 4 07:20:03 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77B2528C0DD for ; Fri, 4 Jun 2010 07:20:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QhzlH-KP79-k for ; Fri, 4 Jun 2010 07:20:02 -0700 (PDT) Received: from imr-da05.mx.aol.com (imr-da05.mx.aol.com [205.188.105.147]) by core3.amsl.com (Postfix) with ESMTP id D004C28C0D0 for ; Fri, 4 Jun 2010 07:20:01 -0700 (PDT) Received: from mtaout-ma02.r1000.mx.aol.com (mtaout-ma02.r1000.mx.aol.com [172.29.41.2]) by imr-da05.mx.aol.com (8.14.1/8.14.1) with ESMTP id o54EJJEX027580; Fri, 4 Jun 2010 10:19:25 -0400 Received: from palantir.local (unknown [10.181.183.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-ma02.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id DC141E0000D2; Fri, 4 Jun 2010 10:19:24 -0400 (EDT) Message-ID: <4C090B6C.9030707@aol.com> Date: Fri, 04 Jun 2010 10:19:24 -0400 From: George Fletcher Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Luke Shepard References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------000003010003030400080605" x-aol-global-disposition: G X-AOL-SCOLL-SCORE: 0:2:341162592:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d29024c090b6c2db0 X-AOL-IP: 10.181.183.108 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Partially standardized format for access tokens? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 14:20:03 -0000 This is a multi-part message in MIME format. --------------000003010003030400080605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 6/4/10 9:53 AM, Luke Shepard wrote: > Having a single resource server that works with multiple independent > auth servers is not in scope for OAuth. That said, there's nothing to > stop multiple servers to agree amongst themselves to have a > standardized format for access token- and if necessary, to write that > agreement as a separate spec (perhaps an extension). -1 limiting OAuth to a single Authorization Server (AS) and it's associated SPs (resource owners) significantly restricts the value of delegation across the internet. On the other hand, if OAuth allows for cross AS token processing, then it becomes very easy for me to protect my photo album while not requiring that all those I've shared it with to have an account at my photo service (as one example; there are many more). Thanks, George > > In particular, I wouldn't like your proposal because of the use of > equals and ampersand, both of which would need to be URL encoded so > developers couldn't copy/paste the token as easily. For Facebook, it's > important that the access tokens are as short as possible; other sites > may have different requirements. > > On Jun 4, 2010, at 6:37 AM, Andrew Arnott wrote: > >> Having just implemented OAuth 2.0 web server flow, it was great to be >> able to issue an "opaque" access token to the client. This access >> token is in an encrypted format that only the resource server >> understands. I feel pretty good about this approach as it lends to >> high security and tokens that only the client needs to store (or not >> at all). >> >> But I'm wondering about the resource server that trusts multiple auth >> servers, which each have their own access token format. Without even >> a standardized way for an access token to express what format it is >> in, a resource server may have to just try decoding the token each >> known way until one "works". >> >> Proposal: perhaps the access token can be /mostly/ opaque, but not >> quite. For instance: >> The access token is in the format: /format=URI&opaquevalue/ >> Where URI is an arbitrary URI assigned by the auth server to assist >> the resource server in interpreting the /opaquevalue/ part of the token. >> >> Feedback? >> >> -- >> 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 > --------------000003010003030400080605 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 6/4/10 9:53 AM, Luke Shepard wrote:
Having a single resource server that works with multiple independent auth servers is not in scope for OAuth. That said, there's nothing to stop multiple servers to agree amongst themselves to have a standardized format for access token- and if necessary, to write that agreement as a separate spec (perhaps an extension).
-1

limiting OAuth to a single Authorization Server (AS) and it's associated SPs (resource owners) significantly restricts the value of delegation across the internet.

On the other hand, if OAuth allows for cross AS token processing, then it becomes very easy for me to protect my photo album while not requiring that all those I've shared it with to have an account at my photo service (as one example; there are many more).

Thanks,
George

In particular, I wouldn't like your proposal because of the use of equals and ampersand, both of which would need to be URL encoded so developers couldn't copy/paste the token as easily. For Facebook, it's important that the access tokens are as short as possible; other sites may have different requirements.

On Jun 4, 2010, at 6:37 AM, Andrew Arnott wrote:

Having just implemented OAuth 2.0 web server flow, it was great to be able to issue an "opaque" access token to the client.  This access token is in an encrypted format that only the resource server understands.  I feel pretty good about this approach as it lends to high security and tokens that only the client needs to store (or not at all).

But I'm wondering about the resource server that trusts multiple auth servers, which each have their own access token format.  Without even a standardized way for an access token to express what format it is in, a resource server may have to just try decoding the token each known way until one "works". 

Proposal: perhaps the access token can be mostly opaque, but not quite.  For instance:
The access token is in the format:  format=URI&opaquevalue
Where URI is an arbitrary URI assigned by the auth server to assist the resource server in interpreting the opaquevalue part of the token.

Feedback?

--
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
<ATT00001..txt>

= 

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--------------000003010003030400080605-- From eve@xmlgrrl.com Fri Jun 4 07:30:29 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80FA13A69D1 for ; Fri, 4 Jun 2010 07:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.308 X-Spam-Level: * X-Spam-Status: No, score=1.308 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id onUPNGGgUtrs for ; Fri, 4 Jun 2010 07:30:27 -0700 (PDT) Received: from mail.promanage-inc.com (eliasisrael.com [98.111.84.13]) by core3.amsl.com (Postfix) with ESMTP id 6743A3A67F0 for ; Fri, 4 Jun 2010 07:30:27 -0700 (PDT) Received: from [192.168.168.198] ([192.168.168.198]) (authenticated bits=0) by mail.promanage-inc.com (8.14.3/8.14.3) with ESMTP id o54EU9oZ000634 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 4 Jun 2010 07:30:09 -0700 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/alternative; boundary=Apple-Mail-24-1001865700 From: Eve Maler In-Reply-To: <4C09085E.4020906@aol.com> Date: Fri, 4 Jun 2010 07:30:08 -0700 Message-Id: <00703F08-4C12-49E4-AD1A-35C3CE43F419@xmlgrrl.com> References: <4C09085E.4020906@aol.com> To: George Fletcher X-Mailer: Apple Mail (2.1078) Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Partially standardized format for access tokens? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 14:30:30 -0000 --Apple-Mail-24-1001865700 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This is exactly the direction UMA is headed (as George knows :-), since = we *are* trying to solve for "unmooring" authorization servers and = resource servers -- which we call authorization managers and hosts. The absolute simplest thing to do is hand out tokens that are = essentially artifacts that the host must carry over and validate at the = AM (I think Dick was calling these "identifiers" but I'm coming to like = "artifact"). But by then, in our case, the host and AM have already met = in the context of the user who controls the protected resource in = question, and in fact the host has gotten an access token to use at the = AM's token validation endpoint so it already knows where to go to = validate. Thus, the artifact could be an opaque string. There are other aspects to the host-specific API at the AM that become = handy/necessary when you have to build in this kind of dynamic = association. For example, the host needs to tell the AM what resources = it's protecting on behalf of this user; we're fleshing out that API now, = but for now it's just POSTing a complete JSON structure (wielding its = access token to do so). And I believe it's possible to solve some = scoping interop this way too, though we're not there yet by a long shot. Would love to have folks interested in these use cases come on over to = the UMA WG and share their thoughts: http://kantarainitiative.org/confluence/display/uma/Home Eve On 4 Jun 2010, at 7:06 AM, George Fletcher wrote: > +1 to some standardization to the token >=20 > The URI would also allow for discovery and the ability for the = provider to define an endpoint in the XRD for the URI that allows "dumb = mode" token validation. This way, even if the resource owner doesn't = know how to "crack" the token locally, they could ask the provider to do = it for them. >=20 > Thanks, > George >=20 > On 6/4/10 9:37 AM, Andrew Arnott wrote: >>=20 >> Having just implemented OAuth 2.0 web server flow, it was great to be = able to issue an "opaque" access token to the client. This access token = is in an encrypted format that only the resource server understands. I = feel pretty good about this approach as it lends to high security and = tokens that only the client needs to store (or not at all). >>=20 >> But I'm wondering about the resource server that trusts multiple auth = servers, which each have their own access token format. Without even a = standardized way for an access token to express what format it is in, a = resource server may have to just try decoding the token each known way = until one "works". =20 >>=20 >> Proposal: perhaps the access token can be mostly opaque, but not = quite. For instance:=20 >> The access token is in the format: format=3DURI&opaquevalue >> Where URI is an arbitrary URI assigned by the auth server to assist = the resource server in interpreting the opaquevalue part of the token. >>=20 >> Feedback? >>=20 >> -- >> 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 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> =20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth Eve Maler eve@xmlgrrl.com http://www.xmlgrrl.com/blog --Apple-Mail-24-1001865700 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

The absolute simplest thing to do is = hand out tokens that are essentially artifacts that the host must carry = over and validate at the AM (I think Dick was calling these = "identifiers" but I'm coming to like "artifact"). But by then, in our = case, the host and AM have already met in the context of the user who = controls the protected resource in question, and in fact the host has = gotten an access token to use at the AM's token validation endpoint so = it already knows where to go to validate. Thus, the artifact could be an = opaque string.

There are other aspects to the = host-specific API at the AM that become handy/necessary when you have to = build in this kind of dynamic association.  For example, the host = needs to tell the AM what resources it's protecting on behalf of this = user; we're fleshing out that API now, but for now it's just POSTing a = complete JSON structure (wielding its access token to do so). And I = believe it's possible to solve some scoping interop this way too, though = we're not there yet by a long shot.

Would love = to have folks interested in these use cases come on over to the UMA WG = and share their thoughts:


<= div> = Eve

On 4 Jun 2010, at 7:06 AM, George Fletcher = wrote:

+1 to some standardization to the token

The URI would also allow for discovery and the ability for the provider to define an endpoint in the XRD for the URI that allows "dumb mode" token validation. This way, even if the resource owner doesn't know how to "crack" the token locally, they could ask the provider to do it for them.

Thanks,
George

On 6/4/10 9:37 AM, Andrew Arnott wrote:
Having just implemented OAuth 2.0 web server flow, it was great to be able to issue an "opaque" access token to the client.  = This access token is in an encrypted format that only the resource server understands.  I feel pretty good about this approach as it lends to high security and tokens that only the client needs to store (or not at all).

But I'm wondering about the resource server that trusts multiple auth servers, which each have their own access token format.  Without = even a standardized way for an access token to express what format it is in, a resource server may have to just try decoding the token each known way until one "works". 

Proposal: perhaps the access token can be mostly opaque, but not quite.  For instance:
The access token is in the = format:  format=3DURI&opaquevalue
Where URI is an arbitrary URI assigned by the auth server to assist the resource server in interpreting the opaquevalue part of the token.

Feedback?

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

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


= --Apple-Mail-24-1001865700-- From jricher@mitre.org Fri Jun 4 08:04:27 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA9B73A6A75 for ; Fri, 4 Jun 2010 08:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.649 X-Spam-Level: X-Spam-Status: No, score=-4.649 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oj1lXI9eu0h9 for ; Fri, 4 Jun 2010 08:04:21 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 2F7663A69D1 for ; Fri, 4 Jun 2010 08:04:21 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o54F46B9008812 for ; Fri, 4 Jun 2010 11:04:06 -0400 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o54F46ef008793; Fri, 4 Jun 2010 11:04:06 -0400 Received: from [129.83.50.65] (129.83.50.65) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server id 8.2.254.0; Fri, 4 Jun 2010 11:04:06 -0400 From: Justin Richer To: Torsten Lodderstedt In-Reply-To: <4C07F407.4050305@lodderstedt.net> References: <4BFAA6AB.8040809@lodderstedt.net> <4BFC3142.6010506@lodderstedt.net> <4BFC371A.5040109@lodderstedt.net> <4C07F407.4050305@lodderstedt.net> Content-Type: text/plain; charset="UTF-8" Date: Fri, 4 Jun 2010 11:04:05 -0400 Message-ID: <1275663845.7068.94.camel@localhost.localdomain> MIME-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] multiple access tokens from a single authorization flow? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 15:04:28 -0000 What if you had a supertoken that was only good for getting subtokens? In other words, only the AS knows about the supertoken (a refresh token, perhaps?), and it allows you to get sub-tokens using the refresh flow to access each of the different services. Then you could grab as many different tokens with individual scopes as you want. This could also be an application for the rescoping proposal, which I'm liking more now. I've had some colleagues ask me about redelegation in OAuth2, and I'm starting to think that the rescoping methods might be the right answer there. I see Torsten's problem as something similar: you get a token that's good for getting other tokens but not for accessing protected resources (the refresh token). You then use this token that has a "global" scope to request tokens with more directed scopes, which can have all of the per-service signed characteristics in the token itself that Torsten was talking about. Would that work? -- Justin On Thu, 2010-06-03 at 14:27 -0400, Torsten Lodderstedt wrote: > I probably exaggerated a bit. It's not impossible but it is complex and > insecure for several reasons: > > 1) Such a super token would need to contain the union of all data and > permissions needed by all requested target services. > 2) Not all services may by authorized to see all data contained in such > a super token (privacy!). So, you would need to built different > service-specific (encrypted) compartments within the token. > 3) There are target-service-specific characteristics of such a token, > such as the audience and the signature. You would need to have such > attributes per service. Using public-key cryptography would relieve this > point but slow down processing. > 4) You have to (somehow) prevent a target service from _abusing_ this > token to access another service for which the super token is valid for. > The only way I see is the usage of the client secret. > > That's why I think, returning multiple tokens is much simpler. > > regards, > Torsten. > > Am 03.06.2010 20:10, schrieb Lukas Rosenstock: > > Hi! > > I'm curious why this is impossible. If access tokens are arbitrary > > handles which are generated by the authorization server and > > distributed to all resources, it doesn't make much difference whether > > one or multiple are generated and in this case it would be better to > > keep the load on the server rather complicating things for clients. > > In the scenario (as you have mentioned) where access tokens are > > self-contained and digitally signed, would it not be possible to > > generate a "super token" which contains signatures from all resources? > > I agree this token might be a bit lengthy, but is there any other > > concern?! > > > > Regards, > > Lukas > > > > 2010/5/25 Torsten Lodderstedt: > > > >> As I said, every service in our setup needs another access token, with > >> different content, signed and encrypted with another shared secret. It is > >> technically impossible to create the super access token. Refresh tokens are > >> just handles representing the user's authorization and are used by the authz > >> server only. They therefore can represent any scope. > >> > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From lshepard@facebook.com Fri Jun 4 08:05:35 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46AE53A6839 for ; Fri, 4 Jun 2010 08:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.925 X-Spam-Level: X-Spam-Status: No, score=-0.925 tagged_above=-999 required=5 tests=[AWL=-0.260, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wsXPqHDO90xp for ; Fri, 4 Jun 2010 08:05:33 -0700 (PDT) Received: from mailout-snc1.facebook.com (mailout-snc1.facebook.com [69.63.179.25]) by core3.amsl.com (Postfix) with ESMTP id A7C323A6857 for ; Fri, 4 Jun 2010 08:05:32 -0700 (PDT) Received: from mail.thefacebook.com ([192.168.18.212]) by pp01.snc1.tfbnw.net (8.14.3/8.14.3) with ESMTP id o54F4npV019421 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 4 Jun 2010 08:04:53 -0700 Received: from sc-hub06.TheFacebook.com (192.168.18.83) by sc-hub04.TheFacebook.com (192.168.18.212) with Microsoft SMTP Server (TLS) id 14.0.694.1; Fri, 4 Jun 2010 08:03:17 -0700 Received: from SC-MBXC1.TheFacebook.com ([192.168.18.102]) by sc-hub06.TheFacebook.com ([192.168.18.83]) with mapi; Fri, 4 Jun 2010 08:00:24 -0700 From: Luke Shepard To: George Fletcher Date: Fri, 4 Jun 2010 08:00:36 -0700 Thread-Topic: [OAUTH-WG] Partially standardized format for access tokens? Thread-Index: AcsD9qhIVR+Pga23TTqWlKpamXS7UQ== Message-ID: References: <4C090B6C.9030707@aol.com> In-Reply-To: <4C090B6C.9030707@aol.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-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-06-04_01:2010-02-06, 2010-06-04, 2010-06-04 signatures=0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Partially standardized format for access tokens? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 15:05:35 -0000 X-List-Received-Date: Fri, 04 Jun 2010 15:05:35 -0000 On Jun 4, 2010, at 7:19 AM, George Fletcher wrote: > On 6/4/10 9:53 AM, Luke Shepard wrote: >>=20 >> Having a single resource server that works with multiple independent aut= h servers is not in scope for OAuth. That said, there's nothing to stop mul= tiple servers to agree amongst themselves to have a standardized format for= access token- and if necessary, to write that agreement as a separate spec= (perhaps an extension). > -1 >=20 > limiting OAuth to a single Authorization Server (AS) and it's associated = SPs (resource owners) significantly restricts the value of delegation acros= s the internet. >=20 I'm not saying that we need to limit it just to that circumstance, but the = single-server scenario is one of the most common use cases for OAuth - for = example, Google, Flickr, Facebook, Yahoo, Twitter all generally support tok= ens that only work on their own services. I've listed one reason why a form= alized structure would be bad for Facebook (token size would increase). We should solve one problem at a time. It's easy to layer structure on top = of an opaque blob in a separate spec. The question to ask is, if a provider= chose NOT to support whatever standardized token format that came up, woul= d they still be able to use the OAuth 2.0 flows? If the answer is yes, then= it belongs in a different spec. > On the other hand, if OAuth allows for cross AS token processing, then it= becomes very easy for me to protect my photo album while not requiring tha= t all those I've shared it with to have an account at my photo service (as = one example; there are many more). There is a lot more that would need to happen to support this outcome than = merely standardizing the format of the token.=20 From jricher@mitre.org Fri Jun 4 08:15:17 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C971E3A6A8B for ; Fri, 4 Jun 2010 08:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.612 X-Spam-Level: X-Spam-Status: No, score=-4.612 tagged_above=-999 required=5 tests=[AWL=-0.427, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-vqQv0frKce for ; Fri, 4 Jun 2010 08:15:14 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 363FF3A6981 for ; Fri, 4 Jun 2010 08:15:14 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o54FF0Qm020341 for ; Fri, 4 Jun 2010 11:15:00 -0400 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o54FF0jS020335; Fri, 4 Jun 2010 11:15:00 -0400 Received: from [129.83.50.65] (129.83.50.65) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server id 8.2.254.0; Fri, 4 Jun 2010 11:14:59 -0400 From: Justin Richer To: Andrew Arnott In-Reply-To: References: <4C0900FD.3050904@aol.com> Content-Type: text/plain; charset="UTF-8" Date: Fri, 4 Jun 2010 11:14:59 -0400 Message-ID: <1275664499.7068.98.camel@localhost.localdomain> MIME-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Definition of XML response format X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 15:15:17 -0000 I'd personally rather see something flatter, even with an implied root namespace defined in the spec. Maybe like: asdfasoij234f 2f098jadfasdfasdf 300 Mirroring the key-value format for the JSON and form-encoded forms, this keeps the field names as elements and the values as text node values. I'd rather not see us hang a "value=" attribute in all of these. -- Justin On Fri, 2010-06-04 at 09:42 -0400, Andrew Arnott wrote: > Thanks, George. From that I get this: > > token > secret > > > From the text around it, it sounds like SPs were permitted to add to > this (presumably using their own element names). While this seems > reasonable, it seems that SP-specific extensions that used alternate > element names would then be incompatible with JSON and url-encoded > responses since they cannot include this extra element metadata. > (well JSON could, with some breaking changes to the format). > > So with that, it seems like we should eliminate the redundant > oauth_parameter element name in favor of just using the name of the > parameter as the element name. > > -- > 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 Fri, Jun 4, 2010 at 6:34 AM, George Fletcher > wrote: > I don't know if this is helpful or not... but there was a > proposed extension for OAuth 1.0 dealing with encoding OAuth > responses in different body formats... this can be found on > the now extinct oauth-extensions google group. > > http://groups.google.com/group/oauth-extensions/browse_thread/thread/419ec4e986ff5cd8?hl=en# > > Thanks, > George > > > On 6/4/10 8:56 AM, Andrew Arnott wrote: > > > > In the absence of anyone else volunteering an XML format, > > what would you say to this as a proposal (because the > > implementation of which happens to be simple for me): > > > > > > some access > > token > > some refresh > > token > > 235298298 > > > > > > So the main points here is: > > 1. no namespace > > 2. root tag is called "root" > > 3. each parameter is an element > > 4. each element has a type parameter that is either > > string, number, or object to assist the deserializer > > to understnad how to cast the contents. > > We may axe #4. In fact we may want to switch all the > > elements to attributes because it's slightly more compact > > which might help small devices. > > > > -- > > 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 Mon, May 31, 2010 at 9:12 AM, Andrew Arnott > > wrote: > > Where is the definition of how a auth server > > response in XML format should look? At the least we > > need an XML namespace and root node name. > > > > -- > > 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 > > > From john@jkemp.net Fri Jun 4 08:22:10 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79BB53A6405 for ; Fri, 4 Jun 2010 08:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.335 X-Spam-Level: X-Spam-Status: No, score=0.335 tagged_above=-999 required=5 tests=[BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OIE3o5VQmrAA for ; Fri, 4 Jun 2010 08:22:05 -0700 (PDT) Received: from cpoproxy3-pub.bluehost.com (cpoproxy3-pub.bluehost.com [67.222.54.6]) by core3.amsl.com (Postfix) with SMTP id BB5CE3A67AD for ; Fri, 4 Jun 2010 08:22:05 -0700 (PDT) Received: (qmail 14883 invoked by uid 0); 4 Jun 2010 15:21:52 -0000 Received: from unknown (HELO box320.bluehost.com) (69.89.31.120) by cpoproxy3.bluehost.com with SMTP; 4 Jun 2010 15:21:52 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=jkemp.net; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-Identified-User; b=vejMAwvFlXvETQV1dJ+12Fg468SXgimaEHL7AvXy4jvwCzjBndq6BlYfKzy9LaYQrZjpNsBST6UqrVa7/I40B1XalPbNlY9JriFM4jUD+FdDCvYxAILTwERaQlm/W0uO; Received: from cpe-69-205-56-47.nycap.res.rr.com ([69.205.56.47] helo=[192.168.1.107]) by box320.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1OKYiV-00035T-Ve; Fri, 04 Jun 2010 09:21:52 -0600 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: John Kemp In-Reply-To: Date: Fri, 4 Jun 2010 11:21:50 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C090B6C.9030707@aol.com> To: Luke Shepard X-Mailer: Apple Mail (2.1078) X-Identified-User: {1122:box320.bluehost.com:jkempnet:jkemp.net} {sentby:smtp auth 69.205.56.47 authed with john+jkemp.net} Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Partially standardized format for access tokens? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 15:22:10 -0000 Hi Luke, On Jun 4, 2010, at 11:00 AM, Luke Shepard wrote: >=20 > On Jun 4, 2010, at 7:19 AM, George Fletcher wrote: >=20 >> On 6/4/10 9:53 AM, Luke Shepard wrote: >>>=20 >>> Having a single resource server that works with multiple independent = auth servers is not in scope for OAuth. That said, there's nothing to = stop multiple servers to agree amongst themselves to have a standardized = format for access token- and if necessary, to write that agreement as a = separate spec (perhaps an extension). >> -1 >>=20 >> limiting OAuth to a single Authorization Server (AS) and it's = associated SPs (resource owners) significantly restricts the value of = delegation across the internet. >>=20 >=20 > I'm not saying that we need to limit it just to that circumstance, but = the single-server scenario is one of the most common use cases for OAuth = - for example, Google, Flickr, Facebook, Yahoo, Twitter all generally = support tokens that only work on their own services. I've listed one = reason why a formalized structure would be bad for Facebook (token size = would increase). >=20 > We should solve one problem at a time. It's easy to layer structure on = top of an opaque blob in a separate spec. The question to ask is, if a = provider chose NOT to support whatever standardized token format that = came up, would they still be able to use the OAuth 2.0 flows? If the = answer is yes, then it belongs in a different spec. I think that even if specific token formats are defined in separate = specs. (which I agree with) you would still need to define a = standardized optional attribute to carry the format description = reference.=20 What is wrong with agreeing in OAuth itself to do that much - define an = optional attribute called "token_format" which MAY be present, and if so = MUST be passed on by the client? If the format attribute is not present, = it's value has default semantics of "opaque"? Other specifications may = then define additional format values and describe in more details what = they mean.=20 Regards, - johnk From jricher@mitre.org Fri Jun 4 08:23:32 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB8D93A67D1 for ; Fri, 4 Jun 2010 08:23:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.448 X-Spam-Level: X-Spam-Status: No, score=-4.448 tagged_above=-999 required=5 tests=[AWL=-0.449, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dd29Lo47KHjS for ; Fri, 4 Jun 2010 08:23:31 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 14D733A67AD for ; Fri, 4 Jun 2010 08:23:31 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o54FNHgh028737 for ; Fri, 4 Jun 2010 11:23:17 -0400 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o54FNHqV028734; Fri, 4 Jun 2010 11:23:17 -0400 Received: from [129.83.50.65] (129.83.50.65) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server id 8.2.254.0; Fri, 4 Jun 2010 11:23:16 -0400 From: Justin Richer To: Luke Shepard In-Reply-To: References: <4C090B6C.9030707@aol.com> Content-Type: text/plain; charset="UTF-8" Date: Fri, 4 Jun 2010 11:23:16 -0400 Message-ID: <1275664996.7068.102.camel@localhost.localdomain> MIME-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Partially standardized format for access tokens? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 15:23:32 -0000 > We should solve one problem at a time. It's easy to layer structure > on top of an opaque blob in a separate spec. +1 to this. Token structure seems like a nice idea, but it's outside what should be dictated by the OAuth spec. We want people to be able to use OAuth to shuttle their existing tokens around, or create hexblobs that mean nothing to anyone else, or encode 37 fields in a structured format that's signed with a private key, or whatever else they want to do, and still have all of that be OAuth. If someone wants to say "we use OAuth and our tokens are UberTokens so they're compatible with everyone else", that's fine; but you should be fully able to do OAuth without adding *any* structure to your tokens whatsoever. -- Justin On Fri, 2010-06-04 at 11:00 -0400, Luke Shepard wrote: > On Jun 4, 2010, at 7:19 AM, George Fletcher wrote: > > > On 6/4/10 9:53 AM, Luke Shepard wrote: > >> > >> Having a single resource server that works with multiple independent auth servers is not in scope for OAuth. That said, there's nothing to stop multiple servers to agree amongst themselves to have a standardized format for access token- and if necessary, to write that agreement as a separate spec (perhaps an extension). > > -1 > > > > limiting OAuth to a single Authorization Server (AS) and it's associated SPs (resource owners) significantly restricts the value of delegation across the internet. > > > > I'm not saying that we need to limit it just to that circumstance, but the single-server scenario is one of the most common use cases for OAuth - for example, Google, Flickr, Facebook, Yahoo, Twitter all generally support tokens that only work on their own services. I've listed one reason why a formalized structure would be bad for Facebook (token size would increase). > > We should solve one problem at a time. It's easy to layer structure on top of an opaque blob in a separate spec. The question to ask is, if a provider chose NOT to support whatever standardized token format that came up, would they still be able to use the OAuth 2.0 flows? If the answer is yes, then it belongs in a different spec. > > > On the other hand, if OAuth allows for cross AS token processing, then it becomes very easy for me to protect my photo album while not requiring that all those I've shared it with to have an account at my photo service (as one example; there are many more). > > There is a lot more that would need to happen to support this outcome than merely standardizing the format of the token. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From dick.hardt@gmail.com Fri Jun 4 08:37:44 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D819E3A67D1 for ; Fri, 4 Jun 2010 08:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pgCxGKXmRyO2 for ; Fri, 4 Jun 2010 08:37:44 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id E5FC13A67BD for ; Fri, 4 Jun 2010 08:37:43 -0700 (PDT) Received: by pvf33 with SMTP id 33so712565pvf.31 for ; Fri, 04 Jun 2010 08:37:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=CoJ3Cg9uLpwWq8u9xhPuKBeKbnMQYNCBf60E54PYawA=; b=SBkU19hWNGAHh/U98zxaRoY/35MAv+Cg4jMGdRTA9HyN806A3OiKqWIwGPFu1JJFGb OjiQpY2yXK4URL3qfg60EXKm2srAQ2Qsf3PAtisp4lTHBkNa6Mt0c/Nqd7OD48FzdigU 4M+bGti83e6Mz34+GvBAtiJjTagrz53F9IWZo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=dYbL2URIJe+FemHtsgA9nyefUmQ18itAKiGdvVuXED2gNxN1GesJLDvXGdSPlJ5ykA SZp0FTFIjYwPBU2Xv4I7kAukkkrV8CQXJABFBk2SQ3xtWfH94UVYDJ+3gQwcQ0T8iwzZ wi00YgvNb/TRnTEqfUp6nD67ClgGvyq3I4yBY= MIME-Version: 1.0 Received: by 10.142.9.31 with SMTP id 31mr8264521wfi.7.1275665846694; Fri, 04 Jun 2010 08:37:26 -0700 (PDT) Received: by 10.143.167.14 with HTTP; Fri, 4 Jun 2010 08:37:26 -0700 (PDT) In-Reply-To: <1275664996.7068.102.camel@localhost.localdomain> References: <4C090B6C.9030707@aol.com> <1275664996.7068.102.camel@localhost.localdomain> Date: Fri, 4 Jun 2010 08:37:26 -0700 Message-ID: From: Dick Hardt To: Justin Richer Content-Type: multipart/alternative; boundary=0016368e230ea4f39104883619d9 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Partially standardized format for access tokens? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 15:37:44 -0000 --0016368e230ea4f39104883619d9 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jun 4, 2010 at 8:23 AM, Justin Richer wrote: > > We should solve one problem at a time. It's easy to layer structure > > on top of an opaque blob in a separate spec. > > +1 to this. Token structure seems like a nice idea, but it's outside > what should be dictated by the OAuth spec. We want people to be able to > use OAuth to shuttle their existing tokens around, or create hexblobs > that mean nothing to anyone else, or encode 37 fields in a structured > format that's signed with a private key, or whatever else they want to > do, and still have all of that be OAuth. If someone wants to say "we use > OAuth and our tokens are UberTokens so they're compatible with everyone > else", that's fine; but you should be fully able to do OAuth without > adding *any* structure to your tokens whatsoever. Token format has been out of scope of WRAP and OAuth 2.0. A separate spec defining standard tokens has been discussed. Luke was commenting on not supporting multiple AS. That *IS* in scope and was a design objective and *IS* being implemented. -- DIck > --0016368e230ea4f39104883619d9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Jun 4, 2010 at 8:23 AM, Justin Rich= er <jricher@mitre= .org> wrote:
> We should solve one problem at a time. It's easy= to layer structure
> on top of an opaque blob in a separate spec.

+1 to this. Token structure seems like a nice idea, but it's outs= ide
what should be dictated by the OAuth spec. We want people to be able to
use OAuth to shuttle their existing tokens around, or create hexblobs
that mean nothing to anyone else, or encode 37 fields in a structured
format that's signed with a private key, or whatever else they want to<= br> do, and still have all of that be OAuth. If someone wants to say "we u= se
OAuth and our tokens are UberTokens so they're compatible with everyone=
else", that's fine; but you should be fully able to do OAuth witho= ut
adding *any* structure to your tokens whatsoever.

Token format has been out of scope of WRAP and OAuth 2.0.

<= div>A separate spec defining standard tokens has been discussed.

Luke was commenting on not supporting multiple AS. That= *IS* in scope and was a design objective and *IS* being implemented.
=

-- DIck=A0
=A0

--0016368e230ea4f39104883619d9-- From dick.hardt@gmail.com Fri Jun 4 08:41:56 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBFDB3A67BD for ; Fri, 4 Jun 2010 08:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dH2rRtRxLJWt for ; Fri, 4 Jun 2010 08:41:55 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 51A393A67A1 for ; Fri, 4 Jun 2010 08:41:55 -0700 (PDT) Received: by pvf33 with SMTP id 33so714943pvf.31 for ; Fri, 04 Jun 2010 08:41:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=WQWosYgiPzegg3ueKuHUMmsshSqpcuRwL0HMLrTW15E=; b=rknCWZjZCdo0qZ4a4rT1e3YIKQ+GuqBYcYCPeMenMYWVCLngeDvkg+JvfDCU8r44yS JmdM4LhEuVrm3i5wZmJEXXnaeBw9pz9JdjV6R3FdGkzX+XjmPyFLd4id/1V7Nd6V8oxf r522f+YxVSDc1nyiHsAp99rgKulYLzgelSgJc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=LoKipci8GEb8EuNbUrHDvUg6CoOP/qhbxboLbW384ZwTE4aZgtcnxWYMcRhqKJ/bFX msdF4dNk+vDxGA2kgIKa+piUij9YrRvRU+VFoVcfwBHQJCqejNgSaRp8NVyMxWH1gQdT 7LAooZn/EiWbrGJoFpIfYAJNVKbK9MwbOWtHM= MIME-Version: 1.0 Received: by 10.142.9.31 with SMTP id 31mr8268704wfi.7.1275666099306; Fri, 04 Jun 2010 08:41:39 -0700 (PDT) Received: by 10.143.167.14 with HTTP; Fri, 4 Jun 2010 08:41:39 -0700 (PDT) In-Reply-To: References: <4C090B6C.9030707@aol.com> Date: Fri, 4 Jun 2010 08:41:39 -0700 Message-ID: From: Dick Hardt To: Luke Shepard Content-Type: multipart/alternative; boundary=0016368e230eb380510488362838 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Partially standardized format for access tokens? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 15:41:56 -0000 --0016368e230eb380510488362838 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jun 4, 2010 at 8:00 AM, Luke Shepard wrote: > > On Jun 4, 2010, at 7:19 AM, George Fletcher wrote: > > > On 6/4/10 9:53 AM, Luke Shepard wrote: > >> > >> Having a single resource server that works with multiple independent > auth servers is not in scope for OAuth. That said, there's nothing to stop > multiple servers to agree amongst themselves to have a standardized format > for access token- and if necessary, to write that agreement as a separate > spec (perhaps an extension). > > -1 > > > > limiting OAuth to a single Authorization Server (AS) and it's associated > SPs (resource owners) significantly restricts the value of delegation across > the internet. > > > > I'm not saying that we need to limit it just to that circumstance, but the > single-server scenario is one of the most common use cases for OAuth - for > example, Google, Flickr, Facebook, Yahoo, Twitter all generally support > tokens that only work on their own services. I've listed one reason why a > formalized structure would be bad for Facebook (token size would increase). > > We should solve one problem at a time. It's easy to layer structure on top > of an opaque blob in a separate spec. The question to ask is, if a provider > chose NOT to support whatever standardized token format that came up, would > they still be able to use the OAuth 2.0 flows? If the answer is yes, then it > belongs in a different spec. Agree we don't standardize the token. Disagree on supporting multiple AS. There is more to the web than the social web Luke, and supporting multiple AS has been a design goal of WRAP and OAuth 2.0 and is being implemented. Having an optional parameter that would carry the token type from the AS to the PR would be useful and has been discussed in the past. Just like the access token, it could be opaque to the client. -- Dick -- Dick > --0016368e230eb380510488362838 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Jun 4, 2010 at 8:00 AM, Luke She= pard <lshepar= d@facebook.com> wrote:

On Jun 4, 2010, at 7:19 AM, George Fletcher wrote:

> On 6/4/10 9:53 AM, Luke Shepard wrote:
>>
>> Having a single resource server that works with multiple independe= nt auth servers is not in scope for OAuth. That said, there's nothing t= o stop multiple servers to agree amongst themselves to have a standardized = format for access token- and if necessary, to write that agreement as a sep= arate spec (perhaps an extension).
> -1
>
> limiting OAuth to a single Authorization Server (AS) and it's asso= ciated SPs (resource owners) significantly restricts the value of delegatio= n across the internet.
>

I'm not saying that we need to limit it just to that circumstance= , but the single-server scenario is one of the most common use cases for OA= uth - for example, Google, Flickr, Facebook, Yahoo, Twitter all generally s= upport tokens that only work on their own services. I've listed one rea= son why a formalized structure would be bad for Facebook (token size would = increase).

We should solve one problem at a time. It's easy to layer structure on = top of an opaque blob in a separate spec. The question to ask is, if a prov= ider chose NOT to support whatever standardized token format that came up, = would they still be able to use the OAuth 2.0 flows? If the answer is yes, = then it belongs in a different spec.

Agree we don't standardize the token. Disagree on s= upporting multiple AS.

There is more to the web th= an the social web Luke, and supporting multiple AS has been a design goal o= f WRAP and OAuth 2.0 and is being implemented.

Having an optional parameter that would carry the token= type from the AS to the PR would be useful and has been discussed in the p= ast. Just like the access token, it could be opaque to the client.=A0

-- Dick

-- Dick
=A0

--0016368e230eb380510488362838-- From stpeter@stpeter.im Fri Jun 4 08:46:04 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFCBF3A6957 for ; Fri, 4 Jun 2010 08:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.249 X-Spam-Level: X-Spam-Status: No, score=-1.249 tagged_above=-999 required=5 tests=[AWL=-0.509, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LDdHbVYOuVkv for ; Fri, 4 Jun 2010 08:46:03 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 4C9AC3A694A for ; Fri, 4 Jun 2010 08:46:03 -0700 (PDT) Received: from squire.local (dsl-205-108.dynamic-dsl.frii.net [216.17.205.108]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C3A6C40E61 for ; Fri, 4 Jun 2010 09:45:48 -0600 (MDT) Message-ID: <4C091FAB.5070603@stpeter.im> Date: Fri, 04 Jun 2010 09:45:47 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: oauth@ietf.org References: <4C090B6C.9030707@aol.com> <1275664996.7068.102.camel@localhost.localdomain> In-Reply-To: <1275664996.7068.102.camel@localhost.localdomain> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050009090401070504030108" Subject: Re: [OAUTH-WG] Partially standardized format for access tokens? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 15:46:05 -0000 This is a cryptographically signed message in MIME format. --------------ms050009090401070504030108 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 6/4/10 9:23 AM, Justin Richer wrote: >> We should solve one problem at a time. It's easy to layer structure=20 >> on top of an opaque blob in a separate spec.=20 >=20 > +1 to this. Token structure seems like a nice idea, but it's outside > what should be dictated by the OAuth spec. We want people to be able to= > use OAuth to shuttle their existing tokens around, or create hexblobs > that mean nothing to anyone else, or encode 37 fields in a structured > format that's signed with a private key, or whatever else they want to > do, and still have all of that be OAuth. If someone wants to say "we us= e > OAuth and our tokens are UberTokens so they're compatible with everyone= > else", that's fine; but you should be fully able to do OAuth without > adding *any* structure to your tokens whatsoever. Agreed. And in true IETF fashion, I welcome those who care about this issue to write an Internet-Draft. :) BTW, it's possible that you might glean some interesting ideas from a previous attempt to define an open token format (for cookies): http://tools.ietf.org/html/draft-smith-opentoken-02 Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms050009090401070504030108 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDYwNDE1NDU0N1owIwYJKoZIhvcNAQkEMRYEFJ+ScgfZ14BJ/xwaRYPp NG7GFziBMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAhNG+35rXIHJ38sbYe39VHfm6iCqhVEQIbriyx43u evabMoUElacS+OlGLjMvWXTTgo/UROYdwcRMUIXtP41dBm/j1yseBIaTXRXr/QRemh+vh9Bp WyffSHtOF3I0LbihnwyZG74gxjpSvo9lOF+oaPt8JihpK8VXIXiKeWeXpqFB5XEw59rM682H h3cW2g9FN6zK6RFvJGW9ZjjGEXrvjYkphhAmLoqdqC7+83mjC8wAzz/gqB2rHaARQuPv67JG 6SgWn+lWCYcQH7VNSiFUDbfFL4vQA3Bqyek5VIWM3vjQFh4ZHMN1jgatvX/coECnOliIQIXD lgytpGz8l/bSqAAAAAAAAA== --------------ms050009090401070504030108-- From torsten@lodderstedt.net Fri Jun 4 08:57:51 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94BFF3A69B9 for ; Fri, 4 Jun 2010 08:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.447 X-Spam-Level: X-Spam-Status: No, score=0.447 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QrVo30xukbVu for ; Fri, 4 Jun 2010 08:57:50 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.18.43]) by core3.amsl.com (Postfix) with ESMTP id 2F2E93A69B1 for ; Fri, 4 Jun 2010 08:57:50 -0700 (PDT) Received: from p4fff0aeb.dip.t-dialin.net ([79.255.10.235] helo=[127.0.0.1]) by smtprelay01.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OKZH5-0004L9-1b; Fri, 04 Jun 2010 17:57:35 +0200 Message-ID: <4C09226A.6090502@lodderstedt.net> Date: Fri, 04 Jun 2010 17:57:30 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: John Kemp References: <4C090B6C.9030707@aol.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Partially standardized format for access tokens? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 15:57:51 -0000 +1 for an optional "token_format" attribute/parameter Am 04.06.2010 17:21, schrieb John Kemp: > Hi Luke, > > On Jun 4, 2010, at 11:00 AM, Luke Shepard wrote: > > >> On Jun 4, 2010, at 7:19 AM, George Fletcher wrote: >> >> >>> On 6/4/10 9:53 AM, Luke Shepard wrote: >>> >>>> Having a single resource server that works with multiple independent auth servers is not in scope for OAuth. That said, there's nothing to stop multiple servers to agree amongst themselves to have a standardized format for access token- and if necessary, to write that agreement as a separate spec (perhaps an extension). >>>> >>> -1 >>> >>> limiting OAuth to a single Authorization Server (AS) and it's associated SPs (resource owners) significantly restricts the value of delegation across the internet. >>> >>> >> I'm not saying that we need to limit it just to that circumstance, but the single-server scenario is one of the most common use cases for OAuth - for example, Google, Flickr, Facebook, Yahoo, Twitter all generally support tokens that only work on their own services. I've listed one reason why a formalized structure would be bad for Facebook (token size would increase). >> >> We should solve one problem at a time. It's easy to layer structure on top of an opaque blob in a separate spec. The question to ask is, if a provider chose NOT to support whatever standardized token format that came up, would they still be able to use the OAuth 2.0 flows? If the answer is yes, then it belongs in a different spec. >> > I think that even if specific token formats are defined in separate specs. (which I agree with) you would still need to define a standardized optional attribute to carry the format description reference. > > What is wrong with agreeing in OAuth itself to do that much - define an optional attribute called "token_format" which MAY be present, and if so MUST be passed on by the client? If the format attribute is not present, it's value has default semantics of "opaque"? Other specifications may then define additional format values and describe in more details what they mean. > > Regards, > > - johnk > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From bcampbell@pingidentity.com Fri Jun 4 09:04:31 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC5A828C124 for ; Fri, 4 Jun 2010 09:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.377 X-Spam-Level: X-Spam-Status: No, score=-3.377 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id omCU6u+3nIje for ; Fri, 4 Jun 2010 09:04:30 -0700 (PDT) Received: from na3sys009aog110.obsmtp.com (na3sys009aog110.obsmtp.com [74.125.149.203]) by core3.amsl.com (Postfix) with SMTP id 804433A67AD for ; Fri, 4 Jun 2010 09:04:30 -0700 (PDT) Received: from source ([209.85.212.181]) by na3sys009aob110.postini.com ([74.125.148.12]) with SMTP ID DSNKTAkkAPvIOhmjhck3fumu/Jh0i3czwjsM@postini.com; Fri, 04 Jun 2010 09:04:17 PDT Received: by mail-px0-f181.google.com with SMTP id 4so311124pxi.40 for ; Fri, 04 Jun 2010 09:04:16 -0700 (PDT) Received: by 10.229.216.136 with SMTP id hi8mr2810628qcb.135.1275667454616; Fri, 04 Jun 2010 09:04:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.86.19 with HTTP; Fri, 4 Jun 2010 09:03:44 -0700 (PDT) In-Reply-To: <1275664499.7068.98.camel@localhost.localdomain> References: <4C0900FD.3050904@aol.com> <1275664499.7068.98.camel@localhost.localdomain> From: Brian Campbell Date: Fri, 4 Jun 2010 10:03:44 -0600 Message-ID: To: "OAuth WG (oauth@ietf.org)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [OAUTH-WG] Definition of XML response format X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 16:04:32 -0000 At the risk of betraying my SAML roots, I'd suggest that if name-space and typing like functionality is desired, we not try and reinvent the wheel and actually use a schema. After all, is effectively an attempt at nonstandard namespacing and is the same kind of thing for data typing. XML Schema has its issues and I'm sure many on this list are not fans, but it is a standard and there are open source and commercial tools that support it. And it's pretty easy to ignore for implementations that don't want to care about it. I could draft something up, if there is interest. Alternatively, keeping things really simple, along the lines of what Justin suggested, might make sense as well. Data types are implied/known by the names and any extensions or proprietary parameters will just have to make sure they don't have name conflicts. As far as I can tell, this is already the case with the other response types so it doesn't seem like a problem to have the same limitations for XML. On Fri, Jun 4, 2010 at 9:14 AM, Justin Richer wrote: > I'd personally rather see something flatter, even with an implied root > namespace defined in the spec. Maybe like: > > =A0 > =A0 =A0 =A0asdfasoij234f > =A0 =A0 =A02f098jadfasdfasdf > =A0 =A0 =A0300 > =A0 > > Mirroring the key-value format for the JSON and form-encoded forms, this > keeps the field names as elements and the values as text node values. > I'd rather not see us hang a "value=3D" attribute in all of these. > > =A0-- Justin > > > On Fri, 2010-06-04 at 09:42 -0400, Andrew Arnott wrote: >> Thanks, George. =A0From that I get this: >> >> =A0 =A0 =A0 token >> =A0 =A0 =A0 secret >> >> >> From the text around it, it sounds like SPs were permitted to add to >> this (presumably using their own element names). =A0While this seems >> reasonable, it seems that SP-specific extensions that used alternate >> element names would then be incompatible with JSON and url-encoded >> responses since they cannot include this extra element metadata. >> (well JSON could, with some breaking changes to the format). >> >> So with that, it seems like we should eliminate the redundant >> oauth_parameter element name in favor of just using the name of the >> parameter as the element name. >> >> -- >> 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 Fri, Jun 4, 2010 at 6:34 AM, George Fletcher >> wrote: >> =A0 =A0 =A0 =A0 I don't know if this is helpful or not... but there was = a >> =A0 =A0 =A0 =A0 proposed extension for OAuth 1.0 dealing with encoding O= Auth >> =A0 =A0 =A0 =A0 responses in different body formats... this can be found= on >> =A0 =A0 =A0 =A0 the now extinct oauth-extensions google group. >> >> =A0 =A0 =A0 =A0 http://groups.google.com/group/oauth-extensions/browse_t= hread/thread/419ec4e986ff5cd8?hl=3Den# >> >> =A0 =A0 =A0 =A0 Thanks, >> =A0 =A0 =A0 =A0 George >> >> >> =A0 =A0 =A0 =A0 On 6/4/10 8:56 AM, Andrew Arnott wrote: >> =A0 =A0 =A0 =A0 > >> =A0 =A0 =A0 =A0 > In the absence of anyone else volunteering an XML form= at, >> =A0 =A0 =A0 =A0 > what would you say to this as a proposal (because the >> =A0 =A0 =A0 =A0 > implementation of which happens to be simple for me): >> =A0 =A0 =A0 =A0 > >> =A0 =A0 =A0 =A0 > >> =A0 =A0 =A0 =A0 > =A0 =A0some access >> =A0 =A0 =A0 =A0 > token >> =A0 =A0 =A0 =A0 > =A0 =A0some refresh >> =A0 =A0 =A0 =A0 > token >> =A0 =A0 =A0 =A0 > =A0 =A0235298298 >> =A0 =A0 =A0 =A0 > >> =A0 =A0 =A0 =A0 > >> =A0 =A0 =A0 =A0 > So the main points here is: >> =A0 =A0 =A0 =A0 > =A0 =A0 =A01. no namespace >> =A0 =A0 =A0 =A0 > =A0 =A0 =A02. root tag is called "root" >> =A0 =A0 =A0 =A0 > =A0 =A0 =A03. each parameter is an element >> =A0 =A0 =A0 =A0 > =A0 =A0 =A04. each element has a type parameter that i= s either >> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 string, number, or object to assist th= e deserializer >> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 to understnad how to cast the contents= . >> =A0 =A0 =A0 =A0 > We may axe #4. =A0In fact we may want to switch all th= e >> =A0 =A0 =A0 =A0 > elements to attributes because it's slightly more comp= act >> =A0 =A0 =A0 =A0 > which might help small devices. >> =A0 =A0 =A0 =A0 > >> =A0 =A0 =A0 =A0 > -- >> =A0 =A0 =A0 =A0 > Andrew Arnott >> =A0 =A0 =A0 =A0 > "I [may] not agree with what you have to say, but I'll >> =A0 =A0 =A0 =A0 > defend to the death your right to say it." - S. G. >> =A0 =A0 =A0 =A0 > Tallentyre >> =A0 =A0 =A0 =A0 > >> =A0 =A0 =A0 =A0 > >> =A0 =A0 =A0 =A0 > On Mon, May 31, 2010 at 9:12 AM, Andrew Arnott >> =A0 =A0 =A0 =A0 > wrote: >> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 Where is the definition of how a auth = server >> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 response in XML format should look? = =A0At the least we >> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 need an XML namespace and root node na= me. >> =A0 =A0 =A0 =A0 > >> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 -- >> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 Andrew Arnott >> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 "I [may] not agree with what you have = to say, but >> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 I'll defend to the death your right to= say it." - S. >> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 G. Tallentyre >> =A0 =A0 =A0 =A0 > >> =A0 =A0 =A0 =A0 > >> =A0 =A0 =A0 =A0 > >> =A0 =A0 =A0 =A0 > _______________________________________________ >> =A0 =A0 =A0 =A0 > OAuth mailing list >> =A0 =A0 =A0 =A0 > OAuth@ietf.org >> =A0 =A0 =A0 =A0 > https://www.ietf.org/mailman/listinfo/oauth >> =A0 =A0 =A0 =A0 > >> > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From dick.hardt@gmail.com Fri Jun 4 09:23:49 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A010D3A68BF for ; Fri, 4 Jun 2010 09:23:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FOHXGb0-Btgu for ; Fri, 4 Jun 2010 09:23:48 -0700 (PDT) Received: from mail-pz0-f195.google.com (mail-pz0-f195.google.com [209.85.222.195]) by core3.amsl.com (Postfix) with ESMTP id 99AD63A67D1 for ; Fri, 4 Jun 2010 09:23:48 -0700 (PDT) Received: by pzk33 with SMTP id 33so1629135pzk.17 for ; Fri, 04 Jun 2010 09:23:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=2wIMGaMBJM3vep2w+TlqmNf/Kc7vu1pHmd5xEXxKCzk=; b=BilrHV3F8j7tDuvSODxDtdexlIKSBEAZxogu7Qej1bINTjxj58ox2cgdraeZEI6i4y WFTN8dH/IsIczwG98K3aKCRv0MlJ30q/kBZ3vm41cVM1rYJ87l4c48A82aiLd39dhXxd b05+yJ5uTx4A/RlBPekW7vh2c3T6ajmHqp56U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=U12XzsIhmiQZbXIf+IFFv8sIlB7MJtuOD75/FnHveKMEB6XPfjTjWhNsM8DsCUJAPC ZZhF4ZKWa8IujrF66fxMiPCgyEyD0Akpt/3eKWInvEnxoeaY8RLhwi1CbxkOu/mNrRDp PxNNjMPgWoer5rzoC0XkTiYHj4ZhPx7sweokE= Received: by 10.140.56.21 with SMTP id e21mr9157357rva.46.1275668612601; Fri, 04 Jun 2010 09:23:32 -0700 (PDT) Received: from [10.0.1.15] ([24.130.32.55]) by mx.google.com with ESMTPS id l29sm2503285rvb.16.2010.06.04.09.23.31 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 04 Jun 2010 09:23:31 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Dick Hardt In-Reply-To: <4C09226A.6090502@lodderstedt.net> Date: Fri, 4 Jun 2010 09:23:29 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C090B6C.9030707@aol.com> <4C09226A.6090502@lodderstedt.net> To: Torsten Lodderstedt X-Mailer: Apple Mail (2.1078) Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Partially standardized format for access tokens? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 16:23:49 -0000 +1 (just in case that was not clear from my other emails :) On 2010-06-04, at 8:57 AM, Torsten Lodderstedt wrote: > +1 for an optional "token_format" attribute/parameter >=20 > Am 04.06.2010 17:21, schrieb John Kemp: >> Hi Luke, >>=20 >> On Jun 4, 2010, at 11:00 AM, Luke Shepard wrote: >>=20 >> =20 >>> On Jun 4, 2010, at 7:19 AM, George Fletcher wrote: >>>=20 >>> =20 >>>> On 6/4/10 9:53 AM, Luke Shepard wrote: >>>> =20 >>>>> Having a single resource server that works with multiple = independent auth servers is not in scope for OAuth. That said, there's = nothing to stop multiple servers to agree amongst themselves to have a = standardized format for access token- and if necessary, to write that = agreement as a separate spec (perhaps an extension). >>>>> =20 >>>> -1 >>>>=20 >>>> limiting OAuth to a single Authorization Server (AS) and it's = associated SPs (resource owners) significantly restricts the value of = delegation across the internet. >>>>=20 >>>> =20 >>> I'm not saying that we need to limit it just to that circumstance, = but the single-server scenario is one of the most common use cases for = OAuth - for example, Google, Flickr, Facebook, Yahoo, Twitter all = generally support tokens that only work on their own services. I've = listed one reason why a formalized structure would be bad for Facebook = (token size would increase). >>>=20 >>> We should solve one problem at a time. It's easy to layer structure = on top of an opaque blob in a separate spec. The question to ask is, if = a provider chose NOT to support whatever standardized token format that = came up, would they still be able to use the OAuth 2.0 flows? If the = answer is yes, then it belongs in a different spec. >>> =20 >> I think that even if specific token formats are defined in separate = specs. (which I agree with) you would still need to define a = standardized optional attribute to carry the format description = reference. >>=20 >> What is wrong with agreeing in OAuth itself to do that much - define = an optional attribute called "token_format" which MAY be present, and if = so MUST be passed on by the client? If the format attribute is not = present, it's value has default semantics of "opaque"? Other = specifications may then define additional format values and describe in = more details what they mean. >>=20 >> Regards, >>=20 >> - johnk >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> =20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From lshepard@facebook.com Fri Jun 4 09:46:47 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB9193A67A3 for ; Fri, 4 Jun 2010 09:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.181 X-Spam-Level: X-Spam-Status: No, score=-2.181 tagged_above=-999 required=5 tests=[AWL=1.084, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RDctGdCGJ00W for ; Fri, 4 Jun 2010 09:46:46 -0700 (PDT) Received: from mailout-snc1.facebook.com (mailout-snc1.facebook.com [69.63.179.25]) by core3.amsl.com (Postfix) with ESMTP id DFCAF3A67E5 for ; Fri, 4 Jun 2010 09:46:46 -0700 (PDT) Received: from mail.thefacebook.com ([192.168.18.198]) by pp01.snc1.tfbnw.net (8.14.3/8.14.3) with ESMTP id o54Gk9f2003414 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 4 Jun 2010 09:46:09 -0700 Received: from sc-hub06.TheFacebook.com (192.168.18.83) by sc-hub03.TheFacebook.com (192.168.18.198) with Microsoft SMTP Server (TLS) id 14.0.694.1; Fri, 4 Jun 2010 09:46:29 -0700 Received: from SC-MBXC1.TheFacebook.com ([192.168.18.102]) by sc-hub06.TheFacebook.com ([192.168.18.83]) with mapi; Fri, 4 Jun 2010 09:45:02 -0700 From: Luke Shepard To: Dick Hardt Date: Fri, 4 Jun 2010 09:45:15 -0700 Thread-Topic: [OAUTH-WG] Partially standardized format for access tokens? Thread-Index: AcsEBUbQBodPN7E7S+qVt3Gv7NqbBA== Message-ID: References: <4C090B6C.9030707@aol.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 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-06-04_01:2010-02-06, 2010-06-04, 2010-06-04 signatures=0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Partially standardized format for access tokens? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 16:46:48 -0000 On Jun 4, 2010, at 8:41 AM, Dick Hardt wrote: > There is more to the web than the social web Luke, and supporting multipl= e AS has been a design goal of WRAP and OAuth 2.0 and is being implemented. Whoa, I didn't say there wasn't. I agree that supporting multiple authoriza= tion servers is a reasonable design goal and there are some people who are = making that work. I was just pointing that that a common case, today, is to have a single aut= horization server for a given resource - I mentioned several examples of se= rvices that work this way now. OAuth 2.0 needs to support that use case in = a clean way.= From gffletch@aol.com Fri Jun 4 09:59:01 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AB8B3A694C for ; Fri, 4 Jun 2010 09:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.556 X-Spam-Level: X-Spam-Status: No, score=-0.556 tagged_above=-999 required=5 tests=[AWL=-0.371, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hzyWpfIUA9hi for ; Fri, 4 Jun 2010 09:59:00 -0700 (PDT) Received: from imr-mb02.mx.aol.com (imr-mb02.mx.aol.com [64.12.207.163]) by core3.amsl.com (Postfix) with ESMTP id 954F53A67E5 for ; Fri, 4 Jun 2010 09:59:00 -0700 (PDT) Received: from mtaout-mb02.r1000.mx.aol.com (mtaout-mb02.r1000.mx.aol.com [172.29.41.66]) by imr-mb02.mx.aol.com (8.14.1/8.14.1) with ESMTP id o54GwP5N023917; Fri, 4 Jun 2010 12:58:27 -0400 Received: from palantir.local (unknown [10.181.183.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-mb02.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 2C818E0000AD; Fri, 4 Jun 2010 12:58:27 -0400 (EDT) Message-ID: <4C0930B2.80802@aol.com> Date: Fri, 04 Jun 2010 12:58:26 -0400 From: George Fletcher Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Luke Shepard References: <4C090B6C.9030707@aol.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit x-aol-global-disposition: G X-AOL-SCOLL-SCORE: 0:2:343404224:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d29424c0930b32ac0 X-AOL-IP: 10.181.183.108 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Partially standardized format for access tokens? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 16:59:01 -0000 Could I conclude then that "we" are all in "agreement"? :) 1. OAuth 2.0 should not require a structured token (i.e. don't break existing use cases) 2. OAuth 2.0 should not prohibit resource owners supporting multiple Authentication Servers 3. OAuth 2.0 should allow for structured tokens via a separate spec 4. OAuth 2.0 should consider specifying an additional, optional parameter that is opaque to the client but identifies the "token format" Thanks, George On 6/4/10 12:45 PM, Luke Shepard wrote: > On Jun 4, 2010, at 8:41 AM, Dick Hardt wrote: > > >> There is more to the web than the social web Luke, and supporting multiple AS has been a design goal of WRAP and OAuth 2.0 and is being implemented. >> > Whoa, I didn't say there wasn't. I agree that supporting multiple authorization servers is a reasonable design goal and there are some people who are making that work. > > I was just pointing that that a common case, today, is to have a single authorization server for a given resource - I mentioned several examples of services that work this way now. OAuth 2.0 needs to support that use case in a clean way.= > > From recordond@gmail.com Fri Jun 4 10:35:25 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01CA73A69A1 for ; Fri, 4 Jun 2010 10:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.467 X-Spam-Level: X-Spam-Status: No, score=-1.467 tagged_above=-999 required=5 tests=[AWL=-0.728, BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BO18J7ESIIQd for ; Fri, 4 Jun 2010 10:35:23 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id B6DE13A6874 for ; Fri, 4 Jun 2010 10:35:23 -0700 (PDT) Received: by iwn42 with SMTP id 42so1282336iwn.31 for ; Fri, 04 Jun 2010 10:35:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=+3Jpd8PenwL0JkoMGv/CG+0RoeohXTY1uGfbSWplWp4=; b=woia1TQmyj509zcRpz45Q1SFO7No4i62Luj8lPt7ispSUlhQ7lYOSwDU+S+HiFQj2n ridh0hW2OkF71TvtHAOYs5+81ecdCk3sbXDSfLow+y7fRWyQZ1wrEJjY2ISHunHmuutt +LjH/8xu/m35Cy4rdI78o1reFO2YYK25zIs2s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=QF611pHBlSR45xYWaCPJUCZqmWIzU8kktW4sk6lzCUh/yWSlkB9e3GEHwdsCTYGDg3 twvLWPU+HmYnhEGjd6s0AXIgQOzuPKzrm9hXVMdONtn2fhjUyZQLwGsry71S4cpeTRrG KodPWscU5k14h39UXC5RhqBXUHyZ6YgWQvI2Q= MIME-Version: 1.0 Received: by 10.231.115.206 with SMTP id j14mr1150173ibq.131.1275672906589; Fri, 04 Jun 2010 10:35:06 -0700 (PDT) Received: by 10.231.192.19 with HTTP; Fri, 4 Jun 2010 10:35:06 -0700 (PDT) In-Reply-To: <4C0930B2.80802@aol.com> References: <4C090B6C.9030707@aol.com> <4C0930B2.80802@aol.com> Date: Fri, 4 Jun 2010 10:35:06 -0700 Message-ID: From: David Recordon To: George Fletcher Content-Type: multipart/alternative; boundary=00504501444c727846048837be15 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Partially standardized format for access tokens? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 17:35:25 -0000 --00504501444c727846048837be15 Content-Type: text/plain; charset=ISO-8859-1 #4 should happen as part of #3. On Fri, Jun 4, 2010 at 9:58 AM, George Fletcher wrote: > Could I conclude then that "we" are all in "agreement"? :) > > 1. OAuth 2.0 should not require a structured token (i.e. don't break > existing use cases) > 2. OAuth 2.0 should not prohibit resource owners supporting multiple > Authentication Servers > 3. OAuth 2.0 should allow for structured tokens via a separate spec > 4. OAuth 2.0 should consider specifying an additional, optional parameter > that is opaque to the client but identifies the "token format" > > Thanks, > George > > > On 6/4/10 12:45 PM, Luke Shepard wrote: > >> On Jun 4, 2010, at 8:41 AM, Dick Hardt wrote: >> >> >> >>> There is more to the web than the social web Luke, and supporting >>> multiple AS has been a design goal of WRAP and OAuth 2.0 and is being >>> implemented. >>> >>> >> Whoa, I didn't say there wasn't. I agree that supporting multiple >> authorization servers is a reasonable design goal and there are some people >> who are making that work. >> >> I was just pointing that that a common case, today, is to have a single >> authorization server for a given resource - I mentioned several examples of >> services that work this way now. OAuth 2.0 needs to support that use case in >> a clean way.= >> >> >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --00504501444c727846048837be15 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable #4 should happen as part of #3.


On F= ri, Jun 4, 2010 at 9:58 AM, George Fletcher <gffletch@aol.com> wrote:
Could I conclude then that "we" are all in "agreement"?= :)

1. OAuth 2.0 should not require a structured token (i.e. don't break ex= isting use cases)
2. OAuth 2.0 should not prohibit resource owners supporting multiple Authen= tication Servers
3. OAuth 2.0 should allow for structured tokens via a separate spec
4. OAuth 2.0 should consider specifying an additional, optional parameter t= hat is opaque to the client but identifies the "token format"

Thanks,
George


On 6/4/10 12:45 PM, Luke Shepard wrote:
On Jun 4, 2010, at 8:41 AM, Dick Hardt wrote:

=A0
There is more to the web than the social web Luke, and supporting multiple = AS has been a design goal of WRAP and OAuth 2.0 and is being implemented. =A0 =A0
Whoa, I didn't say there wasn't. I agree that supporting multiple a= uthorization servers is a reasonable design goal and there are some people = who are making that work.

I was just pointing that that a common case, today, is to have a single aut= horization server for a given resource - I mentioned several examples of se= rvices that work this way now. OAuth 2.0 needs to support that use case in = a clean way.=3D

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

--00504501444c727846048837be15-- From kris.selden@gmail.com Fri Jun 4 10:42:41 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B3883A6892 for ; Fri, 4 Jun 2010 10:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[AWL=-0.464, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dSRIpvKKs0c2 for ; Fri, 4 Jun 2010 10:42:40 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 2FE833A67E5 for ; Fri, 4 Jun 2010 10:42:40 -0700 (PDT) Received: by pwi8 with SMTP id 8so786474pwi.31 for ; Fri, 04 Jun 2010 10:42:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=R7oB/xJaEkt1GLhFMssHhv60gSSrq8HVtEfEMXOLb4s=; b=JJyfczNOIQ+/7Gsc3pVWd05USVKPOrZqEBezmseJV/jtPG5qAfnZbTs9h092aON2G4 37inuLDck0c65YKeara/AsgkxfhENIMaI95bmpGNIB9jbrwWWsVq+/ESmT3lvWTO/LyZ uxlfAVa2NWIx1X9eSb3lMDRZY73J1m1nMRnWw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=fXDGg0OdTXbdPw4uCwocAc13rGbbOk3C4yN2kV5/EaCQnYWKI4t9lahiFj+gFsg2Zo rj2APUVFeZUHyCg3KgsqmNfQHcC3k6Q0MyTiezjbTJcnwG7/W5UftQJMXj+029Ttpfot DidSe33kQIVrfVv6Re7Vj+dj3dpwJbDpu8NH0= Received: by 10.143.21.19 with SMTP id y19mr8259746wfi.259.1275673343750; Fri, 04 Jun 2010 10:42:23 -0700 (PDT) Received: from [10.210.5.137] (74-94-67-45-tacoma-wa.hfc.comcastbusiness.net [74.94.67.45]) by mx.google.com with ESMTPS id 23sm985571pzk.2.2010.06.04.10.42.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 04 Jun 2010 10:42:22 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Kris Selden In-Reply-To: <1275664499.7068.98.camel@localhost.localdomain> Date: Fri, 4 Jun 2010 10:42:20 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0258337A-3B75-4F22-BA2A-DED35B0F9841@gmail.com> References: <4C0900FD.3050904@aol.com> <1275664499.7068.98.camel@localhost.localdomain> To: Justin Richer X-Mailer: Apple Mail (2.1078) Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Definition of XML response format X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 17:42:41 -0000 How about keeping it even more flat and compact: This also is more simple on the DOM side, just doc.root['access_token'] = instead of traversing or xpath. Anyway, I think OAuth 2 is better served in general by the KISS = principle . -Kris On Jun 4, 2010, at 8:14 AM, Justin Richer wrote: > I'd personally rather see something flatter, even with an implied root > namespace defined in the spec. Maybe like: >=20 > > asdfasoij234f > 2f098jadfasdfasdf > 300 > >=20 > Mirroring the key-value format for the JSON and form-encoded forms, = this > keeps the field names as elements and the values as text node values. > I'd rather not see us hang a "value=3D" attribute in all of these. >=20 > -- Justin >=20 >=20 > On Fri, 2010-06-04 at 09:42 -0400, Andrew Arnott wrote: >> Thanks, George. =46rom that I get this: >> >> token >> secret >>=20 >> >> =46rom the text around it, it sounds like SPs were permitted to add = to >> this (presumably using their own element names). While this seems >> reasonable, it seems that SP-specific extensions that used alternate >> element names would then be incompatible with JSON and url-encoded >> responses since they cannot include this extra element metadata. >> (well JSON could, with some breaking changes to the format). >>=20 >> So with that, it seems like we should eliminate the redundant >> oauth_parameter element name in favor of just using the name of the >> parameter as the element name. >>=20 >> -- >> 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 >>=20 >>=20 >> On Fri, Jun 4, 2010 at 6:34 AM, George Fletcher >> wrote: >> I don't know if this is helpful or not... but there was a >> proposed extension for OAuth 1.0 dealing with encoding OAuth >> responses in different body formats... this can be found on >> the now extinct oauth-extensions google group. >>=20 >> = http://groups.google.com/group/oauth-extensions/browse_thread/thread/419ec= 4e986ff5cd8?hl=3Den# >>=20 >> Thanks, >> George >>=20 >>=20 >> On 6/4/10 8:56 AM, Andrew Arnott wrote: >>>=20 >>> In the absence of anyone else volunteering an XML format, >>> what would you say to this as a proposal (because the >>> implementation of which happens to be simple for me): >>>=20 >>> >>> some access >>> token >>> some refresh >>> token >>> 235298298 >>> >>>=20 >>> So the main points here is: >>> 1. no namespace >>> 2. root tag is called "root" >>> 3. each parameter is an element >>> 4. each element has a type parameter that is either >>> string, number, or object to assist the deserializer >>> to understnad how to cast the contents. >>> We may axe #4. In fact we may want to switch all the >>> elements to attributes because it's slightly more compact >>> which might help small devices. >>>=20 >>> -- >>> 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 >>>=20 >>>=20 >>> On Mon, May 31, 2010 at 9:12 AM, Andrew Arnott >>> wrote: >>> Where is the definition of how a auth server >>> response in XML format should look? At the least we >>> need an XML namespace and root node name. >>>=20 >>> -- >>> 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 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 From john@jkemp.net Fri Jun 4 10:46:13 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCB2C3A69D6 for ; Fri, 4 Jun 2010 10:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.335 X-Spam-Level: X-Spam-Status: No, score=0.335 tagged_above=-999 required=5 tests=[BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fXuJb+pYnQXI for ; Fri, 4 Jun 2010 10:46:12 -0700 (PDT) Received: from cpoproxy3-pub.bluehost.com (cpoproxy3-pub.bluehost.com [67.222.54.6]) by core3.amsl.com (Postfix) with SMTP id A57F23A69BF for ; Fri, 4 Jun 2010 10:46:12 -0700 (PDT) Received: (qmail 15186 invoked by uid 0); 4 Jun 2010 17:45:59 -0000 Received: from unknown (HELO box320.bluehost.com) (69.89.31.120) by cpoproxy3.bluehost.com with SMTP; 4 Jun 2010 17:45:59 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=jkemp.net; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-Identified-User; b=ejp6VD8afjJiNm7doCLsXN4/JLSf9+5Vn1ZGjraac8W1vaxUcDvMP7dpiQcQ3mqWIM1KthV69UEma5z2n3V7+Y3mQZKpyJelZJ5g0ljIUtT7XrGtyXJBfm+/ftAc+kj8; Received: from cpe-69-205-56-47.nycap.res.rr.com ([69.205.56.47] helo=[192.168.1.107]) by box320.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1OKaxy-00032D-QL; Fri, 04 Jun 2010 11:45:59 -0600 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: John Kemp In-Reply-To: Date: Fri, 4 Jun 2010 13:45:57 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <39D25154-9A0E-4357-B5D0-439AFBFC3DE7@jkemp.net> References: <4C090B6C.9030707@aol.com> <4C0930B2.80802@aol.com> To: David Recordon X-Mailer: Apple Mail (2.1078) X-Identified-User: {1122:box320.bluehost.com:jkempnet:jkemp.net} {sentby:smtp auth 69.205.56.47 authed with john+jkemp.net} Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Partially standardized format for access tokens? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 17:46:13 -0000 On Jun 4, 2010, at 1:35 PM, David Recordon wrote: > #4 should happen as part of #3. How would ALL OAuth 2.0+ clients know to pass along the format if it is = there? I fail to see the problem with specifying an optional token format = parameter in the main spec. and giving it a default value, and semantics = of "opaque" for when it isn't present (ie. the current case). That = explicitly allows other specifications to use the attribute, and is then = good for future interoperability (and also future = backwards-compatibility) - johnk >=20 >=20 > On Fri, Jun 4, 2010 at 9:58 AM, George Fletcher = wrote: > Could I conclude then that "we" are all in "agreement"? :) >=20 > 1. OAuth 2.0 should not require a structured token (i.e. don't break = existing use cases) > 2. OAuth 2.0 should not prohibit resource owners supporting multiple = Authentication Servers > 3. OAuth 2.0 should allow for structured tokens via a separate spec > 4. OAuth 2.0 should consider specifying an additional, optional = parameter that is opaque to the client but identifies the "token format" >=20 > Thanks, > George >=20 >=20 > On 6/4/10 12:45 PM, Luke Shepard wrote: > On Jun 4, 2010, at 8:41 AM, Dick Hardt wrote: >=20 > =20 > There is more to the web than the social web Luke, and supporting = multiple AS has been a design goal of WRAP and OAuth 2.0 and is being = implemented. > =20 > Whoa, I didn't say there wasn't. I agree that supporting multiple = authorization servers is a reasonable design goal and there are some = people who are making that work. >=20 > I was just pointing that that a common case, today, is to have a = single authorization server for a given resource - I mentioned several = examples of services that work this way now. OAuth 2.0 needs to support = that use case in a clean way.=3D >=20 > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From torsten@lodderstedt.net Fri Jun 4 11:31:51 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A62973A6994 for ; Fri, 4 Jun 2010 11:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.441 X-Spam-Level: X-Spam-Status: No, score=0.441 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aVgMS6BZbTf4 for ; Fri, 4 Jun 2010 11:31:50 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.32]) by core3.amsl.com (Postfix) with ESMTP id 5B8BD3A67E5 for ; Fri, 4 Jun 2010 11:31:49 -0700 (PDT) Received: from p4fff0aeb.dip.t-dialin.net ([79.255.10.235] helo=[127.0.0.1]) by smtprelay04.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OKbg6-0003Pr-GB; Fri, 04 Jun 2010 20:31:34 +0200 Message-ID: <4C094683.1080606@lodderstedt.net> Date: Fri, 04 Jun 2010 20:31:31 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: John Kemp References: <4C090B6C.9030707@aol.com> <4C0930B2.80802@aol.com> <39D25154-9A0E-4357-B5D0-439AFBFC3DE7@jkemp.net> In-Reply-To: <39D25154-9A0E-4357-B5D0-439AFBFC3DE7@jkemp.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Partially standardized format for access tokens? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 18:31:51 -0000 Am 04.06.2010 19:45, schrieb John Kemp: > On Jun 4, 2010, at 1:35 PM, David Recordon wrote: > > >> #4 should happen as part of #3. >> > How would ALL OAuth 2.0+ clients know to pass along the format if it is there? > > I fail to see the problem with specifying an optional token format parameter in the main spec. and giving it a default value, and semantics of "opaque" for when it isn't present (ie. the current case). That explicitly allows other specifications to use the attribute, and is then good for future interoperability (and also future backwards-compatibility) > > there is another point: such a parameter could be used to let the authorization server indicate the format of the access token to the resource server. This will help deployments with more than one token format in use. For example, we use SAML and another proprietary format. Without such a parameter, the resource server has to somehow (magically) find out the format of the incomming token. From my point of view, #4 should happen now independent of #3. regards, Torsten. > - johnk > > >> >> On Fri, Jun 4, 2010 at 9:58 AM, George Fletcher wrote: >> Could I conclude then that "we" are all in "agreement"? :) >> >> 1. OAuth 2.0 should not require a structured token (i.e. don't break existing use cases) >> 2. OAuth 2.0 should not prohibit resource owners supporting multiple Authentication Servers >> 3. OAuth 2.0 should allow for structured tokens via a separate spec >> 4. OAuth 2.0 should consider specifying an additional, optional parameter that is opaque to the client but identifies the "token format" >> >> Thanks, >> George >> >> >> On 6/4/10 12:45 PM, Luke Shepard wrote: >> On Jun 4, 2010, at 8:41 AM, Dick Hardt wrote: >> >> >> There is more to the web than the social web Luke, and supporting multiple AS has been a design goal of WRAP and OAuth 2.0 and is being implemented. >> >> Whoa, I didn't say there wasn't. I agree that supporting multiple authorization servers is a reasonable design goal and there are some people who are making that work. >> >> I was just pointing that that a common case, today, is to have a single authorization server for a given resource - I mentioned several examples of services that work this way now. OAuth 2.0 needs to support that use case in a clean way.= >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From dick.hardt@gmail.com Fri Jun 4 11:33:32 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 187D83A69BF for ; Fri, 4 Jun 2010 11:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.462 X-Spam-Level: X-Spam-Status: No, score=-0.462 tagged_above=-999 required=5 tests=[AWL=-0.464, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b6bpZddKmw0Q for ; Fri, 4 Jun 2010 11:33:30 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id D9A883A6994 for ; Fri, 4 Jun 2010 11:33:30 -0700 (PDT) Received: by pwi8 with SMTP id 8so805154pwi.31 for ; Fri, 04 Jun 2010 11:33:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=mPt6ftKd2EWSsx8V1eXqMU2ICHHdJNa1LqLA0YYwZgM=; b=iTheMQduQ6tdWF/s9MQN2h3HXWZOdcliNbVb1UXwfFW7tEWRLEl58e+sJIYSMz0lzS Za+++JkPSJ5A0Q6tSko6aYE1xn2jPHhJJCvxQGqxFf3clDXSEn0bPa8Jdm1HkcnxPGtt 9MkOSTJ0K5Pn+RJArPzCRC07O1xSFTSi5pIvY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=WH2gdz4evOvYozmjzKyyl3sS8uPf45VqcjiGIY1pqraCeIm6xcuyO/Fg168qluax62 v3CrYZ8CrwzYTeVxCmdxdbKrN1UES5VMmXpfJYBmTb2Re53YFoMCAX2jntEms1IB3QLH qnZKQH0Yfr1NAre3IqnYYFevJEHpFcH9cmcNg= MIME-Version: 1.0 Received: by 10.142.210.13 with SMTP id i13mr8514131wfg.143.1275676394166; Fri, 04 Jun 2010 11:33:14 -0700 (PDT) Received: by 10.143.167.14 with HTTP; Fri, 4 Jun 2010 11:33:14 -0700 (PDT) In-Reply-To: <39D25154-9A0E-4357-B5D0-439AFBFC3DE7@jkemp.net> References: <4C090B6C.9030707@aol.com> <4C0930B2.80802@aol.com> <39D25154-9A0E-4357-B5D0-439AFBFC3DE7@jkemp.net> Date: Fri, 4 Jun 2010 11:33:14 -0700 Message-ID: From: Dick Hardt To: John Kemp Content-Type: multipart/alternative; boundary=000e0cd32eaa529b610488388ec1 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Partially standardized format for access tokens? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 18:33:32 -0000 --000e0cd32eaa529b610488388ec1 Content-Type: text/plain; charset=ISO-8859-1 David, are you saying the optional parameter should be a separate spec, or that #3 and #4 are the same thing? (I disagree with both L) I see a new, standard token and specifying the token format are orthogonal. The PR may accept multiple proprietary token types. if we have the parameter in the spec, then clients know to pass it along if they see it. -- Dick On Fri, Jun 4, 2010 at 10:45 AM, John Kemp wrote: > On Jun 4, 2010, at 1:35 PM, David Recordon wrote: > > > #4 should happen as part of #3. > > How would ALL OAuth 2.0+ clients know to pass along the format if it is > there? > > I fail to see the problem with specifying an optional token format > parameter in the main spec. and giving it a default value, and semantics of > "opaque" for when it isn't present (ie. the current case). That explicitly > allows other specifications to use the attribute, and is then good for > future interoperability (and also future backwards-compatibility) > > - johnk > > > > > > > On Fri, Jun 4, 2010 at 9:58 AM, George Fletcher > wrote: > > Could I conclude then that "we" are all in "agreement"? :) > > > > 1. OAuth 2.0 should not require a structured token (i.e. don't break > existing use cases) > > 2. OAuth 2.0 should not prohibit resource owners supporting multiple > Authentication Servers > > 3. OAuth 2.0 should allow for structured tokens via a separate spec > > 4. OAuth 2.0 should consider specifying an additional, optional parameter > that is opaque to the client but identifies the "token format" > > > > Thanks, > > George > > > > > > On 6/4/10 12:45 PM, Luke Shepard wrote: > > On Jun 4, 2010, at 8:41 AM, Dick Hardt wrote: > > > > > > There is more to the web than the social web Luke, and supporting > multiple AS has been a design goal of WRAP and OAuth 2.0 and is being > implemented. > > > > Whoa, I didn't say there wasn't. I agree that supporting multiple > authorization servers is a reasonable design goal and there are some people > who are making that work. > > > > I was just pointing that that a common case, today, is to have a single > authorization server for a given resource - I mentioned several examples of > services that work this way now. OAuth 2.0 needs to support that use case in > a clean way.= > > > > > > _______________________________________________ > > OAuth mailing 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 > --000e0cd32eaa529b610488388ec1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable David, are you saying the optional parameter should be a separate spec, or = that #3 and #4 are the same thing? (I disagree with both L)

<= div>I see a=A0new, standard token and specifying the token format are ortho= gonal. The PR may accept multiple proprietary token types.

if we have the parameter in the spec, then clients know= to pass it along if they see it.=A0

-- Dick

On Fri, Jun 4, 2010 at= 10:45 AM, John Kemp <john@jkemp.net> wrote:
On Jun 4, 2010, at 1:35 P= M, David Recordon wrote:

> #4 should happen as part of #3.

How would ALL OAuth 2.0+ clients know to pass along the format if it = is there?

I fail to see the problem with specifying an optional token format paramete= r in the main spec. and giving it a default value, and semantics of "o= paque" for when it isn't present (ie. the current case). That expl= icitly allows other specifications to use the attribute, and is then good f= or future interoperability (and also future backwards-compatibility)

- johnk

>
>
> On Fri, Jun 4, 2010 at 9:58 AM, George Fletcher <gffletch@aol.com> wrote:
> Could I conclude then that "we" are all in "agreement&q= uot;? :)
>
> 1. OAuth 2.0 should not require a structured token (i.e. don't bre= ak existing use cases)
> 2. OAuth 2.0 should not prohibit resource owners supporting multiple A= uthentication Servers
> 3. OAuth 2.0 should allow for structured tokens via a separate spec > 4. OAuth 2.0 should consider specifying an additional, optional parame= ter that is opaque to the client but identifies the "token format"= ;
>
> Thanks,
> George
>
>
> On 6/4/10 12:45 PM, Luke Shepard wrote:
> On Jun 4, 2010, at 8:41 AM, Dick Hardt wrote:
>
>
> There is more to the web than the social web Luke, and supporting mult= iple AS has been a design goal of WRAP and OAuth 2.0 and is being implement= ed.
>
> Whoa, I didn't say there wasn't. I agree that supporting multi= ple authorization servers is a reasonable design goal and there are some pe= ople who are making that work.
>
> I was just pointing that that a common case, today, is to have a singl= e authorization server for a given resource - I mentioned several examples = of services that work this way now. OAuth 2.0 needs to support that use cas= e in a clean way.=3D
>
>
> _______________________________________________
> OAuth mailing 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

--000e0cd32eaa529b610488388ec1-- From dick.hardt@gmail.com Fri Jun 4 11:35:20 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5345A3A6998 for ; Fri, 4 Jun 2010 11:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.717 X-Spam-Level: X-Spam-Status: No, score=-0.717 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uROxWUe-UZO9 for ; Fri, 4 Jun 2010 11:35:19 -0700 (PDT) Received: from mail-pz0-f195.google.com (mail-pz0-f195.google.com [209.85.222.195]) by core3.amsl.com (Postfix) with ESMTP id 6A6C53A68C7 for ; Fri, 4 Jun 2010 11:35:19 -0700 (PDT) Received: by pzk33 with SMTP id 33so1747007pzk.17 for ; Fri, 04 Jun 2010 11:35:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=nVCcOa7Dozrct9tIhSIl2cv/+UvNRN0zeFvOlO/8Go0=; b=LDNWVhZHS/cV/pR3UhF86ZpOnrTGcaSY6lEbOt4D2k53FnbxyofLbNRzU5JK+VEcbU VRzTLBwJh0j1POgCQ+zLlWRsf3Wz0lI1AnkrPSn8TKB7D3AQ9xAmejVV4+W4t6dTL0W6 0jztMt3fyiN2O+J1+T7Yr5oAdAg2pOodGZQnA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Cr4BuTyr0iUICi26kxMwX2KdjjgQ5MgcdGi67rJdczQs4uz4zNqCvw+QGcYRaVbSXN PxTDPYCfbfMwFeN6EEtaNvEZsu7sOKcR8yBb03Hj+Z5SGRQNAHI5N13RRaS3Jfdn4dq8 1RleLrpa8BC6vVLo1bB3laJduP74ImDZTRLLc= MIME-Version: 1.0 Received: by 10.142.61.24 with SMTP id j24mr8373792wfa.177.1275676502882; Fri, 04 Jun 2010 11:35:02 -0700 (PDT) Received: by 10.143.167.14 with HTTP; Fri, 4 Jun 2010 11:35:02 -0700 (PDT) In-Reply-To: References: <4C090B6C.9030707@aol.com> Date: Fri, 4 Jun 2010 11:35:02 -0700 Message-ID: From: Dick Hardt To: Luke Shepard Content-Type: multipart/alternative; boundary=0016368e290ecd7e0e048838947e Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Partially standardized format for access tokens? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 18:35:20 -0000 --0016368e290ecd7e0e048838947e Content-Type: text/plain; charset=ISO-8859-1 You earlier stated that multiple AS was out of scope. I am aligned that using OAuth 2.0 needs to support the widely deployed social web use cases -- if you recall, I drove getting rid of the signature requirement! :) On Fri, Jun 4, 2010 at 9:45 AM, Luke Shepard wrote: > > On Jun 4, 2010, at 8:41 AM, Dick Hardt wrote: > > > There is more to the web than the social web Luke, and supporting > multiple AS has been a design goal of WRAP and OAuth 2.0 and is being > implemented. > > Whoa, I didn't say there wasn't. I agree that supporting multiple > authorization servers is a reasonable design goal and there are some people > who are making that work. > > I was just pointing that that a common case, today, is to have a single > authorization server for a given resource - I mentioned several examples of > services that work this way now. OAuth 2.0 needs to support that use case in > a clean way. --0016368e290ecd7e0e048838947e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable You earlier stated that multiple AS was out of scope. I am aligned that usi= ng OAuth 2.0 needs to support the widely deployed social web use cases -- i= f you=A0recall, I drove getting rid of the signature requirement! :)
On Fri, Jun 4, 2010 at 9:45 AM, Luke Shepard <lshepard@facebo= ok.com> wrote:

On Jun 4, 2010, at 8:41 AM, Dick Hardt wrote:

> There is more to the web than the social web Luke, and supporting mult= iple AS has been a design goal of WRAP and OAuth 2.0 and is being implement= ed.

Whoa, I didn't say there wasn't. I agree that supporting mult= iple authorization servers is a reasonable design goal and there are some p= eople who are making that work.

I was just pointing that that a common case, today, is to have a single aut= horization server for a given resource - I mentioned several examples of se= rvices that work this way now. OAuth 2.0 needs to support that use case in = a clean way.

--0016368e290ecd7e0e048838947e-- From jricher@mitre.org Fri Jun 4 12:46:56 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58C8A3A6890 for ; Fri, 4 Jun 2010 12:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.939 X-Spam-Level: X-Spam-Status: No, score=-4.939 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9chqc0bp+ISE for ; Fri, 4 Jun 2010 12:46:55 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 52E713A6858 for ; Fri, 4 Jun 2010 12:46:55 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o54JkelZ021173 for ; Fri, 4 Jun 2010 15:46:41 -0400 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o54Jke1O021163; Fri, 4 Jun 2010 15:46:40 -0400 Received: from [129.83.50.65] (129.83.50.65) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server id 8.2.254.0; Fri, 4 Jun 2010 15:46:40 -0400 From: Justin Richer To: George Fletcher In-Reply-To: <4C0930B2.80802@aol.com> References: <4C090B6C.9030707@aol.com> <4C0930B2.80802@aol.com> Content-Type: text/plain; charset="UTF-8" Date: Fri, 4 Jun 2010 15:46:40 -0400 Message-ID: <1275680800.2502.2.camel@localhost.localdomain> MIME-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Partially standardized format for access tokens? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 19:46:56 -0000 1. ++ 2. ++ 3. ++ 4. ++ as a part of 3., otherwise -- -- justin On Fri, 2010-06-04 at 12:58 -0400, George Fletcher wrote: > Could I conclude then that "we" are all in "agreement"? :) > > 1. OAuth 2.0 should not require a structured token (i.e. don't break > existing use cases) > 2. OAuth 2.0 should not prohibit resource owners supporting multiple > Authentication Servers > 3. OAuth 2.0 should allow for structured tokens via a separate spec > 4. OAuth 2.0 should consider specifying an additional, optional > parameter that is opaque to the client but identifies the "token format" > > Thanks, > George > > On 6/4/10 12:45 PM, Luke Shepard wrote: > > On Jun 4, 2010, at 8:41 AM, Dick Hardt wrote: > > > > > >> There is more to the web than the social web Luke, and supporting multiple AS has been a design goal of WRAP and OAuth 2.0 and is being implemented. > >> > > Whoa, I didn't say there wasn't. I agree that supporting multiple authorization servers is a reasonable design goal and there are some people who are making that work. > > > > I was just pointing that that a common case, today, is to have a single authorization server for a given resource - I mentioned several examples of services that work this way now. OAuth 2.0 needs to support that use case in a clean way.= > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From john@jkemp.net Fri Jun 4 12:52:54 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 477F23A69DD for ; Fri, 4 Jun 2010 12:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.335 X-Spam-Level: X-Spam-Status: No, score=0.335 tagged_above=-999 required=5 tests=[BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WHsVCITC9Qqt for ; Fri, 4 Jun 2010 12:52:53 -0700 (PDT) Received: from cpoproxy2-pub.bluehost.com (cpoproxy2-pub.bluehost.com [67.222.39.38]) by core3.amsl.com (Postfix) with SMTP id 2C4CD28C0DB for ; Fri, 4 Jun 2010 12:52:53 -0700 (PDT) Received: (qmail 5735 invoked by uid 0); 4 Jun 2010 19:52:39 -0000 Received: from unknown (HELO box320.bluehost.com) (69.89.31.120) by cpoproxy2.bluehost.com with SMTP; 4 Jun 2010 19:52:39 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=jkemp.net; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-Identified-User; b=EXL5WTe56dwcN3s0UR96aLM0MD8n943MH7DVHhkDvHVCTy9Rov6fMKeOIFYCK02yE1fYvwqPyTnXZIJ1FmXRxV1mLryPIDV6fdFLEzOY78k76n7+FuOpy226yEe1Awy4; Received: from cpe-69-205-56-47.nycap.res.rr.com ([69.205.56.47] helo=[192.168.1.107]) by box320.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1OKcwZ-0003Sy-Cm; Fri, 04 Jun 2010 13:52:39 -0600 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: John Kemp In-Reply-To: <4C094683.1080606@lodderstedt.net> Date: Fri, 4 Jun 2010 15:52:38 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4FDA83D1-EA6B-4248-9A57-8F4578ED1E05@jkemp.net> References: <4C090B6C.9030707@aol.com> <4C0930B2.80802@aol.com> <39D25154-9A0E-4357-B5D0-439AFBFC3DE7@jkemp.net> <4C094683.1080606@lodderstedt.net> To: Torsten Lodderstedt X-Mailer: Apple Mail (2.1078) X-Identified-User: {1122:box320.bluehost.com:jkempnet:jkemp.net} {sentby:smtp auth 69.205.56.47 authed with john+jkemp.net} Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Partially standardized format for access tokens? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 19:52:54 -0000 Torsten, On Jun 4, 2010, at 2:31 PM, Torsten Lodderstedt wrote: >=20 > Am 04.06.2010 19:45, schrieb John Kemp: >> On Jun 4, 2010, at 1:35 PM, David Recordon wrote: >>=20 >> =20 >>> #4 should happen as part of #3. >>> =20 >> How would ALL OAuth 2.0+ clients know to pass along the format if it = is there? >>=20 >> I fail to see the problem with specifying an optional token format = parameter in the main spec. and giving it a default value, and semantics = of "opaque" for when it isn't present (ie. the current case). That = explicitly allows other specifications to use the attribute, and is then = good for future interoperability (and also future = backwards-compatibility) >>=20 >> =20 >=20 > there is another point: such a parameter could be used to let the = authorization server indicate the format of the access token to the = resource server. This will help deployments with more than one token = format in use. For example, we use SAML and another proprietary format. = Without such a parameter, the resource server has to somehow (magically) = find out the format of the incomming token. Yes, that's a good additional point. >=20 > =46rom my point of view, #4 should happen now independent of #3. Agreed. - johnk >=20 > regards, > Torsten. >> - johnk >>=20 >> =20 >>>=20 >>> On Fri, Jun 4, 2010 at 9:58 AM, George Fletcher = wrote: >>> Could I conclude then that "we" are all in "agreement"? :) >>>=20 >>> 1. OAuth 2.0 should not require a structured token (i.e. don't break = existing use cases) >>> 2. OAuth 2.0 should not prohibit resource owners supporting multiple = Authentication Servers >>> 3. OAuth 2.0 should allow for structured tokens via a separate spec >>> 4. OAuth 2.0 should consider specifying an additional, optional = parameter that is opaque to the client but identifies the "token format" >>>=20 >>> Thanks, >>> George >>>=20 >>>=20 >>> On 6/4/10 12:45 PM, Luke Shepard wrote: >>> On Jun 4, 2010, at 8:41 AM, Dick Hardt wrote: >>>=20 >>>=20 >>> There is more to the web than the social web Luke, and supporting = multiple AS has been a design goal of WRAP and OAuth 2.0 and is being = implemented. >>>=20 >>> Whoa, I didn't say there wasn't. I agree that supporting multiple = authorization servers is a reasonable design goal and there are some = people who are making that work. >>>=20 >>> I was just pointing that that a common case, today, is to have a = single authorization server for a given resource - I mentioned several = examples of services that work this way now. OAuth 2.0 needs to support = that use case in a clean way.=3D >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> =20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> =20 >=20 From bcampbell@pingidentity.com Fri Jun 4 14:39:01 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C16D3A6782 for ; Fri, 4 Jun 2010 14:39:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.933 X-Spam-Level: X-Spam-Status: No, score=-3.933 tagged_above=-999 required=5 tests=[AWL=0.556, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5v7ochAgqT9 for ; Fri, 4 Jun 2010 14:39:00 -0700 (PDT) Received: from na3sys009aog111.obsmtp.com (na3sys009aog111.obsmtp.com [74.125.149.205]) by core3.amsl.com (Postfix) with SMTP id 875603A67AE for ; Fri, 4 Jun 2010 14:38:59 -0700 (PDT) Received: from source ([209.85.212.49]) by na3sys009aob111.postini.com ([74.125.148.12]) with SMTP ID DSNKTAlyY/WNkvUOJn3Fjwq2DxMq5h0BZ3xB@postini.com; Fri, 04 Jun 2010 14:38:46 PDT Received: by mail-vw0-f49.google.com with SMTP id 7so1910249vws.36 for ; Fri, 04 Jun 2010 14:38:43 -0700 (PDT) Received: by 10.224.79.22 with SMTP id n22mr6147438qak.258.1275687523173; Fri, 04 Jun 2010 14:38:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.86.19 with HTTP; Fri, 4 Jun 2010 14:38:13 -0700 (PDT) In-Reply-To: <4C07C84C.9070705@stpeter.im> References: <4C07C84C.9070705@stpeter.im> From: Brian Campbell Date: Fri, 4 Jun 2010 15:38:13 -0600 Message-ID: To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Assertion flow and token bootstrapping X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 21:39:01 -0000 On Thu, Jun 3, 2010 at 9:20 AM, Peter Saint-Andre wrote: > > At least for the assertion flow, that's definitely true. At the interim > meeting we had some discussion about perhaps pulling the assertion flow > out of the base spec and into a separate document. Perhaps that's the > best way to proceed. I'd like to see the assertion flow remain in the base spec. From torsten@lodderstedt.net Fri Jun 4 14:42:22 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2E1A3A6895 for ; Fri, 4 Jun 2010 14:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.736 X-Spam-Level: X-Spam-Status: No, score=0.736 tagged_above=-999 required=5 tests=[AWL=-0.215, BAYES_50=0.001, HELO_EQ_DE=0.35, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e51gSSK7FDj6 for ; Fri, 4 Jun 2010 14:42:21 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.39]) by core3.amsl.com (Postfix) with ESMTP id 477FD3A6861 for ; Fri, 4 Jun 2010 14:42:21 -0700 (PDT) Received: from p4fff0aeb.dip.t-dialin.net ([79.255.10.235] helo=[127.0.0.1]) by smtprelay01.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OKeeT-0006To-Js; Fri, 04 Jun 2010 23:42:05 +0200 Message-ID: <4C09732B.5040800@lodderstedt.net> Date: Fri, 04 Jun 2010 23:42:03 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Justin Richer References: <4BFAA6AB.8040809@lodderstedt.net> <4BFC3142.6010506@lodderstedt.net> <4BFC371A.5040109@lodderstedt.net> <4C07F407.4050305@lodderstedt.net> <1275663845.7068.94.camel@localhost.localdomain> In-Reply-To: <1275663845.7068.94.camel@localhost.localdomain> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] multiple access tokens from a single authorization flow? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 21:42:23 -0000 Am 04.06.2010 17:04, schrieb Justin Richer: > What if you had a supertoken that was only good for getting subtokens? > In other words, only the AS knows about the supertoken (a refresh token, > perhaps?), and it allows you to get sub-tokens using the refresh flow to > access each of the different services. Then you could grab as many > different tokens with individual scopes as you want. > I've been thinking about your idea and came up with the following options. 1) authz-server token Let's assume the authorization server issues service-specific (ordinary) access tokens as long as it's possible. If the authorization encounters a scope which requires different access tokens, e.g. "imap,sip,contacts", it issues a special access token instead. Let's call it "authz-server" token. The scope of the access token issued is indicated by a scope return parameter. { "access_token":"SlAV32hkKG", "scope":["authz-server"] "expires_in":3600 } So clients detect the different outcome by evaluating the scope response parameter. Tokens with the special scope "authz-server" are used to acquire service-specific access tokens using the new request "issue_token" (using the assertion flow would also be an option). The desired target service is indicated by a scope parameter. I see different way how this request could work: a) input: orginal scope, output: cannot work for the same reasons the authz flow responded with a "authz-server" token Seems we just shifted the problem :-( b) input: orginal scope, output: multiple access tokens Why did'nt the authorization flow respond that way? Ok, we don't like arrays of tokens. But how can we circumvent that "problem"? c) input: single scope element in (e.g. "imap"), output: token for that scope element only This works, but the client needs to call that request for each and every string in the original scope. That may cause a lot of unnecessary network communication. d) input: single scope element in, output: token for that scope element and all other applicable scopes elements So the result would be the token with the maximum privileges out of the "authz-token" relative to the requested scope element. { "access_token":"SlAV32hkKG", "scope":["imap", "contacts"] "expires_in":3600 } Pro: no token array Con: increases the number of requests a client has to exchange with the authorization server. 2) refresh token Apparently, the authorization server could also return a refresh token instead of an acess token, if it encounters a multi-service scope. The refresh token request could than be used to actually issue access tokens. The request variants are the same as for option (1). Using refresh tokens that way causes a significant change in the refresh token semantics. Currently, they are (1) long-living, (2) optional for some flows and (3) not issued by other flows. With the new semantics, (1) all flows would need to (optionally) issue refresh tokens and (2) all kinds of duration would be possible (from short- to long-living). I'm still convinced that just returning multiple access token from the authz flow (and the refresh token request) would be the simplest solution. Since a request token is really powerful in a multi-service situation, support for scope downgrading by the refresh token request would be a reasonable complement. ------------------------------------------------------------------------------------------------------------ I think it's crucial to agree on the following: authorization of access to different services, which propably require different access tokens, within a single authorization flow is a relevant use case for OAuth2. In my opinion, this is just a consequence of the decoupling of authorization server and resource server(s) in OAuth2. If a single authorization server is responsible for several resource servers, it has to ensure privacy protection and prevention of token abuse for all of its services. This should also include some separation between services, no matter if one uses self-contained tokens or handles. If we agree on the relevance of that use case, we will find a solution. I'm open for feedback and ideas. Any thoughts? regards, Torsten. > This could also be an application for the rescoping proposal, which I'm > liking more now. I've had some colleagues ask me about redelegation in > OAuth2, and I'm starting to think that the rescoping methods might be > the right answer there. I see Torsten's problem as something similar: > you get a token that's good for getting other tokens but not for > accessing protected resources (the refresh token). You then use this > token that has a "global" scope to request tokens with more directed > scopes, which can have all of the per-service signed characteristics in > the token itself that Torsten was talking about. > > Would that work? > > -- Justin > > > On Thu, 2010-06-03 at 14:27 -0400, Torsten Lodderstedt wrote: > >> I probably exaggerated a bit. It's not impossible but it is complex and >> insecure for several reasons: >> >> 1) Such a super token would need to contain the union of all data and >> permissions needed by all requested target services. >> 2) Not all services may by authorized to see all data contained in such >> a super token (privacy!). So, you would need to built different >> service-specific (encrypted) compartments within the token. >> 3) There are target-service-specific characteristics of such a token, >> such as the audience and the signature. You would need to have such >> attributes per service. Using public-key cryptography would relieve this >> point but slow down processing. >> 4) You have to (somehow) prevent a target service from _abusing_ this >> token to access another service for which the super token is valid for. >> The only way I see is the usage of the client secret. >> >> That's why I think, returning multiple tokens is much simpler. >> >> regards, >> Torsten. >> >> Am 03.06.2010 20:10, schrieb Lukas Rosenstock: >> >>> Hi! >>> I'm curious why this is impossible. If access tokens are arbitrary >>> handles which are generated by the authorization server and >>> distributed to all resources, it doesn't make much difference whether >>> one or multiple are generated and in this case it would be better to >>> keep the load on the server rather complicating things for clients. >>> In the scenario (as you have mentioned) where access tokens are >>> self-contained and digitally signed, would it not be possible to >>> generate a "super token" which contains signatures from all resources? >>> I agree this token might be a bit lengthy, but is there any other >>> concern?! >>> >>> Regards, >>> Lukas >>> >>> 2010/5/25 Torsten Lodderstedt: >>> >>> >>>> As I said, every service in our setup needs another access token, with >>>> different content, signed and encrypted with another shared secret. It is >>>> technically impossible to create the super access token. Refresh tokens are >>>> just handles representing the user's authorization and are used by the authz >>>> server only. They therefore can represent any scope. >>>> >>>> >>> >>> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > From torsten@lodderstedt.net Fri Jun 4 14:42:48 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE7CA3A6A18 for ; Fri, 4 Jun 2010 14:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.853 X-Spam-Level: X-Spam-Status: No, score=-0.853 tagged_above=-999 required=5 tests=[AWL=1.396, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29n7ootm4TTO for ; Fri, 4 Jun 2010 14:42:48 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.41]) by core3.amsl.com (Postfix) with ESMTP id E95E03A6A14 for ; Fri, 4 Jun 2010 14:42:47 -0700 (PDT) Received: from p4fff0aeb.dip.t-dialin.net ([79.255.10.235] helo=[127.0.0.1]) by smtprelay03.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OKeet-0006Tn-6p; Fri, 04 Jun 2010 23:42:31 +0200 Message-ID: <4C097346.8050809@lodderstedt.net> Date: Fri, 04 Jun 2010 23:42:30 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Brian Campbell References: <4C07C84C.9070705@stpeter.im> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Assertion flow and token bootstrapping X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 21:42:48 -0000 +1 Am 04.06.2010 23:38, schrieb Brian Campbell: > On Thu, Jun 3, 2010 at 9:20 AM, Peter Saint-Andre wrote: > >> At least for the assertion flow, that's definitely true. At the interim >> meeting we had some discussion about perhaps pulling the assertion flow >> out of the base spec and into a separate document. Perhaps that's the >> best way to proceed. >> > > I'd like to see the assertion flow remain in the base spec. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From dick.hardt@gmail.com Fri Jun 4 14:51:18 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B9B83A6A11 for ; Fri, 4 Jun 2010 14:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[AWL=0.947, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BVIYHDNMfpHR for ; Fri, 4 Jun 2010 14:51:17 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id DB65A3A6782 for ; Fri, 4 Jun 2010 14:51:14 -0700 (PDT) Received: by pwi8 with SMTP id 8so870114pwi.31 for ; Fri, 04 Jun 2010 14:50:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=3MldElZvLrT581SfNYUry+5TS1Q2lWxEg9QRC4/0ung=; b=KUkJ6BUJxlRsG5c4wTmYC6/cDD9Gguh1zs558wJKunIb5yfdnfRJSdvcwtfcft/Eo/ /XOn+jxQ7Ys8xC30K2876BUSmHX1fuGeau69fbDZd+Fr5T8RrSzlqH0Fp4SWpRc+CIp4 4iG+2LELjD+CNpy4oGk+oRih+fW10Lsu4fWV0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=aehbWSI3l87dVF8ffIsLq6YHFW0Hj4Jb1lar5u80ccWPLEGcGu0RUwT4y69Kd6cJo0 tNwLi/2hsb2OfYQBLM/qDFKGGR59H+FlXCKWr+86hXwyFCbTqja8xG8zJXgIvG18Zv2t 224ho8cxp+Cczq9I5AAUMx9YY85fWlrc0CISI= MIME-Version: 1.0 Received: by 10.142.120.2 with SMTP id s2mr8720542wfc.324.1275688258425; Fri, 04 Jun 2010 14:50:58 -0700 (PDT) Received: by 10.143.167.14 with HTTP; Fri, 4 Jun 2010 14:50:58 -0700 (PDT) In-Reply-To: <98B37F7D0484184B9DBDCC44B6C8EDA304B5283E@S4DE9JSAAID.ost.t-com.de> References: <98B37F7D0484184B9DBDCC44B6C8EDA304B5283E@S4DE9JSAAID.ost.t-com.de> Date: Fri, 4 Jun 2010 14:50:58 -0700 Message-ID: From: Dick Hardt To: Axel.Nennker@telekom.de Content-Type: multipart/alternative; boundary=001636e0a80c7cd4cb04883b51d5 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] "3.4. Client Credentials" text change proposal X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 21:51:18 -0000 --001636e0a80c7cd4cb04883b51d5 Content-Type: text/plain; charset=ISO-8859-1 +1 On Fri, Jun 4, 2010 at 12:36 AM, wrote: > +1 > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Nat Sakimura > Sent: Saturday, May 08, 2010 6:45 AM > To: oauth > Subject: [OAUTH-WG] "3.4. Client Credentials" text change proposal > > 3.4. Client Credentials > > When requesting access from the authorization server, the client > identifies itself using its authorization-server-issued client > credentials. > > The Client Credentials does not necessarily be issued by the > authorization server, > but may be issued by the server that authorization server trusts. Thus, > I would like to propose the text change as: > > 3.4. Client Credentials > > When requesting access from the authorization server, the client > identifies itself using its authorization-server-verifiable client > credentials. > > > -- > Nat Sakimura (=nat) > http://www.sakimura.org/en/ > http://twitter.com/_nat_en > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001636e0a80c7cd4cb04883b51d5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1

On Fri, Jun 4, 2010 at 12:36 AM, <Axel.Nennker@t= elekom.de> wrote:
+1

-----Original Message-----
From: oauth-bounces@ietf.org = [mailto:oauth-bounces@ietf.org] On Behalf
Of Nat Sakimura
Sent: Saturday, May 08, 2010 6:45 AM
To: oauth
Subject: [OAUTH-WG] "3.4. Client Credentials" text change proposa= l

3.4. =A0Client Credentials

=A0 When requesting access from the authorization server, the client
=A0 identifies itself using its authorization-server-issued client
=A0 credentials.

The Client Credentials does not necessarily be issued by the
authorization server,
but may be issued by the server that authorization server trusts. Thus,
I would like to propose the text change as:

3.4. =A0Client Credentials

=A0 When requesting access from the authorization server, the client
=A0 identifies itself using its authorization-server-verifiable client
=A0 credentials.


--
Nat Sakimura (=3Dnat)
http://www.sakimu= ra.org/en/
http://twitter.com= /_nat_en
_______________________________________________
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

--001636e0a80c7cd4cb04883b51d5-- From tonynad@microsoft.com Fri Jun 4 15:08:21 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAFBB3A6782 for ; Fri, 4 Jun 2010 15:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.109 X-Spam-Level: X-Spam-Status: No, score=-9.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mx1DHrsEdvRy for ; Fri, 4 Jun 2010 15:08:20 -0700 (PDT) Received: from smtp.microsoft.com (maila.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 6E1703A6825 for ; Fri, 4 Jun 2010 15:08:20 -0700 (PDT) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 4 Jun 2010 15:08:06 -0700 Received: from TK5EX14MBXC101.redmond.corp.microsoft.com ([169.254.1.223]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.01.0160.007; Fri, 4 Jun 2010 15:08:05 -0700 From: Anthony Nadalin To: Andrew Arnott , George Fletcher Thread-Topic: [OAUTH-WG] Definition of XML response format Thread-Index: AQHLANwuWQYShiG3AkGzYy07XyBvyZJyPjOAgAAK2oCAAAI2AP//++lQ Date: Fri, 4 Jun 2010 22:08:05 +0000 Message-ID: References: <4C0900FD.3050904@aol.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_A08279DC79B11C48AD587060CD93977125F7F153TK5EX14MBXC101r_" MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Definition of XML response format X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 22:08:22 -0000 --_000_A08279DC79B11C48AD587060CD93977125F7F153TK5EX14MBXC101r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It would be useful to understand the token type as the AS and RS server may= each generate and accept different token types From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of A= ndrew Arnott Sent: Friday, June 04, 2010 6:43 AM To: George Fletcher Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Definition of XML response format Thanks, George. From that I get this: token secret >From the text around it, it sounds like SPs were permitted to add to this (= presumably using their own element names). While this seems reasonable, it= seems that SP-specific extensions that used alternate element names would = then be incompatible with JSON and url-encoded responses since they cannot = include this extra element metadata. (well JSON could, with some breaking = changes to the format). So with that, it seems like we should eliminate the redundant oauth_paramet= er element name in favor of just using the name of the parameter as the ele= ment name. -- 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 Fri, Jun 4, 2010 at 6:34 AM, George Fletcher > wrote: I don't know if this is helpful or not... but there was a proposed extensio= n for OAuth 1.0 dealing with encoding OAuth responses in different body for= mats... this can be found on the now extinct oauth-extensions google group. http://groups.google.com/group/oauth-extensions/browse_thread/thread/419ec4= e986ff5cd8?hl=3Den# Thanks, George On 6/4/10 8:56 AM, Andrew Arnott wrote: In the absence of anyone else volunteering an XML format, what would you sa= y to this as a proposal (because the implementation of which happens to be = simple for me): some access token some refresh token 235298298 So the main points here is: 1. no namespace 2. root tag is called "root" 3. each parameter is an element 4. each element has a type parameter that is either string, number, or o= bject to assist the deserializer to understnad how to cast the contents. We may axe #4. In fact we may want to switch all the elements to attribute= s because it's slightly more compact which might help small devices. -- 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 Mon, May 31, 2010 at 9:12 AM, Andrew Arnott > wrote: Where is the definition of how a auth server response in XML format should = look? At the least we need an XML namespace and root node name. -- 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 --_000_A08279DC79B11C48AD587060CD93977125F7F153TK5EX14MBXC101r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

It would be useful to und= erstand the token type as the AS and RS server may each generate and accept= different token types

 <= /p>

From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Andrew Arnott
Sent: Friday, June 04, 2010 6:43 AM
To: George Fletcher
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Definition of XML response format=

 

Thanks, George.  From that I get this:

<response>
        <oau=
th_parameter name=3D"oauth_token">token</oauth_parameter>=
;
        <oauth_parameter name=3D=
"oauth_token_secret">secret</oauth_parameter>

</response>

From the text around = it, it sounds like SPs were permitted to add to this (presumably using thei= r own element names).  While this seems reasonable, it seems that SP-s= pecific extensions that used alternate element names would then be incompatible with JSON and url-encoded responses since= they cannot include this extra element metadata.  (well JSON could, w= ith some breaking changes to the format).

So with that, it seems like we should eliminate the redundant oauth_paramet= er element name in favor of just using the name of the parameter as the ele= ment name.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the d= eath your right to say it." - S. G. Tallentyre

On Fri, Jun 4, 2010 at 6:34 AM, George Fletcher <= gffletch@aol.com> wrote:

I don't know if this is helpful or not... but there wa= s a proposed extension for OAuth 1.0 dealing with encoding OAuth responses = in different body formats... this can be found on the now extinct oauth-extensions google group.

http://groups.google.com/g= roup/oauth-extensions/browse_thread/thread/419ec4e986ff5cd8?hl=3Den#
Thanks,
George


On 6/4/10 8:56 AM, Andrew Arnott wrote:

In the absence of anyone else volunteering an XML fo= rmat, what would you say to this as a proposal (because the implementation = of which happens to be simple for me):

<root type=3D"object">
   <access_token type=3D"string">some access toke= n</access_token>
   <refresh_token type=3D"string">some refresh to= ken</refresh_token>
   <expires_in type=3D"number">235298298</expi= res_in>
</root>

So the main points here is:

  1. no namespace
  2. root tag is called "root"
  3. each parameter is an element
  4. each element has a type parameter that is either string, number, or object = to assist the deserializer to understnad how to cast the contents.

We may axe #4.  = In fact we may want to switch all the elements to attributes because it's s= lightly more compact which might help small devices.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the d= eath your right to say it." - S. G. Tallentyre

On Mon, May 31, 2010 at 9:12 AM, Andrew Arnott <<= a href=3D"mailto:andrewarnott@gmail.com" target=3D"_blank">andrewarnott@gma= il.com> wrote:

Where is the definition of how a auth server respons= e in XML format should look?  At the least we need an XML namespace an= d root node name.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the d= eath your right to say it." - S. G. Tallentyre

 

 
_______________________________________________
OAuth mailing list
OAuth@ietf.org=

https://www.ietf.org/mailman/listinfo/oauth
 

 

--_000_A08279DC79B11C48AD587060CD93977125F7F153TK5EX14MBXC101r_-- From pharding@pingidentity.com Fri Jun 4 16:42:18 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B21A43A68E1 for ; Fri, 4 Jun 2010 16:42:18 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mqsOgbJHcvOs for ; Fri, 4 Jun 2010 16:42:17 -0700 (PDT) Received: from na3sys009aog102.obsmtp.com (na3sys009aog102.obsmtp.com [74.125.149.69]) by core3.amsl.com (Postfix) with SMTP id 821083A6A60 for ; Fri, 4 Jun 2010 16:42:17 -0700 (PDT) Received: from source ([209.85.211.201]) by na3sys009aob102.postini.com ([74.125.148.12]) with SMTP ID DSNKTAmPS9z05BqNc7XGJaSMOTtsREyXwqtF@postini.com; Fri, 04 Jun 2010 16:42:04 PDT Received: by mail-yw0-f201.google.com with SMTP id 39so1331319ywh.12 for ; Fri, 04 Jun 2010 16:42:03 -0700 (PDT) Received: by 10.150.142.11 with SMTP id p11mr11183045ybd.209.1275694923117; Fri, 04 Jun 2010 16:42:03 -0700 (PDT) Received: from [10.77.21.157] ([166.205.7.48]) by mx.google.com with ESMTPS id q8sm21123098ybk.19.2010.06.04.16.41.59 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 04 Jun 2010 16:42:02 -0700 (PDT) From: Patrick Harding To: Brian Campbell In-Reply-To: X-Mailer: iPhone Mail (7E18) References: <4C07C84C.9070705@stpeter.im> Message-Id: <700AC043-9E28-491D-B3CD-789245E30EA9@pingidentity.com> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (iPhone Mail 7E18) Date: Fri, 4 Jun 2010 19:41:32 -0400 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Assertion flow and token bootstrapping X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 23:42:19 -0000 +1 Sent from my iPhone On Jun 4, 2010, at 5:38 PM, Brian Campbell wrote: > On Thu, Jun 3, 2010 at 9:20 AM, Peter Saint-Andre > wrote: >> >> At least for the assertion flow, that's definitely true. At the >> interim >> meeting we had some discussion about perhaps pulling the assertion >> flow >> out of the base spec and into a separate document. Perhaps that's the >> best way to proceed. > > > I'd like to see the assertion flow remain in the base spec. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From lshepard@facebook.com Fri Jun 4 18:43:36 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A5AD3A69AE for ; Fri, 4 Jun 2010 18:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.407 X-Spam-Level: X-Spam-Status: No, score=-1.407 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jECpmyu8Gh-W for ; Fri, 4 Jun 2010 18:43:35 -0700 (PDT) Received: from mailout-snc1.facebook.com (mailout-snc1.facebook.com [69.63.179.25]) by core3.amsl.com (Postfix) with ESMTP id 583F73A68D5 for ; Fri, 4 Jun 2010 18:43:35 -0700 (PDT) Received: from mail.thefacebook.com ([192.168.18.212]) by pp01.snc1.tfbnw.net (8.14.3/8.14.3) with ESMTP id o551gpeP010690 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 4 Jun 2010 18:42:55 -0700 Received: from sc-hub05.TheFacebook.com (192.168.18.82) by sc-hub04.TheFacebook.com (192.168.18.212) with Microsoft SMTP Server (TLS) id 14.0.694.1; Fri, 4 Jun 2010 18:39:56 -0700 Received: from SC-MBXC1.TheFacebook.com ([192.168.18.102]) by sc-hub05.TheFacebook.com ([192.168.18.82]) with mapi; Fri, 4 Jun 2010 18:39:39 -0700 From: Luke Shepard To: Dick Hardt Date: Fri, 4 Jun 2010 18:39:35 -0700 Thread-Topic: [OAUTH-WG] Partially standardized format for access tokens? Thread-Index: AcsET/W+J2d2J2+HRIirVLuHtzYbVg== Message-ID: References: <4C090B6C.9030707@aol.com> <4C0930B2.80802@aol.com> <39D25154-9A0E-4357-B5D0-439AFBFC3DE7@jkemp.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 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-06-04_02:2010-02-06, 2010-06-04, 2010-06-04 signatures=0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Partially standardized format for access tokens? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jun 2010 01:43:36 -0000 I don't see how the extra parameter is required to support multiple auth se= rvers for a resource. Responses to Dick and Torsten: On Jun 4, 2010, at 11:33 AM, Dick Hardt wrote: > if we have the parameter in the spec, then clients know to pass it along = if they see it.=20 My main objection here is that the extra param requires more code on the cl= ient. Even if it's an optional param, the client needs to worry about multi= ple parameters, and that's annoying. For example, here's the PHP code needed to make a resource request today (a= t the end of the web server flow): $access_token =3D oauth_get_access_token($_GET['code']); $resource =3D file_get_contents('https://example.com/resource?oauth_token= =3D' . $access_token); With this proposal, the client now needs to keep track of two parameters an= d pass them both: list($access_token, $format) =3D oauth_get_access_token($_GET['code']); $resource =3D file_get_contents('https://example.com/resource?oauth_token= =3D' . $access_token . '&format=3D' . $format); =20 Why? On Jun 4, 2010, at 2:31 PM, Torsten Lodderstedt wrote: > there is another point: such a parameter could be used to let the authori= zation server indicate the format of the access token to the resource serve= r. This will help deployments with more than one token format in use. For e= xample, we use SAML and another proprietary format. Without such a paramete= r, the resource server has to somehow (magically) find out the format of th= e incomming token. It's not "magically" - the server just decodes the token and extracts any u= seful information it's expecting. If it doesn't match the format it expects= , then it throws it away. Tokens will undoubtedly encode all sorts of usefu= l stuff that resource servers know how to decode - like format, expiration,= scope, whatever. The point is that the structure is undefined *to the clie= nt*. For example, if the format is just encoded in the token, like this: format=3Dubertoken&token=3Dabcdefg The protected resource request is then: https://example.com/resource?oauth_token=3Dformat%3Dubertoken%26token%3D= abcdefg and there's no extra code required on the client. Why is this not sufficien= t?= From lshepard@facebook.com Fri Jun 4 18:46:26 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEF813A67ED for ; Fri, 4 Jun 2010 18:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-SRubjQLmGY for ; Fri, 4 Jun 2010 18:46:26 -0700 (PDT) Received: from mailout-snc1.facebook.com (mailout-snc1.facebook.com [69.63.179.25]) by core3.amsl.com (Postfix) with ESMTP id 209F73A6803 for ; Fri, 4 Jun 2010 18:46:26 -0700 (PDT) Received: from mail.thefacebook.com ([192.168.18.212]) by pp01.snc1.tfbnw.net (8.14.3/8.14.3) with ESMTP id o551jkU0013239 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 4 Jun 2010 18:45:51 -0700 Received: from sc-hub02.TheFacebook.com (192.168.18.105) by sc-hub04.TheFacebook.com (192.168.18.212) with Microsoft SMTP Server (TLS) id 14.0.694.1; Fri, 4 Jun 2010 18:44:16 -0700 Received: from SC-MBXC1.TheFacebook.com ([192.168.18.102]) by sc-hub02.TheFacebook.com ([192.168.18.105]) with mapi; Fri, 4 Jun 2010 18:40:26 -0700 From: Luke Shepard To: Patrick Harding Date: Fri, 4 Jun 2010 18:40:24 -0700 Thread-Topic: [OAUTH-WG] Assertion flow and token bootstrapping Thread-Index: AcsEUBI+2NIzcwxkRH+8R7Dx5je2ZA== Message-ID: <57FA7F56-ADC2-404A-950E-5D43FBDE75D9@facebook.com> References: <4C07C84C.9070705@stpeter.im> <700AC043-9E28-491D-B3CD-789245E30EA9@pingidentity.com> In-Reply-To: <700AC043-9E28-491D-B3CD-789245E30EA9@pingidentity.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-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-06-04_02:2010-02-06, 2010-06-04, 2010-06-04 signatures=0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Assertion flow and token bootstrapping X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jun 2010 01:46:27 -0000 Why? On Jun 4, 2010, at 4:41 PM, Patrick Harding wrote: > +1 >=20 > Sent from my iPhone >=20 > On Jun 4, 2010, at 5:38 PM, Brian Campbell =20 > wrote: >=20 >> On Thu, Jun 3, 2010 at 9:20 AM, Peter Saint-Andre =20 >> wrote: >>>=20 >>> At least for the assertion flow, that's definitely true. At the =20 >>> interim >>> meeting we had some discussion about perhaps pulling the assertion =20 >>> flow >>> out of the base spec and into a separate document. Perhaps that's the >>> best way to proceed. >>=20 >>=20 >> I'd like to see the assertion flow remain in the base spec. >> _______________________________________________ >> OAuth mailing 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 dick.hardt@gmail.com Fri Jun 4 18:58:55 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E81A33A6A74 for ; Fri, 4 Jun 2010 18:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K4-TYW0BoU8f for ; Fri, 4 Jun 2010 18:58:55 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 27BD83A6888 for ; Fri, 4 Jun 2010 18:58:55 -0700 (PDT) Received: by pwi8 with SMTP id 8so928889pwi.31 for ; Fri, 04 Jun 2010 18:58:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=cQvBB1iBVrtIGsN97BSMbG4Vs1lXNxJqCE/wGeetDUg=; b=qKkh6lgiAuTaUUDuqSiGBcEkyvuBvqxP7iaMTUm0heqNcdkrCPnPUeA+HY4QXs3voR MWd4Zrx/dn2/ut7Rf/D9aWEj2kb5zywFmGNL3QB9AeJ6KsqLUtXygVBpV61yoPBP3EhH 0Z5OgvUf4TTvsK0gl1I0I2uoP7ezUd7zHzhNo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=ecFImaktlFZxe5pJbRvgBZ4CHsYJJHXufFYuXtMCeJz3GTu9042jLc+8isHE6YZSdb P92EdSx6HDVjz+xqgaaK7lgfJxZbfl+nob3bgi56PVOElUnhPdR8HYWwwr1Zpm1ZWYIi WzNW0+/szGHGCcj3BqpzGrvi1mgaTFuwXGW8o= Received: by 10.142.5.28 with SMTP id 28mr8746169wfe.205.1275703118339; Fri, 04 Jun 2010 18:58:38 -0700 (PDT) Received: from [10.0.1.15] ([24.130.32.55]) by mx.google.com with ESMTPS id c22sm13820121wam.18.2010.06.04.18.58.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 04 Jun 2010 18:58:37 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Dick Hardt In-Reply-To: Date: Fri, 4 Jun 2010 18:58:36 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7BB45F28-C209-4014-B9F5-FBACADCFF09E@gmail.com> References: <4C090B6C.9030707@aol.com> <4C0930B2.80802@aol.com> <39D25154-9A0E-4357-B5D0-439AFBFC3DE7@jkemp.net> To: Luke Shepard X-Mailer: Apple Mail (2.1078) Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Partially standardized format for access tokens? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jun 2010 01:58:56 -0000 On 2010-06-04, at 6:39 PM, Luke Shepard wrote: > I don't see how the extra parameter is required to support multiple = auth servers for a resource. it is needed if there are multiple token types >=20 > Responses to Dick and Torsten: >=20 > On Jun 4, 2010, at 11:33 AM, Dick Hardt wrote: >> if we have the parameter in the spec, then clients know to pass it = along if they see it.=20 >=20 >=20 > My main objection here is that the extra param requires more code on = the client. Even if it's an optional param, the client needs to worry = about multiple parameters, and that's annoying. >=20 > For example, here's the PHP code needed to make a resource request = today (at the end of the web server flow): >=20 > $access_token =3D oauth_get_access_token($_GET['code']); > $resource =3D = file_get_contents('https://example.com/resource?oauth_token=3D' . = $access_token); >=20 > With this proposal, the client now needs to keep track of two = parameters and pass them both: >=20 > list($access_token, $format) =3D = oauth_get_access_token($_GET['code']); > $resource =3D = file_get_contents('https://example.com/resource?oauth_token=3D' . = $access_token . '&format=3D' . $format); >=20 > Why? The client would only need to do that if the AS will issue the = parameter. I would expect that libraries would deal with the two = parameters. Moving an extra one around does not seem to be hard.=20 >=20 > On Jun 4, 2010, at 2:31 PM, Torsten Lodderstedt wrote: >> there is another point: such a parameter could be used to let the = authorization server indicate the format of the access token to the = resource server. This will help deployments with more than one token = format in use. For example, we use SAML and another proprietary format. = Without such a parameter, the resource server has to somehow (magically) = find out the format of the incomming token. >=20 > It's not "magically" - the server just decodes the token and extracts = any useful information it's expecting. If it doesn't match the format it = expects, then it throws it away. Tokens will undoubtedly encode all = sorts of useful stuff that resource servers know how to decode - like = format, expiration, scope, whatever. The point is that the structure is = undefined *to the client*. what if there are multiple token formats? that is were the magic comes = in. Detecting format can be tricky. >=20 > For example, if the format is just encoded in the token, like this: >=20 > format=3Dubertoken&token=3Dabcdefg >=20 > The protected resource request is then: >=20 > = https://example.com/resource?oauth_token=3Dformat%3Dubertoken%26token%3Dab= cdefg >=20 > and there's no extra code required on the client. Why is this not = sufficient? one token could be SAML, another JSON in one format, another in URL = encoded name/value pairs. The PR is having to detect both syntax and = semantics.= From dick.hardt@gmail.com Fri Jun 4 18:59:11 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 007723A686C for ; Fri, 4 Jun 2010 18:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9SL3vnWzwVMP for ; Fri, 4 Jun 2010 18:59:10 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 3C8B23A6A82 for ; Fri, 4 Jun 2010 18:59:10 -0700 (PDT) Received: by mail-pw0-f44.google.com with SMTP id 8so928889pwi.31 for ; Fri, 04 Jun 2010 18:58:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=mzlPpSJcxCer4w87/fndvJHN5f1/uB/PJQ5/Hqthf98=; b=IeB77pXCG8rRelOKDbC6DwJvYfP0QoXfHtJpXwUvxhoO5j1eyZ8Tdy/Z6FkWk8tMBt SaDVkNBv9L02jSDzNzglsDNuAWDyYhYDl5RtpQKswZRNMY2Y5kWCVVJn+F6hYGtXV1S/ MlTIpKgfAZgFwtYrTQ2K5fPyGFPsPR0vua76A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=QJQQplTc1o9ABymNjhZwbUJ0INMpHBoEyrVFN3ilTkvXA+bS76n1bAF09SBSzsD8zP X9CCjoRgOP5UAyRxPh624tarEpTsWgWzADPrw3aVRiyDgJwzGIoigMfIXbhpuboK4eGG wogOod9nUbxMl9Y+NHPVmuIYGp7Ge2KnQmauI= Received: by 10.142.152.18 with SMTP id z18mr8545475wfd.230.1275703136586; Fri, 04 Jun 2010 18:58:56 -0700 (PDT) Received: from [10.0.1.15] ([24.130.32.55]) by mx.google.com with ESMTPS id c22sm13820121wam.18.2010.06.04.18.58.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 04 Jun 2010 18:58:56 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Dick Hardt In-Reply-To: <57FA7F56-ADC2-404A-950E-5D43FBDE75D9@facebook.com> Date: Fri, 4 Jun 2010 18:58:55 -0700 Content-Transfer-Encoding: 7bit Message-Id: <4C2E55D5-072B-4F08-A341-7405F2F1C944@gmail.com> References: <4C07C84C.9070705@stpeter.im> <700AC043-9E28-491D-B3CD-789245E30EA9@pingidentity.com> <57FA7F56-ADC2-404A-950E-5D43FBDE75D9@facebook.com> To: Luke Shepard X-Mailer: Apple Mail (2.1078) Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Assertion flow and token bootstrapping X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jun 2010 01:59:11 -0000 because we use it On 2010-06-04, at 6:40 PM, Luke Shepard wrote: > Why? > > On Jun 4, 2010, at 4:41 PM, Patrick Harding wrote: > >> +1 >> >> Sent from my iPhone >> >> On Jun 4, 2010, at 5:38 PM, Brian Campbell >> wrote: >> >>> On Thu, Jun 3, 2010 at 9:20 AM, Peter Saint-Andre >>> wrote: >>>> >>>> At least for the assertion flow, that's definitely true. At the >>>> interim >>>> meeting we had some discussion about perhaps pulling the assertion >>>> flow >>>> out of the base spec and into a separate document. Perhaps that's the >>>> best way to proceed. >>> >>> >>> I'd like to see the assertion flow remain in the base spec. >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From andrewarnott@gmail.com Fri Jun 4 21:50:17 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 358073A68FB for ; Fri, 4 Jun 2010 21:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.431 X-Spam-Level: X-Spam-Status: No, score=-0.431 tagged_above=-999 required=5 tests=[AWL=-0.433, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mim1KImhFul5 for ; Fri, 4 Jun 2010 21:50:12 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 698F83A68FD for ; Fri, 4 Jun 2010 21:50:12 -0700 (PDT) Received: by gwb11 with SMTP id 11so1401654gwb.31 for ; Fri, 04 Jun 2010 21:49:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=QQVdAEY9093UMsVhHi1GRSUu/dpw1Esw5QIsMNAJdl4=; b=dEZNp3pq0+Cc19UCXPtuLnSheBVc0eVOoqIrRFOgfv6+Qs6m5TrZszs0s7aorcUzN7 Ejknn8dD/wVfpNbITM2Z8xbHvVMgFrjD9JvsiDfsQzp0TOSSvEPYzYsl0QO0WlF7Q3lL DiWtDbsCCiJ2DIRpMKKYJQspl/G/BsXua5wfo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=BXkrSOonIiqgz6UuxjHGGv6V8vSL9xJnV+Y4c7To+dz49oc3NvJEyRnam5576fhKnT xsImt6GOcmEyGyuuOQDEOqnehN1dqO848N6U1Hem/YkYKW0rj+u+h4ayW9AFJtqTolNb FoaGzBcwgP0QbYi/ZkMLt/Rm2j1pu8grFzyJY= MIME-Version: 1.0 Received: by 10.150.56.25 with SMTP id e25mr11017834yba.188.1275713395622; Fri, 04 Jun 2010 21:49:55 -0700 (PDT) Received: by 10.151.26.19 with HTTP; Fri, 4 Jun 2010 21:49:55 -0700 (PDT) Date: Fri, 4 Jun 2010 21:49:55 -0700 Message-ID: From: Andrew Arnott To: "OAuth WG (oauth@ietf.org)" Content-Type: multipart/alternative; boundary=000e0cd61158c803cf0488412b7e Subject: [OAUTH-WG] User-agent flow and pre-registered redirect_uri X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jun 2010 04:50:17 -0000 --000e0cd61158c803cf0488412b7e Content-Type: text/plain; charset=ISO-8859-1 The user agent flow indicates that the redirect_uri SHOULD be preregistered with the auth server for a given client. I would like to suggest that the SHOULD here be changed to *MUST*. Unless I'm missing something, without a preregistered redirect_uri any arbitrary client can obtain an access token under the pretense of being another client, and thereby perhaps altogether skip a user authorization prompt. As there will likely be a few popular client_id's in use, it will actually make it trivially easy to obtain elevated access to private user data as a rogue application. This danger is unique to the user-agent flow because in this flow the client_secret is not required to obtain the access token, whereas it is for other flows. 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 --000e0cd61158c803cf0488412b7e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The user agent flow indicates that the redirect_uri SHOULD be preregistered= with the auth server for a given client.=A0 I would like to suggest that t= he SHOULD here be changed to MUST.=A0 Unless I'm missing somethi= ng, without a preregistered redirect_uri any arbitrary client can obtain an= access token under the pretense of being another client, and thereby perha= ps altogether skip a user authorization prompt.=A0

As there will likely be a few popular client_id's in use, it will a= ctually make it trivially easy to obtain elevated access to private user da= ta as a rogue application.=A0 This danger is unique to the user-agent flow = because in this flow the client_secret is not required to obtain the access= token, whereas it is for other flows.=A0

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.&quo= t; - S. G. Tallentyre
--000e0cd61158c803cf0488412b7e-- From sakimura@gmail.com Mon Jun 7 08:08:06 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 901D13A6405 for ; Mon, 7 Jun 2010 08:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JKg-korBQUJ3 for ; Mon, 7 Jun 2010 08:08:04 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 25EF328CBB9 for ; Mon, 7 Jun 2010 05:55:19 -0700 (PDT) Received: by iwn42 with SMTP id 42so3344748iwn.31 for ; Mon, 07 Jun 2010 05:55:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=jp70dZC6UuVwV1H+IUrfTGl3jWXqY/fgFIyNrKVbWLg=; b=htN95zCGBk1CXtr5M6KIhTMNHRXbcRpRfabcyx7zM0ihaMCTQ8mBDxsT3duDRWiO10 blUQmQovZvcfqWFM+yLEnLfUkYzexF8FTQo4KlqBZUwhr9nibRfCWLZfBnTZgxSZVz2w BnAl/XkfSqnh1xnI5zUw1pV79NuZE2cQD3c6g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Nrl9RtmTQDQM7haqnx/reXty8/Nd+AALHu2o+SpCid/GWhp2qn/djqdjgho//QD8iR moeK3WJotPJ6bVCHFZo1NRqlSlKKlT9WlA+9jk4dYOJ7S2+CVJP5t9OE/7kKMSOX1AGz ng6k8pqghU7FVuY98jhu0qVLlLIjqPgT5fMc0= MIME-Version: 1.0 Received: by 10.231.176.213 with SMTP id bf21mr2170624ibb.67.1275915316466; Mon, 07 Jun 2010 05:55:16 -0700 (PDT) Received: by 10.231.15.133 with HTTP; Mon, 7 Jun 2010 05:55:16 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11263E5D01B@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E11263AC0282@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E11263B6402C@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E11263BF2F2E@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E11263E5D01B@WSMSG3153V.srv.dir.telstra.com> Date: Mon, 7 Jun 2010 21:55:16 +0900 Message-ID: From: Nat Sakimura To: "Manger, James H" Content-Type: multipart/alternative; boundary=0016e68dd8e83394b40488702f77 Cc: oauth Subject: Re: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 15:08:06 -0000 --0016e68dd8e83394b40488702f77 Content-Type: text/plain; charset=ISO-8859-1 Ah, I am starting to getting your point. I was assuming that the text was just dealing with this particular flow, possibly a separate standalone document as David R. suggested. On the other hand, you are starting to think of it as a generic "include" mechanism, are you? I agree that would be actually quite useful. If the idea gets support in the community I am all for it. =nat On Fri, Jun 4, 2010 at 4:21 PM, Manger, James H < James.H.Manger@team.telstra.com> wrote: > Nat, > > >>> All the request parameters MUST be provided through request file. > >>"All" doesn't make much sense if params can still appear in the URI, and > override the file. > > > What about this: > > > > Request parameters SHOULD be provided through request file. > > If it is perfectly legitimate to include some params in the user-url, and > those override the same params in the file, then there is no point requiring > the overridden params to be present in the file with a MUST or even a > SHOULD. What about saying: > "A shorter user-uri is more likely to avoid mobile browser URI length > limits, and to reduce bandwidth and latency for mobile traffic. > Consequently, as many parameters as practical should be provided through the > request file, instead of directly in the user-uri." > > > > >>> The "request_url" MUST be provided in the URL. > >> This isn't really a "MUST", its just indicates if you are using this > feature (this "flow"). > > > It is a MUST. Without it, you just cannot obtain other required > parameters. > > Without it you are using "normal" OAuth2 (all the params in the user-uri), > which is fine and shouldn't violate a MUST. > If this mechanism is defined in a separate spec then I guess it could be a > MUST for that spec. Even in that case, though, servers that support > request_url shouldn't reject interactions with all the params directly in > the user-uri. > > > > >> Would be good to say "A request_url param MUST NOT be provided in a > request file". Probably good to add "A request file MUST be rejected if it > includes a request_url param". > > > request_url param MAY be provided in a request file. It is just its > identifier. It probably is best to be there. > > It sounds like you are assuming the request_url in the file is the same as > the request_url in user-uri that led to the file. The server treats > request_url in user-uri as a trigger to include more params, but the server > treats request_url in the file as merely a name for the file (which it > ignores because there is nothing for the server to do with such a name). > > This is inconsistent. > > request_url should be an include mechanism, regardless of where it appears. > If we only want to support an include mechanism in user-uri, and not > supported nested includes, then we should explicitly say request_url MUST > NOT appear in a file. > > -- > James Manger > -- Nat Sakimura (=nat) http://www.sakimura.org/en/ http://twitter.com/_nat_en --0016e68dd8e83394b40488702f77 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ah, I am starting to getting your point.=A0

I was assumi= ng that the text was just dealing with this particular flow, possibly a sep= arate standalone document as David R. suggested.=A0
On the other = hand, you are starting to think of it as a generic "include" mech= anism, are you?=A0

I agree that would be actually quite useful.=A0

If the idea gets support in the community I am all for it= .=A0

=3Dnat

On Fri, Jun 4, 2010 at 4:21 PM, Manger, James H <James.H.Manger@team.telstr= a.com> wrote:
Nat,

>>> All the request parameters MUST be provided through request fi= le.
>>"All" doesn't make much sense if params can still app= ear in the URI, and override the file.

> What about this:=A0
>
> Request parameters SHOULD be provided through request file.=A0

If it is perfectly legitimate to include some params in the user-url,= and those override the same params in the file, then there is no point req= uiring the overridden params to be present in the file with a MUST or even = a SHOULD. What about saying:
"A shorter user-uri is more likely to avoid mobile browser URI length = limits, and to reduce bandwidth and latency for mobile traffic. Consequentl= y, as many parameters as practical should be provided through the request f= ile, instead of directly in the user-uri."



>>> The "request_url" MUST be provided in the URL.
>> This isn't really a "MUST", its just indicates if yo= u are using this feature (this "flow").

> It is a MUST. Without it, you just cannot obtain other required parame= ters.=A0

Without it you are using "normal" OAuth2 (all the params in= the user-uri), which is fine and shouldn't violate a MUST.
If this mechanism is defined in a separate spec then I guess it could be a = MUST for that spec. Even in that case, though, servers that support request= _url shouldn't reject interactions with all the params directly in the = user-uri.

=A0

>> Would be good to say "A request_url param MUST NOT be provide= d in a request file". Probably good to add "A request file MUST b= e rejected if it includes a request_url param".

> request_url param MAY be provided in a request file. It is just its id= entifier. It probably is best to be there.=A0

It sounds like you are assuming the request_url in the file is the sa= me as the request_url in user-uri that led to the file. The server treats r= equest_url in user-uri as a trigger to include more params, but the server = treats request_url in the file as merely a name for the file (which it igno= res because there is nothing for the server to do with such a name).

This is inconsistent.

request_url should be an include mechanism, regardless of where it appears.= If we only want to support an include mechanism in user-uri, and not suppo= rted nested includes, then we should explicitly say request_url MUST NOT ap= pear in a file.

--
James Manger



--
Nat Sakimura (= =3Dnat)
http://www.sakimura.org/= en/
http://twitter.com/_nat_e= n
--0016e68dd8e83394b40488702f77-- From hardjono@mit.edu Mon Jun 7 08:09:08 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8DDA3A679F for ; Mon, 7 Jun 2010 08:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M78ezZBzMfGo for ; Mon, 7 Jun 2010 08:09:08 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (DMZ-MAILSEC-SCANNER-8.MIT.EDU [18.7.68.37]) by core3.amsl.com (Postfix) with ESMTP id 9FE7C3A92BC for ; Sun, 6 Jun 2010 15:23:03 -0700 (PDT) X-AuditID: 12074425-b7d00ae000002295-db-4c0c1fc873af Received: from mailhub-auth-2.mit.edu (MAILHUB-AUTH-2.MIT.EDU [18.7.62.36]) by dmz-mailsec-scanner-8.mit.edu (Symantec Brightmail Gateway) with SMTP id 9A.79.08853.8CF1C0C4; Sun, 6 Jun 2010 18:23:04 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-EXCHANGE-2.MIT.EDU [18.9.28.16]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id o56MN3E4030155; Sun, 6 Jun 2010 18:23:03 -0400 Received: from oc11exedge1.exchange.mit.edu (OC11EXEDGE1.EXCHANGE.MIT.EDU [18.9.3.17]) ) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id o56MN3lN013312; Sun, 6 Jun 2010 18:23:03 -0400 Received: from oc11exhub5.exchange.mit.edu (18.9.3.15) by oc11exedge1.exchange.mit.edu (18.9.3.17) with Microsoft SMTP Server (TLS) id 8.1.393.1; Sun, 6 Jun 2010 18:22:42 -0400 Received: from EXPO10.exchange.mit.edu ([18.9.4.15]) by oc11exhub5.exchange.mit.edu ([18.9.3.15]) with mapi; Sun, 6 Jun 2010 18:23:03 -0400 From: Thomas Hardjono To: Dick Hardt , "oauth@ietf.org" Date: Sun, 6 Jun 2010 18:22:55 -0400 Thread-Topic: [OAUTH-WG] Assertion flow and token bootstrapping Thread-Index: AcsEUqrR4GjyUdZhRUGqsOqov9UnlgBc65TQ Message-ID: References: <4C07C84C.9070705@stpeter.im> <700AC043-9E28-491D-B3CD-789245E30EA9@pingidentity.com> <57FA7F56-ADC2-404A-950E-5D43FBDE75D9@facebook.com> <4C2E55D5-072B-4F08-A341-7405F2F1C944@gmail.com> In-Reply-To: <4C2E55D5-072B-4F08-A341-7405F2F1C944@gmail.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-Brightmail-Tracker: AAAAAA== Subject: Re: [OAUTH-WG] Assertion flow and token bootstrapping X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 15:09:09 -0000 Apologies for another newbie question: is the design-intention underlying t= he Assertion Flow in OAuth2.0-draft-05 the same as that in the WRAP draft (= draft-hardt-oauth-01)? /thomas/ __________________________________________ > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of > Dick Hardt > Sent: Friday, June 04, 2010 9:59 PM > To: Luke Shepard > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Assertion flow and token bootstrapping >=20 > because we use it >=20 > On 2010-06-04, at 6:40 PM, Luke Shepard wrote: >=20 > > Why? > > > > On Jun 4, 2010, at 4:41 PM, Patrick Harding wrote: > > > >> +1 > >> > >> Sent from my iPhone > >> > >> On Jun 4, 2010, at 5:38 PM, Brian Campbell > >> wrote: > >> > >>> On Thu, Jun 3, 2010 at 9:20 AM, Peter Saint-Andre > >>> wrote: > >>>> > >>>> At least for the assertion flow, that's definitely true. At the > >>>> interim > >>>> meeting we had some discussion about perhaps pulling the assertion > >>>> flow > >>>> out of the base spec and into a separate document. Perhaps that's th= e > >>>> best way to proceed. > >>> > >>> > >>> I'd like to see the assertion flow remain in the base spec. > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From James.H.Manger@team.telstra.com Mon Jun 7 08:16:28 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85C523A67CC for ; Mon, 7 Jun 2010 08:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.698 X-Spam-Level: * X-Spam-Status: No, score=1.698 tagged_above=-999 required=5 tests=[HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qEYjd2SFlEgJ for ; Mon, 7 Jun 2010 08:16:27 -0700 (PDT) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by core3.amsl.com (Postfix) with ESMTP id 9D4E13A8068 for ; Mon, 7 Jun 2010 06:52:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,378,1272808800"; d="scan'208";a="3894723" Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipocni.tcif.telstra.com.au with ESMTP; 07 Jun 2010 23:51:56 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6005"; a="3278434" Received: from wsmsg3752.srv.dir.telstra.com ([172.49.40.173]) by ipcani.tcif.telstra.com.au with ESMTP; 07 Jun 2010 23:51:57 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3752.srv.dir.telstra.com ([172.49.40.173]) with mapi; Mon, 7 Jun 2010 23:51:56 +1000 From: "Manger, James H" To: Nat Sakimura Content-Class: Date: Mon, 7 Jun 2010 23:51:54 +1000 Thread-Topic: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow Thread-Index: AcsGSJeExEBZv3rGRryCMs/luu9ZEw== Message-ID: <255B9BB34FB7D647A506DC292726F6E11262FEE7D8@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US, en-AU Content-Language: en-AU X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: oauth Subject: Re: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 15:16:28 -0000 Nat, > On the other hand, you are starting to think of it as a generic "include"= mechanism, are you? Yes. That feels like the simplest mental model for this functionality, and = the simplest way to specify it. -- James Manger From dick.hardt@gmail.com Mon Jun 7 08:29:07 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CEF33A67FC for ; Mon, 7 Jun 2010 08:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VkEewaf4SGYy for ; Mon, 7 Jun 2010 08:29:06 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 1AB863A9F6E for ; Sun, 6 Jun 2010 17:10:31 -0700 (PDT) Received: by pvf33 with SMTP id 33so1446436pvf.31 for ; Sun, 06 Jun 2010 17:10:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=tWJebcCum236EiX/50gZgBSGR0sQbVc1dNTw1L67Log=; b=pJCGeSoHUlr1yvX9l3aniqZlOVg0LGvCEmpfkb8lQFSWxPSgFC8UxvtWNT3SR+P+Be oOT0youBykZuzJMW47wJ4WAa2Pf1fLZNlGYnWqL2N3K6b2LGgOp8tFXgi1cToxt7FdaN WKXeuD+Mx8gfC04eZYqYokOzkZS4sqYv0ydF8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=aHekY/op89yUC95YEfEIU71RlLaxCv/YeKx+auPcB5H/CIqnBbeRtyrxb5TIWwGZsy 9115fjQR1lf6+V/LYRRASb+G3UAcIL/8Bfs5KyAvhADhdna9Mkv/nvCNlEMAWB3W0Tzc y5YMENh6CUD04KBu7n3uFW8ELhzxOaLZ2xEwI= Received: by 10.141.187.3 with SMTP id o3mr11226847rvp.224.1275869428769; Sun, 06 Jun 2010 17:10:28 -0700 (PDT) Received: from [10.0.1.18] ([24.130.32.55]) by mx.google.com with ESMTPS id d14sm4128332rva.18.2010.06.06.17.10.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 06 Jun 2010 17:10:28 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Dick Hardt In-Reply-To: Date: Sun, 6 Jun 2010 17:10:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <77E0A4F9-9211-4E2A-B6A1-4E812192BA82@gmail.com> References: <4C07C84C.9070705@stpeter.im> <700AC043-9E28-491D-B3CD-789245E30EA9@pingidentity.com> <57FA7F56-ADC2-404A-950E-5D43FBDE75D9@facebook.com> <4C2E55D5-072B-4F08-A341-7405F2F1C944@gmail.com> To: Thomas Hardjono X-Mailer: Apple Mail (2.1078) Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Assertion flow and token bootstrapping X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 15:29:07 -0000 I hope so. On 2010-06-06, at 3:22 PM, Thomas Hardjono wrote: > Apologies for another newbie question: is the design-intention = underlying the Assertion Flow in OAuth2.0-draft-05 the same as that in = the WRAP draft (draft-hardt-oauth-01)? >=20 > /thomas/ >=20 > __________________________________________ >=20 >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf Of >> Dick Hardt >> Sent: Friday, June 04, 2010 9:59 PM >> To: Luke Shepard >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] Assertion flow and token bootstrapping >>=20 >> because we use it >>=20 >> On 2010-06-04, at 6:40 PM, Luke Shepard wrote: >>=20 >>> Why? >>>=20 >>> On Jun 4, 2010, at 4:41 PM, Patrick Harding wrote: >>>=20 >>>> +1 >>>>=20 >>>> Sent from my iPhone >>>>=20 >>>> On Jun 4, 2010, at 5:38 PM, Brian Campbell >>>> wrote: >>>>=20 >>>>> On Thu, Jun 3, 2010 at 9:20 AM, Peter Saint-Andre >>>>> wrote: >>>>>>=20 >>>>>> At least for the assertion flow, that's definitely true. At the >>>>>> interim >>>>>> meeting we had some discussion about perhaps pulling the = assertion >>>>>> flow >>>>>> out of the base spec and into a separate document. Perhaps that's = the >>>>>> best way to proceed. >>>>>=20 >>>>>=20 >>>>> I'd like to see the assertion flow remain in the base spec. >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth From hannes.tschofenig@nsn.com Mon Jun 7 08:58:08 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72F5B3A6A45 for ; Mon, 7 Jun 2010 08:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bVged0lhTkR7 for ; Mon, 7 Jun 2010 08:57:47 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 4A80F3A7D4D for ; Mon, 7 Jun 2010 05:40:52 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o57CemGV003302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 7 Jun 2010 14:40:48 +0200 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o57CegPa013546 for ; Mon, 7 Jun 2010 14:40:48 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 7 Jun 2010 14:39:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB063E.7D2BDA59" Date: Mon, 7 Jun 2010 15:39:51 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4502ABEC3F@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Meeting Notes from the Interim Meeting Thread-Index: AcsGPoYrb3rFdkY7TUqKrTL8F30sWg== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "OAuth WG" X-OriginalArrivalTime: 07 Jun 2010 12:39:37.0147 (UTC) FILETIME=[7D6178B0:01CB063E] Subject: [OAUTH-WG] Meeting Notes from the Interim Meeting X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 15:58:08 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB063E.7D2BDA59 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable OAuth 2.0 Draft 5 Issues List Intro: - Purposes/use cases should appear in intro - Describe role wrt OpenID and auth schemes ?? - Requirements should be removd out of intro Intro should describe goals and possibilities of OAuth - Requirements is a limited set, but it should be clarified that they're = not the *only* reqs Terminology: - We don't say what client secret is - Describe relationships between terms - Cryptographic terms ?? - Verification code - Cliented defined as HTTP, not the case s/Cliented/Client/ - Should use the term "capability" when talking about bearer tokens. Overview: - Should relate to Intro (confusing) - Standardization of tokens should be called out as defined elsewhere - Call out the face that separation of resource and authz serviers is = not in scope - Intro talks about three flows. We have 6, maybe 7 or 8 (Terminology: Call that bearer tokens are access tokens and cover = cryptographic variant) Examples: - Scope? - Best one? Conformance: - Useful? 3.2 End-user endpoint - Can we call it "approval url" instead? - Brian Eaton - No mandatory to implement language. That's an interop problem. - = Peter St. Andre - No guidelines or examples of how to verify user identity. - ???? - When using TLS/SSL: make sure it's server authentication, not client = certificates. - Eve Maler - User-uri attribute is very experimental, no clients using anything = like this today. We should have a couple of working clients. - Explain that end-user endpoint only relevant to some flows. - Should standardize existing service provider specific parameters for = UI, e.g. language, display type, user hint. (Brian Eaton) 3.3 Token endpoint - First sentence not true for all flows. But don't change it at the = expense of readability. - David Recordon - "Token issuing endpoint" might need a new name. - MUST use SSL? - Mandate POST? - Marius Scurtescu - Security requirements depend on type of authentication used. - Should authorization server return token type? Should client use = token type? - Dick Hardt 3.3.1 Client Authentication - need new text for certificate authentication - Peter St. Andre - need more flexible language - Justin Smith 3.3.2 Response Format - Do we need so many formats? - Are all formats needed on both sides? - Jim Fenton - Please pick just one. - Justin Smith - What if XML becomes uncool? - Leah Culver - Data model problem, not all formats support all data types we might = need. - Justin Smith - Is no-store enough of a cache-control header? - Chuck Mortimore 3.3.2.1 Access Token Response - Define scope once, include by reference. - Peter St. Andre and Eve = Maler - Need "scope" example - Hannes - Scope is underspecified. - Hannes - Authorization server MUST honor client request for token secret? - = Justin Smith - Semantics of "expires_in" are underspecified. - Hannes - expires_in: duration or absolute time? - Jim Fenton had an opinion 3.3.2.2 Error response - Data format needs to be in sync across entire spec. Either allow XML = here, or drop it everywhere. - Justin Smith and others - Add debugging message field to JSON. - Marius Scurtescu - Predefined list of error responses? 3.4 Flow Parameters - More on error handling? - Peter St. Andre 3.5 User-Agent Flow - If refresh token leaks, you can't recover. Changing client secret is = not enough. - Brian Eaton - Desktop and mobile applications work. - David Recordon - Can we change order of user-agent and web app flow in spec? - Leah = Culver - WRAP web server flow was more secure for rich-client apps, because web = sites cannot pretend to be rich clients. User-Agent flow does not allow = this. - Sarah Faulkner - Where do we handle custom protocol schemes in redirect URIs? - Blaine = Cook and Marius Scurtescu - Mention that security is based on user-agent same-origin policy - = Zachary Zeltsan - Maybe move installed applications to a separate section - Marius = Scurtescu - Need to give installed app developers a way to specify device name. - Brian Eaton - Can mobile developers use HTTP URL discovery from slide deck instead? = - Bill Keenan - Explain how to authenticate client? 3.5.1 Client Requests Authorization - What if malicious actor (either user or "man in the browser") tampers = with "scope" or "state" parameter? - Eve Maler - Should we add an extension so that users can self-identify their = device? - Bill Smith - Client state is yucky - Luke Shephard - Authorization servers MAY restrict the redirection URI to not include = a query component. This will break PHP clients. - Marius Scurtescu 3.5.1.1 End-user grants authorization - seems odd that client is requesting the token secret - Bill Smith - what happens if server doesn't want to issue token secret? - Bill = Smith and Marius Scurtescu - should we make example https? - Chuck Mortimore 3.5.1.2 End-user denies authorization - More error codes needed. - Sarah Faulkner and Marius Scurtescu - Immedate mode failure needs an error code. - Marius Scurtescu 3.5.2 Client extracts access token - Can we tell user-agents not to send fragment in HTTP request? IE does = this in certain circumstances. - Brian Eaton 3.6 Web Server Flow 3.6.1 Client Requests Authorization - redirect_uri validation strategy should be described once in the spec, = and then included by reference. - Brian Eaton - Some of required parameters don't make sense if authentication of user = is out of band. - Eve Maler 3.6.1.1 - End-user grants authorization - What does the verification code provide? - Hannes - How do people keep verification code from leaking in referer header? - Sarah Faulkner - Should we define time-limit for verification code? 5 minutes? - Peter = St. Andre - Specify that verification code should be used only once. - Brian Eaton 3.6.1.2 - End-user denies authorization? 3.6.2 - Client requests access token - should mention https. - David Recordon 3.7 - Device flow - mandating polling is terrible - Leah Culver - is polling OK if we mandate back-off behavior? - David Recordon - are there other options besides polling? post backs? - Leah Culver - do we even need this? Is there enough of a use case? - Leah Culver - is long polling/hanging GET an option? - Brian Eaton - what about telling user to click a button once they've approved? - can we get comments from NetFlix or someone who has already done this? = - David Recordon - what about devices with secure storage? - Bill Keenan - should call out that device manufacture must register with service = provider - Brian Eaton - huh? Why is that a requirement in this profile? 3.7.1 - Client requests approval - can we rename "verification uri" to be something else, since it is = different than code in web server flow? - Marius Scurtescu 3.7.2 - Client requests access token - Is "code" REQUIRED or OPTIONAL - Hank - Can we rename "code" to something else, since it is different? - = Marius Scurtescu 3.8 - Username and password flow - Can we just call this the secure flow? - Blaine - We can't tell whether the client has really thrown away password. - = Hank - Add to point (B) that client should discard password. - Hank - should we move client credentials to basic auth header? - Blaine - unauthorized_client: has extra apostrophe - Brian - need to return error URL from this flow , so that users can get their = account unblocked if they are on the same IP range as a botnet. - Brian - need to fix examples to use "https" instead of "http 3.9 - Client Credentials Flow - end user is not related to client secret, should eliminate all mention = of end user. - Justin Smith - should call out absence of end-user in front paragraph. - Leah Culver - add motivating examples. - Peter St. Andre - is this the same as username password flow? - Dirk Balfanz 3.9.1 - Client requests access token - all content-type headers should include charset. - Brian Eaton - what if developers want to use client secret directly? - David = Recordon - then they should use basic auth - Justin Smith 3.10 - Assertion Flow - comment on 2.2: section 2.2 still calls this an autonomous flow. - = Chuck Mortimore - if we get client secret right in other flows (e.g. client secret is = replaced with assertion), then this flow is no longer necessary. - = Justin Smith - James Manger has been saying the same thing for a while, instead use = assertion based HTTP method. - Eran - we need client id, client secret, and assertion. This will get = confusing. Let's keep the separate flow. - Chuck - we need an example. - Leah Culver - two format parameters. First should be assertion format. - Marius = Scurtescu - content-type should include charset - Bill Mills - are we always using json here, or do we support format choice? - Bill = Mills 4 - Refresh Token - should we alway tell clients to use a secret, e.g. "anonymous" or = "opensecret"? Absent secret might be confusing? - Brian Eaton - can we differentiate between token refresh and changing secret type? - Dick Hardt - should we allow down-scoping on this endpoint? - Marius Scurtescu - scope needs to be figured out through entire flow - Eve Maler - can we sign with client secret from request, to prevent accidental = logging? - Bill Mills - auth servers can be assumed to be smarter than that. - Allen Tom - passing client secret across affects lots of flows - Leah Culver - can we always sign with client secret? - Leah Culver - we should use POST instead of GET to mitigate risk - Marius Scurtescu 5 - Accessing a protected resource - Did anyone read this? - Eran - No clear error path - Bill Smith - Can we really call it "Token"? - Leah Culver - Can we say "bearer tokens" MUST NOT be sent over secure channels? - = Jim Fenton - Can we write a spec that reflects security reality - people do send = bearer tokens over HTTP connections - Brian Eaton - No, we can't. Security reviewers will block that. - Eran - People violate specs all the time, we can call them noncompliant and = stupid. - Peter St. Andre - "Token" scheme name is weird.- Dick - Can we have the discussion to close it out? - Eran - Why isn't it "OAuth"? - Dick - What about "OAuth2"? - Dick - Can we drop name=3D"value" syntax and replace with JSON or something = else? - Brian Eaton - Is changing the header format worth our time? - Eran - Could treat security considerations better in separate section - = Hannes - Agreed, security here is weak - Peter St. Andre - Can we call scheme "LessBasic" - Blaine - Can we say MUST NOT send bearer tokens to unfamiliar sites? - Brian = Eaton - Is "unfamiliar" well-defined? - Jim Fenton - Can we have a same-origin policy? - Blaine Cook 5.2 - Bearer Token Requests - Rationalize language here - Does the token need to explicitly include a bit that says it's a = bearer token vs a crypto token. This is a problem if resource servers = support both - Bill Smith - Text/terms should be a bit clearer on differentation. - Bill Smith - We should drop realm, it has no meaningful semantics here. - Brian = Eaton - We have to update RFC 2617 to do that. - Eran - Let's do it. - Brian Eaton 5.2.1. Query String - what about protected resources that accept both OAuth1 and OAuth2? We have a parameter name conflict here. 5.2.2 Post body - this introduces yet another way to return error responses (401 = response vs response body). Can we make this consistent? - Bill Smith - this applies throughout the spec. - Eran - what happens if both query and post body have oauth_token? - - can we eliminate oauth_token in post body? - Eran - no, some tokens don't fit in query, and you don't have access to = headers. - Dick - Can we either always use "token" or always use "oauth_token"? - Bill = Smith - We don't need to be consistent. - Eran 5.3 Cryptographic Signatures - we're probably going to change this dramatically. - Hannes - 6 - Identifying a protected resource - should we add error handling here? You'll never return this unless the = request was made in error regardless. - Leah Culver - should name be "identifying authentication requirements for a = resource"? - Eve Maler - there should be examples and pictures. - Eve Maler, Eran 6.1 - WWW-Authenticate Response header - what about resources that return public data if request is = unauthenticated? Facebook does this. - David Recordon - POST vs GET might have different security policy for example. - David = Recordon 6.1.1. - describing the WWW-Authenticate response header - we need a way to puke back an approval URL. - Bill Smith - we need to enumerate the types of flows that are supported so that = clients can pick the flow to use. - Bill Smith - can we scrap this entire section and let Bill figure this out for = IMAP? And then write down what he did instead. Or move this section to = an extension? - Brian Eaton - ABNF problem? Is pound notation space delimited? - Jim Fenton - Maybe think about how oauth discovery should work? - Dirk Balfanz - is scope a URI or a string? ABNF says URI ,should be string. - Chuck 7 - Security Considerations - can we reuse the WRAP security considerations? - Brian Eaton - no. Needs to be more authoritative. Rewrite it to change the voice. - = Eran - can we reuse the NIST approach in special publication 800-6 of = defining specific levels of security along with necessary requirements = to meet that level? - Hannes Appendix A - Differences from OAuth 1.0a - can someone volunteer for this? - Eran Authors and Acknowledgements - do we need three separate classes of contributors? - Eran - typically have authors and editors, contributors, and = acknowledgements. - Hannes Discussion Notes What response formats should we use? (Eran Leads) 1) Clients always send form-encoded query or post body 2) Servers can - return form-encoded in query uri or fragment - form-encoded body 3) Discussion on list about servers returning JSON instead - what if JSON is too heavy? - what if APIs use XML? Nobody has suggested using XML only. People have said: should only support one format, but they don't care = much which one. People have said: should only support JSON People have said: servers = implement all three, clients indicate their preference. Con: too much complexity, too little value Con: this has data model implications for the future, e.g. how will = we serialize arrays in XML? Easy way out: can we all agree on either JSON or form-encoded for = responses? - no one thinks form-encoded only - some support for json only - some support for supporting both json and form-encoded Leah: it is bad to require JSON, because it's not built into python = before 2.6. David: APIs are returning JSON anyway, so claiming that libraries don't = need JSON is silly. Blaine: let's make form-encoded required, but support JSON as an = optional response type. It's weird to have APIs return XML, but authentication services that = return JSON. Dick: when you are working with bearer tokens, you don't need a library = at all... except for the form-encoding. And they are likely to be using = JSON for APIs. So going pure JSON makes things strictly simpler for = developers. This is backed out by WRAP implementation experience. Eran: form-encoding is like the OAuth signature base string: it looks = easy, but developers write their own and get it wrong. Eran: do people have in their heads use-cases when people want to return = more than name/value pairs in responses? If there are needs for that, = we should go with JSON now. Marius: if someone has trouble parsing form-encoded, they will have = trouble with JSON as well. Marius: we are forcing people to generate form-encoded data, which is = harder. Mariius: there are several profiles where repsonses are returned on = query/fragment that still require parsing form-encoded parameters? David: parsing form-encoded is tricky, people do try to do it themselves = and get it wrong. Marius: but... Dick: hey, I have the talking stick! Dick: we ran into problems at microsoft with developers messing up = parsing form-encoded. We talked with other large service providers, and = they had the same experience. ...: in order to prevent bugs, we have to keep the data format. Blaine: this is built into PHP, see urldecode function. Marius: there are flows that require parsing form-encoded *no matter = what*. We aren't actually going to remove the need for parsing = form-encoded by switching to JSON. For example, redirect URI has = "error_code=3Duser_denied". Dick: there are tools for parsing URLs parameters. This is what web = servers do automatically. Marius: what about rich clients? They don't have the web server to do = it for them. Leah: some of this is language dependent. Dick: no it isn't. Leah: yes it is. It's built into python. There is a method that builds = dictionaries from name/value pairs. David: python 2.6 has been out since October, 2008. Brian: signing is going to end up using JSON. Chuck: adding three repsonse formats at service provider is pretty = cheap, we should just do it. ... more discussion, Brian left the room... ... wow, I am all the way down the hall and I can hear people yelling = ... ... chairs close discussion. New topic: how do we unify error responses? Eran: we need different response formats for API calls vs Authorization = server calls? ... Brian is a flaky note taker... Blaine and Peter - what should we talk about now? What about custom protocol handlers? Eran: we can't recommend existing practice (make up random protocol handler) because it violates IETF rules. But we could recommend good = practice for the future. Something about using app: URIs. Leah: everybody knows how to do this. Blaine: lots of twitter developers don't know how to do this. Brian: we've run sessions at IIW every six months for the past two years = on how to do this. People still think it's impossible. Blaine: Eran's suggestion seems reasonable. ------_=_NextPart_001_01CB063E.7D2BDA59 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Meeting Notes from the Interim Meeting

OAuth 2.0 Draft 5 Issues List

Intro:
- Purposes/use cases should appear in = intro
- Describe role wrt OpenID and auth = schemes ??
- Requirements should be removd out of = intro

Intro should describe goals and = possibilities of OAuth
- Requirements is a limited set, but = it should be clarified that they're not the *only* reqs

Terminology:
- We don't say what client secret = is
- Describe relationships between = terms
- Cryptographic terms ??
- Verification code
- Cliented defined as HTTP, not the = case s/Cliented/Client/
- Should use the term = “capability” when talking about bearer tokens.

Overview:
- Should relate to Intro = (confusing)
- Standardization of tokens should be = called out as defined elsewhere
- Call out the face that separation of = resource and authz serviers is not in scope
- Intro talks about three flows. We = have 6, maybe 7 or 8
(Terminology: Call that bearer tokens = are access tokens and cover cryptographic variant)

Examples:
- Scope?
- Best one?

Conformance:
- Useful?


3.2 End-user endpoint

- Can we call it “approval = url” instead? - Brian Eaton
- No mandatory to implement language. = =A0That’s an interop problem. - Peter St. Andre
- No guidelines or examples of how to = verify user identity. - ????
- When using TLS/SSL: make sure = it’s server authentication, not client certificates. - Eve = Maler
- User-uri attribute is very = experimental, no clients using anything like this today. =A0We should = have a couple of working clients.

- Explain that end-user endpoint only = relevant to some flows.
- Should standardize existing service = provider specific parameters for UI, e.g. language, display type, user = hint. =A0(Brian Eaton)

3.3 Token endpoint
- First sentence not true for all = flows. =A0But don’t change it at the expense of readability. =A0- = David Recordon
- “Token issuing endpoint” = might need a new name.
- MUST use SSL?
- Mandate POST? - Marius = Scurtescu
- Security requirements depend on type = of authentication used.
- Should authorization server return = token type? =A0Should client use token type? =A0- Dick Hardt


3.3.1 Client Authentication
- need new text for certificate = authentication - Peter St. Andre
- need more flexible language - Justin = Smith


3.3.2 Response Format
- Do we need so many formats?
- Are all formats needed on both = sides? - Jim Fenton
- Please pick just one. =A0- Justin = Smith
- What if XML becomes uncool? =A0- = Leah Culver
- Data model problem, not all formats = support all data types we might need. =A0- Justin Smith
- Is no-store enough of a = cache-control header? =A0- Chuck Mortimore

3.3.2.1 Access Token Response
- Define scope once, include by = reference. =A0- Peter St. Andre and Eve Maler
- Need “scope” example - = Hannes
- Scope is underspecified. - = Hannes
- Authorization server MUST honor = client request for token secret? =A0- Justin Smith
- Semantics of = “expires_in” are underspecified. - Hannes
- expires_in: duration or absolute = time? - Jim Fenton had an opinion

3.3.2.2 Error response
- Data format needs to be in sync = across entire spec. =A0Either allow XML here, or drop it everywhere. = =A0- Justin Smith and others

- Add debugging message field to JSON. = - Marius Scurtescu
- Predefined list of error = responses?

3.4 Flow Parameters
- More on error handling? - Peter St. = Andre

3.5 User-Agent Flow
- If refresh token leaks, you = can’t recover. =A0Changing client secret is not enough. - Brian = Eaton
- Desktop and mobile applications = work. =A0- David Recordon
- Can we change order of user-agent = and web app flow in spec? - Leah Culver
- WRAP web server flow was more secure = for rich-client apps, because web sites cannot pretend to be rich = clients. =A0User-Agent flow does not allow this. - =A0Sarah = Faulkner

- Where do we handle custom protocol = schemes in redirect URIs? - Blaine Cook and Marius Scurtescu
- Mention that security is based on = user-agent same-origin policy - Zachary Zeltsan
- Maybe move installed applications to = a separate section - Marius Scurtescu
- Need to give installed app = developers a way to specify device name.
- Brian Eaton
- Can =A0mobile developers use HTTP = URL discovery from slide deck instead? - Bill Keenan
- Explain how to authenticate = client?

3.5.1 Client Requests = Authorization
- What if malicious actor (either user = or “man in the browser”) tampers with “scope” or = “state” parameter? - Eve Maler
- Should we add an extension so that = users can self-identify their device? - Bill Smith
- Client state is yucky - Luke = Shephard
- Authorization servers MAY restrict = the redirection URI to not include a query component. This will break = PHP clients. =A0- Marius Scurtescu

3.5.1.1 End-user grants = authorization
- seems odd that client is requesting = the token secret - Bill Smith
- what happens if server doesn’t = want to issue token secret? - Bill Smith and Marius Scurtescu
- should we make example https? - = Chuck Mortimore

3.5.1.2 End-user denies = authorization
- More error codes needed. - Sarah = Faulkner and Marius Scurtescu
- Immedate mode failure needs an error = code. - Marius Scurtescu

3.5.2 Client extracts access = token
- Can we tell user-agents not to send = fragment in HTTP request? =A0IE does this in certain circumstances. - = Brian Eaton

3.6 Web Server Flow

3.6.1 Client Requests = Authorization
- redirect_uri validation strategy = should be described once in the spec, and then included by reference. - = Brian Eaton
- Some of required parameters = don’t make sense if authentication of user is out of band. - Eve = Maler

3.6.1.1 - End-user grants = authorization
- What does the verification code = provide? - Hannes
- How do people keep verification code = from leaking in referer header?
- Sarah Faulkner
- Should we define time-limit for = verification code? =A05 minutes? - Peter St. Andre
- Specify that verification code = should be used only once. - Brian Eaton

3.6.1.2 - End-user denies = authorization?

3.6.2 - Client requests access = token
- should mention https. - David = Recordon

3.7 - Device flow
- mandating polling is terrible =A0- = Leah Culver
- is polling OK if we mandate back-off = behavior? - David Recordon
- are there other options besides = polling? post backs? =A0- Leah Culver
- do we even need this? =A0Is there = enough of a use case? - Leah Culver
- is long polling/hanging GET an = option? - Brian Eaton
- what about telling user to click a = button once they’ve approved?
- can we get comments from NetFlix or = someone who has already done this? - David Recordon
- what about devices with secure = storage? - Bill Keenan
- should call out that device = manufacture must register with service provider - Brian Eaton
- huh? =A0Why is that a requirement in = this profile?

3.7.1 - Client requests approval
- can we rename “verification = uri” to be something else, since it is different than code in web = server flow? - Marius Scurtescu

3.7.2 - Client requests access = token
- Is “code” REQUIRED or = OPTIONAL - Hank
- Can we rename “code” to = something else, since it is different? - Marius Scurtescu

3.8 - Username and password flow
- Can we just call this the secure = flow? - Blaine
- We can’t tell whether the = client has really thrown away password. - Hank
- Add to point (B) that client should = discard password. - Hank
- should we move client credentials = =A0to basic auth header? - Blaine
- unauthorized_client: has extra = apostrophe - Brian
- need to return error URL from this = flow , so that users can get their account unblocked if they are on the = same IP range as a botnet.

- Brian
- need to fix examples to use = “https” instead of “http

3.9 - Client Credentials Flow
- end user is not related to client = secret, should eliminate all mention of end user. =A0- Justin = Smith
- should call out absence of end-user = in front paragraph. - Leah Culver
- add motivating examples. - Peter St. = Andre
- is this the same as username = password flow? - Dirk Balfanz

3.9.1 - Client requests access = token
- all content-type headers should = include charset. - Brian Eaton
- what if developers want to use = client secret directly? - David Recordon
- then they should use basic auth - = Justin Smith

3.10 - Assertion Flow
- comment on 2.2: section 2.2 still = calls this an autonomous flow. - Chuck Mortimore
- if we get client secret right in = other flows (e.g. client secret is replaced with assertion), then this = flow is no longer necessary. - Justin Smith

- James Manger has been saying the same = thing for a while, instead use assertion based HTTP method. - = Eran
- we need client id, client secret, = and assertion. =A0This will get confusing. =A0Let’s keep the = separate flow. - Chuck
- we need an example. - Leah = Culver
- two format parameters. =A0First = should be assertion format. - Marius Scurtescu
- content-type should include charset = - Bill Mills
- are we always using json here, or do = we support format choice? - Bill Mills

4 - Refresh Token
- should we alway tell clients to use = a secret, e.g. “anonymous” or “opensecret”? = =A0Absent secret might be confusing? - Brian Eaton

- can we differentiate between token = refresh and changing secret type?
- Dick Hardt
- should we allow down-scoping on this = endpoint? - Marius Scurtescu
- scope needs to be figured out = through entire flow - Eve Maler
- can we sign with client secret from = request, to prevent accidental logging? - Bill Mills
- auth servers can be assumed to be = smarter than that. - Allen Tom
- passing client secret across affects = lots of flows - Leah Culver
- can we always sign with client = secret? - Leah Culver
- we should use POST instead of GET to = mitigate risk =A0- Marius Scurtescu

5 - Accessing a protected = resource
- Did anyone read this? - Eran
- No clear error path - Bill = Smith
- Can we really call it = “Token”? - Leah Culver
- Can we say “bearer = tokens” MUST NOT be sent over secure channels? - Jim Fenton
- Can we write a spec that reflects = security reality - people do send bearer tokens over HTTP connections - = Brian Eaton
- No, we can’t. =A0Security = reviewers will block that. - Eran
- People violate specs all the time, = we can call them noncompliant and stupid. - Peter St. Andre
- “Token” scheme name is = weird.- Dick
- Can we have the discussion to close = it out? - Eran
- Why isn’t it = “OAuth”? - Dick
- What about “OAuth2”? - = Dick
- Can we drop = name=3D”value” syntax and replace with JSON or something = else? - Brian Eaton
- Is changing the header format worth = our time? - Eran
- Could treat security considerations = better in separate section - Hannes
- Agreed, security here is weak - = Peter St. Andre
- Can we call scheme = “LessBasic” - Blaine
- Can we say MUST NOT send bearer = tokens to unfamiliar sites? - Brian Eaton
- Is “unfamiliar” = well-defined? - Jim Fenton
- Can we have a same-origin policy? - = Blaine Cook

5.2 - Bearer Token Requests
- Rationalize language here
- Does the token need to explicitly = include a bit that says it’s a bearer token vs a crypto token. = =A0This is a problem if resource servers support both - Bill = Smith

- Text/terms should be a bit clearer on = differentation. - Bill Smith
- We should drop realm, it has no = meaningful semantics here. - Brian Eaton
- We have to update RFC 2617 to do = that. =A0- Eran
- Let’s do it. - Brian = Eaton


5.2.1. Query String
- what about protected resources that = accept both OAuth1 and OAuth2?
We have a parameter name conflict = here.

5.2.2 Post body
- this introduces yet another way to = return error responses (401 response vs response body). =A0Can we make = this consistent? - Bill Smith

- this applies throughout the spec. - = Eran
- what happens if both query and post = body have oauth_token? -
- can we eliminate oauth_token in post = body? - Eran
- no, some tokens don’t fit in = query, and you don’t have access to headers. - Dick
- Can we either always use = “token” or always use “oauth_token”? - Bill = Smith
- We don’t need to be = consistent. - Eran

5.3 =A0Cryptographic Signatures
- we’re probably going to change = this dramatically. - Hannes
-


6 - Identifying a protected = resource
- should we add error handling here? = You’ll never return this unless the request was made in error = regardless. =A0- Leah Culver

- should name be “identifying = authentication requirements for a resource”? - Eve Maler
- there should be examples and = pictures. =A0- Eve Maler, Eran

6.1 - WWW-Authenticate Response = header
- what about resources that return = public data if request is unauthenticated? =A0Facebook does this. - = David Recordon
- POST vs GET might have different = security policy for example. - David Recordon

6.1.1. - describing the = WWW-Authenticate response header
- we need a way to puke back an = approval URL. - Bill Smith
- we need to enumerate the types of = flows that are supported so that clients can pick the flow to use. =A0- = Bill Smith
- can we scrap this entire section and = let Bill figure this out for IMAP? =A0And then write down what he did = instead. =A0Or move this section to an extension? - Brian = Eaton

- ABNF problem? =A0Is pound notation = space delimited? - Jim Fenton
- Maybe think about how oauth = discovery should work? - Dirk Balfanz
- is scope a URI or a string? ABNF = says URI ,should be string. - Chuck


7 - Security Considerations
- can we reuse the WRAP security = considerations? - Brian Eaton
- no. =A0Needs to be more = authoritative. Rewrite it to change the voice. - Eran
- can we reuse the NIST approach in = special publication 800-6 of defining specific levels of security along = with necessary requirements to meet that level? - Hannes

Appendix A - Differences from OAuth = 1.0a
- can someone volunteer for this? - = Eran

Authors and Acknowledgements
- do we need three separate classes of = contributors? - Eran
- typically have authors and editors, = contributors, and acknowledgements. - Hannes



Discussion Notes

What response formats should we use? = (Eran Leads)
1) Clients always send form-encoded = query or post body
2) Servers can
=A0 - return form-encoded in query uri = or fragment
=A0 - form-encoded body
3) Discussion on list about servers = returning JSON instead
=A0 - what if JSON is too = heavy?
=A0 - what if APIs use XML?

Nobody has suggested using XML = only.
People have said: should only support = one format, but they don’t care much which one.
People have said: should only support = JSON People have said: servers implement all three, clients indicate = their preference.

=A0 =A0Con: too much complexity, too = little value
=A0 =A0Con: this has data model = implications for the future, e.g. how will we serialize arrays in = XML?

Easy way out: can we all agree on = either JSON or form-encoded for responses?
=A0- no one thinks form-encoded = only
=A0- some support for json only
=A0- some support for supporting both = json and form-encoded

Leah: it is bad to require JSON, = because it’s not built into python before 2.6.
David: APIs are returning JSON anyway, = so claiming that libraries don’t need JSON is silly.

Blaine: let’s make form-encoded = required, but support JSON as an optional response type.

It’s weird to have APIs return = XML, but authentication services that return JSON.

Dick: when you are working with bearer = tokens, you don’t need a library at all... except for the = form-encoding. =A0And they are likely to be using JSON for APIs. =A0So = going pure JSON makes things strictly simpler for developers. =A0This is = backed out by WRAP implementation experience.

Eran: form-encoding is like the OAuth = signature base string: it looks easy, but developers write their own and = get it wrong.

Eran: do people have in their heads = use-cases when people want to return more than name/value pairs in = responses? =A0If there are needs for that, we should go with JSON = now.

Marius: if someone has trouble parsing = form-encoded, they will have trouble with JSON as well.

Marius: we are forcing people to = generate form-encoded data, which is harder.

Mariius: there are several profiles = where repsonses are returned on query/fragment that still require = parsing form-encoded parameters?

David: parsing form-encoded is tricky, = people do try to do it themselves and get it wrong.

Marius: but...

Dick: hey, I have the talking = stick!

Dick: we ran into problems at microsoft = with developers messing up parsing form-encoded. =A0We talked with other = large service providers, and they had the same experience.

...: in order to prevent bugs, we have = to keep the data format.

Blaine: this is built into PHP, see = urldecode function.

Marius: there are flows that require = parsing form-encoded *no matter what*. =A0We aren’t actually going = to remove the need for parsing form-encoded by switching to JSON. =A0For = example, redirect URI has = “error_code=3Duser_denied”.

Dick: there are tools for parsing URLs = parameters. =A0This is what web servers do automatically.

Marius: what about rich clients? = =A0They don’t have the web server to do it for them.

Leah: some of this is language = dependent.

Dick: no it isn’t.

Leah: yes it is. =A0It’s built = into python. =A0There is a method that builds dictionaries from = name/value pairs.

David: python 2.6 has been out since = October, 2008.

Brian: signing is going to end up using = JSON.

Chuck: adding three repsonse formats at = service provider is pretty cheap, we should just do it.

... more discussion, Brian left the = room...
... wow, I am all the way down the = hall and I can hear people yelling ...
... chairs close discussion.



New topic: how do we unify error = responses?
Eran: we need different response = formats for API calls vs Authorization server calls?
... Brian is a flaky note = taker...

Blaine and Peter - what should we talk = about now?

What about custom protocol = handlers?
Eran: we can’t recommend = existing practice (make up random protocol
handler) because it violates IETF = rules. =A0But we could recommend good practice for the future. = =A0Something about using app: URIs.

Leah: everybody knows how to do = this.

Blaine: lots of twitter developers = don’t know how to do this.

Brian: we’ve run sessions at IIW = every six months for the past two years on how to do this. =A0People = still think it’s impossible.

Blaine: Eran’s suggestion seems = reasonable.

------_=_NextPart_001_01CB063E.7D2BDA59-- From James.H.Manger@team.telstra.com Mon Jun 7 09:23:58 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6B4B28CAD1 for ; Mon, 7 Jun 2010 09:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.698 X-Spam-Level: * X-Spam-Status: No, score=1.698 tagged_above=-999 required=5 tests=[HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41-HcvsDBtPK for ; Mon, 7 Jun 2010 09:23:58 -0700 (PDT) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by core3.amsl.com (Postfix) with ESMTP id 3F87F3A9A91 for ; Sun, 6 Jun 2010 20:15:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,375,1272808800"; d="scan'208";a="3967145" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipoavi.tcif.telstra.com.au with ESMTP; 07 Jun 2010 13:15:00 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6005"; a="2875925" Received: from wsmsg3753.srv.dir.telstra.com ([172.49.40.174]) by ipcdvi.tcif.telstra.com.au with ESMTP; 07 Jun 2010 13:15:01 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3753.srv.dir.telstra.com ([172.49.40.174]) with mapi; Mon, 7 Jun 2010 13:15:01 +1000 From: "Manger, James H" To: "OAuth WG (oauth@ietf.org)" Date: Mon, 7 Jun 2010 13:14:57 +1000 Thread-Topic: [OAUTH-WG] Partially standardized format for access tokens? Thread-Index: AcsEDEtJzMteawZGReWWOUyPgZ8rwAB1UK3w Message-ID: <255B9BB34FB7D647A506DC292726F6E11263E5DA7C@WSMSG3153V.srv.dir.telstra.com> References: <4C090B6C.9030707@aol.com> <4C0930B2.80802@aol.com> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {D4D7FF48-A0BF-42F1-B013-E05BC643DB29} x-cr-hashedpuzzle: AC6E A9ks BEHD BN7T BkC6 DBWV DC9/ E/Je FOUy GFco GXkh Gei0 IdEC Io+X J/ER LBuE; 1; bwBhAHUAdABoAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {D4D7FF48-A0BF-42F1-B013-E05BC643DB29}; agBhAG0AZQBzAC4AaAAuAG0AYQBuAGcAZQByAEAAdABlAGEAbQAuAHQAZQBsAHMAdAByAGEALgBjAG8AbQA=; Mon, 07 Jun 2010 03:14:57 GMT; UgBFADoAIABbAE8AQQBVAFQASAAtAFcARwBdACAAUABhAHIAdABpAGEAbABsAHkAIABzAHQAYQBuAGQAYQByAGQAaQB6AGUAZAAgAGYAbwByAG0AYQB0ACAAZgBvAHIAIABhAGMAYwBlAHMAcwAgAHQAbwBrAGUAbgBzAD8A acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Partially standardized format for access tokens? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 16:23:58 -0000 T0F1dGgyIGhhcyBhIGZpZWxkIGZvciBBUy10by1QUiBjb21tdW5pY2F0aW9ucyB2aWEgKGJ1dCBv cGFxdWUgdG8pIHRoZSBjbGllbnQ6IGFjY2Vzc190b2tlbi4gQW55IGZvcm1hdCBpbmRpY2F0aW9u IChsaWtlIGEgdmFyaWV0eSBvZiBvdGhlciBkZXRhaWxzKSB0aGF0IGFuIEFTIHdhbnRzIHRvIGNv bnZleSB0byB0aGUgUFIgdmlhIHRoZSBjbGllbnQgYXBwIHNob3VsZCBiZSAqaW5zaWRlKiB0aGlz IGV4aXN0aW5nIGZpZWxkLg0KDQpEZWZpbmluZyBhbiBvcHRpb25hbCBwcmVmaXggZm9yIGFjY2Vz c190b2tlbiB2YWx1ZXMgdG8gaW5kaWNhdGUgdGhlIGZvcm1hdCB3b3VsZCB3b3JrIHdlbGwuDQpJ IHN1Z2dlc3QgYSBwbGFpbiB0ZXh0IGxhYmVsIHNlcGFyYXRlZCBieSwgc2F5LCBhICIuIiBmcm9t IHRoZSByZXN0IG9mIHRoZSB2YWx1ZS4gRm9yIGV4YW1wbGU6DQogIGFjY2Vzc190b2tlbj1zYW1s LmZoSEZoZ2Y2NTc1ZmhnRkdyeXRyDQpUaGVyZSBjYW4gYmUgYW4gSUFOQSByZWdpc3RyeSBmb3Ig cHJlZml4ZXMgaWYgdGhhdCBpcyBoZWxwZnVsLg0KQSBzZXJ2aWNlIGN1cnJlbnRseSBzdXBwb3J0 aW5nIGEgc2luZ2xlIHRva2VuIGZvcm1hdCBjYW4gc3RhcnQgaXRzIGFjY2Vzc190b2tlbiB2YWx1 ZXMgd2l0aCAiLiIgc28gYXQgbGVhc3QgdGhleSB3aWxsIG5vdCBhY2NpZGVudGFsbHkgY2xhc2gg d2l0aCBhbnkgZnV0dXJlIHZhbHVlcyB0aGF0IGRvIHNwZWNpZnkgYSBmb3JtYXQuDQogIGFjY2Vz c190b2tlbj0uNjc4NjM0NV9KR0pTZ2ZqaHNnZmhqLXNzX3MNCkEgc2VydmljZSB0aGF0IHdpbGwg bmV2ZXIgbmVlZCB0b2tlbiBmb3JtYXQgaW50ZXJvcCBkb2Vzbid0IG5lZWQgdG8gdXNpbmcgYW55 IHByZWZpeCAoZW1wdHkgb3Igb3RoZXJ3aXNlKSwgYW5kIGNhbiB1c2UgZG90cyBob3dldmVyIGl0 IHdhbnRzLg0KDQoNCg0KUC5TLiBPQXV0aDIgaGFzIG5vIGV4cGxpY2l0IHN0YXRlbWVudCBhYm91 dCBhbGxvd2VkIGNoYXJzIGluIGFuIGFjY2Vzc190b2tlbi4gVGhlIDx0b2tlbi1pZD4gQUJORiBp biBzZWN0aW9uIDUuMSAiQXV0aHogUmVxdWVzdCBIZWFkZXIiIGltcGxpZXMgNzcgQVNDSUkgY2hh cnMgYXJlIGFsbG93ZWQuDQpJIHRoaW5rIHRoZSBzcGVjIHNob3VsZCBleHBsaWNpdGx5IHNheSBh Y2Nlc3NfdG9rZW4gdmFsdWVzIGNhbiBvbmx5IHVzZSB0aGUgNjYgPHVucmVzZXJ2ZWQ+IGNoYXJz LiBJdCBhdm9pZHMgZXNjYXBpbmcgaXNzdWVzIGluIFhNTCBhdHRyaWJ1dGVzLCBYTUwgY29udGVu dCwgSlNPTiwgVVJJcywgZm9ybSBib2RpZXMsIEhUVFAgaGVhZGVycyBldGMuIEl0IGlzIHNhZmVy IChsZXNzIGNoYW5jZSBvZiBYU1Mtc3R5bGUgYnVncyk7IGl0IGNhbiBlYXNpbHkgc3VwcG9ydCBh cmJpdHJhcnkgdGV4dCBvciBiaW5hcnkgZm9ybWF0cyBieSB1c2luZyBhIGJhc2U2NHVybCBlbmNv ZGluZy4NCg0KLS0gDQpKYW1lcyBNYW5nZXINCg== From andrewarnott@gmail.com Mon Jun 7 10:18:27 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 019D93A6824 for ; Mon, 7 Jun 2010 10:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j8urFRTloD0u for ; Mon, 7 Jun 2010 10:18:25 -0700 (PDT) Received: from mail-yw0-f171.google.com (mail-yw0-f171.google.com [209.85.211.171]) by core3.amsl.com (Postfix) with ESMTP id BAA3628C140 for ; Mon, 7 Jun 2010 08:39:14 -0700 (PDT) Received: by ywh1 with SMTP id 1so2930033ywh.22 for ; Mon, 07 Jun 2010 08:39:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:content-type; bh=p8QQfd3K6FRgijmck29LHNftm1/pq7tuifgsF9g6m6E=; b=ixWb6ZEC6peNmsUaH4NFqQpmX8zA46+dd4FkfyNw3mS1LERXfL7SS673OtqdU+q6eW /PPIxXKb09DK75TsDyXNDKcaOaXOiXOjuq3YN158AWdHX5BxvTc788LMhxSgHIPvvGDv CYjHIKzLItk488idRDSuKD05x9FsCVeFa66tw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=wRpBJV7Waae3AHFqS8nXXRVM8qgvFFtqhGgcXSrmiImWWul4vMl/cCR1KZ0kcCbgEz td7AhY1QWuxNLnbKBobpo7mt6PRf2X6+FyLDLhvXAqCup4Uwh9USjXHnW3ugkFRKsGkv rP4mwCn9cJm3yoh7ltqfw3k2Tmk7k75UU+TjE= Received: by 10.151.18.38 with SMTP id v38mr13915321ybi.420.1275925147033; Mon, 07 Jun 2010 08:39:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.26.19 with HTTP; Mon, 7 Jun 2010 08:38:46 -0700 (PDT) In-Reply-To: References: From: Andrew Arnott Date: Mon, 7 Jun 2010 08:38:46 -0700 Message-ID: To: "OAuth WG (oauth@ietf.org)" Content-Type: multipart/alternative; boundary=000e0cdf1970261f45048872795c Subject: [OAUTH-WG] User agent flow missing optional scope parameter in response? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 17:18:27 -0000 --000e0cdf1970261f45048872795c Content-Type: text/plain; charset=ISO-8859-1 The web server flow includes an optional scope parameter in a success response. The user agent flow seems to be missing that. If a single auth server supports both flows, and actually leverages the capability in the web server flow to change the set of granted scopes from the requested ones by sending a new scope value, it will be unable to do so for user-agent clients. Is this intended? -- 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 --000e0cdf1970261f45048872795c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The web server flow includes an optional scope p= arameter in a success response.=A0 The user agent flow seems to be missing = that.=A0 If a single auth server supports both flows, and actually leverage= s the capability in the web server flow to change the set of granted scopes= from the requested ones by sending a new scope value, it will be unable to= do so for user-agent clients.

Is this intended?
--
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

--000e0cdf1970261f45048872795c-- From andrewarnott@gmail.com Mon Jun 7 10:18:47 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 735303A6DB4 for ; Mon, 7 Jun 2010 10:18:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljLmsPEi1e9P for ; Mon, 7 Jun 2010 10:18:46 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 58BB928C1BB for ; Mon, 7 Jun 2010 08:40:20 -0700 (PDT) Received: by gwj21 with SMTP id 21so702257gwj.31 for ; Mon, 07 Jun 2010 08:40:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:content-type; bh=IIVdlxlLKXWC/f2EeP1TNFkrQwm0CBdqVZy8+6kN5XM=; b=fcMFLgfeYT5ksuMrNkgsh4P2Zq3MHyviEwUBeiHPdyjItk/q23KO1OUqJcvrTgLjjD VssevRp+ahHPW/0rfDykvTDJD/2QEcYkXgxW3jzhsKaqcBHFPkFwXERlKr/+i6tRKF7m FGbjMOZoEOqhLx3Q3wH6BRJyG8Kk87YKzEGTc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=EoOobiYdPX++VbK2vsIquZP2kbdDy/4zvyp8s311ig2ZzpkzZbVIBIVbwSzZKhY6rR SG20ad94Y1wyoaKbKoSvSu1/QgCUkbzacq7eweUj/UyjlW83OPR3CGnuN2kwt+erDza0 UgBDqdn5DwdM4afl83K0w5Hy+sZyzNBlr+syE= Received: by 10.150.165.3 with SMTP id n3mr13970590ybe.47.1275925217114; Mon, 07 Jun 2010 08:40:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.26.19 with HTTP; Mon, 7 Jun 2010 08:39:57 -0700 (PDT) In-Reply-To: References: From: Andrew Arnott Date: Mon, 7 Jun 2010 08:39:57 -0700 Message-ID: To: "OAuth WG (oauth@ietf.org)" Content-Type: multipart/alternative; boundary=000e0cd5637e537d760488727d43 Subject: [OAUTH-WG] Device profile wording X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 17:18:47 -0000 --000e0cd5637e537d760488727d43 Content-Type: text/plain; charset=ISO-8859-1 >From the spec: The client makes the following request at an arbitrary but reasonable *interval *which MUST NOT *exceed the minimum **interval rate *provided by the authorization server (if present via the interval parameter). I know what an interval is, and I know what a rate is. But "interval rate" I think is a poor combination of words that makes this sentence confusing. Also, "MUST NOT exceed the minimum" is another confusing combination of words. We can't exceed the minimum? Well then that sounds like a maximum to me. :) So to be constructive rather than just derogatory, here's my proposed new text: The client makes the following request at an arbitrary but reasonable *interval *which MUST be at least the time provided by the authorization server (if present via the interval parameter). Further down in the flow there's some wording that might also be adjusted for the same reasons. -- 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 --000e0cd5637e537d760488727d43 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
From the spec:

The client makes the following request at an arbitrary but reasonable= interval which MUST NOT exceed the minimum interval rate provide= d by the=20 authorization server (if present via the interval parameter).

I know = what an interval is, and I know what a rate is.=A0 But "interval rate&= quot; I think is a poor combination of words that makes this sentence confu= sing.=A0 Also, "MUST NOT exceed the minimum" is another confusing= combination of words.=A0 We can't exceed the minimum?=A0 Well then tha= t sounds like a maximum to me. :)=A0

So to be constructive rather than just derogatory, here's my propos= ed new text:

The client makes the fo= llowing request at an arbitrary but reasonable interval which MUST be at least the time provided by the=20 authorization server (if present via the interval parameter).

Further down in the f= low there's some wording that might also be adjusted for the same reaso= ns.

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

--000e0cd5637e537d760488727d43-- From andrewarnott@gmail.com Mon Jun 7 10:19:01 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3DEB3A6DD5 for ; Mon, 7 Jun 2010 10:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OYQ2ZZkPsdfA for ; Mon, 7 Jun 2010 10:19:00 -0700 (PDT) Received: from mail-yw0-f171.google.com (mail-yw0-f171.google.com [209.85.211.171]) by core3.amsl.com (Postfix) with ESMTP id D858128C1F9 for ; Mon, 7 Jun 2010 08:41:07 -0700 (PDT) Received: by ywh1 with SMTP id 1so2932284ywh.22 for ; Mon, 07 Jun 2010 08:41:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:content-type; bh=a3mEIb7N0VJYghOfcZ5QoIWLl4Rq9AnA6tm9z0jj6ZI=; b=UChxehhDSox32HGlOBbEGsBH6OQc/Vq1bO7W7CoFGkkoZAeFPipuFtb7MYl1P7V9v/ PTv+aLRcwaDuu4QxyJr0A7DeClPexp8Qe6G5d7JL8s3Tg8ZXk/Js0uDShDk2doaFbltZ qUOFusbzorT8ozD0/E+GQjDgaKwH4cOk5G47c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=pk7PZCTH+w3nb7nE7GEkwT78F7Lc4DsJ52wj26vZfnvdJAe3b1f5lWVj/0cVmyCt1R oKCb95Hl6TUsSdQkfYTwG3FJM0jgSxalt0ROrm5QY459Mio86hQLIRukBpzwbnblhaFK VYsFsIRTfZD+gRU7QoBNM/ZNMsiaxRqRbH0FI= Received: by 10.151.18.38 with SMTP id v38mr13917384ybi.420.1275925263289; Mon, 07 Jun 2010 08:41:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.26.19 with HTTP; Mon, 7 Jun 2010 08:40:42 -0700 (PDT) In-Reply-To: References: From: Andrew Arnott Date: Mon, 7 Jun 2010 08:40:42 -0700 Message-ID: To: "OAuth WG (oauth@ietf.org)" Content-Type: multipart/alternative; boundary=000e0cdf1970140fb2048872806d Subject: [OAUTH-WG] Username and Password flow: no captcha? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 17:19:01 -0000 --000e0cdf1970140fb2048872806d Content-Type: text/plain; charset=ISO-8859-1 In WRAP, there was a CAPTCHA in this profile, but I don't see it in the latest OAuth 2.0 draft. Since I've already implemented the CAPTCHA stuff from WRAP, I'll leave it there if the OAuth 2.0 is likely to pick it up, or rip it out now if OAuth 2.0 decided it wasn't necessary. Does anyone from the WG have something they can say on the subject? -- 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 --000e0cdf1970140fb2048872806d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
In WRAP, there was a CAPTCHA in this profile, bu= t I don't see it in the latest OAuth 2.0 draft.=A0 Since I've alrea= dy implemented the CAPTCHA stuff from WRAP, I'll leave it there if the = OAuth 2.0 is likely to pick it up, or rip it out now if OAuth 2.0 decided i= t wasn't necessary.

Does anyone from the WG have something they can say on the subject?
--
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

--000e0cdf1970140fb2048872806d-- From andrewarnott@gmail.com Mon Jun 7 10:19:32 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F4363A6E38 for ; Mon, 7 Jun 2010 10:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0yHE7PK32zH for ; Mon, 7 Jun 2010 10:19:30 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 87B9A28C33A for ; Mon, 7 Jun 2010 08:43:10 -0700 (PDT) Received: by gwj21 with SMTP id 21so705007gwj.31 for ; Mon, 07 Jun 2010 08:43:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:content-type; bh=aHtOf7vAPrwC0aIF9DenTIr9rcz5Qw7yVYHtB08lPHo=; b=HaQIsQrydNctw3r6z2fr8LNQ/ak0Z2Jvk/i37AgCrjfpqj25b8tmldLryJQ3Bx3zDl M6ROTn5/9iPI0L8DohZNCmflAvrVlvmzN6TkcdP7ogqmjmtOkX4i7G1hljaIEpyoBxi/ FRqCGd6Vr4x6cRpTU+wzea55VClb/0Xy+wnF8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=l1bl2pZYYedji6jKF8nR1i44GaKhYTWbu1HxlK+iJ8mO06L1jLj61wgoRnByoQGBsK 6wJxf6qL8OGQb/+veQeVFIoJGXwxYxWGe7wXhMAZFdlWKVE0iHe+KSiFXI1wwhral2Fm qjxRg5SdqXJI82btVP+i+cLkhqklQcV/1SsKg= Received: by 10.150.165.3 with SMTP id n3mr13974733ybe.47.1275925387121; Mon, 07 Jun 2010 08:43:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.26.19 with HTTP; Mon, 7 Jun 2010 08:42:42 -0700 (PDT) In-Reply-To: References: <4C090B6C.9030707@aol.com> <4C0930B2.80802@aol.com> <39D25154-9A0E-4357-B5D0-439AFBFC3DE7@jkemp.net> <7BB45F28-C209-4014-B9F5-FBACADCFF09E@gmail.com> From: Andrew Arnott Date: Mon, 7 Jun 2010 08:42:42 -0700 Message-ID: To: "OAuth WG (oauth@ietf.org)" Content-Type: multipart/alternative; boundary=000e0cd5637e7b9f6c04887287ca Subject: Re: [OAUTH-WG] Partially standardized format for access tokens? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 17:19:32 -0000 --000e0cd5637e7b9f6c04887287ca Content-Type: text/plain; charset=ISO-8859-1 (resending to DL due to apparent DL failure over the weekend... I know Dick and Luke already received my email because they were individual recipients as well... I don't know if the DL received their replies or not)... Great discussion, all. I am also for an optional parameter that's part of the main spec, and defining possible structures for the access token in separate specs. But *token_format* is not the idea I think. It's more like *token_origin. *The scenario I had in mind was that a RS actually accepts access tokens from two auth servers, both tokens are in the *same* format, but the RS needs to know which public keys to apply while verifying signatures and decrypting the token in order to complete it successfully. Now, an AS identifier *could* be encoded directly into the access token to help the RS know, which is fine if everyone was coordinating their design together. But if you have two auth servers issues encrypted access tokens in different formats, it gets *much* harder for the resource server to decide how to decrypt, verify, and decode the access token. As the number of auth servers supported by a RS goes up, the trial-and-error approach gets progressively worse. The only way I can see to avoid this is for an OAuth 2.0 specified standard to exist so that all auth servers provide a way for RS to know "ok, this access token came from *x*, so I'll decode it this way..." So to recap, *knowing just the format is insufficient, *since that doesn't tell you the public keys to use. Including the public keys in the token itself will significantly increase the size of the token, and assumes again that the RS knows how to pull it out in advance of decoding it. Chicken-and-egg problem. -- 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 Fri, Jun 4, 2010 at 6:58 PM, Dick Hardt wrote: > > On 2010-06-04, at 6:39 PM, Luke Shepard wrote: > > > I don't see how the extra parameter is required to support multiple auth > servers for a resource. > > it is needed if there are multiple token types > > > > > Responses to Dick and Torsten: > > > > On Jun 4, 2010, at 11:33 AM, Dick Hardt wrote: > >> if we have the parameter in the spec, then clients know to pass it along > if they see it. > > > > > > My main objection here is that the extra param requires more code on the > client. Even if it's an optional param, the client needs to worry about > multiple parameters, and that's annoying. > > > > For example, here's the PHP code needed to make a resource request today > (at the end of the web server flow): > > > > $access_token = oauth_get_access_token($_GET['code']); > > $resource = file_get_contents(' > https://example.com/resource?oauth_token=' . $access_token); > > > > With this proposal, the client now needs to keep track of two parameters > and pass them both: > > > > list($access_token, $format) = oauth_get_access_token($_GET['code']); > > $resource = file_get_contents(' > https://example.com/resource?oauth_token=' . $access_token . '&format=' . > $format); > > > > Why? > > The client would only need to do that if the AS will issue the parameter. I > would expect that libraries would deal with the two parameters. Moving an > extra one around does not seem to be hard. > > > > > > On Jun 4, 2010, at 2:31 PM, Torsten Lodderstedt wrote: > >> there is another point: such a parameter could be used to let the > authorization server indicate the format of the access token to the resource > server. This will help deployments with more than one token format in use. > For example, we use SAML and another proprietary format. Without such a > parameter, the resource server has to somehow (magically) find out the > format of the incomming token. > > > > It's not "magically" - the server just decodes the token and extracts any > useful information it's expecting. If it doesn't match the format it > expects, then it throws it away. Tokens will undoubtedly encode all sorts of > useful stuff that resource servers know how to decode - like format, > expiration, scope, whatever. The point is that the structure is undefined > *to the client*. > > what if there are multiple token formats? that is were the magic comes in. > Detecting format can be tricky. > > > > > For example, if the format is just encoded in the token, like this: > > > > format=ubertoken&token=abcdefg > > > > The protected resource request is then: > > > > > https://example.com/resource?oauth_token=format%3Dubertoken%26token%3Dabcdefg > > > > and there's no extra code required on the client. Why is this not > sufficient? > > one token could be SAML, another JSON in one format, another in URL encoded > name/value pairs. The PR is having to detect both syntax and semantics. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000e0cd5637e7b9f6c04887287ca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
(resending to DL due to apparent DL failure over= the weekend... I know Dick and Luke already received my email because they= were individual recipients as well... I don't know if the DL received = their replies or not)...

Great discussion, all.=A0 I am also for an o= ptional parameter that's part of the main spec, and defining possible s= tructures for the access token in separate specs.

But token_forma= t is not the idea I think.=A0 It's more like token_origin.=A0 The scenario I had in mind was that a RS actually accepts access tokens f= rom two auth servers, both tokens are in the same format, but the RS= needs to know which public keys to apply while verifying signatures and de= crypting the token in order to complete it successfully.=A0 Now, an AS iden= tifier could be encoded directly into the access token to help the R= S know, which is fine if everyone was coordinating their design together.= =A0 But if you have two auth servers issues encrypted access tokens in diff= erent=A0 formats, it gets much harder for the resource server to dec= ide how to decrypt, verify, and decode the access token.=A0 As the number o= f auth servers supported by a RS goes up, the trial-and-error approach gets= progressively worse.=A0

The only way I can see to avoid this is for an OAuth 2.0 specified stan= dard to exist so that all auth servers provide a way for RS to know "o= k, this access token came from x, so I'll decode it this way...&= quot;

So to recap, knowing just the format is insufficient, since that= doesn't tell you the public keys to use.=A0 Including the public keys = in the token itself will significantly increase the size of the token, and = assumes again that the RS knows how to pull it out in advance of decoding i= t.=A0 Chicken-and-egg problem.


--
Andrew Arnott
"I [may] not agree with what = you have to say, but I'll defend to the death your right to say it.&quo= t; - S. G. Tallentyre


= On Fri, Jun 4, 2010 at 6:58 PM, Dick Hardt <dick.hardt@gmail.com>= ; wrote:

On 2010-06-04, at 6:39 PM, Luke Shepard wrote:

> I don't see how the extra parameter is required to support multipl= e auth servers for a resource.

it is needed if there are multiple token types

>
> Responses to Dick and Torsten:
>
> On Jun 4, 2010, at 11:33 AM, Dick Hardt wrote:
>> if we have the parameter in the spec, then clients know to pass it= along if they see it.
>
>
> My main objection here is that the extra param requires more code on t= he client. Even if it's an optional param, the client needs to worry ab= out multiple parameters, and that's annoying.
>
> For example, here's the PHP code needed to make a resource request= today (at the end of the web server flow):
>
> =A0$access_token =3D oauth_get_access_token($_GET['code']); > =A0$resource =3D file_get_contents('https://example.com/resource?oa= uth_token=3D' . $access_token);
>
> With this proposal, the client now needs to keep track of two paramete= rs and pass them both:
>
> =A0list($access_token, $format) =3D oauth_get_access_token($_GET['= code']);
> =A0$resource =3D file_get_contents('https://example.com/resource?oa= uth_token=3D' . $access_token . '&format=3D' . $format)= ;
>
> Why?

The client would only need to do that if the AS will issue the parame= ter. I would expect that libraries would deal with the two parameters. Movi= ng an extra one around does not seem to be hard.


>
> On Jun 4, 2010, at 2:31 PM, Torsten Lodderstedt wrote:
>> there is another point: such a parameter could be used to let the = authorization server indicate the format of the access token to the resourc= e server. This will help deployments with more than one token format in use= . For example, we use SAML and another proprietary format. Without such a p= arameter, the resource server has to somehow (magically) find out the forma= t of the incomming token.
>
> It's not "magically" - the server just decodes the token= and extracts any useful information it's expecting. If it doesn't = match the format it expects, then it throws it away. Tokens will undoubtedl= y encode all sorts of useful stuff that resource servers know how to decode= - like format, expiration, scope, whatever. The point is that the structur= e is undefined *to the client*.

what if there are multiple token formats? that is were the magic come= s in. Detecting format can be tricky.

>
> For example, if the format is just encoded in the token, like this: >
> =A0 format=3Dubertoken&token=3Dabcdefg
>
> The protected resource request is then:
>
> =A0 https://example.com/resource?oa= uth_token=3Dformat%3Dubertoken%26token%3Dabcdefg
>
> and there's no extra code required on the client. Why is this not = sufficient?

one token could be SAML, another JSON in one format, another in URL e= ncoded name/value pairs. =A0The PR is having to detect both syntax and sema= ntics.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth


--000e0cd5637e7b9f6c04887287ca-- From andrewarnott@gmail.com Mon Jun 7 10:19:39 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 793D33A6892 for ; Mon, 7 Jun 2010 10:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.648 X-Spam-Level: X-Spam-Status: No, score=-0.648 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dxkaTr2QAF8w for ; Mon, 7 Jun 2010 10:19:38 -0700 (PDT) Received: from mail-yw0-f171.google.com (mail-yw0-f171.google.com [209.85.211.171]) by core3.amsl.com (Postfix) with ESMTP id 1EC3428C38A for ; Mon, 7 Jun 2010 08:43:46 -0700 (PDT) Received: by ywh1 with SMTP id 1so2935439ywh.22 for ; Mon, 07 Jun 2010 08:43:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:content-type; bh=s1kWxa2sr0aG/OmpR2zwaQZAJXADuDdaaajHaIRzeq0=; b=EhplGfvth5YcrnsujvCVcxU6RrjY2csz6T0bIaq8+r4xp8WKLeGh6RuLnTwIPRInKC Jzx9J/CUnl5Zi6xrpkNmeEseKK40CbZbmIAgXd5wXIDS/UT8MDclIGzwT+eeoxRcEV25 Wo1gVqapCf2cmtd/hXWSKLb5c9aR3/oePEku8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=br0o/Kuf8ipU8zP9qAGa8DdTqG4gaeKWdGYIqC1FK3eY8/pjS+QWJ2bJvVks32MLtQ GsJWQuRBoRiXqnJlBBcO4XoxEhoprvX6/ER3WWNzfd5njY+wJua+AaRG04qlEDnherp0 bMKSfRwlydSFVJeegLzIBbZVb5sq77smQaOQ8= Received: by 10.150.208.10 with SMTP id f10mr13833997ybg.261.1275925423996; Mon, 07 Jun 2010 08:43:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.26.19 with HTTP; Mon, 7 Jun 2010 08:43:23 -0700 (PDT) In-Reply-To: References: From: Andrew Arnott Date: Mon, 7 Jun 2010 08:43:23 -0700 Message-ID: To: "OAuth WG (oauth@ietf.org)" Content-Type: multipart/alternative; boundary=000e0cdf1baaab436a04887289e2 Subject: Re: [OAUTH-WG] User-agent flow and pre-registered redirect_uri X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 17:19:39 -0000 --000e0cdf1baaab436a04887289e2 Content-Type: text/plain; charset=ISO-8859-1 Rick, ... On Sat, Jun 5, 2010 at 12:45 PM, Rick Olson wrote: > How else are you preregistered with the auth server? I don't understand the question, sorry. > Why can't you > just return the temporary code and rely on the JS or Desktop app to > make another call to get the access token? JSONP would work well for > the response to JS apps. > Besides being less convenient for the clients, what would that accomplish? I don't think it would improve security, if that's the objective, since the clients still can't keep their own secrets and it's the secret that accompany the follow-up request for an access token that prevent the security problem in the other flows. > > On Sat, Jun 5, 2010 at 12:49 AM, Andrew Arnott > wrote: > > The user agent flow indicates that the redirect_uri SHOULD be > preregistered > > with the auth server for a given client. I would like to suggest that > the > > SHOULD here be changed to MUST. Unless I'm missing something, without a > > preregistered redirect_uri any arbitrary client can obtain an access > token > > under the pretense of being another client, and thereby perhaps > altogether > > skip a user authorization prompt. > > > > As there will likely be a few popular client_id's in use, it will > actually > > make it trivially easy to obtain elevated access to private user data as > a > > rogue application. This danger is unique to the user-agent flow because > in > > this flow the client_secret is not required to obtain the access token, > > whereas it is for other flows. > > > > 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 > > > > > > > > -- > Rick Olson > --000e0cdf1baaab436a04887289e2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Rick, ...

On Sat, Jun 5, 2010 at 12:45 PM, Rick Olson <technoweenie@gmail.com> wrote:
How else are you preregistered with the auth server?
I don't understand the question, sorry.
<= blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-l= eft:1px solid rgb(204, 204, 204);padding-left:1ex"> =A0Why can't you
just return the temporary code and rely on the JS or Desktop app to
make another call to get the access token?=A0 JSONP would work well for
the response to JS apps.
Besides being less conv= enient for the clients, what would that accomplish?=A0 I don't think it= would improve security, if that's the objective, since the clients sti= ll can't keep their own secrets and it's the secret that accompany = the follow-up request for an access token that prevent the security problem= in the other flows.

On Sat, Jun 5, 2010 at 12:49 AM, Andrew Arnott <andrewarnott@gmail.com> wrote: > The user agent flow indicates that the redirect_uri SHOULD be preregis= tered
> with the auth server for a given client.=A0 I would like to suggest th= at the
> SHOULD here be changed to MUST.=A0 Unless I'm missing something, w= ithout a
> preregistered redirect_uri any arbitrary client can obtain an access t= oken
> under the pretense of being another client, and thereby perhaps altoge= ther
> skip a user authorization prompt.
>
> As there will likely be a few popular client_id's in use, it will = actually
> make it trivially easy to obtain elevated access to private user data = as a
> rogue application.=A0 This danger is unique to the user-agent flow bec= ause in
> this flow the client_secret is not required to obtain the access token= ,
> whereas it is for other flows.
>
> 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
>
>



--
Rick Olson


--000e0cdf1baaab436a04887289e2-- From eran@hueniverse.com Mon Jun 7 10:19:57 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 221823A6E7C for ; Mon, 7 Jun 2010 10:19:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3B6Hd25n+0D for ; Mon, 7 Jun 2010 10:19:56 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 4D6E728C3D9 for ; Mon, 7 Jun 2010 08:44:28 -0700 (PDT) Received: (qmail 32351 invoked from network); 7 Jun 2010 15:44:28 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 7 Jun 2010 15:44:28 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 7 Jun 2010 08:44:15 -0700 From: Eran Hammer-Lahav To: "OAuth WG (oauth@ietf.org)" Date: Mon, 7 Jun 2010 08:44:16 -0700 Thread-Topic: Next draft Thread-Index: AcsFSvXXsHDK63TGRoqifZC+D7SOsg== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF6898@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] Next draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 17:19:57 -0000 I still need to catch up on the list (I took a little break). I plan to pos= t a new draft this week incorporating many editorial changes discussed at t= he interim meeting. I am also planning of removing some non-stable features= (such as discovery and signatures) from the draft and moving them to new d= rafts. As soon as -06 is published, I plan to issue informal last-calls for= each section so that we can lock down the normative portions of the draft. If you have any must-happen changes for -05 that were not already posted to= the list, please let me know. EHL From hardjono@mit.edu Mon Jun 7 10:20:56 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D2453A6DE9 for ; Mon, 7 Jun 2010 10:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zOQSZbZt7qSe for ; Mon, 7 Jun 2010 10:20:55 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (DMZ-MAILSEC-SCANNER-1.MIT.EDU [18.9.25.12]) by core3.amsl.com (Postfix) with ESMTP id E9A2628C528 for ; Mon, 7 Jun 2010 08:48:00 -0700 (PDT) X-AuditID: 1209190c-b7bd2ae000005d05-4a-4c0d030ed562 Received: from mailhub-auth-4.mit.edu (MAILHUB-AUTH-4.MIT.EDU [18.7.62.39]) by dmz-mailsec-scanner-1.mit.edu (Symantec Brightmail Gateway) with SMTP id 7C.3D.23813.E030D0C4; Mon, 7 Jun 2010 10:32:46 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-EXCHANGE-2.MIT.EDU [18.9.28.16]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id o57EWkDp028954; Mon, 7 Jun 2010 10:32:46 -0400 Received: from w92exedge3.EXCHANGE.MIT.EDU (W92EXEDGE3.EXCHANGE.MIT.EDU [18.7.73.15]) ) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id o57EWgu7010878; Mon, 7 Jun 2010 10:32:46 -0400 Received: from oc11exhub1.exchange.mit.edu (18.9.3.11) by w92exedge3.exchange.mit.edu (18.7.73.15) with Microsoft SMTP Server (TLS) id 8.1.393.1; Mon, 7 Jun 2010 10:32:13 -0400 Received: from EXPO10.exchange.mit.edu ([18.9.4.15]) by oc11exhub1.exchange.mit.edu ([18.9.3.11]) with mapi; Mon, 7 Jun 2010 10:32:42 -0400 From: Thomas Hardjono To: Dick Hardt Date: Mon, 7 Jun 2010 10:32:40 -0400 Thread-Topic: [OAUTH-WG] Assertion flow and token bootstrapping Thread-Index: AcsF1f/j29sX9+E2SBa/6rmqqrl8FAAd9GKQ Message-ID: References: <4C07C84C.9070705@stpeter.im> <700AC043-9E28-491D-B3CD-789245E30EA9@pingidentity.com> <57FA7F56-ADC2-404A-950E-5D43FBDE75D9@facebook.com> <4C2E55D5-072B-4F08-A341-7405F2F1C944@gmail.com> <77E0A4F9-9211-4E2A-B6A1-4E812192BA82@gmail.com> In-Reply-To: <77E0A4F9-9211-4E2A-B6A1-4E812192BA82@gmail.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-Brightmail-Tracker: AAAAAA== Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Assertion flow and token bootstrapping X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 17:20:56 -0000 Thanks Dick. I was just kinda confused: if the Assertion Flow was already = in the WRAP draft and now in the core spec (OAuth2.0-draft-05), what do we = gain from separating it off again. /thomas/ __________________________________________ > -----Original Message----- > From: Dick Hardt [mailto:dick.hardt@gmail.com] > Sent: Sunday, June 06, 2010 8:10 PM > To: Thomas Hardjono > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Assertion flow and token bootstrapping >=20 > I hope so. >=20 > On 2010-06-06, at 3:22 PM, Thomas Hardjono wrote: >=20 > > Apologies for another newbie question: is the design-intention underlyi= ng > the Assertion Flow in OAuth2.0-draft-05 the same as that in the WRAP draf= t > (draft-hardt-oauth-01)? > > > > /thomas/ > > > > __________________________________________ > > > >> -----Original Message----- > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf= Of > >> Dick Hardt > >> Sent: Friday, June 04, 2010 9:59 PM > >> To: Luke Shepard > >> Cc: oauth@ietf.org > >> Subject: Re: [OAUTH-WG] Assertion flow and token bootstrapping > >> > >> because we use it > >> > >> On 2010-06-04, at 6:40 PM, Luke Shepard wrote: > >> > >>> Why? > >>> > >>> On Jun 4, 2010, at 4:41 PM, Patrick Harding wrote: > >>> > >>>> +1 > >>>> > >>>> Sent from my iPhone > >>>> > >>>> On Jun 4, 2010, at 5:38 PM, Brian Campbell > >>>> wrote: > >>>> > >>>>> On Thu, Jun 3, 2010 at 9:20 AM, Peter Saint-Andre > >>>>> wrote: > >>>>>> > >>>>>> At least for the assertion flow, that's definitely true. At the > >>>>>> interim > >>>>>> meeting we had some discussion about perhaps pulling the assertion > >>>>>> flow > >>>>>> out of the base spec and into a separate document. Perhaps that's = the > >>>>>> best way to proceed. > >>>>> > >>>>> > >>>>> I'd like to see the assertion flow remain in the base spec. > >>>>> _______________________________________________ > >>>>> OAuth mailing 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 From john@jkemp.net Mon Jun 7 10:33:16 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6B0C28C152 for ; Mon, 7 Jun 2010 10:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.335 X-Spam-Level: X-Spam-Status: No, score=0.335 tagged_above=-999 required=5 tests=[BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ejs1WfvDKDQj for ; Mon, 7 Jun 2010 10:33:09 -0700 (PDT) Received: from cpoproxy1-pub.bluehost.com (cpoproxy1-pub.bluehost.com [69.89.21.11]) by core3.amsl.com (Postfix) with SMTP id 4236E3A695A for ; Mon, 7 Jun 2010 09:39:03 -0700 (PDT) Received: (qmail 30470 invoked by uid 0); 7 Jun 2010 16:39:04 -0000 Received: from unknown (HELO box320.bluehost.com) (69.89.31.120) by cpoproxy1.bluehost.com with SMTP; 7 Jun 2010 16:39:04 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=jkemp.net; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-Identified-User; b=cCjZC6xK2Ejao0a9Rx5yESEpVJqGflj69o2HG6/BIu250eH89Wj5PZoOSOygLVpzpatVsDejTSId1OWTSUDp3C7k+oQH5QgSrhPol5IfEahqupaOLxbHa5pNbifZSvbH; Received: from cpe-69-205-56-47.nycap.res.rr.com ([69.205.56.47] helo=[192.168.1.107]) by box320.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1OLfLr-0000PP-Ir; Mon, 07 Jun 2010 10:39:03 -0600 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: John Kemp In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11263E5DA7C@WSMSG3153V.srv.dir.telstra.com> Date: Mon, 7 Jun 2010 12:39:00 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <383A9188-1AA6-49FE-95FC-5D6316BD18CD@jkemp.net> References: <4C090B6C.9030707@aol.com> <4C0930B2.80802@aol.com> <255B9BB34FB7D647A506DC292726F6E11263E5DA7C@WSMSG3153V.srv.dir.telstra.com> To: "Manger, James H" X-Mailer: Apple Mail (2.1078) X-Identified-User: {1122:box320.bluehost.com:jkempnet:jkemp.net} {sentby:smtp auth 69.205.56.47 authed with john+jkemp.net} Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Partially standardized format for access tokens? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 17:33:16 -0000 On Jun 6, 2010, at 11:14 PM, Manger, James H wrote: > OAuth2 has a field for AS-to-PR communications via (but opaque to) the = client: access_token. Any format indication (like a variety of other = details) that an AS wants to convey to the PR via the client app should = be *inside* this existing field. I take your point, I think, that the format is a description of the = token, and should thus be "inside" the token.=20 However, in this case, what we're calling a token is simply an "opaque = string" - an opaque string only becomes a token via some mapping made by = some entity (one or more entities) able to make the mapping.=20 I think it would be more accurate to call what we currently call token a = "token_string" or "artifact" or anything else that indicates that the = thing you're passing around often isn't the token itself but a = compressed version, or pointer to the actual token. But if we keep = calling it token, I still think we should be clear on what it actually = is.=20 I don't think the "format" which defines the mapping from token string = to token belongs inside the token string.=20 >=20 > Defining an optional prefix for access_token values to indicate the = format would work well. > I suggest a plain text label separated by, say, a "." from the rest of = the value. For example: > access_token=3Dsaml.fhHFhgf6575fhgFGrytr What is the advantage of doing it this way over having a separate field? = What if the format is a URI?=20 > There can be an IANA registry for prefixes if that is helpful. Personally, I'd like to see this solution be a bit more distributed, and = a registry isn't. - johnk > A service currently supporting a single token format can start its = access_token values with "." so at least they will not accidentally = clash with any future values that do specify a format. > access_token=3D.6786345_JGJSgfjhsgfhj-ss_s > A service that will never need token format interop doesn't need to = using any prefix (empty or otherwise), and can use dots however it = wants. >=20 >=20 >=20 > P.S. OAuth2 has no explicit statement about allowed chars in an = access_token. The ABNF in section 5.1 "Authz Request Header" = implies 77 ASCII chars are allowed. > I think the spec should explicitly say access_token values can only = use the 66 chars. It avoids escaping issues in XML = attributes, XML content, JSON, URIs, form bodies, HTTP headers etc. It = is safer (less chance of XSS-style bugs); it can easily support = arbitrary text or binary formats by using a base64url encoding. >=20 > --=20 > James Manger > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From dick.hardt@gmail.com Mon Jun 7 10:36:04 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D514B3A6B63 for ; Mon, 7 Jun 2010 10:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RUU7dXAdu3BW for ; Mon, 7 Jun 2010 10:35:56 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 097913A6B80 for ; Mon, 7 Jun 2010 09:41:18 -0700 (PDT) Received: by pvf33 with SMTP id 33so1788556pvf.31 for ; Mon, 07 Jun 2010 09:41:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=zOlkHmTpWVMC515V+Qk8VYMfAN9nYwP6wZmHLXyQmvc=; b=uKjDmLqz655wlXYwXnhQ8XnEQ7tMILlMy1quufNaDSb63QYmsb5QuZ1DimlCRVwq8J 8mbnEQ4jKBZ647vtYRXHsg9YterQR4Zd+XNaHdKOf/sgtVzEpT+4sO66t3CYCPcjaSf1 kKXloOczKaUxu+qYfbdklqVV9RJwdJLzWTvHY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=YVBoz9Ent2b3ZU/OshrHF0uXRcguEzf86P4kX0J4+ZCvNcjB3cAYxxSwzCBH2qZAzM T/M/LIlT6QWvp5Rg08Bo5d8JgTZR7Mk1xPBPgD2FBhHe7LzS/WVHKfsgef1/Ep8u9253 l1C9BlcQE9jRYYlo0HiRTt5M+2wE0DPukeDas= Received: by 10.141.15.8 with SMTP id s8mr12102356rvi.126.1275928875523; Mon, 07 Jun 2010 09:41:15 -0700 (PDT) Received: from [10.0.1.18] ([24.130.32.55]) by mx.google.com with ESMTPS id b2sm4873422rvn.7.2010.06.07.09.41.13 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 07 Jun 2010 09:41:13 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Dick Hardt In-Reply-To: Date: Mon, 7 Jun 2010 09:41:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C07C84C.9070705@stpeter.im> <700AC043-9E28-491D-B3CD-789245E30EA9@pingidentity.com> <57FA7F56-ADC2-404A-950E-5D43FBDE75D9@facebook.com> <4C2E55D5-072B-4F08-A341-7405F2F1C944@gmail.com> <77E0A4F9-9211-4E2A-B6A1-4E812192BA82@gmail.com> To: Thomas Hardjono X-Mailer: Apple Mail (2.1078) Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Assertion flow and token bootstrapping X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 17:36:05 -0000 I would prefer to see it in the core spec.=20 On 2010-06-07, at 7:32 AM, Thomas Hardjono wrote: > Thanks Dick. I was just kinda confused: if the Assertion Flow was = already in the WRAP draft and now in the core spec (OAuth2.0-draft-05), = what do we gain from separating it off again. >=20 > /thomas/ >=20 > __________________________________________ >=20 >=20 >> -----Original Message----- >> From: Dick Hardt [mailto:dick.hardt@gmail.com] >> Sent: Sunday, June 06, 2010 8:10 PM >> To: Thomas Hardjono >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] Assertion flow and token bootstrapping >>=20 >> I hope so. >>=20 >> On 2010-06-06, at 3:22 PM, Thomas Hardjono wrote: >>=20 >>> Apologies for another newbie question: is the design-intention = underlying >> the Assertion Flow in OAuth2.0-draft-05 the same as that in the WRAP = draft >> (draft-hardt-oauth-01)? >>>=20 >>> /thomas/ >>>=20 >>> __________________________________________ >>>=20 >>>> -----Original Message----- >>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf Of >>>> Dick Hardt >>>> Sent: Friday, June 04, 2010 9:59 PM >>>> To: Luke Shepard >>>> Cc: oauth@ietf.org >>>> Subject: Re: [OAUTH-WG] Assertion flow and token bootstrapping >>>>=20 >>>> because we use it >>>>=20 >>>> On 2010-06-04, at 6:40 PM, Luke Shepard wrote: >>>>=20 >>>>> Why? >>>>>=20 >>>>> On Jun 4, 2010, at 4:41 PM, Patrick Harding wrote: >>>>>=20 >>>>>> +1 >>>>>>=20 >>>>>> Sent from my iPhone >>>>>>=20 >>>>>> On Jun 4, 2010, at 5:38 PM, Brian Campbell >>>>>> wrote: >>>>>>=20 >>>>>>> On Thu, Jun 3, 2010 at 9:20 AM, Peter Saint-Andre >>>>>>> wrote: >>>>>>>>=20 >>>>>>>> At least for the assertion flow, that's definitely true. At the >>>>>>>> interim >>>>>>>> meeting we had some discussion about perhaps pulling the = assertion >>>>>>>> flow >>>>>>>> out of the base spec and into a separate document. Perhaps = that's the >>>>>>>> best way to proceed. >>>>>>>=20 >>>>>>>=20 >>>>>>> I'd like to see the assertion flow remain in the base spec. >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >=20 From lshepard@facebook.com Mon Jun 7 11:30:27 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8B793A67AE for ; Mon, 7 Jun 2010 11:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.405 X-Spam-Level: X-Spam-Status: No, score=-1.405 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uDQ1DDftAxKA for ; Mon, 7 Jun 2010 11:30:19 -0700 (PDT) Received: from mailout-snc1.facebook.com (mailout-snc1.facebook.com [69.63.179.25]) by core3.amsl.com (Postfix) with ESMTP id 6371D3A67C2 for ; Mon, 7 Jun 2010 11:30:15 -0700 (PDT) Received: from mail.thefacebook.com ([192.168.18.198]) by pp01.snc1.tfbnw.net (8.14.3/8.14.3) with ESMTP id o57ITonx032387 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 7 Jun 2010 11:29:50 -0700 Received: from sc-hub01.TheFacebook.com (192.168.18.104) by sc-hub03.TheFacebook.com (192.168.18.198) with Microsoft SMTP Server (TLS) id 14.0.694.1; Mon, 7 Jun 2010 11:30:10 -0700 Received: from SC-MBXC1.TheFacebook.com ([192.168.18.102]) by sc-hub01.TheFacebook.com ([192.168.18.104]) with mapi; Mon, 7 Jun 2010 11:30:09 -0700 From: Luke Shepard To: Andrew Arnott Date: Mon, 7 Jun 2010 11:30:08 -0700 Thread-Topic: [OAUTH-WG] Username and Password flow: no captcha? Thread-Index: AcsGb3W1/y2Y74TjSNORcvTS7rXvPw== Message-ID: <067D69D3-6E06-4B53-B9AB-A39B3DE9E957@facebook.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_067D69D36E064B53B9ABA39B3DE9E957facebookcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-06-07_03:2010-02-06, 2010-06-07, 2010-06-07 signatures=0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Username and Password flow: no captcha? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 18:30:28 -0000 --_000_067D69D36E064B53B9ABA39B3DE9E957facebookcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The username/password flow is designed to work in a situation where there i= s no web browser available. At least at Facebook, none of our clients imple= ment captcha - it doesn't really make sense in many contexts. A provider is still welcome to offer a non-standard captcha support but it = shouldn't be part of the core spec. On Jun 7, 2010, at 8:40 AM, Andrew Arnott andrewarnott@gmail.com wrote: In WRAP, there was a CAPTCHA in this profile, but I don't see it in the lat= est OAuth 2.0 draft. Since I've already implemented the CAPTCHA stuff from= WRAP, I'll leave it there if the OAuth 2.0 is likely to pick it up, or rip= it out now if OAuth 2.0 decided it wasn't necessary. Does anyone from the WG have something they can say on the subject? -- 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 --_000_067D69D36E064B53B9ABA39B3DE9E957facebookcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
The username/password= flow is designed to work in a situation where there is no web browser avai= lable. At least at Facebook, none of our clients implement captcha - it doe= sn't really make sense in many contexts.

A provide= r is still welcome to offer a non-standard captcha support but it shouldn't= be part of the core spec.

On Jun 7, 2010, at 8:40 AM, A= ndrew Arnott andrewarnott@gmail.c= om wrote:

In WRAP, there was a CAPTCHA in this p= rofile, but I don't see it in the latest OAuth 2.0 draft.  Since I've = already implemented the CAPTCHA stuff from WRAP, I'll leave it there if the= OAuth 2.0 is likely to pick it up, or rip it out now if OAuth 2.0 decided = it wasn't necessary.

Does anyone from the WG have something they can say on the subject?
--
Andrew Arnott
"I [may] not a= gree with what you have to say, but I'll defend to the death your right to = say it." - S. G. Tallentyre

<ATT00001..txt>

= --_000_067D69D36E064B53B9ABA39B3DE9E957facebookcom_-- From dick.hardt@gmail.com Mon Jun 7 11:40:32 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B3F33A67D6 for ; Mon, 7 Jun 2010 11:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.204 X-Spam-Level: X-Spam-Status: No, score=-1.204 tagged_above=-999 required=5 tests=[AWL=-0.095, BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E1DPgwQ67NsK for ; Mon, 7 Jun 2010 11:40:26 -0700 (PDT) Received: from mail-pz0-f195.google.com (mail-pz0-f195.google.com [209.85.222.195]) by core3.amsl.com (Postfix) with ESMTP id A43D43A67A7 for ; Mon, 7 Jun 2010 11:40:25 -0700 (PDT) Received: by pzk33 with SMTP id 33so4515058pzk.17 for ; Mon, 07 Jun 2010 11:40:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:message-id:references:to :x-mailer; bh=3aC83b5dPidZ4Op6FIDLMbDR5O79i1jz5NN4neu46yQ=; b=iPc8t+YMwj3GU8byb15rgewohvfkp2hk1PLqo3JgkmlFjhBifreW1gzqc8okYTfUHO BC7Ol9SQ86LrISFI1q3PX+OE7HQn7b2XVAc7J9KdnnFgFRuHBOruoKxSCLwJxCUGh7vg cRGlL/TJOSC+XLYcfAHCiqQdw0DSkY+hBZtTw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; b=vdpAI3ZA5fjDdVywEMmkbaLKHPVgc2Ki18Q858KhuMyCOHdA0Scm9bEIttLYjcsq5+ 5J4+4bZ56Q3FsdWpp/5SRSqH4BHpa2/+8gqOyIRpewx7sX4joUMdEfD4Umr3Mi+Ib97k memgaHQZKNhMN1tR8fP+djfPkA8CLzFqjzOAY= Received: by 10.140.247.5 with SMTP id u5mr561306rvh.62.1275936023570; Mon, 07 Jun 2010 11:40:23 -0700 (PDT) Received: from [10.0.1.15] (c-24-130-32-55.hsd1.ca.comcast.net [24.130.32.55]) by mx.google.com with ESMTPS id g14sm4946967rvb.13.2010.06.07.11.40.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 07 Jun 2010 11:40:22 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/alternative; boundary=Apple-Mail-1--871406722 From: Dick Hardt In-Reply-To: <067D69D3-6E06-4B53-B9AB-A39B3DE9E957@facebook.com> Date: Mon, 7 Jun 2010 11:40:20 -0700 Message-Id: <82D12A9F-B304-439D-80F9-943ECB5F8BBF@gmail.com> References: <067D69D3-6E06-4B53-B9AB-A39B3DE9E957@facebook.com> To: Luke Shepard X-Mailer: Apple Mail (2.1078) Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Username and Password flow: no captcha? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 18:40:32 -0000 --Apple-Mail-1--871406722 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Background: The username / password flow can be used to brute force = attack a system to find valid credentials. A captcha is presented to = slow the attack down -- similar to what happens when you log in with an = invalid password on a webpage. The captcha would be displayed by the app for the user to enter in if = the AS thinks it is getting attacked from that IP or whatever. The = captcha does not require a web browser -- it actually does make sense = for most of the Facebook clients.=20 The captcha was dropped because there were a number of aspects that had = not been standardized, so it was decided to drop it from the core. On 2010-06-07, at 11:30 AM, Luke Shepard wrote: > The username/password flow is designed to work in a situation where = there is no web browser available. At least at Facebook, none of our = clients implement captcha - it doesn't really make sense in many = contexts. >=20 > A provider is still welcome to offer a non-standard captcha support = but it shouldn't be part of the core spec. >=20 > On Jun 7, 2010, at 8:40 AM, Andrew Arnott andrewarnott@gmail.com = wrote: >=20 >> In WRAP, there was a CAPTCHA in this profile, but I don't see it in = the latest OAuth 2.0 draft. Since I've already implemented the CAPTCHA = stuff from WRAP, I'll leave it there if the OAuth 2.0 is likely to pick = it up, or rip it out now if OAuth 2.0 decided it wasn't necessary. >>=20 >> Does anyone from the WG have something they can say on the subject? >> -- >> 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 >>=20 >> >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-1--871406722 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
The username/password flow = is designed to work in a situation where there is no web browser = available. At least at Facebook, none of our clients implement captcha - = it doesn't really make sense in many = contexts.

A provider is still welcome to offer = a non-standard captcha support but it shouldn't be part of the core = spec.

On Jun 7, 2010, at 8:40 AM, Andrew Arnott andrewarnott@gmail.com = wrote:

In WRAP, there was a CAPTCHA in = this profile, but I don't see it in the latest OAuth 2.0 draft.  = Since I've already implemented the CAPTCHA stuff from WRAP, I'll leave = it there if the OAuth 2.0 is likely to pick it up, or rip it out now if = OAuth 2.0 decided it wasn't necessary.

Does anyone from the WG have something they can say on the = subject?
--
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

= <ATT00001..txt>

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

= --Apple-Mail-1--871406722-- From mscurtescu@google.com Mon Jun 7 12:26:24 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93ADE3A6802 for ; Mon, 7 Jun 2010 12:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.377 X-Spam-Level: X-Spam-Status: No, score=-99.377 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TADk7d9e7r9A for ; Mon, 7 Jun 2010 12:26:23 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 8B0733A680E for ; Mon, 7 Jun 2010 12:26:22 -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 o57JQGhh030777 for ; Mon, 7 Jun 2010 12:26:16 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1275938777; bh=8XirLNDD06U4bz2L18r6w5MUKxo=; h=MIME-Version:From:Date:Message-ID:Subject:To:Content-Type; b=ERxGv27+lnU704fA9eAbUglGd60N295ZmzrVgaJHzfVRuzZiRwrXVLmqyzyJuKnJC G845lipW7KP9zMB3EgKYA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:from:date:message-id:subject:to:content-type; b=nMRJY3VeDMtfgBGa5VLsPyYr0gZjNTl7FVP+swvjqLjLCaIIKE5vOpU6IZTAdBNta pGwsJ72Dm48Zqp/msnHSQ== Received: from pxi6 (pxi6.prod.google.com [10.243.27.6]) by kpbe16.cbf.corp.google.com with ESMTP id o57JQFrN030978 for ; Mon, 7 Jun 2010 12:26:15 -0700 Received: by pxi6 with SMTP id 6so1466573pxi.1 for ; Mon, 07 Jun 2010 12:26:14 -0700 (PDT) Received: by 10.141.214.41 with SMTP id r41mr12352322rvq.77.1275938774874; Mon, 07 Jun 2010 12:26:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.124.13 with HTTP; Mon, 7 Jun 2010 12:25:53 -0700 (PDT) From: Marius Scurtescu Date: Mon, 7 Jun 2010 12:25:53 -0700 Message-ID: To: OAuth WG Content-Type: multipart/mixed; boundary=000e0cd1a89a6e7a66048875a5f1 Subject: [OAUTH-WG] OAuth 2 for Native Apps X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 19:26:24 -0000 --000e0cd1a89a6e7a66048875a5f1 Content-Type: text/plain; charset=ISO-8859-1 Hi, I attached a document that summaries how native applications can use OAuth 2. Feedback more than welcome, especially if you have experience with native apps and OAuth. The current Web Server and Device flows need small changes and clarifications in order to properly support native apps, I will start a separate thread on that. Marius --000e0cd1a89a6e7a66048875a5f1 Content-Type: application/pdf; name="OAuth2andNativeApps.pdf" Content-Disposition: attachment; filename="OAuth2andNativeApps.pdf" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ga5oup1t0 JVBERi0xLjQKJeLjz9MKNCAwIG9iago8PC9MZW5ndGggMTIyNzcvRmlsdGVyL0ZsYXRlRGVjb2Rl Pj5zdHJlYW0KeJyVfUuvrstNJiizxYAEiSHSHqDuRkIfdb8wRCEJJE04ySEnkPQMpRFKkNKTnvTP 4AdTdr0ry+WVdj1WpGxp6fne43K5XLbLl9++/c3Xb7l96bV9+fpf3/7267ev3n77Fr70mb78Zv0b vvz6rcX0u3/p779++7e3b97+4y1++b9v6cvfL9S/v8Xw5X++/eJ/hS//un4ev9D//s///t13Pn75 /q3w/P/7937Ffwn0o0XQX30vfknly9e/Wp+iv8YvPX1pPb/G+PL1b97+xx+kv/j634nY34ud4dX6 Af9zCx7DOMA/N8EpvVo78N+Y+LyIqQf+hya+1FeOB/5bJr7G1zzp/1MT39b3s+P7ivHfNcFjfbwc +K8sfArhAH/fBMeiOW9SnlLUK40mPg/9fXOxqaZXiLgkpHYu9kc2uGkZ/mcTP8IrnDv1AxM/8yt3 nJk5rO8X/Ezl2PX3f2ri82JmduDL4s888D878XFo9bH+E3lDf/kXFnZkif2xCR0S+hMLOsdrTon+ FwsdY1LwY3lpAfTyIismxv61hR3rk+OA/9CEj1c90D+y0Ev1znLAf2zClxTOA/4DEz5fNR7wb1nw GNJrXWsS/10bvzTAwKmPMb5i8uDzq3YH/XEJ+fn9ZOJTfcWT/j838Uu66vn9n9v4xZ984L8x8SXy IUVFLZb+Gp79reE1zv39Uxvf+K6Ev9+20hP4v7Px+RWmQx7WXVzP7//ExPfIN5TA/4uNn68TbioR ur093F+aIZ6f/56JX4e9eU7jOu39PC1fWfgU6mtMnP60Tvs8VdvfmvhYX6Hhyorsj+iQtpTKKxX8 NKZlWWbH9qZc9Wmx6V+nd578/76NH1r67fUuyzV6+F/7K530/PKX5g9a0gJkE7SO40gOgVvHUV12 pkCnPrQAmeozjcWg80Cad28aWV93/2zjp0+g59IPHn4ukydlnD85lFc+BeKnJj6GV+kefHvVgR+Y vFy9cOL/2MYv/hScPzkt/uDaP+fCniEqnrks9pzsN2+jXBLZ0vj5yuvAZ4eCy+vAF4f5kGt5FYf5 kNd17RDnvFwsZTfb5Ld1Hw1cP+deX9Mhbeu0Fwf1o2tb+J9M/PTdRnkWfXhN7V+Wg6gOr0l/CU0f XlM6C93W0fF9uq1P+v/exKdPt5GprEr6dBuZwlzotk64Mi/50+VlaoeybHN1ek3tUErFhaGUTzeX aQiX+unmsje3frq57MXWydER1BAurWtHyjyLpWft2Nn86U3fjDY9o+jv28IwmuaPzU+62T38X8rB JQ9LOSjlY5pudSkHxX/z8NalHLrjJl1qvE625u9uSF9680CbkrZMqnZ+3DxVi++Lbgk35WwZVOmE 28GVTuEJCTdVcgz5dcJNpscwScNKvHmjcDTD8/24mOOgfllT4yTHdkeXNTU6zsyYI5lT8NbG3Ml6 wekh82se+EuwJFMwQOIvwZJJhwNfb02viItmXN5Wc6yWbK/m2F0yvgZ+DmNPr4kf8rhcrZOXdmBr sD6T+H+8hjI8ok+hjInLGoUy1FG0PUUyjk7Z/zM7lJHotQDeXQ59nOs1Q8xpnd3ScP6kdRaVKrFD Aessdgf56yj2U+k3IJKBk78cleTQnBTJUKrKdtQbP9bg9CxPRakemx4yd07+mI5uWuZOcqjm1CfZ yhI/7MBE19+3I1tz2crRwZ8FHBnnTw5J8/PbNr5pfppx+LxuUvV901fJ6yZtjvVSYKJnXP3kdRxH wdUPRSYmLg55nd55agc7LlTKK3QH+TW84kmPeRfl2rQlcIljTAq8Svx/twMHXX/f3q51HJWlYaqH vC67eeJNS4AiDUqdmJdpXt7HcKifPPntEufnbPTMIvGmd5nXbXqy8xI5iNqwsp3L0LUpYztz63Js uLLiQMMB/46E52WHa9eG1OF+5P5y84KW6KS5P9tN7HgpuP0IXFghCLj9ThtocRJuCsDyJpe3KuGm dREpTjxxamIMbN0JvGld8LNrxsknx4asQYE3zYuYOltfMP05U1xZ4m3HLLfXSY6pPmKhHAOcmmUc leSgpnIUHedmrXq19jNhi6/UDrztxzXOTJF421Pp+3KG6V/GUT2F3zR2yPdQ37+80k7WrvB+Le0a o2O/9rOrxJvGTgqLP+d+mcZOWqdRfd80dtI6jcOx3pSy1ia2r5XWbXLKv+1r5USBdFge6Nk1nfwx bzdKQ0vnes3rjZ2b8/vm9ZZKo2dgiTevN3JuBi6eqYWXQ3eya9Pw086uTcelmV0bx83Frorj6kqU TRUd7Bmc4iLx9pvuukoVPWZkIq3Tq7SzbQsu40hJg/1IGIper2270xut47bIsbDrjfKf8gzV/trr XXd1nbh2YNfJQU5adlXDlQl7Wg47jF2n7GA/uU7VQU/p+rK4uEKBcoBw9i9joDmUc66DPVdUeeZl DPSBK0NyzaZDOnukdxj4NOYRNPn2dpGnVRzbRbaAg/vLMcuOqyIvJ6U4TKuylEN1XI3saWWc/rKU iTIlbXqW6ZAc5MRPut9+0k2fdL95eMtSDsVhaZdc2HGF6c8cskfdnFKy9gFN4S9LN2TH2eJHXdzO KOvoKjvS9qNbo+wrnJsLGJpjub1p9lzegKdWPaZuKGNo+s03ijKrpt/kD725VsdVVMN+6kTXS2+0 rePiVmPiNxB0v2rkhA+YHtqrOkn/3CNa+w1YoE2t/LwBC7iZZva8AQu4yfe52SLgphjMzRUBt705 SoHvB/7yCDwoZVvibe942WvjpOcSK+lsbwq8HYtZ3twcB95OSovLnSvDQRDlwDu2Ky53rp4MujzT Rn6bgDeAcuCzg37KgT/pscMfShousRXOg8GZs3RyPJlvv0m3oY+WHarqRdNjM3PZX6k4mDlY2eD8 WWe9RFw1xKXDa8bxaXlnreL0p2WAObaXQjHDsb0pcrUVTs6yv+a5XNs5XgZVOfF2KGMZVPVkj+0c 07Ox4yymZSF5ziKHVqZje+sOVcHrXUAl/nbwYJlU6rjboTBKk5sOeehBX3XfsfGckASzc1lg49xe 802D89/P5dqxIXpXKY7jQtVq1cHOuWNVqPhTbGWeeNvZXXd1yLg4U2wlVpw/FFsZDlsjp6jXa7uj dLcnnJ85B71e+5k8N73ey7v05LQD1Iqk4Ep3HF8KlgzPeuv2cNDjmFtwbFbjaiyc+J39LvF2oLCn V0oO5vdKj5zwYdzp8jgvd7o8bNdmyvByqH56w1aq8xKK2a8OKP0lVI5NoLqB0uWzQzbL0g0l4eJT 4k6RQq9eTpd3+Fwl75QnVPbLOuvFcTVyunx38GeddeWH2PtV+ZUfFZ9SC8dR4e2tXasqe7ta0Jab vdzWHXtL2e/Nsdj+Sc/aezsSp4+hLhdFVvIpm3ZkaGez4/TPzpEV1IflyMrAN6uGzmFadLMqpY+d 9JiRtpq06rQDSam9HNys6+QGhyap+ZPmvMZ5Cley3jnfB9vLAm4HergAV8LN+/8J9Aj4P5iRm6q/ bifF7GdgAbdd7+UqknEq8HZC9RIyMtZQcjiJJjnoeaoDBN6Ok+zqAAG3PfunOgAm/6kOEPhLtn/h LAtUdCjMEx3cKVvfC7wdKKF2JwfcjpPsXH+YmXWwrQYzk1JuhoM5y688Jd+Okiw3sUYPfrKtBpO/ 7pM2Hcynvgjn9+0MHeo/5aGHbE2PrC3b0SP7KSSOuaJHkasJHNtL1QEnObbbHfcbucDbfQVSYdsF Xm7ab+So+KS838hh+p8oEqpp36NI6KWVyuTsSYG3E4DWYc8TP+1pnXZ1vOyoGUWFTtV5ifLsR294 v9Zx7yf9lzBP0PTb4jy4iw7OH3qRcVzU1BbhFE/bE10X9XSQ8x7lEfhf2FGbzDFm9CrirggTXy4X H1RcG3JXhOpYb975nKgVRlEepU4uKTeTozCo9qe2CIoeO1CyuyLg8rBcv+pg//L8qkM7cFAIXmtL /AYP7y2lzxQH75XetD9OibQOxiwrQDHmkjuzU5FguRxDqzVbLncDBVhNPQ0UYLnhBgoOE/JpoCDx X9sRnsp+nMDb+QlU11BwfnJEqOHiwA0RGi4PJVd9zi8RpE8egr1fxechPD0RcHrqJxfhEkLq2oi3 6aHM24IrktIqB4Bx/NDyb4ecetH0XHooJO0g2/zZvUlx/o+hnBZbHCiI5GA/t0RwXNMcRDqXe60b WoZt3Kkz17qhFCgkdze+nrohAUfqhgQcqRsScKRuSMDNOjwKkajPX3NhqO5Q4G2ve7d3lHjbr1yW VziZaRe1Lw1bk4P+tNMrUXZyq+J54O12hzlzWbXA2+0O6T3u/L4doio7v1Lg7XaHdefKw+utWX/f znWqk9MTYPp3e0d8v3Z7R4m34wy98w0Br5eyYU75sWNgy3HKnvUux6mc/LeDYJQNEx30z8Fxd1T5 UDYMxd0F/p4Ogx93ym7J+O5yckvCV8s9FDrOTU6GyQ7urNuhObQh1xl1B/0U9kgO7lPY4zwtl3aQ jfNhUemkbpDRoc3fwx4wf54wBsyfJ7tF4O0w1bJ35knPJbulae1v84fCHtXBf2qi0HDtT3EPpW0v cY+uta1da/HEMQTe7tb4xDHQ/aJukB1nD1UCKfG3uwXSg0PBjztXAjnELZfIUU7UOMlll73C9JRd 9orTQ72JYW2Va9WGp50e0qK2PK+RjFwc5PfwKg5yKJbhuOo4mNFx5ZCXc9McphV1gxzRsbvL1FaH /dLdMfATAmpqUCWQgxwqBIoOYS7USA7fLUpu6RFXbRz6cBhiJe1+QahwljQ1PZfCocovDvD3S9SG 3gXf9Pdt9q+zngYunWUd9jwd0kN5ro7TVVrRp8vOttntI/H1LuWgHEczZF961fTY8jmiPu2XUEbh Fw2Y/tFdjlqhxFjHdj01yuh2kd6nYCfSzGJX9gi0eek+lT0Cbp7zsS1OATfXOXejAAG3gx+DmCjQ l8KeyE2UBP462yKc1FyaoJTXyZprLKMVnJWU7qHIsb9PsY+TPbZvmXYpqsBf6oZy0ASZr5zvTVkE /hJcaYqf9miOkvV6bX6WyheuwF/aO0YukxJ427enZ6d54E3rmvtBVgd7WuYrDt7ftl/9BN5OL+rc 3ByXt6WSc3Lwc+zcbni9I2t67Fjb2LngsDyMya+Q8P5SLOaA201BnqYv6HJTaOrzduFKGHq1duEQ ZS97yIn6mrBd6ce+QzU5ZaCkgW8WtaBRl5wdKiH7ruCHhVrKTAf3yRw8P29HSkrT5FwSUJK+ui4J LvVVHKqcWtBMhzAs1TMd1zrltwTHvU6BnjgdZ4uag3uE+bHWYOmZO+wNr3fusLfA26UToXIkAKWf ElwaLp057kAGKvxc9eSgJnZ91s3d4vQWnPmc3eK4Vzi7xXGvUHZLH/jm5sJDk+B7Iu+hhzj319kl Vwimv+6UbdSCz23nbMP8bDtpGz28VJY0mkP4R9R2mL3ewWMqYLOcx3hUhzLkwiTPaZxTG2LXwqTh uLtKjPpqv4R6HHZDWYe3OG4u6uAyHdJAgRjlAV5yUJKW5kvV086ZEHgz7Ec5KLk68JUnJsGnhQIx 03F6aS5HcGg3DsQkXPtQYKU5rkbq+dId4kM3tUc2qZDJQQ1lrHikeZSXZ7OoVZyDmmUGKGquUZvc 8b2qSzGUiTOzhuEyG9atWCbPyLnL/a4DknDT3h/cREzC7Rkh1ENMok2ds9heDvR14ulJ+WXkR6VH P4m/TEjldi8SfwnzRCqFkHg7hSBy2SdOTwpkm8IbG1Mj2xTeWY7ynOu1o2aZO91LvJ2is7u9SPy1 Dqg3B/9L99FTk6bnWgk0Tnm7ZZmVPaWQsLcsM4qjr3PIn/1vJpZTASTczjLjuKyEm5u647ISbodx KS4r0WbTAWpOXeKBvzenPr9vB5ooaezEX5tTk8Sjq6XCuuShn8boJA+eTTSJtzVa4dFg+PcLN+PG v08Py9PBTzoh9cDbcfTGTT0k/hKI7myj4QRRtdy5AZfROGyjSfxlNg7345Z4W8WOQU/LOJ6yxrpj gykLzCHQuyeShF9G6XTWyCj7nx5K8PnlrLETb6f97J5IMHuenkiwODzVb/h6M3eIxddbuMxC4i/V clxmgdNTt7EGi0Nlaw29K9I6vuq02OKzgOEUt0uLpqlPrx1r7VXTY4vD2AYbzM7BOeM4f+Y22GBx nk2Ls53YErg9HyxuXC1X8PVSNDHiy6XoYEq4csuJ+27A25WTQ/NzP6Tq4E2uWjXYsbVlzLbu2Ktl nKqr1MbXTBVJsGqg+b7Bw/zGJRPw2eWBwMWxWZ3rqmFTg+f0nMJgTmmbgXvopszYP/zPiyMnwZcB KpFLFCX+UkhAJYoSbps8mad9SvzlaTyznAm8PT+FUhmjg3xqap4P/GViSWA5FvhLt4VGlUg4PVRl GR30LLkM3cHPNvV67bflvh0igbfflnvhIIPA22/Lg8fvSbxdx5HWocqTUtJY8P/fxYOW4JuxHzgQ JPAXd7jR64LE25yskyVB4C/9TyNrHIG/zq4h5wOmf/kG5HwI/MWX6OxcCvwl6yGx8yrwdrhj+RJ1 HPhLp4v46g72zM62OCoOlMUwC04O2frhZP+l0wV3WMfpWb76yPh2kW8wpoOexDnasPjQqJvWcXGg PIN44k0DI5Wij8tl1E1j3wAVNyop6dPBz5r08br0bx2UOYDLT+MxqhJvjz7q8eXQVmmd3pwcy116 OXdcW1EFijpe9iSjddqHQ/ukwXMMcXGeiSMBMH8mp3XDx5H6sarjeJml06lPHUw/zcZR6730b+1a /dgdCJZ6UMfdtn9TZVdd4P/G9ieiPo6XEpdOeUI4fwqndeP8L5nqe2F5I38luL4/qb4RVofU2cNF z1Inih674okcCcf5pdwHtb+XBhyVQz0wfumT5uHn4Ikc8PVO027Ueu1QPNmRVEUJ25Ef4Mv872XK xuPjFzumcgGExJutAilo3E/8xc6jjDcJv4aMSTAF/lJovAVf4K8h49oP/CVkPNnMhpc7K6U94Oul OUYRp59CxmTWCrwdU4yclgCvl9JVc8TXm1LgoJnA23YD2XknPfbFngbVEsLyQDHjcuIv+add03Pt u9+ag59lGz7w9ytnL0u8bZdTb9KGyxuVGreTHjsG33Z+gsDbdnAPmh57f3t2MKdPTYwt/KPqw2sL w+DGpriwTa6rxpk/ua4a1s0UYZ4OZUXD3ZuDnzlyXTVMf47c2VTi7Shq4n5yOP2JB9hIvB11zeyD w+Tk7YPD7CnbB4fJLzTkDD4q1HM/nNy/5EvWHSSHt6sORc8l/5SykeGbiMqMU3JwvzdK3cfxy6Ur zSEM6/B6bnaaOOhRDpmaJE9cemi2u7rZ7QAgmYSR58GDJuEHGDMJBR4yCQUeMgkFHjEJBRwyCQUe MgkFHjIJBR4yCeHlPiYhvN7HJETpoR66oeP0UAVTPPl/mXK9TUKBt6/02PhWQfeLQoXpxF+6yVRN zyVUGNlEhfmZK6clwd8vkdOSBN422R6TEJWHtO6JfB6va/eZk523miQPMRQnrA5haF0Rcylg4rJn XHYeixDeK7IIT1mwzd/JDYNhXfJu4aGylgM3DIbpf7fw0O3KYfI7M7pesvCUbrBtmNg1PZe5Slyg hq83NU3PZQ5T0rrh0qqmcpwZlbdcAseNYf4XniMFX71sExaH/FSqIsDZWbnBME5+49JknD1taFV1 sSGL0g4Xk3BH8XB806f30nom+U7vbPr0XkzIqS2NiwlZ9em9mpB5dgr4YCakAEOv0xJvvx7XRGEA ib/U/A+Kt0q8nVxPvso48HZeQONG6xJvm8CdG61L/C01dpBRKH9wKbKPr3zAL/0OO9mEOP2TezRI vN1IP1AHMQm/mpAj4qtNS4JHx7eXiuDnxJdLcxhOci6PzZ1qCPDP50yP2Tg3l9ZfRhLOzsKvBxJv W8CVB9jh31+nKxcHf9RRuVuEzcGcpfOT4yjyU7DnKPLbruMo8tvuAb80F6z0FAYzn5oLxoyTQ0+7 ceKbRU+7wyFsNIRhnsJmNltnk+2kx77TE3WTgW8KakbYqmO528LDl5sHeX/wTTcDP/715wq9ZjYK 8B8ME7xM61kOvH0l0ii0E39tqUxXrsBf6s243F/iv23jCytBgb+0CUr6+/aTaNlKCl5vLRQflPhL glqgBC+Jv7Tx4TGbEn9JbeRhcRJvJ+RRuX898JfUxsR6QeDt1MbOYzYl/praSM/wAzYeP8CY8Sjw kPEo8JDxKPCQ8SjwkPEo8JDxKPCY8Sh+gBiPAg4ZjzD9j/Eo8IjxKOCQ8Yiu9t14RLf33XhEl/sY jwIOGY/w5x/jEebmYzzC7HyMR4GHjEf4+4/xCPNHHRXIeISZ8xiPMPMf4xE+iu/GI7yAbTwKOGQ8 osx/Nx5Rct6NR3Sz3o1HmJ7HeBR4yHgUeMR4RG+Kd+MRXu5jPMLLfYxH9KYj45H6klTUePwAX+aD PMajwF+MwcTnSuDtOpHHeBR4+4qm+q544O3K3szzFHD6qb4rHXj7Riw8T0HibeOL6sFOftomAJkw 5/cvPSlpAIOE322vZS+HitpeH+CLbbRuh3rA7V6Ui2Liu8Bf5ohwlYjE22+tu0pE4i9GbyA+Crht afbGlo7AX56WJxV4498fnKAi8ZenX+65IfG2WE7uuSHx9jGc3HND4i8F55meHmH6U5gvJW0XUy0p absUnI8DfHn25eZ6En8x6zgFGefNstPSxGUh5all7TJEpFI5tcRfMgcnX+UwPZWfxfG9IrvulDXb rF5eUxmO9VJDLMdyybJrjs8PfhWXeNtyHJMeUXDRX5Zaaw7x3BUc8PefCg6YP1Q9XvHdpeLxWnHp 54fcjrM/J059hNlPltesDvas0xW6Y72F29nBmpaaSyrtc2kuGV+e3aL6iuYgn0IYJ/nX3pIx45qW 6yuyg/29cnAKXm/nvvn4ekfSF6+dl0CNzLpju2j+nkN50lCQ5Di9bLAt5yPCBtsHGAuWCTwULBN4 KFgm8FCwTOChYJnAQ8EygceCZeIHSLBMwKFgGUz/EywTeCRYJuBQsAxd7XuwDN3e92AZutwnWCbg ULAM/vwTLIO5+QTLYHY+wTKBh4Jl8PefYBnMH3VUoGAZzJwnWAYz/wmWwUfxPVgGL2AHywQcCpah zH8PlqHkvAfL0M16D5bB9DzBMoGHgmUCjwTL0JviPVgGL/cJlsHLfYJl/7+b7vc0aKTBeMunIOzR oJHUsIKmpfbfr+a/NLH9wH5lYcc4sH9nYZeeX4pSwn9iwanZosL/k4mn5tMn/h9NfDpp/64Jzly+ K/HfmPhlsUjwj2ywhy0t4NvDhQLnx79l46vGdxNPk0s8e/RZBky2p1DwxaZ1aCT4ZyY4Vb2hpvCm fIJ/YIJ3EyOYLdQXLyR8m6jGUeHNbeJGdx76170X8oH/nokf5aV26ocmflb9fXNnKWlb4c0DxWMk TvzXJp6C/Sc/f27i8yf+m/ykJGZFj+likLauXMPCWDNLZPmNy+SQcNNtX25jngfcNN+WfVLqAbc7 WkdKz5Vw84KcXEsg4fZIeC4uhWmnKWqKNXbonobSNnyxPBJ+4OTzGLXs+H7i4lKJv3T3HeS5SLzt KOd9wcL0Z26/KPH2U0UpVDUn8deXlubhP3X3Hbi08Yj34lhvo1i8hNt+bBvkt0u8HRdYSrZnB56m kFXHcpdSrvHAX6aEBS2e9ovnbOQswNtFfnuquDhws96Kbxc36424eqAGXqPh6oEaeM2BywM1avCQ kyZZ/fhyl3ORPN/PlRoY4culQWHDsb2lvzzkV25zACs3qslr3cH9dXi747Kg0IA6XZeyvE+X0aW3 b9b0XDs1zOjg554gj/Nn8IxOWPuQyeZQbjwQ/sRfBshnereF2U8WoZL+S1kevyPD7KHXnJFw8Xl6 AeP0p6z5Y4fj06e761LGV/XxurQb/nR5mbnGuXy6vC51c58ur8tosazF/9KOi9+S8fW2pG29y8j5 oW09W97Ig3Lhp/6+zc9lmHcHe2ZUp/cCb+rr97Fijs0tyxIYDsukBO4dCNPDY8iGg55YtWFrXo3P SHh4s8oeGYrTnwM1QYMtvaK8HJuYEqjxm8SbMVWaB6+cNNPqLzVRswacHgI6RLm0rC86e3OpaX9y 0NN59jPsRfGcMIempUFh2aHZaF77cNx0ZU8AxQ/XngAK3+x1TwCF+Vlj1Iabud4aOesI5idPmnfc 1HXdvOowmoe90s3rWO7O04TJp1AP3aXAydqDzgTa5OPgPhACbZI9eHKmQNtxGxpzJsBm2dPs9OYm 0JdR9pleywX8MpFpvjK8SkoCJivhA34JqPBcegG/j6WfEn4Zh8YFdQJ+Txie8PZzvrCDGLL/cAGg 0rQccb4XftgS8EsGR6FMM5gzdT9CoLTv6fUw7TQ4okv4ZQJTYjcblZk9ih4mZnBJI8zIwUnpsBDM oHSGTfvk0Q4CfokvccNulBgKF40KE5PWtXR8/BLL2QF/kO0pDrYJUNLJPsQFkjJCRsOJWYpgdlgG qD/nqTfsuEae6uxdcmzzy8HHMpW0272Dlh4YuDzS9KdxMMbscM2j4Q/G2I2J+rabUcZQvKfjbO87 nvEB/44Nn0rLXIND+dC/3YZPeqeCD9Os7A6BQkChoTRg2inHJOMCmcPAKaHp8bhFleNU6vGSXFKV TWVHwCjrY8DCzrPmcZWUM09jEPDLtKegDCU7OrJ8xNNQsoNHy0V03MCU2tvxWyy3qLTGJbLTqTAM 5vuTUYES04s6Spev91eEDx5Vpidc+1KL9ewQGZrdiJ+72ZSZf2nMlJS0X7KLhxLfy6j44HFnytID BSd9OZwVv8RKasrUsMMVacflwUus5KpMDTs4Q486+CVGI+gnfomV0imHHRWwZ2A9qn6fefXo4Sgt KbvHDoPQe07EGbnO9Xmjmsqdhs933GajGNHAlUwZVakw++szqaNq7+rc78jgNtXAha3oTUMj4c87 2GQkD5LvsHKv62S3g5F2Pi4FkyLOeArekDU+gIPdOfVYwu2x15GjYAJux28660cBtzNpAsdoBdwU gbnfUgX8NlR7xgNu12wug3Cea7UdSRoDOg687fDT29+5Wrvb8xICRb8dsko8WA2WBI7kDJz7MfMg Npw/TywH3a5nTj0sPFT6PRySTwU5o+Oi/x7Pgfm/HLkYHfS0ps/WdeRi8qyXQkDDsd4+XgU/6u95 PTD5FATqDnGYPFkVZ/+c/ECBsocDOw0Xf4rs5PP7dqbFkweE8pO6bc+E8/M9Dwjlz5MHJOB2osWT 14PjB1siAn+Zsxc4aw5mf8la+u2gDc34Tg72UJCnOMSHojzTQX/jmhxYe6alHUrDj0tap706tAkN +W7Z8f3x6fa6NOju+nhdyrSzFufL4LygxPkys3stF+cOFWm3hksPhXB6x6X/mfENSwPn6Th2i/N0 zt2yQyG5uqSH83ROesy+KByZ6fhpoTF4waHMKZQTHHc7xXKiw1ClYE4qDvrbp8vL3q/26fK6js3L Hv507hEB26pU1h1O+bSDjGO/TKDaOdPl7tC2TyYQzP5lC0SHsqX+3MmhbCmzJw98u8q628fAxa3Q 3X4eL9N1KSlpU9VeLyX5RlwcyjIGukM9UDhoOFyRstTJcJiqpThuolIju/Yw8csS8Pi8Zd3syXHW S+PeRvBNV/onv8umv/MAbPjsFrrZHbJMPr6DO3NnmMKitk66sgPMJyiO8xScOzVkjscJvPkIVcMn zWzn6VCDt4yrqhqHS5VQ3pBHlZANTMZGA2jphV/1BdwU5LFT5wXcLvnamUACbuqoJxVIwIFcIIG2 Yyshadov6UCD2tJJvO17x6ipt2MrkZtzwMyh2FDGdyqmrXIE/pITxO3UcPJz5FCVwF+ygrqPnhI0 PfZ2kbk5Pd+fbI4IvF1zVCvbFwJ/Sd6JbF+gwky9WmZ28L91mn4DH0Wqxy6e768raJzfv2QfDU2P vV+Dh73ix2vwsFec/qVM5nQcr8mxEvR4cUlZwsWNQklp4OykUFJ3aAcOJR1wOzVnXSkh4tLMJWLZ sdzMDc8l/o9s/K6BEvi/tkM9OzUcpv9JDRf4yxy2obXPpb1L5JdZgW82fnCoBKZ/3dNz4NqE6r09 2o3K6D3ajWarebQbh3o8x+UxCVHtlh+TUOAvRV+JmpfAx4uDQwfcjn3EppXVL39lB2/Cy8Eeig0p 9l9ruLJDfLjLQHHQk7XyvCTt7EAzqgxpOG/34GvW37+OVsunNrlO2x0efA/6+39i4zO3SoC3q3dO 9YHXu+zy6LAdaBab0raXUNLkQDlMD2XwOGxJGs9bT7wdOwhd+yGXWExwmf4lZm3627GYOPVtZw7p pTnE2bG/haamnvtrhyeWba5sZ5v/ZTvUMD/XbR1P+k1roJTtgAu8OZ6n1F2vD9PfMvcDgPnZprZt 7YBG301XBN6sU+EcnQNu9l0po+jPm5H+si7r6FnuOo7JIT41JK2u7DqoZQsXx+3CmTe4tqq7fS5s C9ToOLqcpnOqEtMSqIlbduKWQF1nVwVw7GBYLtpRuAaHQv7dTEozENb3e6qA24lD+zlVwO2OPYG6 Cku4nTi0G0kJuJ041Pg1TMDtcEnYb6kCf8kc2m+pAm+7l08mkMBfMod2vZjAXzKHiqbfdr9z4Ncq gb9kDmVN/yU8xMN/cf48ZV3wfj11Xaj0xBrZ4Bd4O5xRtwMC85MygRzkP4k9MPlPbRdMDkVjTvbb nX+pw8/JTjuatyzC7BF/yuh2HPY4dy0rLG6za2VyCd8UfjxGxYGGKajjZae6UJXXSb9d4kNlXic/ L/GbwhYMqmvp7SB3nP/Uy7ckXB4oFWgmXB5ooEIouHqjVJ3kWC5l3jiOFxVkZYd24PDNcIhDj5qe S03WLuGC19unpueS2dNw1c81Wc3BzHXWY3TIDo33jDg9FOtpDl1IDXu646rLYbrsmEzPfyd//tjG T060QPnJLSI7LjyZTIHz+7Z3n7rWbZdgT9Cmj00PBZO6g/+5aV14oWdqU+OSmNT19235qVnr2ktD oKFNpXvVmIOd7ZPqt/OMKPjUHN/vu0UOvF29vobr+0Nbejb76aEo47qWglXDcVVzbdpJj12pQfMp FIMu1WxdE3SJbmV9V18K2ia/pKECQT2HHOq/xJ0XiS6XWhQpr9F8aqEWRcr0tPlfcta25yUzqWlb +JKZNLWtestM4sQCeL+WK9KGg/5l+/TzPrLL/ig5qeAHgMrVmkMBlVa1/ry0NYqaHls+e9cKy96v 5bsoW/WImPye3vU0223sMqsv1qcJ2jnpmz/7lyaWq6wk3Lx1qaVOPOCmEOyiLAm3myfz9AgJN0V4 cqK6hNuRG85Th2mfk+wR+OtPaEXibV96h1Yk3m5NElkfw+RzUdZJj918mIqyTm5eMmMSCS7On8wK WeLvHXOSY71Lny1nCOfn0mfVQX7lxxh8e5dv1k/2XxJjGuVV4fRQaGU6tmsB+3SwczdPlvhLYkyj mkSJtyNVk8dxOfBdf//SPJnHccH84VCJB08tEE+86T49HXFg/lNLnIRrzieyAqvOJ7KCs3NZI2Xi 4p/W6W2Oi4IiK0o7XIqsPl1El1GVhd6C8fW2T3fLpXvyp8vFDq00mkuEwykSc27vZU5Sb/r4Xoqs pqLnElxJFDzAxW03T8bZz82Tcepp0MG52kvPm0hxP5gcyqMJGVcONIapOu5ebpRTcXHg2Ipju6iz TnRIA7XWSefpsrvf5KLv6ksmTaCnVIm/NE9u5Kvg+1XZN8DXS4MRPPtLWbIZF39qmaOOr5341LO+ HG356Z8ur0vwIGl5tksYx/DJz9SXly0O625X4mOTT43xOr5dXDTVcfY/RVPwcrkdzinOl9hBcIkz dcRpDtOfiqa6Y3vLTmOFL18qgvLYnpR4o2xPU51QIs2MuDw8HZRheXs6KOO36dNCGd+wHrR+vhRO Na1vL4VT3EIZF7jxyTeyC62m9o3sUAY1vHGoh7KfTuDv1/10AqtbapHTHdZGjenlcI0ovLJH1N6P yi5UknCgUEnCgUIlCQcKlST8Xqgk0UihksQjhUoSjxQqwZx/CpVg5uxCJXinnkIliUcKlSTefO55 Co/w5eZJ7xkSb6dOUHjFAy8crYKXSy1vDripoGLlRHuJv5QpceI8Tk7j1E9cOCnRxbO7O9EFPlo8 NjI71jt4Sji+XbtMCf8+NTI+13sfZRVxfnLdkeN00QzqXHHlQDOoHeKQyGBrOHsSGWwD316Oxjg0 Lc2snriqSsvdCsnx+aVLlKq9BGOCVrWXDjZNL9emn+y1k/2X4M3QuvMSvOG+8vh6l3vWqkOad54L Ls07zwVfr1Lkl1bFnOci8Ze8laLv6UsN0Ta+UDvgyUOBN+vJQ4HXy3ko0fH9xO9+Ev8LO5bBeSIS f4l9NH0z2s7rzvuAhS0XbqACC1umlNHs+H7lClVY1WaaBoDbJdRfJjh0A/WXic2x3M4Vqrj4dO7+ BZvYeUR6hsfpp4LfiOtmCpXE7qB/Fn2TXvrRdM2fS9GRtvqvWRw14eSX5Wqpm9T+PqVxTFwcSuIs F1jV0uQoZYhdsjK4+ZfEX/oHU/MvWDlTUobDLqGcDOWN2hU+dccBBP6ac7Du6iXPhL3mHORBssCf BQo0JBwo0JBwoEBDwoECDQk39QEN5+kH/NJ6lafzSLxtuD9ZBDh++Oghr3geeNsNTYlvT4G33VDK 4jzXa7vR6/yd5NvTi9ZlOyK+uewVn9+3gwzLK54ZlzVqxxFO2bzUZ/CgHlj0efROc7Cz7cgXvF27 oEPizdl2PH3npN9OKqHxO83BT7o9T/rtrIaZ+V0Rloc9glni735rxY8jZR206cF3zgpAjy+NYFb0 mMf3ySJA2fOeRYCK23sWAczOJ4sAPY48W6fi4kwjmOf5fbt/BPXfn7h4ppo5TALzk2YwNwd/aAbz Kc52K9udRQDDKdkvOaSzd316L/UfU5Fjhw1GfRUHcyY3K8GFZ366imzqZ9fcuTjGWZ9d21MJ+9EG 1W3cqbXhwsYTmCPOH57A7DAdcmr6cF0LLoLDbuMCinO9tqO+Drs6XPZ6KYR97q/tmRXudwfLZ6a7 HZf+5Uc7aCcv2mHU5rbjs/j3J3uhqF3y7nXDezuiOuo2+aNoxWMfrRn0Ub927mgOvf/MX5b46/Qd jxnJ85Sr4/t7njLMT/KKlZlnP/CnT/fWpRPHp3vL7gJLCQcOs4em8MyGH112o8/1mjFLrlVwHHWq VXCYMZw+4LhHue+qgzvUdjU5dqsP7WNepuVEfVrs3R37rRDercGjf/H10sWe8d2lRqrNcXFx+kDF t5cbr+K6k/uuJlw5VEr2cyhPuuN2FOzO+r6zbgXcHpoT+ZgIuD1ReYceBdx0Fne+gUCbxuncKkTA zU2abCkLtO0nUoJoPfCmZf0ehhF4+335CcMIvB33oOSEiG8UZyfkA38E+ihyoWRmcis9hgYLSjkn TaK/a6GXzV6qRH9loWMIEvtzGzvIN0QJibFR5ELAf2zCqbNdlvBv2XAejCng3zPh1IVWon9ioilb 9mD5T204P5AJ+Jnc9glfudBc4L9twltU1Nh8pwhTwSVgl6kI+PdN+NC7atO+xPFkjc1JKgHDl0rB nJOYn5nwyA+TAv6NDZ+KM6YGWCeauqvD0fgPMBCL/wADkfgPMBCH/wDbqWmd3qRBMigGvzj3gbZD iuSmS7Qd4NwNjz7QdrSeXHTJETsYvceqgfyLiXNUP9D2hbVHqn2gL22X2kuKiH1X7cI9dHOoI1KB F0mP2/hW7rlooGg/U9E+0PZDCum1LND2MwqNqe0w3SOd4n2p1OPiBZRuqiGWIngZbdbJcwHFO4Vw HoZLjRJNoIflm1LCDlIugfJ6yrcdx+YwOSixlKx1yPelJRGHyMFj+QTIP9CX0fMcZkDpLhxk+EBf RskHMq/Qb9fmkNhUp0NiU6vnnWM6nzskjhLS4ylTdkCZwucRZgnVvstFmsHMtAyZlmFKxiSPFl0l TSMt8LfJsUJ15lNIB14jTxkdSEiOkXJ2wUXyaHr4auWpZvAiU3ZcaDzQDL7Qck7ngb+EyAe9P4Fa jQPekt12jVcN58VwqZjLL9hIopSxIBl4Ka6rFOhAWbKOcJPsvrScrq8Mr3GPIgMVJnWnHg0+CjTn ocM7SZ2m8aNAM8VgRV/oybqiypgHxcPX2TNNDDUIaDhYHugyqb30cdDskO1yuWtDGU6tpY/7zA7H F+VgXNtK404A18KhmqqsazjAR4c66MQCs4TmvTd4kVSwHtEjT/VvI8KrHOk0e2yJpfzoiqqqsm6/ w1C3Cw93IRsoJhSH7rD2eYrYwJO2S9jAs1B3Kz9wc+puzAfKa02cwQOKYM359xsyX7399i186cu2 +M0bQX/91mL63b/091+//dvbN2//sZBfvf0XKvNe+AplbmRzdHJlYW0KZW5kb2JqCjYgMCBvYmoK PDwvUGFyZW50IDUgMCBSL0NvbnRlbnRzIDQgMCBSL1R5cGUvUGFnZS9SZXNvdXJjZXM8PC9Qcm9j U2V0IFsvUERGIC9UZXh0IC9JbWFnZUIgL0ltYWdlQyAvSW1hZ2VJXS9Gb250PDwvRjEgMSAwIFIv RjIgMiAwIFIvRjMgMyAwIFI+Pj4+L01lZGlhQm94WzAgMCA2MTIgNzkyXT4+CmVuZG9iago3IDAg b2JqCjw8L0xlbmd0aCA5Nzk2L0ZpbHRlci9GbGF0ZURlY29kZT4+c3RyZWFtCniclV1Lj67JTQax 6w2XPVIvIgQivNT9whIlARIumWQgQMIOAUJJpLDhj/CDKbu+M8dVfcZ+rJHmSK2n33a5bJftsl2/ efvLr99ye++1vX/972/f//rtq7ffvIX3PtP7r9a/4f2Xby2mb/6ln//y7b/efvb267f4/r9v6f2H C/XfbzG8/93bz/8tvP/7+vX4Tv/9z39+853Pv/npW+H1/0/f+w/+SaBfWgT9+Q/Se4zvX//H+hT9 NL739YEYnlDev/7V2x//1t/+ydf/TcR+GVueUg74Vxp8hGctXsJ/psLz005ifqLC59NPYn5Hg8/0 9IkTM+sz6gH/kQaPIT6zH/i/1vHjCQOnPsb4RAfrY+xPOnn/PRWf8pM7zp6Y2lMyLjkxjWec3/8X FZ/LTY/OzxKeMh38LPmp1cGfMp920vNTFV/r04cD35b8HPDf1+Hlmc2x3LbELR7476r4Hp/QHeLW +xNP+v9JxY/0NIc2xlFvZf9HHT+fcq73n1X8Uvd62p4faPi01D0knP4Uyq3uqrqk0G56VFuY4uKn wzykOJ7e8P1KqdzmRJW3lPqTPfTnfJsTnf48b/XV6SmLPxE356ks/mQH/bU84+T/v6r49uE00ulv 9f6+Lm9L36eD/F5vcdbJ6eM2D3+l4ke5zYNOzwxPjg565jq9HJ5Gmuv0Srg45JCeerJfPS3yOt2b g568TvfuWG+O5ekdV9+cwpO6Y73rdM+O/cp58Qe3tjmP29P7BxVflrVtuLjlsk4jh3OV62KPZ3tr u8VNp78u58exW+twd9ie3MMtzPpq+7K1pzB8X8cvW3sKg+qKZTqrPcI8xi3MqquU57K1JztVXyDP cZ8VKj/LOqsv5VVd1bKA8cSrZ3uJH84iVZpL/HAWqfwv6cNZpH8/h9uXVH3Pslxzz2FRcr8Pi67i l2t+nY2qsSrLNZ/RwZ+lvSE76K/z9t1UY17W2X6Fajo966y+fKufq/ilv91xuJTenuHQx7L0fThC wbJ8+emwV2X55sERuJcVuUfcXJWl7inh7K9L3bODnBr6fTaqoUJd6j4cZ2mN8w7VVHNYU32iIxKv yzWvjsi6Ltf8CtVUc1KXa+4Rt57e23LHVrRg83JFmfVA6wkizidJuOqV7HyShKuHOknlOOAqW5ZU 5gOtx+srvsznUlWhj0so15ku8Xq6JGY603F6YqP4UuKNdFIiG4V/fwnxOPdKzx/kSECJ19NPOd/0 6PkMEuJzd3+op4caLjlxBZelODZrBZfVw8zab8FXtSq2/MSE61Vs80kZF/24ostLmPX1jngL8x/o +ELJEok3kknLjAzHeld0eZLz9zp8sQdfbQr1FmUjdRMpVQJLQ1qxYpn4atOKFZd7KvGqe82poe6g h1JDGTclnBoqDv5QasihLZwa8uwXpYY89FBqqOLamFq4tUXfr9ZubdFzMT3dpl9fbx8UzuHfX9p4 mXKd/0sbh+MgTdNxDuUQbtOmJ2LCMoXd8/2l645zNC9n8NpcPRUQ+y08Ov1LeSeuuzl9OFmMxM2y DQOX5Zzb7STp5C/dTcVBT6mUiMHXu0LF4ND1XCuFchJ/hMZ5OV63Lzs4e0DYd8vt7YHulOyImDTw hKsB8eD4X8LVRc4lMvWA6/eohcITCdc9QdLAfOD1m5jQnnSSox/mSwMzzpsYKyXLJF4/+1OkzK/E 6xdPy5E9P29ci3b2qwX+3yw/NhYH90mhmoOb6zDMHvpLYb8aZmcNbOwFXvfDV6QKS2ZcJ2c4RUf3 S9fJGbuDmevkJGMPE7/0tpyqovvhK2CdEVfcuDQ3JAd/lh8bhoMeSpwOnD90ydlx9qQY2FFAyU8r Zh0dV/UU5zOng/y0xOFkv5p4STlxGITjByWa4O1NS7dKc/Bz6da1XTo/a35axnU31fn06qCH7iwd 6st3ltmxX3RpWRzfX+oYcetAfmxymMI0Gh38Ev83On7ep7qOpwKm7hCfpb3jFH/dN6I7zop/n+84 HerOd5YnPcad6HZ90e19ub4C/mPLlQ0Nl7ZPrixqPOnOsg3cWtGd5cCl7XVliXN/X1niu9vSUxzG JC9lrw7HJPfFHocxyb3f0q9fAa+z9JJ+4xKyPfOkX78UpbPUw885b/HRLz2WNl77q4pbCZ2zEqgx L3SYOvhf6DDtuPaWlOmSDbY+ZR2+bTroX4fvOK25mnMtud5hhYHvj8PY0p3lRY6+3KXtHvUqdLZn XDzpjvNSr1/8Qv0FurR0WNuy9D05wsDS4x1YGJeQ5ckng9RECV9aDseGjVN5Vc+NbyCTY7F0BekQ /krFw/jnaxh3CK7qYo1czAnzpkYu5oT3iryYJW9zZz30wre1TWRmBVwlZVllsrICror9605OwPVU RmUbK+D6pVMIbGNR4imVQTZW4PXcwQqI6slLvUY6No7/YHpS4lQMTA9dyh1wvSaZSrwrzn26w6Nw V+DVLFikqrGTfD3VQ7mJ6mAP5Saag/4VP82T/Xo6oPGNuMTr6QZKT5z06LkbupY7+annbsgFaw5x oxrv5uDncsHoYgjm51L2nB38Wdpezv3VS+wpndFwPKUzmsOapJcLJvD6Rc9ywS7zY9R4T3bhBV7N pKalvuXkv+ry0MXcJc96gEx1YMXBH6oDm7h88kVewfUrlco+D2rOU43s8qD6RRd5l37pF6O1c/4D 3q+WOV8Fy8/S9zId9Pcd4MP71Rc/PZ8ftznR03OjUIcMbE6oJnxMB/krQpsVZz9dFYaOi08Oleqo YPqpxrtNXHxy3FUT6HpzHE/BtyunyNlF1PrktIsmYHLoqvC05moFDeVXrtNap6ekW7t0epZ1mNnB nzKeORz00FWhg5w67sNUz5e04jpMc+v3YTr0/Eq9v1+t/Eo6D4s/1/Hzpkenfx3ueTr4Q4f7yX89 n0GH+0mPUYT9wffX41fKr+DSz+mVhBsHSq9c2qhHpGk+5+7q6YO8y/Hg1eZxK6NOznLNr6NO3y06 qh3aVdZR7dGuslzzdLJTz7a1ep9dRkn44Ct51PWhbMlFj96C0NtNj75eKtl2kD8qAXHyx30U6bm8 We64V5WGGj4cLUbFdr5PXr1iO0zOf6D0VzqpI25LatoVfKjnwBXbDttD+ZjCsQVj1VslukNrB1y1 O69KFAHXK7B3JYqAq3cy88TquZt+E26UiQS2IAJv9PM3TuEJvFFQvQu7UEZy7iY6vv/K3Qi8kYyp nApD2UnJm3Sy30jGcAM6zk9q4RuO9Zb+JAf5dB12sl9NQ8blfiUHNdSRd+6WXo5PLXnZQT615M0D b1SizOdkvp75oI685MDPeOutXtC+DHg6N1fPPM1GHW0Sb3Tbp1sZjUKUcSujHrpSSTVOfnrdnaFW kAtRzu3SExmp3bpiVFRPLgqD2fO6C4PZQ4Ur0UHP0vXcHd+nQpeE2xIudCm49qa6KzNg+qnQ5Vyv GjulFWtd31djp1diRcDV0CmNeGuvUVC9EyuoLeTCkuQQ/1nZuUatQ1pHdYs4nhMxFV8v12yf3zcS N+Omx2zOv7ZXD0Vjv/lvFGFHbnCA6aGibQd7yHt0eEqcuHF4Spy4cXhKnLjx0E+JmwOe9MTKrpoT +O/oiZL4nJulZwnbTpLD3FyewOwObvadJIe5MwInsQXeqItpXBAMCzPlYU7+6HU6lIfBT/YSHHac G+0dhpByMLHjhrAsRYwOQ8hJGIdmcY2L45yjGpfu8CIpa9Ong548bk00Gu0/+PxGo/0Hn9/O2hTc kFNjfnP4PZy1OderhqNUgzIdUUJZB3VwhLBlHdSXruvKMngQB3yQUtlKcPi1lIcpjhiN8zC4aagr pO6Oc5fSML3j7ORG+1Nd1BlnlLYZAzedNTlsD3XlB4edrTnetkqV/bpO3eZgDjl4K0yoSFcV1Umf cJWUV5u9gOslPbvNXsD1vnmewyjhelpocE2JgBt985XLFAVer5PjGp2M08ON9uPA63mqV6O9wOt5 lVejPcr91xxGnH4q0jnXazTOD3beBd6Yq1hY7mH+UF7olDajQYnnNkq8XuRC13jdwc+2M/UwPxtP G8H5Q5mkc3/11E1vt7wZqSEexIjTP/YZCtNPqaTukJ8VLM6Bmwcq0ok4+VSjExtOPtfoONQ3xV3D BNNDNT3T8f2l7sVhHlLaNU+oOFNNT3OIM9X0XNbc6GnKtzk3anp22TksDjTbySHOlOqJJz16zdBS 31Yd/F/qe5lnYxBjY59E4PXczavZHl7vq9kelv9Z8M361GyPEvOp2R4l5lOzPWrbqIKmRAeeen1P +o3ETeV7QnRzMw2t8dCzlKt46KE7lpMevYeIZiBnB//pLK24sco1PY6jlKckesSHMjfDwZ5XixJM z6s+FrUNuX84W/RU0vhwtuh50dctDsx+mqvosOWZjursEE86qh2uAJXchFMejJqYcKuXkR5qz0m+ OathtxgS1pzVELj5mD+bVexk/07AVaEkhgusNfA+npSo8rii+XbC/1CFh/c6+LQl7G//nx42DQm2 rsYL0S3xxuwwbm2UeL0tI/FscIk3Yrhlh68/YMRAhc4diddjlGW3cz3w+lCEwgNZcXoKDweXeCMG GgSUeDXvRZfjMR94Y3Z9oftEidevixv3+uEC1LnXD6d/xHu9RqPCoHNT4o0YhQvBv1UevmBpaqfx f4ihqRQgvuzXHxmGZjlnEq4bD+6kknB1jbuTSsJ1W9MpbJBw09ZULpEAbc1nsCFa68xY8ZHE66q3 zowVH+H4FX+1kx5dNSjdcsDNbMs6kCTeGGtIk6Il3JiaOF3U7Js6idf14mVnYGbWynon8LpdJbtU HPRTbuaAG2MQ29MdotbmTY2+Wqqwbo7NGhw6SrxhxTh0lHh9+s3MDlbORmk9iTcqcBKFdhKv976E wUcsKgpUsZMrzvy0PL1yMlM9QqgEp2XHeumqrjjopwJrXM+pAicVXJQpzXKRo5O/IrvRcNlPK7Jb kawDz62YEq+7aHRA5EbRKXhAfAYb48VezqjA61oYJ3nREm/k17czKvBGj+18TrhxQHDPo8Tr1wNL cGo/8GY6nlwzmD2VYzSc/prZVRR4w+RTTCfhxmTaRBkTnJxW6cZT4vUjgqo5hoOeXc0h8UY2PrNn KfBGKDN4OKf8hd/T7Xii0jycoDmoMBWWH+6Zjbj80AywGHF5SLukA1ZHyq+ngQsE5ddzwTeY8ut0 rqDqTudEdAgonRPxpF8/t0q56TdKI8NNv/79+sEcGsNpfeaQe1oPuH4u9u0vC7w6PjH1HZnD7Fn6 eLFHVS9Kr8fsEOcZ7u3V9Z1qL9vA9TcHqm771vV+KVKl10O+ML+UzoYLSvUi9Ofos9/RsCMRTsL/ WYMvprR2wH+mwnl+toT/RINHSoiNA/9jFR/b/f3vqfhU7tWq5FOI2PuB/1sVv0zIxZ4fqHh6GbEe +N/R8WxC8O9XNmk4/xvPEJb4n+p4njYv8aeOfPgFOnTPDfg9FT/iTZC+wfS24LkBX6n4OW56/krD 89t/HaefYqGLQSpD6UzsjvWm/WCIxP+Tis/cuA4rQFoCevFHNcpkeTqPtmAsMDlZwoHJyRIOTE6W cGBysoSrZyHl1DpODNm1Pg+8Mc2Ib1Ml3oic+DZV4o1UHF+uSLzxomyg0i2Ym/Ri7Tz5o7uyNPBx HHhjdHJ7TtExXgDhycn4du1HQPDl1kieOL5dlbsucHFo3EWB0/8yy/D3e6FiZny9nbsoJP7PzNDJ s71kxQ+4Xhe2lHfiX3+9Dyvxzcp/5XbgzdlBo+G2hPJf9aTHaHHjljVYuV4ta7Cyv1rWYGnguMnD /92yJvFGnVGhzJTEG3VGgWbpSLz6RA3PWj7g9qjl5Njepbx5ONhJb4ac7P/Fn+iBU6baBtj47xY3 fLt2ixtsTCjOSo5znd+H9Yjb5PdPcXGek31sdH9fs4NgerhlLeHmIe8sJ07PvnKH1Z3fhz33V49b qfTpslfG9CBuvYA3gEqlLmfAmLbMrRfwacfjlh3OSaY8Z8PtLU0P6g57xbVPJ3/UMQ80PmgMh0B0 h6OaOz95IvH66G2azZxw60Czg2ZxCMPMDs7PeptC43XYSDfG8E7RYObmMM08aCjji6Umt8vtNwY/ T5ebXVK6PQGzyS04TDM1uUVHzEVNa8kRdJUSb09Abyor/FoqbtrKvgvD/wCNBYwOhrZABVw4g9bZ PgeujTQ7KHoY2ufjOIqoye2kXu9ZowxqxdX31RMHn1xlfjC0aoMQjWYeGVcveh32slV639c6qYPD kafZzN3hqNYVJV8pDXVuTF3qO3FhIKdtHUW94rkYAUdyMQKO5GIEHMnFCLhe2rJfsZJ449UrfsVK 4oFXrCRcr/uJDJR4Y1J0v8kxbrEz+3coN+OSmpIc7FlGv56ba+RueLYojqfRz/3AGy+y7ngC5j9V wp/06PfGlUdm4PzZXWW4+FDhnUd+Gs+Lk3jjHpvmxeHa0uetXUZTWaLKcJx8evD1/L6ee5rBRw89 7nHSo3fhULYn4tvLXWgZ3960K+FhcUuxUhUHbGpTiuySoPznJ18rLg8pB6o6kHg1l5pyo7IMeL9e k6JxftKTrw72FC6ygK0nv/iaHeSTR+jZXsr2TNy68UNcDutAD3Fd1kdP/tFbHSc9qk+VRrjVV8+G DS7Gw9WLBhqd4qlnz2bjmw2B12eo0EtZjv3lbM/A+U/ZnpBx9eJsj8P3oQFFjsM6kzOQHJ+n5NDA xTMn7vuCxYFzQ8WBp7a4ioszvcQVT2tlNRLR8zxhMNaq7y/0jtj+KtBHJNBWG5GAAl1EAg00EQm0 VddP+YLdAmBXbX7GGndrr3TmZ7hRpL+zmTC88X31Z7heN00lmF3CjYrNysbiM1y/tqNn4w7adc+G ZPWAG0+c7LTkZ7henEoTZzO+1Do584ASQ++bSPTPdZ8yPgflxhiEzsEmSgplJDPOl9GfQ2AMb3Wn L1FaJnfqCLjuWwXu1BFwY5TmTkd+CzFfsm174gli2/Iivb5MJtC7JOFA75KEA71LEg70Lkm4ZePy SJ/e+LaNnABbT1OzlZN4pE9S4o1S87yCOAk37By/LizxhqHjoEnijS7JRkGQxBtdkomCDpweehv+ gBsheniGgxoyjSd3jB7JTLO4JN6o7F5OeC2O5S77WKeD/Z0nWeALpnak7qBnX/JIvNHuNMnLdDBo FtcfSCHcf0APEgPfqUu8HvWFFYQecL2SOnJKC+Ynxeg94fJMVXvpxBuvP82bHqMlaVlZXP65g+kk R48RdxUqLJ6vQnbYeNKgmDpw45naB2OrF4g0viHHt5cK309+6q9Bd/ZCcfq7z9qm8cHa6uI8402/ UWFRbvr/1Iq5r++rlw00K+Zab9BjYm5AlHj9PZtUXOulKbzXeo3ZL/k258bz1PTAi4Trry2VehtP o/4hsscm8L+r4x0nNQ1+CQ5Zoxm8KTp40zNlx/GjJfdB4QC+gBEpgSfxesJmcEU4zv35wTPUr4CD z1iV4DNWZSlXSbixKvGDsdIvgWO5nSvjdaNICTPYFaAahXriVc+cXP7ljnXY5f8MtqY9Ro5sBN4Y pcKpKYnXg2YaV9Ad9FD3aj7w5qshfR543cnek1Qk3vD516l+wI1rPx6MIvHIYBSc/TSw4NxePYTi AQQ4N2mOSnPsFr3xFh3cpFdGPLu7fIbi2V2au3Li9VvXUW56jERKo0oYXBxmuunRh8HOSSXwMD9T qFQCL/HGMEkeWiDxRtF25WMCFTcKEaJjf+kaLw58fzlEGI718pADCTdqsCNbfZh8Gkfe8e2l917D xLWdruVSdNBDIcJJjzFLsnJEDdPTed6dA+9h/tguBrzY8eEk0pk/8235rU7XD0eLccnGrcCw8ubQ b+kxXwEJJ4P0CuPImXl4t+iW7TL+xvDJ5tKWnDg5DysvPetxaYtxa5ZubTHwg51yVFuoonqceCMC aeyTw/ypOyeNGkOaJlmKg5+d64ZhhaRpkpexNR8CuVw3Y5pkvo2/Lp9j3gpsPBzC7YIS//dWzDIj vr8l5Ft/jZil3/qrl8XGRjU38HrpRuVyxoy64cR1wPgCcqAWCliA6M52Oja4lPxED3ze+q7HmMt3 zg7npNRBRSWwfabr+ksf9Tr41m99NMqeA92E4/yhJ1mLY7tGus8vo656uJxJfgwkeeRz9juYUg06 v7Ka8Q2joLp+M2sCCKo/g43qw9c9msBD92gCbwTJ25UReD1s2SOhJF4v1t3jSSVej0r3uFGJNy7G AltmmD9lZ0sEXg+7aqISBgeeJQanf/c+Sbw+DnQPbZJ4vQSD5jgfcOPiiooJcekZle9Z4NXuCU+4 NEwuPoS1ha7FZsWXS9MpSsW5mWJiOyvwRtDLD+/C6+WJTQ7pT0sbC668dI02Kr69VOo6HdTkTN1V Eq9XxhYuNMO5uQcBwrr+GgQo8UZMXdkLg6WHTunu4E8rt+3R2U+n+sl/432G/HSHsPV5mx4jSk4c sqOmMI3p2NuZbkuip6smz4OHicmhPBc9eoQQuQoepp/KVptDFvJufYJlgZqau4d+bn2ScDW3nqkO 0EFNrnxBDa+WJjeeoqZ3+JZILeU490u9vQw9X1LjbWeNS7pw02+85pBv+o34e3K5kcDr8W6PNz16 EXb/YJl1bRkfLLNqOfkhTgf75w4vUUNO73CWjItDCYnTPQJvXBkODv8EXg/XaUiVQ9npCjAnXByo rfmyzPoVIxVAdlwcSiouN4yjdYcbxtG6w88oJTiYubyAcMqy0QM9bp9NJ2bZhuaIuKgF2mPJqQXa Y8m5BTo6+NPmreu6sPUPtlxf74hcbAQLw+iPR1dmoE4F2Okpc9+joeysYd+jobpVQ71tj2o6KROw /NoJZwI+g42K1/1yt8Sb1+v9/P7XViZgHnA9sHxV1Aq8Md0/sZjBy6WK2uRYLqXsy4E3mw36iTf6 AbikVsD1CV4861nCjR7ZXREm8HpahV7ujo7v98JFJQKvjvCi2+/cD7xxW761EN7dyXX4uPTQ7ffJ fuO2fLIHIPBGfWyirjNYGvi2PHq+P/hCTOCNEf+F63VheuhJgFOa9VCXXvuuuHbxbXl30LNf+8a/ v1/vlnhzxNlsuPyn/Xo3zh+6Lj/gxpMA/Hg3vly6LT/J14shXrflMPvpsW+HevEo6eFg/8iPR1tG u6XNuF9Pt7SZPa8549rF9bcnPWpLfI6Br2/Qs4XeahwTF4e8/PcQ8fXSW40ebaSm1EsbjfA+sosK 85MGljnI2UD4cMml3a6DEd0n9lDRw4JKdk9uGhW1VNrmWG7jeSU493vg6BheLlW2ZQc9fdJAApz9 o9xnr3EZ32969OTEmLfvYDzVWNmDR60JZQMc7ORkwLm9ejwUd3MHqrwlnrw8DP8XWhap1uULHYvx 4wh7yol+sWPxxu4R9hIOjLCXcHVkNiVr6gHXR8aHfFOjj1zfcZDE6yPv9wh7iddHxqdxgIcKXn7L 9fGq4gsLl8R/V8XXD1ulE19PzjQVvLyQJbkSrw/Hp7mpJ/E/UvF7Fr3E/7WO51n08M7SpJoZv/37 t+aRinQeGMhYYL6XhAPzvSQcmO8l4cB8LwlH5ntJPDLfS+KB+V4Sjsz3knhkvhfMzNd8L5ibr/le OHv2fC+JR+Z74fg93wunv3TKxkq8MfiAh63j/NzD1iVeH2jRMnmXuDzQqIRzvcaw9UjeLi6eezg7 vt4RKPbE+bkHduH074Fd+P5OTnDj8kmV/gP/PuU60inP5pSFfuKNIgke5w7zh8azX/prjFvnXJnE m89a1VMe9O7PFc206eBnCbd9Gzp+3N+vKr42Si5I/Hd1/PTR39JNv1H2MG77rMsPlSWceKOMgeMB WH/TqBSf4Pu74ofoOF+oGD857DOVGuSEyzMV7+eB8ydHSr7A5iHTo4/RQc5us8OXu9vsJF5PpuR8 f18PD+ki4KRfDz8z3/fh+OKwzTxq3fXx5torqjZMuKnlzMVpGoxJ6+U+6vTQn1IRDtXlVIRHdhbw Ms26bA7O7OD0UL2hQ9P3FA6c/NkpLQtvL5f5n5ZZn++8H5R04LncEJbOQmM7HKpIrckx4eJDrcnN 4WmXfWsAi0PJlfKUOP00t+P8vp4KorkdFVcvmpznEf9SM5Xx4PTvAkWcP8sTCOf39VIJKlBMuL5w G0FxyNvyBMK5X3qrPc35OL+v1+XwNHec/XssCC4O1KVwst/uUigOema92aOPWyfHxHF41eWYXI6M aj0rXXsMXBxqvA87vbJiWZ/piKvrcjSus1cnJ8c7LtKn0ecPSRxrXDwNxokT2Ko+2HAKuLrUFWFS hIbC5z6lBVwdi7/iyxIPuJ592me6gKuZM87njgOvT4rb2SQBN8paKmdvUOrjkrJykmMMluMnPHB6 Et/sS7wxia6wERF4o26msU8C008NMcNB//JQT/KNyXJ0mSLhxpPnPCte4v9Szw3tWEvg9Sokmhox HdzpPD4X537nWAsWts4X3RKvxkKcSjrg+syLyW17OHeW6vZTt/QZFq9MEirLXAUzcfbww4AVp5+q YC7TY2aSZsdlnx/689C/H/qDpZ+qYBJuCfmdv4QLJyeemoM9S9UvU2UktuZNj/79Wm5TZYx+D/f3 df40vujGt7enWxv1xBA93Bcd3x87Ef9t5+4XLnOJRXXPqrXmz9Lu1rI/CwzXlnBrurbEAuO1JRyY ry3h1vBZ0sC2sXaprABDI7YlHpmx7cDzkG2JR6ZsSzwyZlvikTnbEo8M2pZ4ZNK2xCOjtvH17lnb OD08bFvCgWnbEo6M28ap2fO2ce7wwG0JRyZu4+TskdsSj8zclnhk6Pa30vMlqxd5uBFk9aiD92VM ganbEg5M3ZZwYOq2hANTtyXcMnwkBGGChk+AoWkBEo8YPok3nylfDp/E64Zmj9STeGOMNs89knjj ap7nHuH8ofT9yU/dcNNLqQ5yqOj/xBt2ku0eTg7bPXy32qTgS+L1aIRnBeCrpUfKz9UaQ64HF9Xg 9M9IhRG49OxpAbD0v6YFwPSkUPC9ZTN5Eq87k/T06SkLevM8xToH3Gj958kCsOa+RgXAvN+jAvDV Zh5ghHNz+ZRtOLZqjwrAl0sDgE68fgguP/76vhG68LwjnD/U9HdKjx667Ew5/v2d+ob5QycWVf/B J9ZnsOFsvU4sgYdOLIE3TiCeV4Pj97waiTfSc5kFU+D1sZx5PifceMsx3eQY2bxBtTQSb3jePOkc Z0/lZlScHnopIh94Pb3YuFZH4o3xNvzwg8Qb+b9BtfX49g5OsUi8MRAn0xw0ibfOxHkTZJyJidLH +ALoTHRsMD8s4cLX+/tGSi9SaAgLEL0sEaqDnt3YBvOTwxicnZQBvMjRXzbghyVwajKnyyXemHDD T6vi3y/8tKrE67EhXWhXx27RQxSndOpvjTYupcS/TxfOGVd36oOjeAXmT+fpYzj/l7qXc73WSBya 6IPj6YFvB/lz3NZKfziBhuIMnJ30lmMtOHt4KM5Jjz5GhIbcDFzZaciNR/y5lSY76KcxNxVXl9fY GpyewglTWPzzUsfLmdGn+ix19DgzVE7WpoP/S33jidfLt6gTzkNPmzc9xpjZejlXuvgPntGNb9du hMPZM/kqFnZ+uLHtxOujL/aYG1h8XmNuJN6YGsuFqfD3KUion5rVgBjhG6yR9XiFCJ/hUITwGW7c 33MuX8DN+GAccCOTX9hf/gw38lP89ge81J3HF3DjMp6zWSjpO+kv4HryiJ+HgCmne/sDbrjtPPVS wNXxy/zWw8BX2vnFbQE38l489BKWmBnZp0OJWQ57ijDbOXvfYGnnORRdwvW5BjFwxg6GZ89SeTom LjOcwsqwLlHbR8E1NS3FrhE2StwkknG+v/JRoMx8SkeB8v4pGwXaAX6iHWf7CuHnsUvG++mBih5h tu+SUFT3qDjv1A7D366XyBjuNo/dhndpNrqDQpeaQ4DXmUO7zjxj4ATPLIMp2cMqUQl4zZ5EFY9H T0acmMRFO+ge8VMOh/TqHQCUQMNXWsZ1LOkrXXpXcFeDp0h+u6vxhYtTOuAb1vwflzEd+9X287G/ Gzs2EQKutttTCciBVlvEJ79TIeHf0+BxBaCUPRX4f9DxgwMsgdfb4SMPHZP4v1Dxe7CKxOsd6znf 3/++ii886AWnv9TnZKfe0F/5DSecfMrOnqLzjzp+cLpD4P9FxXduLMfpWQEWnR3fRs+tUEvs56CD kqFAP79AA+38Ag108ws00Mwv0Egvv4AjrfwCDnTyCzTSyC/gSB8/ysVXGz/KxlcXP8yY3cQv4EgP PwzfLfww7buDX8CNSxd+8hPeVKpCmDhn2uKMROuR2G7eh2lpk1x8eKXUup9wPnYecQmvdNCES/jj o11qbbz/N59DvoxK7krRhoAbNVfxMhq6lxz6ZTT0sI0e+x4wY+gRhHZ8XY9Ql/d4ft2syW7HLumj 4pZej4jTTq/4dVge6X4ld5z2pddlwLpEQwkjbk95DgBuT7mtv+PE7OJqmJFtXkvVg8i+HCv40ONC bNwM0HN/pxkwwrZAtwYw6fM2p/qo+FCp/RzdJY7c8JODIreOuwMUuQ1cwvLOhcJf32XNqPuQdy4U tUp5vwQEE1PyRYx+1VT4Jg4mpiZKzMK7Wsel2caEQG7kRL2NvJOnqADT8P9SYEOQuQoQPeDppYCI e2151wzCmzrm5fno8fjk+zoBN8b+83UdSnuhYBV3w8quk0ZDjkJTc2ABoxcCJm4h6YGAiZ8FZdd2 w8TkdMUFOttp1i9uNgqdwQmnvfAlHUw7ncGwH1boCMYlgAbxHHxRex/LfkJXwNVKmkIzgSfOl3UC 14pzveMOIb0IEI5Pqw5hOanWydgZWdRMl5kpc4DD22VejP78SfehqJmmlwMqbKXrTuGijKmRB9Gg lrEuRyAOWHIr1fkXmDGV6jCm4+vzOtl1zlAVBm6ml+M4vmmy0wnpPFBAoPWkUKTIV6DVDVoHXTso UX3S3Wgn0HoKKV2UmM0pB1pPw4RMyX4B1/MB65RbR66AGzmhREE1TEzkd5FgYtYx14uEf+rH/Ort N2/hva8j81dvhP3lW1v8/vQv/fyXb//19rO3Xy/kV2//D2ziAdIKZW5kc3RyZWFtCmVuZG9iago4 IDAgb2JqCjw8L1BhcmVudCA1IDAgUi9Db250ZW50cyA3IDAgUi9UeXBlL1BhZ2UvUmVzb3VyY2Vz PDwvUHJvY1NldCBbL1BERiAvVGV4dCAvSW1hZ2VCIC9JbWFnZUMgL0ltYWdlSV0vRm9udDw8L0Yx IDEgMCBSL0YyIDIgMCBSL0YzIDMgMCBSPj4+Pi9NZWRpYUJveFswIDAgNjEyIDc5Ml0+PgplbmRv YmoKOSAwIG9iago8PC9MZW5ndGggNzk1OS9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQp4nJVd S4+uyU0Oyq5ZQNgj9YYoSPCl7heWiElCyG3CSQZmkl0UomgmUtjwR/gt/D7Krq/nuOqcsR9rpGmp 9fR7XC7b5XL58ueXf373kttrr+313e9ePnn38unLn1/Ca5/p9av1M7x++dJi+von/f7Llz+8fPby p5f4+j8v6fXHC/XHlxhef/ryxW/D6+/Wn8dX+u+//+vr77z/y7dvhef/3773e/5NoD9aBH3/B/l1 ffHd79en6Lfxta8PxPyI/fXdVy/fe/37d38kWhmaXmO8oG3OR5wM/VZWsfORywH/lQYf+cD+UsUu 3EnJrzX4LI92wv9WhYfXNuojbexf/K+GjWFI8Ld+rIJjYboFXl1mTOGRigffHrke+B+q+JwepR/4 b+v4+qj5wP+Hii/x0U761X2KpT/iif+Riq/5kdqBV0Us1vaY2bHeOh9zOOhp7REP+BcqvC/2HPB/ 1+H90ZODmpEfIzu4M/rjFJ6f6PDFHM9mzfYI53I/1fAppEc8mf8DHd8fTdmsj1i91jMZBsjqLVFY osyf/a5h9YgrAq5bss0UAVeZMjdPBFw3fJslAm4avlIfvaCG7z1YJ/vN8An8vyCGT+A/0/GZNl3i ddlNDJT4/9QNX7zp0WU9dzbEAq8bmhIeJTr4UxobYoHXTUdNbIhx/Hj05qC/xcdIDnlonbUE5mcv j1Ad+BHInZF4/SBcanjJj35Qzfjo08Gf5YGM6pDnpbjn51UjksJiT8LJIVN5qa/KzkTe4UnPL1R8 So98is8nOn6wHwLTk8ujTnx701KvHh38KfnRO66OqczHGI7vL3W8xP9zFd/C/X2dP607mL8OwegR nt5u3VJ1JY3l5Xg2d7khl26pbktaulgabsvT8kNmw+nJIT9Cx+mhQ3QdF0vdwUP0PfhbP9cP0XVI lAOv3wbiOiTagVcdqLi0Npx445Ae7IzA9OfA1zCBN24bmb0Xgf9XHd/4UBd43QnI86Zf949Leozz +/ohVAYLmsCrWs63Ewf7W2ajD7O/VTayOH6dQdGxXT085vl99ZDgMzo71ktndD3wv/mNeUhXxwLo kD7gut0Ma70O/qdlR3LD1TeF+SgDV9+0fOx54n+mH7rh/r5u95ePXQu+XymtW4fD/KRcH9GDX4f6 9X39XFk+cz/lUz+31iGdXPh+f1/nJx3qp/yrPmFa+j6mQ356cBCznIDL9uvC3OujOmghHyA59nb5 ADE5ZG1mvp/B5M96Hy06e+a4jxbVlOfQ7u/rPkZMHtOT47hNj0p+TvE2zaoo59Tvo0Inf53U9RRN 9STN63p8mXLVZcvr5L0suU7POnlH/2Z6PhYKWtZwOQMfhILoGL+gdSzDnJ8n0Pc08JL6XA78LzT4 EuLl+Er4Jxo8hnR//kcqfvmP8ST/hzp+kBDj+CU1KTvoWQY/RMf3162s9gP/bR3f6WIg8X+n4pcB v77/KxVPDthJ/y9VfI/39z9X8SPd9P9axU8OmuH8X0Yt5G9e70eioHX5eP0ZXO0qdjwu+L+pUdBC nrWEq/q9FjrrAVfN3/LraJ8EXA9OBXZMJV53TAM7phKvB3eWY3d+Xr+mRHZjJV6PVcZ+k6NfUxL7 pTA36ZGpJAd7ciK/UeL12GMe5Nfh+FLI78LpX2ZhZAd/ar6lTb/XLLMQT3FTD/PYJptNmJ7leuWT HiO2yfERiddjm4PjIzg/lzYGjzzMRo98ju/zsy3MzxQWf07+6/GjMMg5knjdl43r2Drp0YN3S79C wflPwdDqMIYUDG3Vsd6lX/ncr+8YzlGt/N7+gXP0sROiVNpd/iyQHSDhVnaAxALZARIOZAdIuPVI VvdzEBbfE2AoO0DikewAB56zAyQeyQ6QeCQ7QOKR7ACJR7IDJB7JDpB4JDsAX+/ODsDp4ewACQey AyQcyQ7AqdnZATh3ODtAwpHsAJycnR0g8Uh2gMQj2QEwPaTly5HKsJa/B2NaLvCQluP4reUCD2m5 wENaLvBGlL3z8Srwuve93Dk6XgVe96afVkHgIasA79fS8nzur64nbR/3Am+E8SeFPfH19vRIycH/ XtidhuVnLL9gOPaL3EWH+JBdOMVTfxThl3B4tRSUzwXnJgXlT7h6T6WYfI34alNMfOVHmZko5DJx 4UlpXZyjY7lp3X2ag505sC8t8Prb6jIOFz1GTD5SIBPnZ+E3Dpw/NT5OctQzlEL4yYNfup5PW/hX On7ZZoeypGUbSnGID0XlHbrOYfnhoGcUCoNLvPoi+3zKx+mZmZ4cJV4/1NfVsJx41ePM4YOzS4+D x8gRMpQ/eZ3tly+gqleOzUcPvdC78P3+vs4fenGvuPrmPClN7Bvp+dhVcm1BwxLNy4xkDPmzQMql hAMplxIOpFxKOJByKeHWbbL0/nYTt/1MATb8nO1nSrwetqIUyvP7etgqLd1zkENu40mO7pbS5TB7 8J2ipDg9yw0c3fF9uuzNA29kRLIbiLNzu4ESr7uZyw0cJz91t64PVhKB1/2upSXjXK+REZnoaMP5 P8ej4svl617H2U9BwHSyR7V8KfJTHbzctCz3cIg/ZUTO5vg+ZUQ2x3rXvXY5prA4p3Uru9RLdwRL eFzWRz/5S6Y3FAe+UZAX52dN5Jji8lMr3ULx77dEt1CJ1z2vNh6nuOl+eI90CcW3d13i8vl93TFa R6LHOqRRKfSF45e2h1N99VyjdSrWiotbDgHfK0q2iBFnZl6XuMuW/NTyAtv5ffXSkZc71DMum5Sd cZlO9RaR16WvVMd6yQuMuCyzF+gQHvYCi4MeyqN0sLNwsgss+7kWep+EdTFXTnbBZZM8gfP7evIK 5V0mhzhTmkB2sLNzMjx8tOQRbtOm00N5l9HxfUq7dOH7/X2d/+vS1younmW5Ar3j4l+Wug+HOhbK u3SIf4mn8Kt+SUkfePEqMwslXTqErSy33GOrSr69fn2tS9UvU6W6AaXU21Tpe1s/uCXo5FcuDoRt SWn8SIqzszUKYMBuWOmcw43zs7fbDVNtW1l+QCwOflLxpONo4Rtp46AHg5H6BYlH6hckXo/ULx+7 nfSYRYCkWwKvR7r325HEGy8ly2k74H+pwztfEQTeqAFkoMQbNX3hkTzwxh42TM7ymMu5XOOdpPEx JPBG2kviYwLerXXhzSc9+rvK2F4YLM37/VTijXKEMW+CjLyXdBOkq8u+UaP8oZrBlnByng+oEh+Q GzIqP283ZIHXrzjPGzJM//OGDNPzvCHD/KSawZP/Rk3i5AAUTD/VDCbcutGNN5/fV/Nx6MZ7wvWX sHXhHQmXTrrBzuJg51LH0HDzwBUDHnZSsmx2iNvcjhK63hw499yB52dyiVdv1DlmvrWg4pBjZc8E 5efzqUHikacGmP85h0cduDpmKu7DT5dcAiW14sstjYqhcPKX9tbiYM/SxlBw9cotcjgYZk/rVKyE 84eK9YqDP8sjDA7rlkd2qSNfMk/x0Stg6HA86dFPX7plXvqoe9pU3Yfzp1BF/WkO1deWsk7HOPD1 Fqqod5BDh2PCt6tQQX1x4Kn2rjro2bV3+PfXYTemY7covFsc7GzpPl30e2PzWf/S4+38qK8tdE/r EzcnZTe5wflPNfKO5a7DLpzb9Zvfa39Ar5j16wIq4BXzPRhqHCPxSLacxBvFDNw4RuLtV8944PVb TubmATj9mZPdJV5/pqPst3zg9Wc6agRz4o1n0sFeLbxeugVGB/93UbrEG1mukYOdAq/f0qhxzLle PSeZitLP9eoxBzq3TvqNtNjBwVFY/qkm3bG/nP+Wcf5zUfrE+c8JcLg4pN1WEBa3FCcnIcDLTYWS FfHvZz7VUe7THTCc1kd/1nu+kgq8ng/2fCWFd+v5SopK89srKczO2il9D2dny3wnhcVheamX9hrP noEqBCRe7ztEz54n/fodn549T/p1L5J7zSTHApb6llMgdLd/qW/D6aeXz8ua6E9RccfQ0P2lOnOP NXl7yRR4/ZbwfJlErWdOnDws8epzAr1khujB79QwmJ48bvr1p8lSbnr0fLwabu9HPe1y5XRj2F7R rbQlx3qXNxAc5jwvB/KyV/otuU3KmsPlrSd+eYbX2+vj1EY9JjPibR6MS2zhGA68XaPf1kSnZ2aO saDOydtLKbq9JeykF/R4JK9/aUyCvf73YMPLe3r9Aq97nZRxcX7fuCVkcgMEXHf6M1e4SrxR8dz4 WIe/XxK/ugm87tRSxfMBN14e9suPwBt1bfkmR/dRqUKmO7hPPv900NO4IFbidR9+V7xIvFHwHDjW JvBG5RwDcencpXA4P3cpHCxuz1I4ide9pGeuI7reFLmPhsT/je6UBz4VUW1PqfGdFF5v5m4w8P5S wXPy4J8vOQKvF3hXzvWG5f/Ny0blJ7XId2SB11+Wnl42ql/sZVcH//sO5qH6mEai7pUSr9+iRr31 xU5GPOXzr3V8pUpZide9thA5lxilh55yLv1S9ZGrQHB1oZeZdpKjexmp3uwxijribU50pyoXDrkJ vOE0c28snJ07XRC1nuSUULAcdkreg60+LDt9ReD1dpQx07YKuH7KPbNdBF4/tXa3Tok3fJ7BoRiB 1+tB8pZigTe6XWZO9YLXSy2so4Od9OLWHeut3OJN4o3q/8kvSjB/2rjpN9pjRh/9vd/06/yhut3i oIfyVxziRtkrB9xoYJ1uburcJ58n4dxhn+ekx8h22T6AwKtXJ2qmmTvOTfaRTnqMbBdupinx+hm6 m2nC/Gcf6eSnns6xfKSRHestO0kWNZ5UuJszLm6cHeOh5/lgCPNzaXuIDnpaubVd95nJpzrp1322 3lzay5FOh7o8A52wupBLdZJjZMf0W5zNntrNcVi8BToFXveRqJ9mdtATd3Ucaq7YB3MYf/LBLvXV 0xuWD9Ydh1fO9fZNDJ8q3s6G3s+0zFv87XQXh7pwuktyrHepY58O/q8r0Si4+eT0GNx6cnZMcix3 5Pv0MrNjosO6cXaMZ7vmvpGi9JelvjPj20XZMdWxXSWG2zzogcvlaoeJr7csdXfRk+JNj17GkDhA h2pjyYFzKWF25v2qhFpnKtqYw7G99MyIn12UrJOSg5tUhNFxZSx13L6Dzs5WXDeRQvESx3L30Cic nD5dR3sZ6bZtuvBTLpDDtpUxOOUFpmfG25VXXdsydz0d6mrXkG9lVL9fw7yUS2VPXa5APMk34wfr slDghgzvwUaqTtxhLYFXD5W3C77AI+M4JF6/oj3LWQTeLGchuRF4o/HXdmkF3mjvl3z0lHrTY6Qy RU5NEnjjgh/4wi7wRgeHxmFgmB7q4HDSo3egoA4O2YEfO+UYpmfulGP4+1S3OfD9ektNQvn/TDVC xZ/aspJZFngjlyNtnxOmn0oxT3kwkofCLZ/6HW3pyyWfxhV/8rMMTP/Sr5pweU5lcPINKj+pFn42 gel5PoPA66V5GR23n9Rsaw4H/TQHy0E+jcE62W++glzqYozN2m/aMPmTx4NIvDE2q/MVUOD/T7+C B5x4brSF8zIv4EWLcb0v1EQKXivnMTlEmTssnPToeUPPPCb4+9RhITvop3kZjr2l6pfZHPSUznk9 qOnPlecB4vtbuUM+bHpy4/mB+HqpljTjppbyhuJJjx7+eLZMgMV/Hb3V4Qq8tUxA17t81Dy56wPm owqwcabvxBuJR9LtJd6YNcDNaSVe9wn3BBeJN33UGQ+80WyWG/zh693NZiVe97E58wYnf/emlXj9 StHiw7Nb66KbT7zRYyzQCSrxak1i7FxEhy+3cxEdvlzKlzu/b/egzo7dmuler35Do8kE+HL5zerc XbWtYaJ5PQf8+zq8URhG4v9Bx08Kw+Dk0w365KbxxDUoDCPxehoQ1aA1B55q0AZuS8hoLjveYKP5 Hmzkmz2NpsDrRi1yjxaJN4wmTx6VeF1tuTOjhBs2k3u04ORTn4oTbzTojvQWIPG61u5EAok3siHr Y3rg7Avi7KGwgWOzaIjUubnGJGx2BXFu7igDTs+OMuDCQza8O6Rh8Gg5nJ0UlTjXqw+lnYFynnH6 J6ecw/zhqMTJH/2hNjR66Me/H3n6ESwP3AG84fJAUYyecO3iKMb5fSPZMtC1FVavZ+IBLD+cnJlw +aHEg4seI/Eg3/QYbTwmvRTi9FBbDsfnd94Bzv5W6aUQF4c2bvHX2bPzFCReb/De202P0ZaDU9tx do56q6Mx+JMLsiRedxp2osI34j/SsZqKUsJHhh/FDydDUj3QW5Ji0LAjs5ILuDo5cHLZloR/qsFp gF3vB/4nOr7c5Hym4yffI1DyqTxjnPTogxVpIt35fX3QY+o3f76r4nP30b88jIt+Hb87UEr8z1R8 +2B/9f3iQUISrs957JnyryVeNckkyOSiPmdCAnMeJRyY8yjhwJxHCQfmPEo4MudR4pE5jxIPzHmU cGTOo8Qjcx5hZj7nPMLcfM55xNmz5zxKPDLnEcfvOY84/XvOo8Tr0YVa7+8bDe84BRIXh1ZuadY9 33U0l4rrFnnutTnkYXC7RIk3PH1+X8b5P/l9GefP5PdleL3kuZeIr5c895px+vn9ceL79ZwLKfH6 e1/i4B0O34eWwOsttzMPCIDND43uSd3BzuWIZ4c4UAZwOcVB7bpNvQ7GwNUxXXtrtINvt+0xvPx5 n3P6Zi23/Tro9Pb31E1vOujp8bYlRr/5eh+Num4NfhvHhWH0W9fN7nvndulP0fODo0h/DwrchwPe LkovPj+vPwdRwK/glpOBDreHsoV7cyyXAn4J536miN/ATQNVeM2ESxs9V06HacjPVxiB1yvaKELo MA2cvXxql9F2odJzHOxIUvby5WnoBYX0DpNxbcw9356A0axv3p6A0ayv3p7Ad3T84IA0vL/0vHny X71U5MmlVTB/Ct1fM84fSi/ujnsFpRePiOtjiZwBidOT8i2fZpP34JBnavKecPUq1PnWcbhQM0CH X14oIufw+wtF5BzaXi7RV5NPqRFgdDiRhea8OJxIagR4ObVmI8DkuDQWmuDXHXs7yn2wG/gPLhVG 8vJ+24JFedabHiP594NLhXpJrqHdpkrdX8oWHg7TUHdbXVhXauRh87Bpq1S8PRz05/tSoZJPPm3g 0jBb1Pr23wVcPRRHYMERcNUDHpxUL+HWiPd+EqMnzNCUV4nWM39Dumk3AkODz0+B12+6FOkpOOf5 gXngzKGsnIzvFAd64oE3AkOTjzd4uRQYyg7yMyee4vQs97E7doviQsnx+cp5pxKvx21ocEJ3LJda Zk4PflDtocQbWTmFjzhY2iiOVA+8HUfqDn4O7qUr8Xp6xdw5YAJvTCLsnGMGr3dy711YXWi04Dz5 aZSSJ3o/gvnDcaRT2/9RDwxxJ3VY/qndzrldxkjn9EiOry/lzSe+6WGeys4mql080bnilp+y0ofj lOMR0Kftt0dAO2w/ZaWXU/qPu9ZHHiCpiWSqjLVG5qZ16qY9XVef9rDczFwOuMrFdbuVWOtojicl eloWjyGRcGteLk/R3lg7i0uAjU6+O4tL4pHUVweeU18lXk/FpSBNP/BGGhfPtpZ43azSgN2TfqM8 i1NfJd4csLsUSeKN/iuNkjXx9VYuasXp4UdTCf9CPwUXew640Ze6U4AYp2ZPD8K5M6hGVcLtzFfP Zu2WcxJvnIHcck7idau9hwd9Iz0fs3pUToQZPYo/PG0pMCdcwoE54RIOzAmXcGBOuISbdm9ZkJFQ u/ceDM0Jl3ijzHTbPYHX3eGdvSrx+jPmTvmXeCTlX+KNZpscbJZ4XfNKoVQhiTf6TgUKFkq88ezM HfYlXrfDjb0BfH97IJ3D17s75uP8p94X00H/ui7U6ZC33TFf4vW0CPKWIs4fTgBNOP3k/o+E84c6 T42B6wt3nhq4vLH774E39rcE3nxGvsyD8YzMWfw4+3cWP87+woNzcPYXDqhKvJ7fS2PTqmO9lUdl Srzx0htu82bg823ezMZTIeHqTlWvl3kzvj9v82bMceOLjsQbzT8Hu3UCr+cb7wRQidfLvukgjent 8gUcpO/BhqF6HqQCrx+MuwwEx+9xpRKvG/7d30HijboODpXj+N2vQeKRfg0Sb9SNDNZEgTcO3sIX JpieXamB87/xrF6cnsazd3F8r3xhEng9rkcNH0+8cSdYFzKH+AxO8sXZST2nTvbr/SpnpUAITv7k JGKJ1w3D81xH18uFHQ7xpy7a0yH+dK7PiYsbnetl4uaHD/Z44I32FInCsA784IMLFWfK95oNV3dq NxEc8kaBwMs86zlES93jdMgDBfaig559t8Xlh0bEnXijX8lytK9/wDh5OUsGF7jnySvweo4YPd0e cKPfxKD0Wlh+cijsN6PLzTHixoSnp57K+1sdP25lNzO4win8qte5nBJ6hggZdEoE2JqMESnRUeKN aAB3HZH4d7pTQpM0JFwPOu5JGhJv9JBK1IgDXy5N3kiO5W4fRuLNIGg/8fbb4QFXn3L46fCA2yPX 44HXr8at010C//4OBUi8+pbDI9T7gdc9qtHIBOK7u2tBcenZ9fwSrwdxJ+dVSbx+ZAVuIwJLA4UO UvR8f5BHKPH6kbtDBzg9lKd2SrN+hFKeWsW1i5tWdwc92yXBv79dEok3ajvZJYHl/+li4Pyht8MD rnuoldOC8eU2TguWeKOndKQTFGc/jWh3qBc7JMPB/kEDEXByRrulzUgST7e0GQ5JoyxcWLty4D4J Em9kiQcahgefLTShfUxcHHhCe8TXyz2oHdqY07i10cj65ixfnJ+UJe4gZ/e0wtlJE90dys6z805p 1mcp0iy84dguits7ltu4ug8+S3kUXnVwv4/77DVm4fH1VeLV6ESefH2FjQm1rJ6K7f/ICyG9iebG WKswmxyrdTnmzwKF2RIOFGZLOFKYLfFIYbbEI4XZMPnPwmyJRwqzJR4pzJb4f1LxS8dLcvCHpkp4 +E9TIk5+/lDFN24Zi/OzTcrulfjPVfwINz06Pwe32JT4ruJnpvsEzM7JIRJY3FLgp1qJ/7mO56dg iVdNJikuHRL9I0v9AMuF6BIOFKJLOFCILuFAIbqEI4XoEo8Uoks8UIgu4UghusQjhegwM5+F6DA3 n4XoOHt2IbrEI4XoOH4Xoku80XGqU4sbnP9l3vQYCceVWvrg/GncQgcXn8aze3D6W+MYksAbDx/U QgfXlj5v7TLyjRM1N8W3a/CoH5ydk1voSLyRz9xu9TJzrUbHxYGiBrnjppCiBmXg6ksPE6e06XHu RHl38G5RzMAjzFy2Phzfz+MWZqMLNg+TkHj9VlkGZdvDwk9pbumkRx82SgVr3cH+dY9o3bG7PfMt Dl5v5+GwOP9HcGkXRQEu7TInV13apQdJ5mAXDKWfhoHOhBtPesaYA9fGvA7fMPH9ynG72Ch/Mh2+ 2bFeSls+6dHvfZm7ouD0Z4fpyYVTLOCTOlfOVYSVhQu/i4M5lLs3HcLQtsOMKldu1aUsmZKWz801 ggb9djz1zaVSH4cnQIXlYTiEk0ZQnPw0Btx3vv+h+1VCuI9GvbI55NvzNArR5+15GoXo9fb0jEJ0 zoWE5Z/mUI2My1tJ43GKpzG3qtBFDhY3KhS/zkZzDtV1NurFxDVyxBLH9/v7xqAonugBq2OhWh9c +kvnAR3w0VU610ni5A+qk8SF/xlsgIV/httP1Xd3+cFz4uTT9T59XQmlS1qnagmJ1hP9ufZYwvVi KJ57A8MpdlAOuB5q6JQ5IOH6i/SuVZZ4/fK6a5Vh3lBW4wk3aokDPzELvF7llDo/MQu8frek2mMP PZknMUi8XgVWeBKDxBtJjTsWIPBJv6vvCKrA60/qy+S05qCncbtbiderD3q8v28UB5dHdLCfyvqS QxyWt5+LQzrnzg9Bl8s943BuJjr/z88bD/Y80xzmJl3Vp+f7cT/5Cbz+whzLTb95ta+ndqmNgCgh oGUHPxM3L5d4Naibcub4u8AbU6wnn6Dweqn42CMP63J/KrtRe8xjbHBy1nXiMm7G3T7z3VLg9RFU PTw80tN3HBWWzl4fDlOVyH05T2m90np8YGqN1tCBb6Ko6afW0JdymTOsY8LXS03momN3KRJwndRG 5KA/HAc7BQJmwoUnU+pexqXn2WQONv3Unvg6qc2mcZf4qE1d8q7Lg8Un73pkidfvxpSMlx3i0wan t8Dr5YJkXHroau/YXSoOcPjANJH6Ui5jwpXjmMi7Ghk2PHnOWxONa3rlex9KfIk8ARemv9Cx63AD SmwcFkK9KpplO09LaIyjbpx1i5qGQjV/BRcG6i93qZaqioXy8ByWnO71YeLyUGq56df5v1T9Mj3G gOl0uQH6dlFzV8dBUZ55e6iql2ceHiz+Ow8PXi21dDt3V29htwdLwuTT/Ofg8BuopVt0mDZq6XZp u+pnUIs2j7bXFB8OYavr3PUoe03zVhYzTBI5T9pWlM5VChKuJ01EfnoScNVsDh5aKeF60kRgtgu4 KmZz3F/XL66UelUOvJGTsW2ywBuTE7dNFngjrrJzzdHlvgVKUG5ypcXERSGuq1YsDn4+Ayv493ew UuCNpIl4029Ucux3MIG3+irtlz+CWh1GBpci8UeBrkoCbTVVElCgp5JAAy2VBPqts8inL39+CYvK 9PrVC0G/fGnrs28/6fdfvvzh5bOXPy3kpy//D/SDCgkKZW5kc3RyZWFtCmVuZG9iagoxMCAwIG9i ago8PC9QYXJlbnQgNSAwIFIvQ29udGVudHMgOSAwIFIvVHlwZS9QYWdlL1Jlc291cmNlczw8L1By b2NTZXQgWy9QREYgL1RleHQgL0ltYWdlQiAvSW1hZ2VDIC9JbWFnZUldL0ZvbnQ8PC9GMSAxIDAg Ui9GMiAyIDAgUi9GMyAzIDAgUj4+Pj4vTWVkaWFCb3hbMCAwIDYxMiA3OTJdPj4KZW5kb2JqCjEx IDAgb2JqCjw8L0xlbmd0aCA2OTkyL0ZpbHRlci9GbGF0ZURlY29kZT4+c3RyZWFtCniclV1Lr23J TW6U2Z4AEgyRziBAAmil3g/ECOWdhnC7b9JJujOLQtTqRAoT/gg/GNtr7XNctfdxfaVIudpnfWu1 y+WyXbbL9efbv3+8xfJSc3n5+LvbDz7ePtz+fHMvtYeXP9K/7uWbW/Hh9V/++ze3P9y+uP3p5l/+ 9xZefkqor2/evfzH7cvfupff0ev+hf/3P//9+p23N+/fctf/37/3e/mL45eIoO/9MLx4//Lx9/Qp /qt/6QT17nDp5eMfb9/5i//77sevmdinWO+aBn/yUxPs08HUKfxnJj64I6QdfDliHvA/MvExHKkO +G/Z+HzkOOB/ZeKTP8pI/y9tfD38iP+xic/xCGXA/8LGl6PHjfHmfvS2QU8phx/gX5rwSuwZ4J/b 8HrUsEFNi0eLG9xp9RiF51MbTszZmaxeDjcO94OFDy4cfmT+D218PYoxWZHWqsYTK0tvR6yCfbE+ zdCWjtjPz/6DiRWuaLi5ZJswRcNNpnThiYabC6oLSzT870y4eynVHamDik+BF4rpVHwabw7zUnwa /3MbH2SgCv/VV/YLTRipXlhoPj8TZGuyWI464n9ma75wtLzB0NSOXgf8QvMRg+KA/8LG56P0Ab/Q fP5ofoOektny4PwvjS0PTj+p1tw26GfdOsBtzU2qNWxQQ6uc7BQ+WlKtceSmqfp8TzP3v2+rSsd2 EF6OrFpdxukPpINHcn5gw4k9AZ+sQKs9pg1yAgkbPluBdEPKuCwH8qIm5WZzP7Yj7HA/JfbqYN0T Up91yU9MPOmG7jfYT16RCxv8KWHWJQt8mcdr01PDrEtMr5etHDmCBTVyr9iFzbps3Bsc8e0V3FYJ gTRO13B7pxH6kbyG24766dgruCnBl1+v4LayT1nUGfr17I8Ucb5nclsHYmxdXBzhFHrp0deAw0kU W8QnteajdZz0SkY/a7jtU7QsviXK9u7FJUKJIZuzI7/kio7ya69pFyf5XRi0PsmvvVXwxJkIMzIE 4kyGhxpCOgaR+c3SegwfN3ddIaYjd3hxhOSOOvDRVI0hlUl+TR0mliPhQ6WlN4q7zccSp6//l20G 4uE3RIY2agHXMoEWU0z412kxpQKr60CrIzd4dURaHRVWv5G8t1hgtkdy3hJuxyI5b+PSs4lhs4fT wlZvWBymIxnJ6sUNxsQ4qQF7pLFPK9WU9pjIaR6k3fTaIq2ljCvImNu0sO2hkg8WG8533p5FfKi0 9MavmzosstkbhMDc3Ecye6Hg8DarPHuotJWrBdaQkbZmbWOonfgecCEgPTByxowIJjdrSJMzyRWO A6E6LHmSSI22QyrJ4/KVyKKOronpa6Qwu9amvU7RTardXEopnvsNlPY4u9Y27SlMlsAUmESbvb7z 9Xp0fG2k7Cbabc4QLuPaOtHGcLRipheWSMmM+ytT/abqR8th2utU687CSy1MC8+eJfIGRpVkf727 ScfYk9rjRIw9S71LNAfkTCYt4DJMTCbXenSrTAnL3h/Z0BrPovAs8vExCs8bxxnKe+x2fvfvLSxN JxOt4L8w4eR+lQH+mQXvZf76byy4d3UA/9IEE7D2Af9jEx9IS1d8qBz5diMnv2XioxeFpPBffcd8 IXnx2dQLX9r4Ll6Ywn9h4rM4vzB/CnnibcB/MPHVzeTY81VPk63wn5r45sU9QWXNk+4I5X36n+Sq cs8cERFsNbHtmOCmXW3paGmAm3qJCO95gJvWo6fD+QFuh32cO3wc8HZ4g9ReGMmx4xuk98bP29lQ 0nt1/PyvbXydybEjS7QTok0czE0uBUhhgz0xMFDj7WR0bEcpG3hS8rVu0E+OTRv5v0hweY7+4vzM 9SijuNkZxuLYauLyUNh5xskpxM5xuuz8YhWPGGcnaSk/st+OTjcJN+OrsYlTjNPTxSvGxbM3di3h 7wcnEWqNt1NQrs7L185R0HKflpcdKfN1Xl52qIxTVg2Xh0Bbnt5weQuR5GFjuEkcWJz9STxYnJwk LqzGm/nXkCU+ASvzkNuWdgglzdrBjg6S01DjxnTVwjtUWJsEstRlY/mGJk4kTj/b6o3ppQ1KLxvk k8OcNmaLNjRpQ9qiC7xN1Xhz4xmduMCw8onse0WcmxLj3PB8OMoZ/Qb95MI3j0tDjGleXWYkPZKt dn0Dn+M8XjPbGLOEaXF+cjSy4+IWS53Ha/Ozxlmb2PJQO+9xYXmOtBstuPKJ7cEtt8Wnk+s56n47 WkvLa/q+HezgQryKDze5zOUc8LYikS2No3r4axufJm1iR6XI9KZxtsxNkQQb6wb5HG3csC0cbtxx lSTeuCE+KeXZVTJtaSLP2bWN6c2Ji3RxesqDNrQjd1z+MfLfDq5Vf7S6Ic7kOscN1y01N2sHm/5W Zu1gzy+5zju+RiLg5GuY9GdyhduG9c0uHRvKNnN2MeHKNvuwFUXIvs2+hikOmZbvjvPAmrB59lbX mvOs7dVwO14itb0absdLpLZXw+1S4MbxCYW2N1wkBTEP+EX4I4mWQsfqveM0MDxY74ts0GD6PRmt AW6HA65wCUwO10uNzF/U9ybZbyn88iTEyE072kD7p5w2ZitxuB1nJm23yoi3gze03aoj9+3dOlcD 9wFvV6uVJrE/eLbq6ZDD4+XoxzhbdvCGFnqJG9LQ8h49rc302NJMHl7LG/zpkhWEVUmgxe5Geuwy Ic9FHDA5XN8bAz7c4Pu8uBb1wGVaXDb1MRxhxP+ljSd/tuKzy/W9cUMVcn1vGhe7HfxID2ZoEfyI G7znxF3BlzoX99ZxruzSO1rqoW0QX8/NAboUObLSNuwKl4FNqsqmh/ZyfVyKdu0geXeubggD+S2+ b9BPbkBIuGqLznExNqwaoiN+DnCzljw6YucoPovqsTwvdbuOiVTD5DbYoQkOleDSLJGSgEtDjHUm 3+Z+kto6nD1k1yc/wJ4tPuaz4QhENux+gz9s2OMGPRyJybhqjmTY3Q79bNhHfpqODBd7TavFHi8f xCm49ol8EGcDn2g17ripXMGV6sb3vedjYjA/01kYDcuzxFYqvl5SeNglLOrEIhdFbnz/YVdh7+3J Fagb8paiVC7i9JAr0Eb+2LEkLoXpG/KQPVei4PRz7GbDMZTYzYb+5NjNhmeSyhnagsWNnIGRO2aO nWvA0gYzSTnksMFMDvRs7IpSD7Pptas7+xnmR/ESuBkX1xBHfVJ6lavjkmbGrg5AZ3IM/XlW+pO4 CJKww6bgpkVnc6Kw9mHpLtpewe3Tz0ly6gq+Ov2cU2BXn7Hrg2EKDLV90HjkaNgGXgpYNR5p+6Dx SNsHjUfaPmg80vZB45G2DxqPtH3Ax3u2fcDpkbYPGg60fdBwpO0DTs3Z9gHnjrR90HCk7QNOztn2 QeORtg8aj7R9gOnhVU6bgtjQVf4GhnocaDzS40DjkR4HGg/1ONAvID0ONN7cW3nezAxwWxCSFJNr /CKm2cW8KrwdgT5bFuDzdbYs0Hhba15ZZZid9SzJgcfLe5+0Md7mxJdTeDsoy00I6gY9vPfZGS8f dRn5v2haUCXygtIfJubYWoQ7EASc+ODjvFYWJ0jbvBjNxStHSAMunCHUeS0u6r8C9xuBFyPHKFvZ 4E+SKnBYeDim2TcWb+AkdN+gP9djZ3qLFFHj08VRzY3ZKk22hTCelnofZ8t0AUKT41L4cFuSbSHM zS4HpjTe3FiFKwWNfj+6M3+Brl4+sTpJz+LIqpeCLoW3w3C02tP4fTuq6R9M14IeOQil8XZBVMiT uNlRJjbUG9yPVcrLFN6OsaYHw2WPlsvFRmmw649orU/ft4Nwuc26YRF0TJLfQQ17JEMdd6S5Fiko gvnJhtpvTG/LUhAC87+dxaGo9uEgZW0b0s+GOuF4Dmp2nHw5xJpx8hM3eKs4+xMt9rrhxyRa7HXD j0nkl4cRb5/BDGmmZxGjdLPytGO+53FWWJzlgOqG9pEjpxvKWerLRnVlluKnfEYD4PnlrhJ+g5+0 W+8BV1dcL9Z2+EPLPdYN/pNfntr7430WtmMR9VjYjrbT9YoGAn0LNRzoW6jhQN9CDQf6Fmr4KnKX SAm2CO7pFXhVpSR7eo23Qzucnhzx9h6L9/R1gx4SEtJNGm/HGKKcJtf4RSROzodrvB0MOtsWajzS thCnn/b0rm/QT7ogj/hFW8HIkUqNt0Me3N9p5I8dCeWOTXGDfnLcU9yQn1ZZd+DjJUc/j+M1dTEH 70rB5ZODd7Xi9ASXGajxi223Z1dN4xeVRJJPw+kPkk/TeDsmwdv0jfniY1phQ/8ErhUf4Iv2TXIQ Bmf/WSqu8XanQFq+JeLLPeTEp+rw6eJjWn6Dfj7bXTemq9RZPdhhgPMs+AY+zPQsio8ksQIvR44D lB1+Nmm8h89X97P6sU8pdjnIA6u36MSVgsWfW1FNy9ccL/sB9bWZBOAHvIEXevzyAxTe1uOXH6Dw C7ueOXyn8Yvy5n6M8EVkP/COVeMXbkPj0DtOfkocesfxWVx2jbdD72cCD2d/CSLHMH+KnLbV+EUP ySZmVOFtt4eAbEZhejjlN/JnkZOTVAA+v2cqAOcnnzCrG/zhMqiR/+t+xKN82nrWRU41bODzTM/C LWmcmoDlWfpJjvNlV/ByGZTH+Rm4DKps0EPqoTRcHrjCueHiwMmAiEsnHwavG6tF+hcb0vxkQ5yK VAQ8bIhZ1GdoSK/GpFpYFhiFHXOtM7hHEQCF/9yCe5cG8NzBZgT7NH987kgz4gnoxoHOHX4mfJ/x c0eaEU+bxAn/ExtfZvptejhgNOKziS8P/LH5WR/4Y/OzSXxb439l4nue8T+38Kz9JvzcAGnCl635 5U3T9P1o4kOc8d838dxGc5Tnn5r4lGa8OV+8i3D5/fl65gU6qaIHvcA38Cf/aHt1mWNkGr+qwPB8 skO/sCgJkT5kGr9o2hNFzyv8omJDzl5q/CK8kzm0rfF2Sp/8ujriF4VWcabH3G9wycb0/UVhVj1G uB3tuBQDTD65aZP82JVccmsEPrvnLRAab5cZdmmKAnOHe+TkjA+XT4kVXBjOSyA0fNEhRy6BgNfK dQmExi98KL4EQsPtrTMbxbJBPrlQfpQF2yWNVXaIMJ6NbtmYXDK6Ez126CiHI27IQs58cAFeWvdI Daw6+RKIXjcIukI1sDjUKJFlhbcLVLhd+Ab7OfKyoUpCk+wPLv20w8q4KpFTXx7nDjcYLyP3F6fK pCOmxpsFJFywMdGzCARVzpnC7OQOPJOhsPkTymQo7GNE7PGEHXznlCZOPhezbnw+tdlQLPrvpNlQ 2G3VOauScV3FzcZ735AeDr+M7LHDiFxZmfC1y6fEXN6QNrLTfpT+RYGH3JqAT2+TM6ewbYn93ECh ykEa9mzQI8CG858rMCa3c1GxwWdIYS81kaXuG6aOD3FNbtjyENe0GhcFEtLQVuPthjpkemvGlW3i eMeGMkxke3vExVPacvcN8SlyKBRWntKAJ+LqgQM7YcO0Syvv8ft2wUbL8/cX/bO9RBNRdZj4sg6P 05/J+E67OruDjStbrh531JmWrykPmbax067LNNY5+NnTtumhXWwqG/REqY3WeLP/F+3vueVZQPf3 Cgzt7zV+kbUJPFEab6ZPOctDA9X4xfZeDmRo/OIWr8qVXxpvnyght2Rkz+JAhhR7aPyiy0zm4hON X2R5ArvwGr8Ir/DNX+MLdnjlrPbA+V86nw7W+EV1iFR7aPwibeM5farxdniF/Yy6MQGtz/TY4RUu 9Ky4/HMahvw8jV/c88gRAZh8OZMxst+ukvediyvg6T0jAhpu39FEqzH7De7wDj9uDDdJZw58uHxX 10jPorjC8RZc4xfFG4XdBo23DwWQ1+86Lv3cY3davXaEgrz+kjf4XwsnLfHv8xUgbWO+2oO1sKW/ P1iLRQikSzQYJuja5MP6/Nrka7y9jXKdN9XwBEhvlw3yz0Z/8PLlQxOTdbd3vXJqAudOTOz149xJ blbmy9YuqePLN2Y5qg8vr+s+MY3/rY1v8/JdtIKRUxY4P0tlrxynn42v3+BnlRw/7AxEMr59w5uJ k+uz6ANDLv/GSuEyy4DLAp+wmCyd3QiDXOvacHqkbcwGObTQJ0W1dOClNQfov79iMff9DQ5l5xQe Sc4pOJKbU3AkNafgSGZOwZHEnIIjeTkFR9JyCg5k5RQaScrBpJ85OQUHUnLwnJ4ZOQVHEnIoX658 HDrSMx2HSsDle7+hkWQcujSuXJyCA6k4hUYycTDpZyJOwZE8HAw/03DwlJ5ZOAUHknCwAJw5OHQh XSk4WD1eGTiYmjMBB8vAmX9TcCD9BrP9zL7BpJ/JN1jaJfeG6oy7Vw7y5e6Ug3bgSrwpOJJ3Q/l4 pd1QPl5ZN5gzknRDNfWVc8PhknKDSZeMG6pjroQbKjBXvg2mJVfZGYAqiW/T6BGnvcj1j6jdiHU2 SourMeokvsu7ekfxXd7V64ev280/uSNJxGnvjavkUc5c55ZRDSbHlgu8sOXyXVzEkpeTOejCljPI w+pYOuwlHhl12F+x9pHTu8P+BrfD21e4/Q1uF61f/vob3I5uRyeOwBvcLumPRTj4Bl+49xILeUMv IudNRAsdKeuXAb7YDPTp63afIVYYVcMXvdkDp3FgxjS5lwD+epOGozAju/QbVfBmw9v09WzBuRA3 eQ3/Fxved2gPrAEiLL98BiE3eFb5pONAy/KcYws4LdyyYGOkZNr7MFI7cBzlghgFt9017m8wCKQd xub2Bh3WA1yc7AcZ+E8bLpe9oOIeijTaQRUBN0sPEec7J+Ibzki+CAcXmSY9c2CRaX0S38WNckG8 QXRSOZQeYLaLE55gPrITXjrMmejlELmC256sb9PqsOEcFs847dwkEJZ2CYoPfLRj1rS5bg2nJbnJ H1hE3OvkD9iTmk/n8Q2+cKvz5A/YbOcYWMKJKVVy6Sgj2QsfiFn6a3zFC+qvvWI/KSt/jcM8b3Db oyLBjV3D7eAa+aTs8aJfZ/euargdMCWT5Iav2z4St7wd4IsDtm0i5p9t/65MXzdvpJN+t1HDne2w hYnv37PhbWuoLIrDUJfda0vDhYCb12q0HWDlAoeg4etWtAkfae8SonqD254AX3s48HHRoVJaWaDE cCeLcVLtOKWXklSY9iC3mqCrI4RzpwxOaiCrwTsxlHayGg4XyHtI9g1ubjj4dOm4mGzaOci6wZki zboU3PbCOcZaYCUWityyDYsYt5fAl4d0lxiWx6p9vFx/ch7JWx275VYR+Ymue3LqVkGRQ7cKvjxz q7DIkVsFR07cKjhy4FbBkfO2Co4ct4WJOU/bKrg34WXmjHk29MreKbh5tJUbGYzwT214nuC/NuHn wVxUCFihjzKzOGbrJvi3TXiIE9yUXtahO/A0D3V1ZFYuwkI9RgX+5J9sH7Cw6td4OwLDTuAAN0Mq V4xP4xd+miRjNN4uKWC/bvz+uhFKHfCLyJ3jPYnGm+ED6XE+4m0nOTeOH2j8oid6YvOl8QvvznGO EOf/pQ4U/tsmnqODZYOesx8ajGe5L3LaBJT7NzAU2tZ42wk/Y9savxB8KSXXeJvxvM2vA34h+GX+ /kLwA5eqa/zyyo864heCH+fvLwS/cH2Mxi8EP7BnpfG2oPGmKW7wn3dNo/zYgs+l5GGDnnbaKhTP gs/l9uhdNwoMxQg03o7/nwpfwRdVVZKl0Xi7UVaUEKfGL7JAdSZ/kalxvC3TePNyJJH7OOAXl1pE UcgKb8sx53bqgF8ciSjHNL3L7E7YYA/tQEIZ8At9L0WrGr8Q+8ZFou/in+xZgtxaAm1ZnH9dTMs9 i8KaTuW1Z1HwH1pw76TqQeN/ZuKvjYvCfzDxIc942+M+w2ga/9HejIxgu3FODjgjWWNPlNj7nFJn vL1Z4ELCkZ5Fl6AqHjdMTw8z/qvv2tuROL+waCvUZry5zeTjM9OA71Wf4eXrmxPYZz+6cQ9N6QhH qD9ev8gaxvDyze3z6ak0Lrv/5MfDH16fz6+fv588fr6oo5jLPN5jt/ovTc9j7SOlwx9enz+8fyf1 4fk7gbNOtBYO/AmD/9WOg3UuS9P4RbFhZhIU3K4HpI0/mVKNX5Qbyt5G401PIJwLFCefeOfjgLfr QqtUHWu8nQOkBT2xfxEOi+wSPqNnJRvT8xzzKFvDH16fP7x/l62H50/p5QMKmlhzn82lUbQ/0fjF gYbGtfIw85KTkC88mYmUVRiF8a9MvPfcQkHjTcci8dnA8ftmZoF7EMSd8UbPZ5413q7XIj8zj2v7 7peOKvD8dYYVAAU5aaXr5/z6+fvJ46e0sn7Ncvec0Gnmnsh/82WAm+58k8vgNdy+RSCR66bRdr0Y n7sPODGe0/jjWO3j066z76zxtjPspS2Hxts5SF9nehbXgEbuO6HxtvMcOlfpaPziwAzpoTi+YC5S Pl/u4gZBZMB83pgwsmBhpGcRbZMToRq/CCJ0rnrS+LsSWK2zlXcwafjr58P794X68Px970IR+2+2 d1FEwz0Z3DvehfSQfsbs1WBW5mz4w+vzh/fvzHh4/r45VMR6xBy+v9SkBcnwhpxK0W/8zaDA79Se v4LcgQNo4Gnir5/z6+fvJ4/fVeBBluLaUPLlNWmAmzq2yVVYGm6uKC7y8gPc1Gg9iwJUcDuWRE4H e4QKb+sPbi/vceq9jxxc0Xi75sRLfajG2wo/+JmeRVA3zfQsilqkAwDMfg4Cs5Oi8Av9zbcmavjC niQy/wPeNiek7lvZICdXvmcOF4eSjpH7iybznCfHhacG7gGv8ZMxeXfNr4zBpB+vnw/v35XGw/P3 jYkiFjImTwZnGpMnvF4NZmUMhj+8Pn94/86Mh+fvGxOUGXLsZIMZ17kTQ/Bm43MdPdFv/O1gfO6j k1+9stcGGI9JTs6f09vnz8eH7xoel1+vNTMzZk1qPzXcNjxS+6nhdoI7yHZUwc3F2qX2U8NtRemk +FPjbUPFhmeALzYO53QrvJ2DCXIQX+MXdkduPNR4OykRg9gphbeTBtc+AGYP2QXfn35/IaIrTTct /vPn/PpdxOen76tJRSikJlHG3dXkEylfjGSl5YY/3J/Pr98ZMT99X0WijLirSJQRdxX5hBGDVpIf NfKtgUuNNU72+Wt69fz5+PA9Zdc8J/eEPDPbT9z1QaPtqxYzp74V2lzM3bEqUmjT5+mF04sKbUY8 +LonDba1lgtcOangttJynQ9RKPjiZsbMhygU3M4Dezl7peBmrPjyrGFiotxe/oQYW8hsfTMuwvPX /O5dQuen7+oqRSOiqlAOXJpKwUdF9d4obEWjf9+fzu/eOTA/fVdJoRy4dBTKgUtFPeHAh9ufb47W PFPJ2G9uhVb//V/++ze3P9y+uP2JkB9u/w+6QbHJCmVuZHN0cmVhbQplbmRvYmoKMTIgMCBvYmoK PDwvUGFyZW50IDUgMCBSL0NvbnRlbnRzIDExIDAgUi9UeXBlL1BhZ2UvUmVzb3VyY2VzPDwvUHJv Y1NldCBbL1BERiAvVGV4dCAvSW1hZ2VCIC9JbWFnZUMgL0ltYWdlSV0vRm9udDw8L0YxIDEgMCBS L0YyIDIgMCBSL0YzIDMgMCBSPj4+Pi9NZWRpYUJveFswIDAgNjEyIDc5Ml0+PgplbmRvYmoKMTMg MCBvYmoKPDwvTGVuZ3RoIDUzMTEvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0KeJydXVsPJbdt NuC385IGSPJW4KBIU7coxqP7COhTEV9yaZO1N3Eu7lOCJDDsAO5L/35JzcxZkpqhKGOBXejo0yzF IT9Sl5G+ffzn20fIz5Ly8+2fHx+9fbx5fPtYn6X65zfw7/r8+pGdf/2Lv3/9+Nvji8ffH+75fw// /Dmgvnq49flfjz/+z/r8MzR3T/zzv399Peddy/NZ6/H3+by/wJO+ar+uz88+eeSypGfxCf7+Zi/k ui5rAOznvNL78CphJS2ftbLtUb6o3gUAyUErH37sn8493/4F+oO/umcJz+IAG59vv3l88N6XH/zr 269QZZfgbV1CZPhfq/CKYhP0Rxq6piV7Bv9Ug7vVLYUL84mOL8uWJvAuLLVMyOMBWCee7/PiHcO/ r+Pr4jPD/7OKD3nh8N+o8LjKx3+m4/MSNob/g4pPcQn89f5Wx9dlmzGHnJYaL/s7cB9eHUplvkfL Z23X+OV8Xf2lrN5zO/kPrWMe3qNwOlURPvolpktFD/rCq1NITBG0fNZ2jV+K6OovZQ3CIVVFhOqn FBHqdqeIgzHzLuteKh7tmfBp5nya5Svn9bL5Xr6ovmPhjORadzlXlVX94jKDq466bYvfGPyNysJx iQz9SxWdl43Dv1Dhdal2yd0KKvYMr1PYWpfMu6ozqvMYQSj+JyOGF8/X5QeGn4EHv1TH8P+t48G+ nf1dIcNv3HA+ZQx5b9Ki/vT1LJ2f13ftT5/o6m9ZkgprYcmrzmksSfGcJe87I+pPpnspg/3wqu/a n8ro6m+Z0qyMgynNyjiY8koZB74sIdAWcYXkiLf4IePWs3d7KW5LCRZyFIZyFGXzvXxRfcutKaOn m7mVwC3cSuAGbiVoC7cSuIFbrZKf3ErwJm4leBO3EnzR8bWZoFU5zjvRXVU5zsdmrwT/Kx1fxKsS VHlroSOqE95/FLv2p4l39fdUSYQ1UeVF51SqJHhBlbedGVEd++FV37U/ldHV31MlEdaNqLJGzW8k 9QVwtJVzxI8Y9Z3S7iXIl9fNwl3ixR9F2XwvX1TfUl8Ii7OP7Qn8jyo6NXJ6h1bdD3hyqxStGlyF TjmKVkkV5wEc66c+rgTiywyu8wzw3looXKdVlxZXr2Qfvd6R3wtXOIpd+9M+uvp73ngnq4k2jC/x ZI3+tYx6MnJ69sOrvmt/aqKrvycNoybO9MqoiTO7ujHQADbGfBaisgMbLQ371J6MUEjEfDUQHSgF eY7A9cwmN5IjcN3B6+K4MCMP91yYgc+uLZkg+H9UH78+U4WxWqNnGP2Dz2/Pt3+CZj947/vYcMXS /f+2keYfvPfjkcODLVD8x6Mx5DaFz/L5+jRYaG5H8bpqQ8HEyI6PQT5fzwNjXpJjeD1Ri+C8heF1 wk0J81KK1wfNGaLFNqFPCLuBwfVgVEA9nuG/p+PzErcJdSK3hQnxIU5n/rrUsO4qqIfjP9fxZfH8 denhFJKnws1BHXZ4cPnAn//ll3oDSDWKXaHewTgi2O3TOxhIVHuHvYOBBH++umTiwd9Ttb9gD/4u FKr3F6Jh4fr5qR7GHaZuZgfwwprVJRCfIoYNu/CpSOdVrdPnFjDMZOJzxRk1uzHAwCWWiZdVNvly dWVucSkT4mxlKXnCNgHoJ0yhZlzBoXh1DO0h7xGmpuIDJPLeTfh6gFR+xvYD5PJCIJV8ggvSd/VE zwE5c/L8mYr3fskT4uCC4YS1hdCG1ebQHiAV2Dj+Fyo+xgndx4IJpdmWQ1oX5+yuG2A47vm7UvOA AHlAmXm3ua0em103lLZ6bNdPKTgfZ3bGsMFoIk44FyQCaZvBbzh9bZcfEgeRN6vLwW0WJdjfb1yT TEx+p+Ihrvts728EXxdcooau6NrytFk/EXx9xrmiiFuqMUQI6iKO/l7FxxW3WpiNP0ISXyaMIUIS X6rd2WPy0rl0Y0jbUvOEPNlL51J3osS8SefS9VPi4icGRRGcPXBjUweBcQP9TJBhBOcVSa2aJ0Wc cePyq4lDhKw/TiSpCbL4POFcCQM1l//7Kh4XGyZGUcklOQhXV4WSeLmqM6bgpDPqaUzCjToTVNLm J8CCqmU537k9xSb4wZr1ilMzFD9YWNlTbIIf7GKCJDIxvOqKbT6jMPxg/mNrcc4sD4xvMu+vPuCN e45N8Pq6WXJtQoDgVetxMMRJXB59fgiGOOvM+8oZd6lRvD5gByqckgeoUMij93dbccWV4vWFua3l zASuMgPOBOY2QydnAn9onQl8Nf/gvX/XPc21DJfg1ZF+8zTP8LrlHTOBBD/cToIzdQSvWyrQkOPy 6JYU6uIKw+tvOqbGFASvMxd6jpuQJ8XGFASvez562kx/89qYxax/8DQujj4xWfzCpdF5rmwthTBr c4ttLEvw+jzvVlsKYdYmrqPyt6vzBC6KVLs2/RoX7lxq+u/duhSuTn2uAtJ/Ycz6zBWk/36zq8d7 L51XDXveg3qy3Rx8iNI4B9OABVdB7fqBEYMgw8HqX8Z1UDM5eBgBCHNWvQVnAjc3IQ+ESWHO+vst a8uICX4YZ6ALuXZx5kfWOPNqbowzBD/IAEszbYJXZ6VaXAoMP9zliBkdwQ/iDOqH4fU4ecQZgjfF GYIfrDhtUn49I0prG9ya9ZMybuu0vy/M6Lj+debFjI7bj55H7IHG/LpKwl2j9u5ubqlcHD3Bh7Gq m3i7Nbasyfp4v664f4fidaJb96EkwY8XnPxmf1244CQEGi44hQlz8+C+yc3g234Yu/y+bQS0KxTS UDdBJx4GcDgAtbqLj6Afbp8/1yPH2lZczf1NoQ2AzO8r7Qt45v7mfQHPLE/eF/CsdO5hALd5O735 4toqg7m/pX3XY5cf5762GXmqlH+wZta+A7LLv828rJraqoS5s5Dlitilz4qvWT5fVU4A8kkTuUAA MslcHjUNCn4u1uESlYh1en8hbd2SXZ+4RCWer68iQdpay4Q+cXfL1PNzG3NayTBAriHk11edUpK5 AEtDL/aOpejRfxHL9o5hpJXQtY0J22OLht0Cw36qYWto2R2Bf6zB3Rra1DzB/0LFgwWL579R8T5J /C9V/JGdEvxbFR85+HcqOHm7Ih0uWvCHv6/ji8T/XsUfK44E/1sVv5Vmi2Z5qpd4p+H9miT+pyre pTbTSPBfqHjvJF61BEyMBF7VJ+6PxSGj9f3iEBnHcVZ9+uQk/scqPkeJ/1zFlyTl1/Fb119dflwh TnbSCZCJC/3zTLxr4PxUh4MPdy+s7bXHVbHNnxv5IwybIJS/duK/anFm7VXEavbDq14238sX1dfE HtoiIJANJfbR/yTqcYMNk5T98Krv2p+idvU3I7QVZF1xo1bT6b+NpgEhgaH4TR9tZRSBwNW5Er9W +fjB4MzjQiXF/8twsMWfr09D+baxm+LVWdg2eOJ4fVoMp/U4Xk9+IT9qpvUOr+e/wFkb1//pYiNb EvXRbdwW2Q+v+q79aYtd/U1+zJWhft6LyTGMHCj+Qz3ZbYRsNsbg21Ks2RiDL/Llq8YY9l0gZmMM 0eFI22yMmOyWaDfGAFmreP5gy1ebuDMbI27hiu7SGEfGJOr3T0SIMbIfXvVd+9MYu/pLeaNQRtY6 F4PDmWeKV2dJcUsPd0x9x1Bsew4oXp0FjGnFWS7zu4wpSPH1HTEp4ywXxQcVn4MkLn07Va6SuPQd NJAMVe576sAag/O6XfoeD/d7CYaByVuSARGBj6Jsvpcvqi9lRb3hJNWR8xi+h6Zw1az276EpfPw9 NEWra3r4FRD0yyzM8aUfxetbC/BTPy798BNnx5+vL3m6IuUZLKyAjSeGH2wQqPjpA8XrU9cOaCvw Bv8wWolZw4RAse3ZtL+w1KYeKX5wRFDGqVCKH+wQaFOJFH866cjPRpmwyE6OYtf+dNSu/j6TJsKq HyXilzghXnbuJjVuH3JdKXvUmVEqJqLjUezan8ro6u9TOasyMJWbUQbOc94oY9SZUSrAfnjVd+1P ZXT196kEEVb98hNTiRo13ulO9whby2xJix+waHZKu5cgr92KJRwJLziKsvlevqi+jWYwStrqxZRI F57aJ+4UrgacLTejIPDRN7DJMbhK73jcHZddXwZfI07FU7xOpm7FqWaz9MdxdxSvL4O73LJvgh98 yOqkPIONolHKoz8/rDgVb1Y/bndLG8MPgplf+OMHwRWs3DO8Hlsh9m15QpxUcJndbg4ZBp8MrodW yJfzhPEAvWWOF5H11udHkVEEi6PYtT9Jo6u/j6xEWFNkveicGlkvdD3qzCgyimBxFLv2pzK6+vvI alXGGVmtyjgj64UyRp0ZRUb2w6u+a38qo6u/j6xE2H9ice981l7C7xWDJXAJGz2Ksvlevqi+jXsw YPHRMLMFcQ8TAALX4177VI/CVa6ovs2BErh+TlU75pXCBwdVtWNeKV6Pkxj3GHwwiGsHmVG8Oi+D Yczz5w/Pbygcr05UHIcAUvzge4d9TGZWD7iLq5fPH1npiGkF+RzFrv1p5l39PVMTYU1MbVXeydQX lj7qzIhpBfkcxa79qYyu/p6prco4mdqqjJOpL5Qx6syIadkPr/qu/amMrv6eqa3KOKdTrcqIodwp 427MBPmhIBJ2IuKrd62En/umzUL+wmv2omx+lC+q72JH+x64GlY5SjvZh8L1c4PayT4UrtJjbQf7 ULiaxda2/ETh6oxerQvv6eC7Oo8bgSleDwV4JGJleJ2q8atDx/D6zls8ErEwvPpV7zFisssDPrHW S3lGRjeicsFue7Fr/7Larv42FFBhLaHArIwjFFC8CAW3nRlRuWC3vdi1fymjq78NBWZlHKHArIwj FFwpY9SZEZWzH876rv1LGV39bSigwlqmw64YjXPpXkrtwxED0wqbPoqy+V6+qL4l6tzE3WccDAc4 Uvz4cgaKNlzOQOGWyxko3nI5gx2/z1bZ5dkvZ7A/f7+cgeItlzNQvOFyBgq3XM5A8ZbLGSjecjkD xVsuZ7Crf7+c4aq/I7cZhQrBnkexa3/6XVd/H2qIsKZQY1XGGWoulD3qzChUCPY8il37Uxld/X2o IcLq5+num2iuLHUk3Ij62Q+v+q792bmu/j50WN/0MYowv+ljFHH1pnk02Euh7bEwxAph00dRNt/L F9W3oQY/vanmXQEUbjglncLHuwIo2nBKOoWPT0k3S36ckk7xllPSKd5ySjrFW26gsMvfbqCww/fJ J4q33EBhflfHDRQUzyef7k16ROOC2Y5i1/70ia7+PgwQYU1h4KJzahggeBEGbjszonHBhEexa38q o6u/DwNWZZwjDqsyzhHHhTJGnRnRPvvhVd+1P5XR1d+HDSIsWyZ4PWsv7duQDLwsbPQoyuZ7+aL6 ltbxoy/LMUcHrRO4hdYJ3EDrBG2hdQI30LpV8pPWCd5E6wRvonWCt1x+YVbOfvmFWTnH5RcUb7j8 gsIFS99a6IhlBfEcxa79aeJd/T1LE2FNLH3ROZWlCV6w9G1nRiwriOcodu1PZXT19yxtVcbJ0lZl nCx9oYxRZ0Ysy3541XftT2V09fcsTYQ1zQtdkAgn3lbyQJZ1s9CysOm9KJsf5YvqO1bHw3vPI7As 80IUb7jZg8INV3tQuOFuDwq3XO5B8ZbbPSjecr0HxVvu97iSf/SeR9wm3H0vdu1fhtLV33IjFdbC jeZ3eXDj1csZdWbEbcLd92LX/qWMrv6WG83KOLjRrIyDG6+UMerMiNvYD2d91/6ljK7+lhupsBZu vHWTi+/Q8VyIZLvDxO93MozF2O8woXDDHSYUbrjDhMINd5hQuOUOE4of3WHicWtT23/7ne4wedd8 NKvg2uwsxQ9mFdqHthSvf7jhN+wzxev5Z2jHE1O8Plkf2odpFK+n56EuXBx9chyP/JxRDww1N66e wRGh7SBCih9cYdKOTLB3dz8giuL1A8BybTHX3N+S8PRje39LOwTDLj+eKFUYfnB0YcF1c4rXcwA8 6pDLo2+hqlXqU7+FYgX92K3frwUTUIrXozCeXJ7t6vQu4zYEile3FbSjC92EPHh0YbCbA37jvFb7 62pHHUa7OeM30Wnm+bHdF03x6hYWH5OUZ3DUocO90hQ/OFAq4gFRdvnxkpRsd992SQp3F/2AJaCH UCfsrbRzaO36LO1GKrv8W5TRSD/asa4yGun2jNeeMLh6EqTHTUcT7ojHXET+etVvWNolJsnOPgF3 HZUJvG/n95ndN/h2w5T5dQVIJUux0w8e+STMU78YIwZc+jbTbQD33cLE+wLgttnNOeDS+jYhPx4z bPfGkLPMlXTx8cOOYrf+AMG91InXtbX90fbnY7B2E/2tAYH2/tb2mQ/F61c/4PmPdvHj2k7XM4uD 15II6xlcM9IOOjd7F+6xdRPqjKEd9mrvb2iHvdr7C6n2ROocMZb6CfGTk7nS4JiBiFs2zc4YwRm3 iVQVjyUQZKu/XvBGQbb6xRsYS/nrUnMfPMYgTqT+ES8om8g9I8TePDHUwYtJgp94Pi4aRbs9pLWd x2POrY6LSexDEcz7QzJ+kejwRl4KH0wt1sbkBD+4P2DDk2opXv9iEPLmyuD6oD26Nsok+MExyrHN pBK8viUML/ji8gxGyQF3CFL86ERuvBLZf/ebH941Hy7fRTxsnuL1b3z2O2ApfrDcF3BVhOL1AfBh GQQ/mA9xUp7hnbGB4/VXvd8ZO4Fvd8BSvO4JaWsTNGb5c2xTd2b95NJyGoIffA27tiBJ8IMJlHaK qF0evASW25s+gXVMiJjlwRyL24/umngJLO+vfkoZ5ljJ3l+cQOHi6PMteKUrV48+IHdbG/Bbu4sH SRa7NXhIyXB+xurt3peFS68Pl4MX0ugXY4Q9YSX4wcUP7R49uzJjO97ZrszkpPJ1eSAMRO6Lg/PZ 8a64OmFs2UuBVOfC6RDx/MEdsHlxE/3FjCxN4Ld1rrs4e8Kfr8+mAZc4O5V4oBLvJ8wB9/3MiF/3 JSErN+Ai2srNWb/jFM942uz9DW6ToUIfzgI5RGe3HtwggcNfq35CCG3y0+q+AcZrZUKdMUk20fHJ ydelHzmYSsv/CX50/jUe4QkiIfZcd3zz+BayvVLxlADEff3Izr/+xd+/fvzt8cXj74B88/h/uWZM OwplbmRzdHJlYW0KZW5kb2JqCjE0IDAgb2JqCjw8L1BhcmVudCA1IDAgUi9Db250ZW50cyAxMyAw IFIvVHlwZS9QYWdlL1Jlc291cmNlczw8L1Byb2NTZXQgWy9QREYgL1RleHQgL0ltYWdlQiAvSW1h Z2VDIC9JbWFnZUldL0ZvbnQ8PC9GMSAxIDAgUi9GMiAyIDAgUi9GMyAzIDAgUj4+Pj4vTWVkaWFC b3hbMCAwIDYxMiA3OTJdPj4KZW5kb2JqCjE1IDAgb2JqCjw8L0xlbmd0aDEgMzE1ODgvTGVuZ3Ro IDE3NjA1L0ZpbHRlci9GbGF0ZURlY29kZT4+c3RyZWFtCnic7b15fBRVtjh+7q29eu/0noTuTied pRMSkg4hEEkFQgQiEGQxQSMBAQEXgoCgM0LcWF1wQ1SUuCEDKk2CmLCMcRm3GZ84ioOOjoyiuDEy 8xBRSffv3OoOAuPMe+/7ft9/vh87OXXudu5y7rlnqapOgACAAm3AgfWSqxcG/nbg7j9gyQYAadCs 1kuveIT7mwPT7wAI5156+TWzRlw0oQrAlAEQ9c2eOW3G67cbBgLUDEKagbOxwP6i7VXMt2I+e/YV C5dc0XbBf2D+bgBH++XzLpkGiUojwOQo5h+7YtqSVqPBdgxg7gFsH2i9ambro64bnJg/AWC9XNgF GTo8ARl8GHDMxKE+iM9JHGJ1DNMvAUhmElKfDngS/kTySAA6yQ/ghhPESwbAKODhO1zpNuiFe8AB E2EdsUM2uGASjCI8tonALeSBxNWJL+AcuBMeSTxLbkhswfrb4WU4gTP4C0+gAsZi+0kwE77gPoWm xP0gwwowwBA4n7hgGryLP9/iHO6Cu+G35NeJEziqA27A/qqgBmoSzydOQgHcwq8VDijPwB2wm4iJ SxJzoB9kwWoaSbyb+AjC0ASPwpM4pwjp4UdCEC6Dm2E98XIvY+oeeAzixEibueHCczjSKJgMV8Ji WA1b4HViJw3CAeFo4leJwyBCGuThnObAF6ScjKGP88bE0MT7cCF0w6u4XvbTw1/IPyFcGK9OPJh4 AZzwLFHJHvK8UCrc1nt94uHE02DE+QxAjozFcabDjfA8vAZ/h3/QZYllMBIm4Mi/I5kkQMLI8Xep ly6lS7m3oT+uthlnuwg2Qgx3ZBfshr3Imz/DQfiUOEg6GU2mkzvIP6iRzqBvcg9wO7h3eML/Bvkd ghzk0UJ4HHbCH+ANeJMI2H8JaSBzyTxyL3mQHKQx+jX9jpf5G/kf+V4hHD8Y/zExNvEteMAH58G1 sAx5+yh0wg74D9gP/4D/hOPESgaR2eRhEiMHyddUoVl0HG2l6+jj9CluLHcH9zxfzg/jL+Pf4N8X lgtrpGlS/OSm+F3xp+JvJZ5NvIWyY8b+w1CHHL0epeJxeA7ext7fgw/hYyY/2P8QMoVcjKMsICvJ 3eQp8jvyFvkSVwn6TxYdQmtx1Hn0KuTTDfQuejeO/ib+7KPv0w/pV/RbTuCyuIHcfO5hLsZ1cfu4 z3grH+b78wP4cfwUPoE7UyqcK0wQNgtbhReEo2KVOENsFT+XbpBukv/QW9D7lzjEZ8dj8U6UXRkl 6VrkxEPwCMr9DtyD15Gj/4EzPgjHcBd8JEhycd6VpI7UkzHkAnIRmUluICvInWQ9eYA8Qp7GFeAa qIRzj9AaOoFOozPpTXQFvZXuwJ9d9DX6Lj1Aj+DM3VyIi3ADuFHcFO5C7kpcw0JuKXcTcvYObgv3 Jvc2d5j7nDuCu+bm+/GL+Gv5+/gn+B38W8J5whX484jwnNAjvCWcFE6KVPSJGWKxOFfcLH4sidJA qUFaJb0j/afcSjJIAc48AKd9qBfPYD+6hTr4ZeQIFmQSHiy48gjuwwQ8Ff8J1Vwc98XM6nFuTurl 0xilqPExpF9IdkM5+R0sEymHWpE/CB3kA3qQf5GeA/tJC/HyT3BXCq/TIGxFbbSW7qG7yTDYQavo ZLqBA/Ip2QyforwvgbvJZWQBbCVHyGByHakgy+Ad6uImkJugKvEI5YlCRpGjgDOA6/kZcDH82w+p hA/gi/hDvIn/NeqnLliHO/okfER+Az8QIfE1ajcOtdE01DK3oLzfDEzrNeM5W4bn0Ysa5HLxTdhB RNTiFeJQ/lo4Ct/DF8IulKhhqEkPx+fwD/GfJCoSRXjC8JTBZjx3s+FcPDGfopTsxTzLXYQnXUVd UoqnugGmwAy4DrXeHYlYYkPixsQ1iXnwe6T9gRSSH0g7nogupKiCV/HndniPrMFzeO6/X+e/+sRn QA98STwkh5TieTgiXC2sFbYIO4TfCm+IA5DbN8EDKNEfozSruIJL4C34Er4jMu6NFwohivMdhHNv hMtpE7cXhhMftOKZzUM9Piy1kgXYyw3IvQ14nvfi2TiKeuIi+C0cIJS4cUWX4Pgy9lOPfJ6KrTfh Dt5IOrFkBmrtAvgK120mg+hCHE/Dntah1urBOX0AnyG3E/q8ClEv1JLJ2Nd3cAHMwBEGQgPZDnWJ naipxkIt9wfkdzaxwjCSRR5DuhY8oWbIhErhE0KhMD42MYjO4faijUlgeTtar3Q4h8zHWVhwHb3g JOOgPH4+FGqaVj30nKohgysHVZRHy0oHlBT3LyqMFOTn5YZzskNZwYC/X2ZGus/rcbucjjS7zWox m4wGVZElUeA5SqBwRKiuJRALt8T4cGjkyCKWD03DgmmnFbTEAlhUd2abWKBFbxY4s6WGLWed1VJL ttROtSTWQBVUFRUGRoQCsTdqQ4EuMmV8I6ZvrQ01BWJH9PQYPb1WT5swHQwiQWCEZ3ZtIEZaAiNi dVfPXj2ipRa7225Qh4eGz1SLCmG7asCkAVMxd6h1O3EPJXqCukcM3k5BNuGkYr5Q7YiYN1TLZhDj ckZMmxFrGN84ojY9GGwqKoyR4ZeEpscgNCxmiehNYLg+TEwcHpP0YQJz2GpgTWB7Yc/qW7qsML0l YpwRmjHtosYYN62JjWGL4Li1Mfe1hzw/ZbFz+/DGFafXpnOrR3jmBFh29eoVgVjP+MbTa4Ps2tSE fSAtzalrWV2HQ9+CTKyfEMDR6M1NjTFyMw4ZYCthq0qub2ZoBCtpmRuIKaFhodmr57bg1vhWx+D8 a4IdPp/WnTgIvhGB1RMbQ8FYdXqoaVptxnYHrD7/mk6vFvCeWVNUuN1qSzJ2u9mSShhNpydmnqrT U3pzlqo//xRnCZtRaBQKRCxwSQBn0hjCNQ1il5mDYPUlg7AZfpoIUsVm4I7MiSnDW1ZbB7NyRh8T cqyhwOpvASUgdOTrM0umpUrEHOu3wJJMTk6JGtb3pWORSKyggImINBz3FOc4VM+XFxVe3UUHhlqt AUTIPmhA3k5rGlyM7A8G2Qav6dJgOmZibeMbk/kATE/vAK040hSjLaymp6/GOYnVtPXVnCJvCaEk 7wDmjztjcvjUr8XqShsxe3CMuP5N9cxkff2EUP34KY2BEatbUrytn3hGLlk/6FRdKhVLG97IpdNU iqZzei0K5UWnGrNMozHG5+CvqAv1jBiHQqkXkEBdzNoyMnltUoPBf0nTJcmnEXUljjIqHf1Elppl bHDkzPyQM/JnzM64msP58mFaP3HK6tXqGXV1qIBWr64LBepWt6ye1pVomx4KWEOru+kT9InVrSNa +ja0K7FrTXqs7pYmXMRsMrgIXQLGbQF/0MJKMGwHJXFR6qLVWhoIfJwDVeLjBLyyKMQpt4eEQUHH 0gOeiPV4VW/VWOuxqjG9VVCNaetJvAwoCdqCthy8EDTWJwNcz0lNgB8hwPegmYcasoLOoe04VqkW LCEaGp8KHNnKBbgSjudqBSsEoASrvfzjl3siY62HmsdYP2uG4iPNA0rSsOcamodumzd+mPVWhh6M UehBLyikTX3Gs9PXnf46/4pnn2efd59PHp4+PGN45mTvA/w9ni38pgxZ9AUgT6zwjeSHe4Z7h/vk bE+2N9vHucL8ZH6lZ0P6howNmVsytmTKdsi0ZgYyB2RenXlT5trMdzPlzK5Ej+ZyOKOZ1Gq0ZLJp UjZTDeeKVZ12VxS66MOdlBgtXWSyFvIbi43UqGG5cVOaoBxwudB0EfD5LQesi6m339svsOUdG3Ps yFjr8flVVWOsR6C6NzL/ELIy0jy/ymavJLaySDNKVzdkJno6bJVsDh0WHWlmayUvWysF2YbYVhnR P00DSkhz/fjGvZCOGi4DITNxcNCgQU1kfnNzM7EFB9orBlYMLI+GQ1milDMwu6wUjaMoibwo8caT udb2r38bGTyzqXG2HP/cS+SX3ztx7piy+PFzXUSI/3g3Uf68vfqCSRfPnPurjM9f//LpSzqn1xxr CKMMMR8GvdpdKEEqKe0GKXFAUyoqo2IeXiQ2XyWvPCpqeMHcAa0hmIt1eMmHAr5AyFOLjYOgQqg2 zoW5dCY3S5gtX6p+zllGi4TKCuFUReElhaDzJbFIXVR4PiCIDkEQZVXzZQ5V2RAGX2ZUzaEcJ/JK F9mjmUWJCjwGs7LR7fbh7kzTDH6ih1hthCNdNFtT/AopUdoUquyi2cBjCyUgEMFruPgSfXeax/R6 jzfPP9Y839M7dsTM2s9Q0KusVdVVY47g/hTjTkWqVgj9Iyuue2lFfw9DkrWqasVLL+FG1McME+pj /fBQdwOXiHfIvLorEUfWnNwu8oMGpbYluXHBIIc/JJjGccJz8d+29e68Jv4yHUIqC15/mYyJdwq7 Tq6mgd6DKGzrkNPTkdNpKIGFcECrXlxAZpuXFHzGH+d5JehUxLzCYI7L7neOc9IS5zYndTodoawc e5occOQQoOm5rWIbBh71ebnbjMTIhFcxRI1d9BY8kf21/g39W/q39m/rv7Z/e3850L+kP+3vyApA IK0kjaZ10TWdRQMmJJnDTv4Ya/P845H5Y44caz6iawEGtsri5vm64DoTbR2ZlU4muD6G2ranMVlt wkYEOQgIp1hlQVZtVwPIlmZoTguW9qNMNl1MQlFEhSAeh9KKgUx6c8MhzhZMZcKhdXT001tXTJk3 dfna5oevHh3/NG4ieS88VXDeBfWjC9/aQuztkWETtGteF3ZlXnTf1EufjOTuWTZj73yTTPmX408J ygXn1k5ShN7u+BLF2Dx22EUFTLdMSxwWLhbexjj7HW3McmWVY5VrI6wXX1He4d4xfMspOUqeMc+U 78h3LRIWKcsFWUqT3O40tzufFnA5gpQnVJNx5D7hXuU17ncGiZxvBXIQPV6qqwubJ6pj1YSYTNHc niJeNmtme9RcP9VCxlmIRXN6oqhK8rQse5HKWb4xT4ZvALukxFeSQTKcue0SsUh+qUTiUF/f0pm+ NLUtuBljrc3Hm3FPmEo5htrkUIRhlhhQAs2EKQNB5EMBsFkhGHC73EKYqQSb1VVWOpCvJv5h8Te+ jn8QX0muJVFi2jyjNP5n3+NXP/r7V9uv3kLTLzz6BbmdTCFXkns2Xhyru+qmL+M/xL/8eh3j2z2o k4+ifBpgrXaOLPCSnCPa/QIpEbYJVBAUjs+hhKpKjgHQFa/n6EgVDMTgC5hKTJqJM/FKgDDFinxC WTOeLmv6qqrGHKs6VvUzoiagjGVWCihjKGrCGaLGCXgqB5SU2YLOYAru4atPfkEP9ga4MmHXifju 7+Lzv8PZ34uzvwlnr8BVWjXOXhRypIBcIj8nfyTzxfJamcoyJJeg4PyrxXF4ks7n0IpSX8BQYqCG M+ev/tz8m9n02eTtbPI/N797uSO9Q+iM3g1sbo+f6L2DcfYWvOzAuXEwT19tZ2k0KjAhCuXoWKt2 uKMgaEKD0CYcFAS/0CK0CkcFvk1AoaEcyJR7D619DGMuroeJIpvnPszxcCU/YGNKeq5KGfTqKmZN 5l+FPMSJ2W4hecKuH+pwHg8ijx4XnkaX4RzN1yCxvnmUeJB5wSdR7vTliwO6T19+nPU7pjfVNes1 6HyQ5NGDwtM/jvqOrREXKnpxjUbypGYwcGE5bEC3gHC4nZqSMTiqBgYPiSpdiYOdKaw9ltEfS/Ei KrL6ifK1ilpQVdNoBm9V/GqIFvIBpVi9lM7mZypz1cV0Cf+YskV9RtmlHld+UF0b+bXKRvVl5TX1 T/QA/67ynnqYfs5/qnypmhYrS9Qb6S38jcot6loqNRpm0rn8pcps9Wp6DS/V0nq+VqlXL5AvUBpV yaMWm6N0MB9VhqjVZomjRl5UFNVJfbxbQZs3RCtCKxbgZUUp5XgHx/HUoKqlHMUkNcgcZ+QpNapo 6CTZbybmLmLqZJHqLjpI3+sLm5N77J4wMSqUSpq0TCby3mXImr2GgMFIu+ggzY6bq2FD0LARlPqZ dsduTAMWobd2bP6RSMRa9Tdrlc9r7Z3fO7/K57Gi/cIC66H5uC9W3bDZ3ZVnGrSIrp/TJuAJkxMH txsCzG416x9dNiIQmc+2khDm+BHU0neQ3UQlEtkTPxL/MP5J/C9ovTzc5z/U8Tf8uJQB7vN6tGIh ds7IJs2scKLs5dwyb0cJxa2GTruhmutKrpphrQAXxJVKskOSZE6mVOIUZBeyiuPZgnm2YL5UfBNt N4qd5tUMDYYWA9dqaDPQdkOPgSbPpqykOlV0F2rChKhSqktrD/Pi9OO66JS8omlH44aLPJ7K6WeC Wa1KQFjRny0eGTSgZLhu4dt2GsrlNkO5PuFzfP2j8gS8CJyLK+U0jq/jbkb10S53yIc48SXuTfl9 GZ3eYjnKDZHHyXdyG+V2bpsc456TDUmHqaw8SrUy3WE6qJmKS6M0wC6SoxxL7tWUYP8onYgXvXVd vwDm8CJTSfJQzi0V0lxpCC2TxlJNuohOlhQHTZfG0BHS/dJW6ff0Pfo5PSx9Tw25NE8aLS2RVkpP UpGd96sifR/o2+Im0HeYnVdiW08CtJGkxf/Uux03toh7+4c6bs/JWuYFNqHNPIw20wLp8Ig26V7h Xnm9cb2Zl4lkli2SJ9ezRFlslxbbljiX86vkVcbl5pvtqxwrnSvdKz3LfUbJjjvsc9p9Dp/H6ZPS ikyKt0jiXLnbVAKqVQ2onMr8lEBJppbZktma2ZbZnikGMo9m0kxrbjsQC/j16IHZw4ylL56yh7qX whJQfaT6CFM+zfPRx4iiB1ExsCxlBoE47Gj+kt5x0/DSpy5d1Ulqyc3xpfG98e74UjLgs+3bP/nw 2WcP0ncOrm/tiAyOXxm/P/5gfB4aw9nfxxOJxMkTPzI+MBt4AqWb8WGxliMK3Y5uD3euQC4V3hWo 3ZZjMpsh3cqsiAVkXJ5EpJQfxky55vJnlqTWJ2RaLadr1Iwzna+k7/WTOdEjMGier2tXNOwp5ykU 8lJcWsp3uof8mZjPX7pl+r1j5772/CPbrh5+8cjydmGXK/jhthVdc2zO3j/xL8Rb+k+vaZhtUnFg 5nPuwfU4IQgntBsqLaMsF0hzDXONW5QnzO2hneYDiirKouqWXepAc525ziLJVsXmMDssDutA80DL uZZF5musb6uGJcoS79WZK5WV3uWZouJyKEaLeYJ5kfkm893mR82COWAyOkwmo8XoNLldOWlWB2lx tDuowwGBIGMXMs4Jspm597lgspqo6Z303HYxJvaI+zCKWdEaIoFQSYiGgs7TuZY14JKfuKbLQspf 1XXeT4ZYP914spvN11lfIraUf4oeE8ZPyNBSnZ/okrrTglx/GgrZbD9xFd3QeV/tb3vh+Zbr5nbG H3r3qokXz6r68/65VeNGZu84LOwa9/oNj/8pY9DyrfGPSfXWpmDvBm5sduOw0RcaBWb5Ric+4/+B Z6eQxLRzum1dmTvzXi7k0al0olPp9ERmCjPzFopLTAvz3jO+GzI2qZPMk7KaQrONs+yXBufkXVq4 OHN55rqg0R5i1rGfP8qwNtPri47PGh96Puv5ED8/a37o+qzrQ3/N+mtIjKgFpuys7FClKRqqV+tN tVnDQ3NNM0PXmK7NWmVanbVJfcK0OStNURWTmCWGvKrX5MqSskKqiSfuyR7NG4jO85B5no0e6tlF Z2LE2aMZfZX+dJJe5OBgJGFqaZQvEGVRfgNpIWtJO4mRHiKTv/Gar9LKE76oQPF8k3ATt5bmjrrr pdywr78/t90as1JrPfnGltxAb9EfUzJfP6FxO2iDmvRoA8NmxJGrmI87P3KsOXIoia+KHEIjllRd umOYhfxIzxyK/NiXwp90pFVmIXsQYe61DjvL7dMs9kpTwF6p6mBhZZ9rZiOWmSpVD4O0ysjpn6bU UUvLcbmSiiNX/ymPDkSlwiedakl0OtwuXpcc5nGPJgHfxhW333HOedHuv7WsWPbNb4iDuKX4gbTr rrt+VHHhIBJ7c9EtCXgu/mX8XfJhxh0rrxkfHZVu7z9k8jVPt7446x+vm+ZfUp5VGc0pnnXF3jVL P7iMECY/hahzuvUI/CotVKyU8CVCg9KKse1aRRKJQHN4jkogKxgK88uYnSRFmipKGA3DMnZKMGvj zA20lbbRtZSnXrn3yRTXxzdup8h13XPtrcILRsKHUjqnSnfl0DCUM7+VfBQfw98aH8u/cOLEj0Nx VnehRcjGWXlhtTZIkiVFsqKSUM6Vz1WkC5TJ1nXWe23rnQ+4nrA+6/qT81PxuGgwGY0YpUo5aYrR EDC9yXwhNOlZWnpDeks615relk4D6SXp7ek96Xw6QR824C3x9ng5LzvovtMMuB6bJq13FdP77LDr Lm1a0IZb4tKPLto0q5mGssJs3+4ieYa023+9tM1H8kquP/D0H99b6shEI/fZ3kFTrrh03dNc5GQ8 fuL9dU3THpi09DjjugQgrdH91Uc1e4SLiAFDmYEHkRg03+CoiG5rJ2LuNNzhLUfv47CmsLsVXrwY +3LAcgI7tRe7MqN8AC8SupCi0QdOJR9yFOkL9bDxO+V79Tuj8IrwmvqK8X14Bz3Wd41fwqeKspV/ VNiqPm7czXcKu9VnjK/ySn8+SyhWA8YH+LuEB9R7jPILBl4IdCVKOkV0RrsSpdpFHBgDwFEaIOBA SVJFQSg1qA6DQVVECWMfxSHLCm8wGlNuq0FEXxXjHd7ICapBUmRRliRB4NEfI0kHFvUzClkx+qdd pERTA+Jew16tmDnxmDUG2P0XSrymvlssPu+Y3mafp7fX5+1t9vTdZUl6o9bUj66X8demX8HGnNQx p3upZyI8m7qNRyWQ8mTYZX4zu8OCHmoaYkLIzPgjpPhDYkTdRP5KCuIb4i9jyPsh7reN++YkBkXo sY78sQsPx6jE53x/fiiEoJSM1WZLPjlDyHT5RqePzBiV82frRzZloLfOe0F4lvfS8PLwnd67fJt8 3emv+F5NN4qiyekSva5cMd/Z5F1Ml9NN4jPiy6Lxueh7VpqZXTrAVmjK1iL9o9laVh5evJnRedkn s2l2nX6fr8RsiZ6TSdj9yFjm95l8ZmYhKQMNS5mvQ2FSUMuwVQe1dCtePL5osIsufIaXjCa1kHkU WKdjrNYxtijEFprmMPQbEJbzlTxTk9+40UgxWEhgvKCZXVGjb1yURFtQum8rQTaV5QenuslHbjLO PdU9z825vWVzavpiRdTA8480s8A2kswd0s8achvVAzrNul7WrWvkCLvXhfvIma1JrTG/mWnPXNSV zK5yDpc7yNSnKOJpZCq0YmBF0hcjzIVxOlzs9k/FwHIyMxH545t7uuq59Jz4lwarxI18rPmxvZMf uPN35zXMq59ILh74ZXZFY+15I8qsBvpx//vvblr1bLzrlpvPy6jwynV1HSun3FqfkRPIGD9iSPyP 9lJPbtWQyaXhiuyZzHdbgXt9t+67ZcCD3WBPnNAGGCor0s9Np/bJ4mR1smuypynjO0ks54eYhqSV p4/g6031aSPS75buU1SjGWUbfMjiDkFyME6nGQwWUN1B2dfaj/Sz5lMubOki+ZqRtEIbs26Z1Ulu zq8ac6S36rOx6NMlPbojTGehiZnfTJqHN2qGWeIsdZZrlmdOhtCMHrkelSPv7Oi8IsdynWmo1E75 ryuI94aOF+Lx3u4Lt2v26Khrmm+86dKZy4VdvUfvjh+Ofx8/Gn//wqYNtODxca0bt+58+EGmzSbh 2qtRzr3wV218o6XJ3uSabZljn+O6znON9156r/Fl68ueP1nf9XwhfiF/kfaF84SYNihtkHO0fbSr ztNknGOUBtsrXBUebrGw2LJCWG5Z5d1sf8LVbd/pUsy6/KVHGX7G7oiay0ysxNsvqmOLLWraRXhQ kWd2mwE0bAoatoOytSiFu1A38VgVcEuElZIgFJtYwhQchybCly4FHV5fY5KV7AYYu/8VOXYkwu6A NR+KJG+AHWKKgUkd8jR5y0sXq4EVApM6FgagLPID4l+ZLxk357pllzXMchJH5NgbX8S/Iq4jL3xK vy6dMPGOLXs3XDiv+LcvkDDhMc7NeYLJzUTk3bSU3KzViuxNYpPaZE9Ky3oUjROK0tqvrR8dzEWN g51R72iu1jjaWeu9T1EcurgYmNRoZoNktuBWqO58sylMmKRYLOC7nclOUPZmNladWuH840mJ0S1x Mq7RPVWUFdMccY46x56UFrG5KRgsTy0QIxw3RnGniwo/Lf5jzfYpz8Z/jL/QcQPx9tqLa6+dtvKm S2es2HBhE8lFj81MvHdT68nWLedd+fhjzz68Eddbg+vNRVlxQAZ5tBuseE7qDJX3Kfeb1lk3C0+o u5Xdpi6fLDvISHquWKeO67fZtFPc6XtFfdX4rnrAeEL6zmTKsGQ4tfTMqFMz26IW53PON52cU5eG ftU6NrsR01s1DBPsDeYWMzV77Myz3OlNj5Iyu34PNTOQvJealZ/EkaIk9mToWLOgsmxnDxWtOO2p djuyuZM32D2M3dkGCYKk2JkUouJ+U/vN67exH9/PEpQ1kyWKDE/pusgZN1WPoGOpOTxanqPao/Wz 4AUVrIdpYt0vrO7VHU87TgJb2NlksJE9pYgZ7uhreixlonQCwAp7JZt0h5uhWKeiDtWzNcFq3Yg1 HWIqtFkf3qwhl8xsUDMb3qwhs3RD16Q/mED3F+1mme7xoLYgTMQD6OQwGQcuqPs/aUkP1U1/IJ6B X2yLf3XzHOJ4+wixi70ad8O0YVNyuSWTL6qqIuT84vsffuaOD1EWIvFX4nuvWzOSXH7tsuHDFzC9 4cED8BnGLi7o0koH8qSAD1gDtia+zSPI/HMe6nTZqMPuspnTLGA1pxGwUociWwxkqiFhoAa2EapI bBYXSbiIi2X7WbHfo9i1mOZQlbJqeZzcIHNynrXYNtVGbV2E10zmtDB1TIV2V4+LuphMKMaoy+te 0k3nQHLPUKWyZ5Inm9Fp9R4CDx4TFuYhVOOlstSCn5QhSivTvfZSt6RrBWeZM4TqNeTZUHnfoiUL wsOHnlP+xz/GD2/gww3Lb5qQ/ZK1cnz9hyef5UbpZz8+nm/R/YNiUqq1LM5ckUntRlPrgOWmtgF8 gGA8ypWQMlrGaWQ4Hc41WZocTTmT8yfjVp2wnUizDTGVuYbklRViGOaqz6stPGrsdau3oT02GE2G AqMp1+xyO4tMRgwkPNlM/p/R5V8Xc7NNF5FOgzGJ8wqS4h/KSeIB0eQxUJzpulGfKjB147fkMmRW ixi7DU7J4xUL8g1hn4epHMXr9fluH0AGoALq0lQoyw7avSWndM+xlPaxHrH2HuozVb3HUneODkXQ XXPrsXMlA0m29pmx+bpussxxzMm5NH9WZE6xyCyZW3C5+4x7OaqplJC6y9FPR988gN5AmuMnfXUN qZEz8yZfWZGTZlra8+510wl57ndtRBrauvv2+D8+Pnljy6W3rZw988a63EHOfkHXgNDFDzz5zO37 iYH4nrrn5Ll7ds2t6r7NTG/8zYMPP/R4+4PIkjsxdmpC3e2CDi1iIX5SyTbLOowMs/2FfE8USXAJ 2bTRNtsmEELTHDZ7GuegxMJYl8lJiqo6nKoLwKCGZUULZEe3KSShEAWZyZ4aZ2VH13raPbTVc9RD v/EQDzjCLqeumrBtu5McdRKn112dZC/GramHBZg6nsrpOp65xEeQp27dh5L1YAY1PnMC+lEnimtU N2kiS5KtK/dO2zAuM344MP6cuivL4ofR9H+6cWTrytt776ADnphSXrtqee/XuGiU37vwsD2pP1mQ YHE3KOxZgk2t1pQGhbYpMaVH2ad8owh+pUVZprRjgcCJEgg8h5ZK058gcNCMfo8oiBKvUgntoi5x wewo75VT6/ppHdX6EdQfelhTnuBVEfZwn91hvIs93Cdefifh4yd/HM2Hf3wfd2gV7tBU/anSX9m9 1g87TTb9DrF2nbcoKnFWLk3MVWaJ29Tn1FeV36vvq+oEroWjJsmj1IkXyFeLwk7lI/4If5L/VhTG SmPlWeJ1/C38A/wG4X7xful+WfXzdjHCR4QCsUAqkItN9Xy9oKLjqaiKrAqqwom8QeBF9rqEwSBL KqeqBr6LXqH5hGK50i8RaaaJGsKkDYgfJ+w1Vv8q5SSzdXutx+d78NywYKbvtlPyZrt8nfWl5Fay e5JXNSeftrAAJUgk2yriJaPIlPg95Ob4W/Fvb8Tg5Di5Ov7r3ovJh6viT7II+9TeTdCfCmn5bOeE BoG2CTGhR9gnfJN8FLRMaMcCARfAoZPFhQn07RF4+X/ao9SulCV3JPXkZymAuB71XC4Z0g35SN2M Y6FdMTpFlzHKReWoJxqqpSPkEZ7akDHAFedPUFry2/I35j8mPiFtMj4jPmOM5e/LP5hvhvzi/Aas eC7/o3wxX/NlRKsx36ZXClKQl3yZzBB0qFJQtwe8ZLXZctMzMsK5KgqaxRq227Qp5S02Mg/FpovW aRZfejgzA8vmZZCWDJKBZTtyMKxnPlQHQK7uVijVDGsDcd652DRXq0GoQsjOjeZqg8+JFue+mftR LmfJ9ee25XKQG8gtyU3k8rnevE+q+oKe1O2fpP6rOo4WHI3M8fnNDPUdVD1+RbV42lPuqyLM0JBI WtDJQh63Hvi4XfrBzT11cH86w0sJt6Zn1rqSukcuWvRIHp7kzNzxQ2b3jx/uVz2wZnZR/DAfvuM3 EydNmjj1otr1vU106kP9q0auWRentO6BKYV1N93XezL5RI1vwj1zwUbNI6W506bIs2W+iye4W9Za udbyhVUQdUVmk8wm0WgwoPNJSdgFuiIDkmBvrfwLRaYawkYz46/JZDylz4zkKFquM/WZzql/UmnJ Y9DntwbPUGA6k1Ct8U3xw9njK0ctjKBaENa83Xz/OD/t9+TMQQ03dcT9fHjDjuGzb/oV02Lno0d6 P67UhPHLvdrIz8lh+bu075z8K/Rzgdq9glehTdbJaZNdTZ576XpxvXyvsUvZT/8sfKDsNx4WDouf m6xPyL+nfxBflF82CovkVeJNMmfTpdDgZixy8JKjUvK1pLem03RzEM4IOJJhW9IN77N1yhzrLPTC 53h4wgwdaU6L2nFZ4HRgyJYdzjnNqp2/unfD30k0/trXd8a/W00C66688p57rrxyHc26hYir4698 8/f4izclNj+0eXP7hs2b2XrXxC/n78X1WjHiuF/rPyhtZBq1R7lKU2VaNL2WG2UalVab/n26wqLW vkjkuPR9uozn5/QI1WUwWC3mvgjVlm82W8JWqx56GM6OUcccqcKNtB76pyhVt0TMurMo9bTIg73J 4WSSDqkwlQUfP616DRHLnp7bTWj8ZHfj7eNwi123zZp+w/JLLl2JW9swI/6XeG/8ePy9ukm9X3Dd nVsf7HziERZ9XIhrn45rt0EmPKhV2Kto1BR1VGWMprWmWsfoDLnVTzJlpzvaJDSpF5gmpzW5m3yT MzepmzJOKMdN3zmMNjCnMybwBmcyTJcsVtGDIVY/ez7GmmGbTQ/TldutxOrzJ12f46et/9hZy4/M TzFgjjBHnZU2xz3HOysTGUBsou7SJGNL5tOQ6E+BJzeq4rGpzyxaTbieuQ9UES5+9OYZs1bdNG3a nfHLqevcCSs3EitBizLlwgd/qON2PLrxkdi2B55mPvcKAK5C3/3NWt69AlHMZIIwS1gkcMX2RvNs c6udVxWL0W+ktxsTRlptHGekxi66WMuXJDzhHBXVPFCsSonSqvCKb5l9o51OtS+zb7Pvs/N2K4TZ /TqUAErbSDu7YWer7iYZ0Her4tSBPt7sHZN0rZEZeL4rS5PCMB/qY+4J9bFy/a2e0kEoCUH9VJ9y skUbaWdnevhltS1NF5x7zpDzi/nwvZfVln/bv2ZL/O+4xhI80VZcYwG9UntItIkhOddtc4fW29c7 7s29p0CRHHUOat9t6ja/Evw0dMJ0PEvMN00yzTTdY7jX/kRWt1GqCWnZteFLs2aEV9hXOJZn3Zit VIRHiHWG0aZxlrrgsCwpKzs3XGEsD5ZnlYfKsyVRFWxK0GPKNWZlZYWk7CytcIFxieMa59X5iwpW Om8quN95T8GOrB0hUxu53X2L576C3xTECsWsrsTvmecdTOEs/SFMNssf7PRnJ/Nen57X0jFxmYkM zKrLWm+6O+ulrHeyxGCW0cTzPkj59lDGvPxOd1E1SYWBej4rJ6o/V8lEewkk+WSFbyFt5CjhACWF PWfh9ZZpLmxJiNYKPJnKH+UpX5dncGnYtavMrWG/bg07dWvlFVE3u/vo1nLy8YL9Wtx+/UYf757k 01DjW3ykwZfwUV9dmuQOurRgKOrSMvxRv4t8hNFamRxsyLk9h+Zonsxojq9Qf0kBzWtDISkpJMWF pLBfsATPUBkJQsoEJ9+AUquTDohiQgcksqSLSdZJNKv6LcWUqdBfLGMGlz3kadaf8qRCDJZlbzZd lcyygKPvZm8yopuPn+bk25PZidc0xWCvtuThBXfg652mSqPDWMmSHUb2nOfL7YZKPXQm7GH3/NQT HfamZG44N1t/osMO7+kPdNjXCtidyhLis195yRUVOQ7nqPiTFy59/9P338mLf2eb2jivJJARJs83 NR775r1eUhw5f1JeRnHA6bDVD5183+o9t60ZMHSY3xXq58yYNbp++Z1/jKHE+xOf0zuEB9GCvaHl BwBDRzXfMtg82txkkbxO8HAuJ7jtaQ7itlMH8XCKpEpGD9toC7jb3TE314Kox825MUTucBKm4DvB yd7oXaiZjQalWC0GjFKn4olmQXSehwu77ZOc1Y6Njm0OrsXR5ljr2Oc46hDAYXUEHCUO3uH1LWnv c33qYxV4pofoLzU6Ej3sodDJ5DMh6zE9wj6ivwmMTQ+h02MrS0XYzQTDaYfOU7eYethiC5WXlefY 6LU9htyM3NGe6b8+79pKg3L99cTHhw/GJ94QyUh/v6Bs/IgB95A3D779WHwV8udW1AgT+DB6Mxs0 9wW2S23rBE4RvWIVrbLV03rbYSrpUZmNN7hAdTocqiKmOcJOJzBlZnbpPk3yNsO/8WkU+ZQzI5Oj MpH/dXCWNAhn+TLNydtt4TB7vOT46UkTN3bw3jmXbTmPeP3nV4+8qoB4N06afvGWdbQ97jk4c8i4 RYdID4Y7uE4Dem1TcJ0G+JvmFPJ8xVGJXUR2kdkFg58DnYj1QCvgGxy9nyciZ5Bl1WjAaJLaOZ/i U7OgyPCKwYgH7aiWlxmIqiAYHOA15ECBIQqDDStAMYDKG1RFoZSImFYq2d1YzZORFzWY/Po7ebzJ 7fZZ1Wp1nP76RYlm4Gmlga/mx/Ecv4uWoIvYplmM5UACqJA44jW+hPLiZQIT8Yw50oyWotmrP9fR 87qHzNxjeyWxVzLHeH6kmd2gSr4JS4JpbnbrPw0joGfjE0nuq4Pdotn6OgnGkSG9Hz8zwlVURPvp UaGC8cgg5JKRfKoNAANRQaSqJCjp4KL9eJvgkxxKP9VmNOqP5kKGSq5SHMmNFNdz60X9frS2pPBc ZIqB5wVeMai8MR18vEtwKF7VaTSGII/PFYqUPDXXOAAqhKFKHZxLzxVGSqOUxbCEXywsUZaoi40r YCW/QliprFRXGN+D9/j9wn7lPXW/8Uv4kj8kHFK+VA8Zv4fv+ePCCem48r163FgkdCXe1pT0wVE+ jBelK/G+nlNZzthXBywn6jfJByffgzJhwqDhJfUcb0zqOd55Wil7jvfvns2JyWdzarG52kzZAzq5 RiFmCCDLrgADggYcMe8IEK/ppW7iSxp69mwu9Wgu+WSu+b/xaE5XwZBUprpORcUMTBPvMGimSlzP iQ5TJS7nBKphg2ZkJUdRDXNJJLLn8gaWO9inlPV7msynYMKRxn5JkONIUzxGbK88Syzbf0+c8a3x fzy7AwVkJO1i8OP7dGvvJJQRI56kFnaSSJu2Jk96lafrpW7yAdkvHTUJsuTjPWKeWAGD5JGkifya LJLUMIlIA8lgqY6MltYbTognJCWHD0sFapQfrA7nx6ov8vJ56kS+SZ3BX6EuIdepd/PrpF3qfv4D 9aRq4nhJUlQXH+AL1DK+Wq3jFSfvVQerY9XL1Cf4Z/nX1OM8eyXwaKfdw87vgU70U3nmGDiNtijh VYlne4hIBkVmL8Qd3JlfFE3or0Ee1Cyu7CgXpoqDUkUQDYZU9VEDYUnNjdWGMAgOAEEUBPTzZAUP udBFr+gQyxR2x8Igzxxn2mg6aOJMHCumZQZWbD+avEnO3rrgYeZPp3i+h93y846xNh/XU1Cc1HZ4 Ye8KRub3PXpNpvru/rkrk2LQPH/+VYRdyoi+f4TtnpEsi99BLtjzMhkdX09WxZ848D4NUS7+AcmO K71vkVHxZ5keNMfH8+fj7qWR6A57nkDS2BI9RktUdpksUYldRHYRXFhG2RHxoy4URJE3GcyilUKa yKdRHqWF3UpuQT+ki2zT7AaLqdicBwFnibPFybHbb7p3FY7qd+XsGf2iTvaeRCWnebzRZfqj61xN oXqOEspydlIJWsbAaOodFcdLKRsZGdPrxSvTfcmvDCBXrhpjPXYIY8Pm4uS5Qb2XfLdIPzeSWb8/ mjouzfUxK5rYwWhiO3gr7ErgriSObuesRP/KQOpV5881s8lWnWZN8+LF7qkWmDhhhuEOzCf7akoe FsnMYQSSqz/oMpNI/AQJxVcNzxl+wbKG8WO9w8qnX+zFg2Om/zhJu5unn5Nl+8C0oEn/Wi77yvFb X99qILdOtVR9K3tl/duqj3xSpf8VgmfO6Xjzhx9O9lpHyNN1bUx0Cp1OGhofC8Ot8MMP8fHWEany Ux8hT0wV0coUbIEu7vfQyi8AO0KdlAlNwiswhRyGi7DuMoThXCZk8E/CJGy/CPMLEN9FKxO92H4y wiMIZQhjEMIIFyJckIIJCDVI8xrCFuxjKutHx5/AXOkNOAfHAoR1CNMQ7hYmwz1Yd69YCdNZOY51 C/YRwvR9WP6guAXuwPR6rG9ibXXM6CfDaKwvxPRdwuREQroVJCwDTPdiuQvHv5PNGXEYx1/AL0gc wXQB9j0K61cgnoR4Ymq+Hj39CaPR18rWuIqlkT9LsfwOhPMR1iBciPxh9CVI58f8rZg24LwUxEYE Mw+QhW2q6DkQQ1yE4w9PrRv0deM6Tq0J56/P6eeB8bTmdMA5sXV9gfAGwr7T5nY23HoGLIBarkzf P7ZmE8IQ+gYMQ77E2bqETxPfMUDJO4Dr2o0g8DNggAyJLTjPamEHrMd8KUKVDguA8BtgHncM92AH XCuug4exHOgAhOOQQ78Gn5gDFci/Ruz/AoSZ2OeLujzMYHNIfI3Yz3+KnsACaEGYi2O/1scnxhvM j8R9bcS2J9mJQL7ehDAHebAe4So2Pxy/mPEc9/07Mjn+G2x7EMepZ4Bj+nXAtSf3FRYh/Xzsi+jj JPchiRGwfi7y9GmE5xCeZ3PoA13OUqD3tQU4uiXxn4jTEHwIbyDcweQNoQWhnbXB8VVsr+ryijLD ZJPJB5MN4RVdViewuSfXoJ+FNakzcwXSX4jgRcgTn4SLUpCHbRl/pjOZZeelr28mW0yu+7Au05cx uSdfsnUymToN3y30wHg2B31clK0+zM4d9nsNw5xTn9P93H5Yy2SWyVsfZnxhssbOIzsTKdxw2loL U2ekEOn76bKOstiH+3hxCr8J92Ofk8U7UE6/grH8+zCW+wOMFa5BfCeurxvLcD38ftRhERgn90A+ 7uU4pL3vLLyegbSfzMWxbue3Ii/2w4M6X/fTLH4/EYStiS8EIK8JW+lSPf1P+GwgPck6hhmcXvc/ Lf8/AfqusBVmYfpLYX8igeu5k50J6StSghDow1jegdCGUCBHyHr5MtIlTQKrCHAMYR6vwWBBgwq+ B6p5J2jIpxwsnySeq+vdtdj/K+QruBX3a7nkhBD3BepGHIu+i/YBgfWPeMxpcnSGzJ0tS324T17P xkxmmN5FLCD24rnbhbAb4f0U/BXhY5THK/Xzi7aB6WfdPqCORrg1Ka+JI6fk8zXYgPi2Pvk8S04L zpJP6Wy5PBsz28L0u25b8JziPG7tWz/Tj0zHMR3J9ByzfX3tz8an0d+DuuNPuh5+A6akznU+QglC MfaxJ6VHdqMregzP6Ofi24ndUnViN/d6Yrd4X2KTdFniVXFHYgOuO/+UTe1J6jJ2nvpsKeMTs4t9 dlQIw6yUPrtfb4vj63Z0sq4HQLwGz99cmI79/oHZVXYOuQ147pCf2N8N/Ga4nP8Y1uLcLdy2ZDk/ AcYynchfjWksR53O6g3cWr3+fP4/4Wo+H9ObET8ANlGCq8UXGE3iDb3sk2QdKxOmwL0od8X8KnhM 2A6NbK/YOmh54nW293jmfXIbPCgByvDHcD//A665B9f4io4f0OWJ0XYmfmDrk4aAW+BwfawNAqMR HoRAih/rdF706Dy6R5dh5AXrU3xH9zdAOIDtN8J1sgr3y7mon74Fn4S6RB9rO1wgazrfed1e/x3P x1coY5NgpeBIfK/L/5OJBPcDnqGv8HwxIFjnBK/wFTyAZ2mlzp8kXsPOD/cVOJmM4Pom6v7EVyjj j8NV4la4RexBuduPtmA/7ttXuJbLYBCm7+C3Jn7EtiOwD2BjY/l43T9hdkpL7GPnReoBj6Th+NiG zUH3/3Bc7lOc712wEnVJjfwVPCoGmF9DCMpeP4QBSdDzyxCWItySBL3MmsQYadwF1+nlM+FVuoWj KN+s/jX+N3j2HoAa7glQ+VnoP3wJN9BiWMGNRbk7gjaDQzrM84WQxx2Beu6Ebn9WCCpU6O1caMc/ hwa+Cel7YAbfATO4BKY9CPegPCKd0AVThEvQz7oY+0kBHYg0CjSIazBdnHiStdPHOJFwMeCvgVKd 7jTQ59oHbM6PnDbne5C316M8sPmy752cNl8211PzTM3x5+anr5P1i3R6mz9DDUDiA4ScJI6Pp7fC VoR2+j764T2wlLAve26AOvIpwoYUPAUjdbwdYTzU8UvJSoQGBJ5fCg8hLkL8JcJ+hA0IexD+xpfD zdj384g7WVzAgP4WdRdirH8cYS/CX/rqTgc21s+Vnw78Z3BGXiiFZQxoIfqEhfDP7R+CKL8E9XAJ 8hOBuxoaGIhmmCfJMI9+jOVMJ52VF/LgXn4e9Puv5vNfAXkTSnQeJkE7fY19+4HY9d+AD07DAYbx fBUx+/y/neP/FHB/lyFcqvO/HfrrMvQ58l8CheyBi8lBlL8NcB6DVL5F5+dDeO5T+4TlK/Xys/YP ZWUgdz5oZ5dj+gYGffmz9/W/ymO/206HPjnoA6kUfREE/i/YHuHsPNqD5QxEJmOFev46Bn35U+P+ K5gIUeRTHWLQZeysvGiFRQxoK+bXA5PzKxicyk9Ev2piUj4ZIG/nMEAesu+is7JLGSDvgAG2vYnB aXxtZHzFMRkt9O1Pn5yfvT9sXvxL2O4Q+swTwXc2PiXfKX1xhsyPT8r7qTzTJZ+e1eanM/HT2cCz 8q/6/H8J8Oy8jvAKwsv/t8diWobpCCvTE2+jvxFDX/VRjDF/D7cC9K4E+PF5gJNTUQ9hVH3yKSyb hOkw4r8jeLBsDmK0Rj+ilJ1EaYy/g/AGQjufDktSfqUX8yOStL2bUv3lJOkZ3Q/o7fw4MEn/4wqE BzD9HwgoZT++iPhuxN9i+xjSNSFeimU3II5ivgGhDvNvYX4oAsX0YIQvEHCeJ9GNOVmM9A8hXM38 kZ+JQ///xf8i/vjv4uQ9AGjWfU6c79kxxH8b9+3nf4HPjjX69v+/wn2xxD/hFB/Q53udwWmxz7+N cfow7uf3KTiG8A2/KtGLPqWk+9Hoy+o+N/MfU1j3t/fr/iRJ3VPUMfOdmf/KfGfmvyLegPhm4U2c zwI4j8X5bF6pG5WX/y9h1z8Drf0/B+5ptGpoz8WxSZCMCJt/ArnkNLgFQF0IYBwNYML1mLOSYFkO YHsZwH4RQFpVEpxZ/z1wmwE8KoAXz5YPz2bGMIBMBD+erwCDx5IQ/C1AVgFACK1g9qsYyncBhHcA 5O4EyLsfIIJzK3wSoAjPcH/kSQm2K93A/t7uL/AL/AK/wC/wC/wCv8Av8Av8Ar/AL/AL/AK/wC/w C/wCKSD6M8d/QBVcAgJQsEIxe3IrjrFeDhzQvdz9YCHsSyU93PpOq6NU6+Lu67SklWo1Vu4eaECg EOPGQA8ChXncHbAMgWLz+o6iAaXdLNGpmkut2H4NBBDaEDhoxyvR8xoCa7+mM83Fur+xw2LT6X7V URJNJjqtntKGGge3BAg3k7sSQuDnliLuh/gSxJmIp3MzwKTPU+u0WEvbcLxqbF7NOSEfq2s4F5Qi ruV8kK43W9RhTo6zqCOvoLRG5YZzHr2JhTNBFLHMSR2l/sBuTsOZatzKTsXA5reyw+os3cvdzEng wFZt2Mrtt+zlVChGYCuZ2KmYStfWGLmJuMyJyBY/zpHARv2qcVd2YEc43gguA1xYdxmXCU7EdVy/ Dqe/Zzd3l97sTtYLjje0Qy5jqNNkLu2pUTj2N9Fi3G3I8dv00dZ2hgeVQk2Yy4MSBIpMXYYp9hfZ rNxqTK3GbVqNW7Mat2Y1zmI1iADcKqxZhW2KuWuhlVsMaxE2YprHLp0dyMFuPZGdV9rNeTkPcsK6 G3lHsNTXqZjZzDwd9jS9mafTaC6t3sstgHEIFCe/sNPtKZ23myvQl1LY6UlnBK0dihFZ507uBRK6 2B7s5TK4fjonMnUOxGr8mCdg4fxA6Ot0H+MOfZvuZ/vL/gGUjn+fwm+k8H8kcaKH7uvEUbQu+keG D9Zk0E+xs6n0Q9iIKUp30xehBAnep11sFvQ92g3ViA9gfgbibsRliHd1BF/1d9GuTkQ49wc6TC62 WPpiR6Q4lfDnpBLu9FTC7iqtyaEv0OchA7v4E+JsxM/THshC/BxiD+IeuhBeRfwMLYchiHek8Et0 D5Np+izdCYMQd3aY2RRiHRJD2zpEhp7ugGSuodi/hz5Nt4IPmz7VEfZh6ebOcLbfshv7I/RxurAj 02+vUenDpJEcw0btcIBhsNNHOipYJ2s79gT83XQtXat5KrQcrUjbxJXklBSVbOICOYGiQEVgU6DG Sm9D1bCR4oGla/BaAQGK0oOgIaylqzr4ilhNL66JrYtCG17b9VQLXlv1FODVeqr2qJ6qpjfDOASK fSxFWIbQhnA98Hi9FuFXCL9GuE4vWYiwCGExqo9WpGhFilakaNUpWpGiFSlakaJVp2jVR1+EwCha kKIFKVqQokWnaEGKFqRoQYoWnYLNtwUpWnSKBqRoQIoGpGjQKRqQogEpGpCiQadoQIoGpGjQKTSk 0JBCQwpNp9CQQkMKDSk0nUJDCg0pNJ2iBClKkKIEKUp0ihKkKEGKEqQo0SlKkKIEKUp0igBSBJAi gBQBnSKAFAGkCCBFQKcIIEUAKQI6hRUprEhhRQqrTmFFCitSWJHCqlNY9f1ZhMAoDiLFQaQ4iBQH dYqDSHEQKQ4ixUGd4iBSHESKg3Txdm5fze+QZB+S7EOSfTrJPiTZhyT7kGSfTrIPSfYhyb7U0hfq zKAoNksRliG0ITDaHqTtQdoepO3RaXt08VqEwGhjSBFDihhSxHSKGFLEkCKGFDGdIoYUMaSI6RTt SNGOFO1I0a5TtCNFO1K0I0W7TtGuC+4iBEbxPxfK//HW0OtJo4zGlbaRfB0vg691vBQO6Pg62K7j X8MmHf8KbtDxtVCh48UQ1jH2p+OF4JdJh7/CUuNCFTAOYSrCPISNCNsQnkOQ9NSbCB8hJGi5lsVb pHHSRmmb9JwkbJMOStQijhM3itvE50Rhm3hQpIGadGrS9SiqFrhdvy7D6zcIaETwWq2nqmkUx42i ni3HnyiNarYjgW8KyJsF5LkCsq2A3F5AahR6LuF1TReACooTJ42aMTzUfwChIpw7FDXTbTu/dvs7 wgP9XWRPEuVrEcRfI2xH2IRwA0IFQilCEUIOgl8vK8D2jVpWqss9CLkIQYQAGwJcLgCw22Stm5rI ps7fmYD9u4+O3Dyk292RW4KoqyN3HKJnO3Kn+2sUshNymRtEnsGd24p4W4f/EFY/lURPdvh3I9rc 4Y8iau7I7Y/owo7cN/w1JjIJ/DwjnZjCE3DdDJ/f4Z+MzcZ3+PMRRTpyw6x1AQ6Ug7X5pBEOIc5J UWUnRwp1+IcgyurwV7LWMuSyjSciFOnTExAY5jpxQt90k0aeaAb/Ef9d/q+R/CtkLIrHe4EuHtGb Oey/zKj+PUUPYeMaf0eNytqjfdiewjGGn/FvylnlfwD7Ijk7/ff5+/tvK+qSsfhWnPcqfYgO/w2B LrpVS/O3+Uv8C4sO+Rf4R/un+c/3N+dgeYf/Iv8eNk1oIo10605/A3Y4CleR0+E/N6dLn2Kd/xq/ 5s/1Vwb2MP7CoGS/FUV7GAegNDl6IfK3IKeLyfikii5i0wqko9Ja6UJpmDRECklZUj8pU3LIdtkq m2WjrMqyLMq8TGWQHexrXxH2xSKHyP4yGIg8u/J62krZlSa/d0SJTGE0xNK4elo/YRipj/VcAvXT A7HjE0JdRB0/JSaEhpGYvR7qJw6LDYrUd0mJ82MVkfqY1HBh43ZCbmvC0hhd2UVgYmMXSbCim9PZ /y7bTuDmW9O7gRDvzbc2NYHHdXW1p9o+1FZZV/szl5bU9bQ/GOw5PZkZW1c/oTG2JbMpVsoSicym +tj17D+bdVMLNY2o7aZmhpoau/lWahlxPivnW2ubsNkhvRlKsxmbQS5D2EweBgHWDPXJMNYM9yjZ Lozk2C7IELZTTRDW24VVk96OJ6zd9gOBEbXbAwG9TQ7AAb3NgRw4rQ1KDNLWbg+H9VahAGlkrUhj KKBPLF/vyO/HJkV+vQlBv07vyE/0wWLFPzXJSTUpP9WkXB+LIz+18SfbOPL62jjysE3kf/mZOSxC OgcsWvoi+2dxLaERMxFaYmuunu2JtU0PBLYvXZT6L3LhlumXzGZ42szYotDM2tjSUG1g+4AXf6b6 RVY9IFS7HV4cMbFx+4vazNqOAdqAEaFptU2d1VWNNWeMterUWI1VP9NZFeuskY1VXfMz1TWsupqN VcPGqmFjVWvV+lgj5jC5b2jcLsMw9n1BHXdSg4oy3JIebBrmsrYOZQLdPSToWZq+iweyGQyRppgx NCxmQmBVRTVFNawKzxmrMrP/CJiq8iwdEkzfRTanqqxYbAsNO/VNXWCN2N/9qI8FJ0xpZKIS06b9 /J4tYB+92gMj5tTiL+YX6oA/p7eEBT/7Wfhzn0WLFi1gl0WRBQD1sYIJ9bGB7K+QSBIO1VLbhGX9 +8o4Ti/brigjuhI9WBnBSZCFbDiWihD2lxk1FaMuibaL7RJlocLCTl9m6by9aMGXIWAcRxd3FOvx Ml3cmZXD4peFncXlSYzxKcMdvmAp+5JpBZIynJPEmq0IE2tz1hatrWjPaS9qr2Bf+N65CQv9m5gp 7SjexMHCyII+RmByYRMk/2AkjvdwR0amPnA7S0QiTZEF+nc/4WxWn/o6duQnxi5I9bpA735h34Yk yxdAsnGyMrKoj2hRikSvXKSTYPL/A/fJ1HkKZW5kc3RyZWFtCmVuZG9iagoxNiAwIG9iago8PC9G b250QkJveFstNjI3IC0zNzYgMjAzMyAxMDQ3XS9DYXBIZWlnaHQgNjk5L1R5cGUvRm9udERlc2Ny aXB0b3IvRm9udEZpbGUyIDE1IDAgUi9TdGVtViA4MC9EZXNjZW50IC0yMTAvRmxhZ3MgMjYyMTc2 L0ZvbnROYW1lL1pURUhRSCtBcmlhbC1Cb2xkTVQvQXNjZW50IDcyOC9JdGFsaWNBbmdsZSAwPj4K ZW5kb2JqCjE3IDAgb2JqCjw8L0Jhc2VGb250L1pURUhRSCtBcmlhbC1Cb2xkTVQvQ0lEU3lzdGVt SW5mbzw8L09yZGVyaW5nKElkZW50aXR5KS9SZWdpc3RyeShBZG9iZSkvU3VwcGxlbWVudCAwPj4v VyBbM1syNzddMTZbMzMzXTIxWzU1Nl0zNls3MjIgNzIyIDcyMl00MFs2NjYgNjEwXTQ0WzI3N100 N1s2MTAgODMzIDcyMiA3NzcgNjY2XTUzWzcyMiA2NjYgNjEwIDcyMl01OFs5NDNdNjhbNTU2IDYx MCA1NTYgNjEwIDU1NiAzMzMgNjEwIDYxMCAyNzddNzhbNTU2IDI3NyA4ODkgNjEwIDYxMCA2MTAg NjEwIDM4OSA1NTYgMzMzIDYxMCA1NTYgNzc3IDU1NiA1NTZdXS9UeXBlL0ZvbnQvU3VidHlwZS9D SURGb250VHlwZTIvRm9udERlc2NyaXB0b3IgMTYgMCBSL0RXIDEwMDAvQ0lEVG9HSURNYXAvSWRl bnRpdHk+PgplbmRvYmoKMTggMCBvYmoKPDwvTGVuZ3RoIDQ1NS9GaWx0ZXIvRmxhdGVEZWNvZGU+ PnN0cmVhbQp4nF2Uy4rbQBBF9/qKXiZkoUdXdY/B1CbDgBd5EDshW1lqGUEsCVle+O8j1XVqIAIf 0G21q/qIUv758HoY+sXl3+exOabFdf3Qzuk23ucmuXO69ENWVq7tm+V5p2yu9ZTl6+bj47ak62Ho xmy/d/mPdfG2zA/34XT6/an4mOXf5jbN/XBZE6p+/lqT432a/qRrGhZXZCKuTd36V1/q6Wt9TS7X je/h6TElV+l9iQ6asU23qW7SXA+XlO2L9ZL923pJlob2v2Xy2HXu3h/3YqwK2aKyEGPVImIx+kqj isRIJSJdB+n5VBAjeUQvYiRGtBMjBUSNGGmHqBMjNRp5bRIktOpLMVJCVImROkR6YJBxbI/TKRnd e+0bZHTvoxiZEOlRQMaBfC1GjhoRTCkDfBGLMaAiBTEGVCStBQZUJMhTBlSknRgDFJKWB8OzibMY wwuiRowBoldtxnBG1IkxwD0XYgxwz2odDHDPlRgD3LMXY4R7JjFGyGEWY4QcxotQRsjhKMYIOYwX oYyQw6oFjJDDeDfKCDmsWsAIOaxawLjTkfo3O9t0bYNvw9rc53mdY/066LRuc9oPyT4g0zhtu9z6 y/4CVjYSsgplbmRzdHJlYW0KZW5kb2JqCjEgMCBvYmoKPDwvRGVzY2VuZGFudEZvbnRzWzE3IDAg Ul0vQmFzZUZvbnQvWlRFSFFIK0FyaWFsLUJvbGRNVC9UeXBlL0ZvbnQvRW5jb2RpbmcvSWRlbnRp dHktSC9TdWJ0eXBlL1R5cGUwL1RvVW5pY29kZSAxOCAwIFI+PgplbmRvYmoKMTkgMCBvYmoKPDwv TGVuZ3RoMSAzMzI2MC9MZW5ndGggMTk0NTIvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0KeJzs vXl8VEXWMHyq7n57u70v6aS70+lOSIctCxCIppF9CfsWJBD2XQgggqIEWQVU1BHBjUVUXAkQMCAO yDDuCG444qio4M7I4yAzAun+Tt3uRGTmfZb3+55/vp/dOfdU1b11q+rUWauqAQgAKFALHGjj588L rp/97nwseRhAbDNp9uSZN+U+9TOm3wIQ6ibPWDhpdO7HQQDjIoD481Mmjp3wRumFdQAVBVin3RQs sM20Po35CZjPmTJz3oI3ts6NY34VgGPzjFnjx5KypV8BjMvD/LaZYxfMVt423gcwH98PwdlzJs7+ /rmaLzD/A4DaKOwHL4JPeBK8fBQ8AMmvEb5hODE1+Q27zzD9Dms3pAFgOzxHpsJzcBAOk3NYawfs g3p4DdzQFce1CP4AK0GEkVhyBwzCr4DlfyDeZD20hi1Ihy1wFJ8dDrfBfnART/JbWAzLufew1nIw QTZ0hgEwC+4kfZM3wij4jF8K7aEv3ACzSW1yRPKu5L3JbfA47ONeSzaCAXwwHr9Hk38T/pL8K7TE GvfDRviM3KvsgTi2UotPPgJz4EGuiifJycmL2IMQ3IR94KECjpJDNIZvnwhfEw9ZxHXBtzyWrEse waf8UAVT4EHYT0pIDxoSRiUrkkfBhW0swLduhF2wF78N8BKcJEbhXHJb8hx4oQB64Xjq4W1yiEs0 LkmUI8UEpFILKMU7s+CP8CocJ2HyMp0lGIVCIS7cnHwfHNAWhmJvn8SaX5F/0Nvwu5h7he+evA7M SJd7GLXhz/A58ZHWpD8ZRlvQWfRRbg7I2GJb/E6AqUjvDfj2T0mM7KVGeox7jH+GvyRmJk4lzTgj UXgIHoGXiQlHGiRzye3kBPmSdqFj6EP0C+4P/FP8u9JYHPVomAl3wjPwD2IjHchAcj2ZQhaRleQe spEcJcfJN7QzHUKn0x+5KVwN9xJ/HX4H83P5pcIKYY34TWJE4kjincQ/koXJFTAQ+WEJ9v5+eBRH tg+OwUf4/Qy+IAIxEDN+gyREhpJb8HsbuZNsJdvJU6QeWzlOviDfkp/Iz+QSBfyKNIOGaDZ+w3QO vYn+gT5Mj+H3OP2B/sK5uWwuxpVwZVwlNwt7tZJbh9893Oe8jz/GJ5HOhcJ6YZOwXXhGOCycE43S 7TLIb11+rDG/8dMEJFYl1id2JeqTn4MT59CHVAhAGfZ+LH6n4XyvR47bAe8RI9LOR/LJtaQvUmYM mUZqyAKk5DLyIHlc7/vz5ABS6UPyI/bZRP16n1vREnod7Y/f0XQiraHr6L20np6gFzmJM3AWzsnl cz24Km4iN49byK3n6ri3uE+4L7gL3GX8JnmVD/DZfJSP8T34MfyN/KP81/zXwijhTeGMqIozxRVi g/gfUjvpWmmANFCqku6W9krvy9XInX+CPfACXPEhp7glXDduD9xFi3gvfZu+jfw8BiZwFRQ5lW4n q+itpJ7mCAvETrQT6Qfn+CjS+hW6iV6gnbgK0ocMhmm0beptooNHbQRl/J/gLH8Ax/Y2vnmBaCS3 0R9FI+wiQEuxzT9zbfgY9yac5D4jEr8FPuZV4iZn6ZPcAOSCl/hrhREQ4h6G57kacivsod1QO12S 1yIf9yNPo14YQgrJP7kkcLQfclF77ktYCtPpX+AsyvEqeIBM4CfDXVBEFsHX8ARKRQvhBjFfdJLX 6VR+NbWTeqD8Uzi6UpJDOMEBy0gV96D4I/0IboRjvAqfcs9i74/R57kK/pwwiExBCbgVVkBNcgks FEbw75LJwJFhEOFPoXZbxBXyIcSLUauMQp22F6V7P+qBzlwFlniQc/oiXwxFDfEgfjegnuCRg6ai jA9HLfY21ItDaANMFswEtQ4A/2ZiEIxMPgEbk5PhhuS90BL1wcrkInzjdjgDd8N2sjxxC8yGLJSc T0lfoTs9JnRPtqSr6Ud0MF3/2/lFakeIB77D7/PQHa4VXoTV/IcwGMqTa5MfIHfnoYbdCOOgN5zG Uf4NW+jJHYKiRD+6M9mdm43j/QwGJp9MBogKU5IzoD8cgMclAcZKsXjnzvHya68p69SxtEP7kuKi wrZtWrdqWRDLb5GXG43khLNDwUBWpj/D5/W4XU6H3WbVLGaT0aAqsiQKPEcJFHQLd68O1kWr6/ho uGfPliwfHosFY68oqK4LYlH33z5TF6zWHwv+9sk4PjnpqifjqSfjzU8SLVgGZS0Lgt3CwbqjXcPB BjJy4AhM39k1XBmsO6unK/T0Oj1twnQohBWC3TxTugbrSHWwW133+VNWd6vuiq/baVC7hLtMVFsW wE7VgEkDpurc4dk7iftaoieou1vHnRRkE3aqzhfu2q3OG+7KelDHRbqNnVA3YOCIbl0zQqHKlgV1 pMv48Lg6CF9XZ4npj0AXvZk6sUudpDcTnMpGA2uCOwsOrV7boMG46phxQnjC2FEj6rixlawNawzb 7Vrnvvm059csvtzWZcTKK+9mcKu7eaYGWXb16pXBus0DR1x5N8SulZX4DqxLI92rV3fHptciEfsM DmJrdHnliDqyHJsMspGwUaXGNzHcjZVUTwvWKeHrwlNWT6vGqfGtroNBC0O7fL74vuQp8HULrh4y IhyqK88IV47t6t/pgNWDFu72xoPe395pWbBTs6YIu9NsSSeMpisTE5vv6Sn9cZbqM6iZsoT1KNwL GaIuOD6IPRkRxjF1YJeJHWD1+A74GH4qCdaqm4AzMrVO6VK9WuvIyln9OiGihYOrfwbkgPDZH35b MjZdIka0n4ElGZ80sxreb0rXxWJ1+fmMRaQuOKfYx2v1fEnLgvkNNByerQURIflgANJ2bGXH1kj+ UIhN8JqGOIzDTF3twBGpfBDGZeyCeOtYZR2tZncONd1xDmV3apvuNFevDiMn1wNzRJ11crT5z6K5 7N2mdKwjrv/k9sTU/T6Dw30GjhwR7La6Ok3bPkN+k0vd79B8L52qs3cZwWXQdIpmcPpdZMpRzQ+z zAhjHR/BP1Fn6gkNkoxcqZeQYPc6rbpn6lqphkL/zUoNyXOslo5+rZbuZl3H2G/znX6T/033jKs5 7DAawT5DRq5erf7mHrJaqsFeaYQcD0NGhIJd6mAoSmYE/xqShzowqMyoiyPJurAHkP9SRensbx7M SKcr8cO4s2VBd1R0q1d3Dwe7r65ePbYhWTsuHNTCq/fRw/Tw6tndqpsYpyG5f01GXfe1lUirKaRj S6BEdz4FQG9WguvqKTktSg10Y9wOAn+aA1XiTxPwyqJwmnIH0Kgr6OK1Ak9Mu1DWWNZPO19W0VgG 5ZjWLuOlbZuQNWSN4IWgSbsc5A5djgtwCYL8ITQ7sCgxkFYL74EG18TVXAsBzSbJmtZAinbDJrOM OG6VNplHA6dxQY7jnrU+spY1VdV44ax24Sy2U45NkCoSpdbi9u3aF4kSfp0aIZ/d/3bFyANLFuZe E46RWGLgAfJPYv7bycZLxytXr3/xpUQgEbyqfWMezdOoomoEbArrgbqJI6wHFtjEjbaYA2Zqftb2 79u3h8FanBvFb5EL7ZhGG5eQWCz7mtyblxwYWXEsMZCcIp8f2Ld+9ch3LzWe/Fvip4SMrT+d+JQs xahChX57VCT3M2IDGRCPEq6MUqKSMlAphxkQO0gd+6PHNQv9h804NZsNWzZgL85XnT+tnS3TkNzs qp3VGs8Sq620bZuikiKnQ5Ry27Vrv/fogOGFpe24o0dr1kQrvGOvx3Y7kwY6jc7EGS6Ie2fT2Ryt IBXYZBioT5iND3j52Xd6Yv2001XaV9C64mzbNlCDgywJOTvTFqRhzx42d/vxshJ7z0Ek7qGss2Wp Lu4AfjPe38zrvbxQVYV0Opvq1P6jR4+yuhgt0lKkOweD9wGX/HSXo5Q2JD+NBx2lD3CEcpu4HRzl 5gNx4NPIksh33DdAv8H5eAob53ffjG8u086f1VJzsFJoFau6VTvC5iIWc5IiQp5alxjhFX64yN6A 0QPQS8IhpPTceJCLm6zF0/nF9G66Ueaf5YkCokA5RSBGSt5QASUpbguFi9sAYTziMwpxk6VYYMVm ViyQIIZgVPAa9pMyshxSlKqJsbHWxFL8X+4uJdZS1h2oioXCVlGUSnA2iuil+s7vDXngi9bz+Fuu XRR4vscbY1j/ynBMEvYvC76Ot+skdBJfFA6KL0qvyq/7pV7GSuMQ83TjBPPNtpvtd9gO2M74zmSc 8xkPGl6w0wzNr2VqWZr4RwwlJbSXMmIleS7uy1I1WRTf8Pscfr9P9vuQrrLPz5mytAa6bXd/K7E2 EM8eU5ZDgKwG+mLcQqhRnet+D/sTx2GSF+kSCIJGOsSN1j3lGPLNoospT/fTHAiQu3eu0ecWZ+BC jE2ELvLlZxurTlttbOx4WWluFTPjpKR4Ejrgh7ALVJGqORFnKNoeKdKuXUlxNJytM2tRIbqASCn8 46XL7ak78tiDP27feMvtD5N99n++896Fnk8e3joq67nnOpeNP3TbkTOTpt/38Gr7sY++e27E0we2 rRrbFik5LPkV70JKxuC9eJ5gcpm6mVaY+G7W4db5Gdwg1wxtmmOC60bTQscK02rHHRmPm1QhyDUk T8UNBqPJzEskbDISRqA4vuxFwoJwEympNxqdvGc/3QZeOiWe48zyC3xWC5Nt7pjgrCAN1kpzo4xm baIEolqURte19DSQDru875H9pANy+6G4AW8HIY5h6bqCBnJvmnyxs4yAyDVnz+tSggRE+pW2RlFm hEzREbkIKYeMRGrs7V2uosIUyaT2zckm6jHySewK4ezosPrA/dMX79h6a1Ffh80wt2HFtKlrHfWh 755f8Mb0SRNuX5f45sTLSbLUs3Fl3e2LtjgepQtuHX/7smXBPa9O3jVhzMOtsl6661Di56+wx/uQ JVbwUd0idIgHeQFESaFiGc+VEZFHuW8N5UCZrGyR05qpBkdTjtLJ5r4U/9q2saP4cwj7UAVwlUeP Xn4SVQGFkcj5RtQEWRhjLIu3Xutbk0EX+RZl0HG+iRl0unGsmY5E9qftzF3NNMMrSzxouVYrmFo4 SBY00B3xcCg7VBZQA2XZ2cGyUCgLRmfdoI52T8vRRgeRyaeFh4/Uac0UNlK7jKnMRl1lXkCGRWKf tuo0rsIPVKEpKWGW5Fp6JWV5RlgzldgAyF9Ilqttzosdtt0090HPPu8/3vyQwMilI9r5aMNRMjXH Nq2iY6fY4+M6Tt20bqPr6MnvnqjeOq9f7+oZiQfYiJONaF8rhf1ISzPJio9vrbXRJstTlGptFbdO e114RTykndMMslBJhtEB2hRDnfZ3499NfzcrvJE38WYOYyOB55FZZVGSjJiWRaOEKjUoGR1YQDku yBsd+ISSJQhylsiJDXR2XAHZ+G2cEkr3EwMQYojbjEGYKHGDBvDH+M94bh1P+AZC4oYBxkPSZ0Zu nZEYWV6zSMckuliqlah0n+XEh6np9SLgnwen2OfVzp4FT3mZ72z5aZ26Z5k6RsFf2coTS8t/qbW0 dKV25Ij5yJGVQgojyfvUGQb3qctCd6qet3CytB91FyT/yZREJZlTUxVGRR7mQpw9xEVzRYmjRe/Q EZ880/jQlo/If2zsnu0vEvZf7E4OJLrSkWT9vpvuXIM8uh456lukrxUyIR+WxAfwfPfwsPCk8Fxl mSJO9d0ozFbmGpYKSw1irkvhPLn5Wa5MRbHbsvLzW7QAf2YWUimQlWUF2RMVh0SiRl9BZlZQtwVV sU6jdGbSfZ0LFWebFB8CchIyVllpa2spk9yU4CJHFVlDV0immYZJqDCl9qJh9IsKU6yG6fU0uv3N uZMmL797eO3LaxP3kWuWdOjdp/vtjyY+JjNHR7uM7Djk/rWJ54T9lfsmjn6iKPdA7eSd1W25QVbX pIpes1pc2iwZO0zvPmhhW2ZRJiW/FuajXGVCQ7x6PJ2WifJZaBoPs2FeZi0sy1wHDwrPcI+b9nH1 pldNx+F05t8zrWZbpjUzk8sX86z5/mCgh2mYY7hzmHeKMD3zFtsa24PcRvOD/u1kG91u/cBsBwf4 NIfm45np3pVXSpiFzM0r1SxA+Ax7lpHLyOIVLWrpDdEgIcQXcEeDMpG9WeNHMZt5vqriLBKxKkVF 1H0pOYzFqqpqUNnNIW6RD2fnIHVsOSiCbinKBJI6HTam+Pj6w9ck/nTmbOLDh3aQLof/Sgo6HSw6 fN9TX46a+dWKx76gtO2Pl14mN7x7hgzdeerNlpvv3Zr48Z4XE9+uPoBa51GUwZHIIxakz7J4NBgg XeTUxFu1LAvI2FGFKL5Appae96xf552pkuZJb9umy8J4Oy5DkkVZkHmZF70en4eKBtWomlROdLoc LruLEzM4d4jYzHjxyP4QcanWEMTQMY3l42cJ0ZnEja6jzemgyCKRUGHaNOYiYzxKfnlm5G2V8+b2 u/meo8sTO0npPY+37VbxwIx+zyXeEvY7M/uOSxw78mQi8dTYwufate327RNf/SM/i3HBVpQFtiZv gOvjTlHIkmVJAo5nA1WVLAPIEpszv2YrloZwvYNq0ERVn4lX0qM2dro+NVHMqdGn6vzp2NUMj56d NeQMpWErn3P5US52+QNumbD/uUT5swnTc6wn27Eny7EnCvSJ5+s9uVsizZ3BjjyMdtRAqc/Q3Lra adRVrZ9Go5JquOrqlrdzn1w+Q+saB7BWOz7XOAnfMBNlYB/KQAT+Eu+W4chw0upcMlq2ExuXkwMh m5tGAFsnojvLzIWyRIWQaG4kBwMN7EtuNeXonNpckpsZDapE9UbHX9/EtRVaFbJCBXaBGWuddxkx 9GzKapcylwdZoysfzvD7/F4/JxqjWsQZDUTlCB8NRzymzBC4LPYQPuywByXMZQuREPEbkEccVrxk KaEQ5HB4QU7ReQVtV1ms6cO4BqWkJGL9jZS43FIrimLCwiCHjUdBaW/l+tKZdyeOb/5LYlP9bjLg 402E3BvdERq3d9bywzeFOqwk9J7bzl1Ly58ljafmzN1HRv/lBJlbP7nhD21m11YMXNZ/1aYjiX/W jm1PrGwmt6HsZOs8NWUfmJjI253FPJelqJvV4ypVBUoNMgpDUJLEqloTMVFDakIZqznxWeSroIkE TQNM1abZJr5TpSdWVYNupC5cVRfYzOpOfWlVa13CSKzIihONEMbrtsP04uHDjaKwv/EJOvJid7q7 sQJffhC7tgR7xcEf9jB+osxf393hGt1v311UnMIt26RwXosUDkdSODMrhT2+lJ/f2qQVB4V1wg4B eQFt690Yd9UB3xoduAEYTJwDwRbEwnXY3Fb+RKWuGrqMGrGrFi1rVWXNnLLGqqZ5YsEAY9Qi68HD zFphX9snv+bG6haqIq5NpJPFefRGcZVplVVUKEY4vniIz7IoSlRV5aihKmgnQXvcPsBebeftJAp9 bHv1Bs9qVTUXmLVF/juLTUBV2jtsV4KNoR+NPmCnHdLs8b2m5R2ufPn2l4+SzZ7ti7rMvY376bK3 4Y1pn7LZZNYyH/siQFHcSCjOowBykPkC9Mm4WaJcWhjFKxTgV1UpHZAaVsi5/jB9F4f29+fwwQ0A ogXfp5Eb44uBWmQHzZD5+cYVxteMnGLsZexl4VrwEVOBeQR3PT/ftMC80iQbqCCXmtqZ+9M+XFcp LleYrjOrG+hGbr20Xt7OPSmJNmoxm9sI1CEIVDaaTG0EGZOycZBlEImjUyPLimowmExmswayQqtt tTZq20+3o/PedpcQlBtI27hqVNRg3LjYQAz76TD0vgx4hzagK6RYCAQtszWCodGwF4JCtVArcEID 3b7byrjTy0LtqjIPDl33djDta86crkLfp7yMBeDNXx96RMwHWnmr7gMhwun51dl5CYzJSxionUBv 8ITu6/SpM+K9PLzHROqfO80qK0WOYtn394ZKzQWhUlMDJtuXmgvb68k9LbG0ZWmKyyrRW4KaKt2Q EJe7XXsSQmkhYWLdQHLI9W1c3hIyhggvJobtSIwQ9l/66Z6eAx7iLl/szr95qYQ/dSnIeOFhlOyA rqO/22kzMDkoQXGVmUcpyehbyugAc7LCU6pIMs8FRVGoChpI0DDAUG2Ybag1CAYZlbcu6Easmdbi KfGI6dJdc75ZvNEpJMwr5FulCERiON56Od69FOOxQ3u7l8rxwlSysFTK9uoLBHu9mCxMJVlpOLVs YAiXSmYHgp3lz++1YzIzlczEpJMl/7nTmaYVU6Xso6vVSmRhwlQLsT78Kkf3v3o5geRZwi9G0tRe qkVfYTxakU+E98EMGbA4Xu2zEIfmcGS4MzJ4XuMdBrchg3/Kvdf8iplzuz0ZNJgZt/a393fHfSOE Ecpwbah1jH2ke4xnmG94xhr3Rqp5szjOlmVQnNEgmkBfbSbJtEQZrbz+Kx2jKuYZ6baF+ZHoEaFb ZNcgVMgzJ0HX+e01KCoEazFFxwjGk1Wk3Zuk+zP1ib0HjyX2b3+NZH74MclY+O09byc+pG+QmeSR w4nH//pZYvOe18jIPyb+kThGiknGbmK4L3EGUl4Rz3b4TeCB4fGSidbpDtpH6+O4XrvewRuMWSiC 4Pak7LUtKvuCPoJ/Po8prSO8VzrHNVUXWPebHAVdkae9YXcWOnE0FLJiutnHoS3urZhxb+XfEq8n VpFbDjxa1bftssQdwn6zbeLemS8mGhuf5cjaxaOWOk3Y0y3IqegIYz+zSd+4xWYwE1s7/8jAJHlm gLc1JL/YbfMVIz63Ozu32MrymbnFWhpb0hjv/2V3ZjR1H5/X0pjdj8/FRMTc2987ONgwyj/TP0dZ YF5oWa6usjxgesrSYPnG/LVFMxuNQavFYbVarBajYsugIZ9LFW1WzWQUPIricvu8WW43hLJ1mnk8 FotZzoqaHxargjmzc2pzuJxsT5p24U7bf3V2cO69pz3My2TaJE1CLMbgQl9cSa2tCM0LXukPMBsU V+W4pdSidbTaOjL+JjW6GjGjmPi8pVYUJBuCOe4v1bIdCAGEZsmovCJYQXfUHuZaUZydsD5T+lpD aAtdfeStm994ryJvaN/k+cNDbxjeMtTnc7Jl+fp+DzyWaCPs7//awodPZEZy+t2YqCFtl63tYJAa b+SK2i/sMWUF0zKjkl/z36NX1gYS8YfHc+P5udw8no/klnCl/i5cL6lvZrdA15zuuYO5SmlU5vC8 O+zmPFM0h+ZwuZF2luJw10i31iODw8JDIzMM00zTzZMcEz0LDTebbrbcqt2YMzeyglttuMO02nKn tjxnaeRe03rLemdWJMdsMggh9PEzZEnkOSqSSE42lqErmtHybuTisy5oqZEgGUCqyWyyjohoievi kZZZWS5OyGqpZER9vZUotCAtfIWhqI1EbUN0mW3b7BaexmD4N/EMW8RBOM8WcXDOWBicCguhqgYl 2t4+ixYVpr38nNxotKQ4tYqTjnScDreLd+uzgbY8JzrqBdOY126d9fTgAaM6JWYMnDr5tp/+8Ngv K4T9lueeqttS2oF8NKL25hWXHnk18feN5EPthjuHXze3a7fJYffYWPvHJs56ecLUt5aY19y15Pr+ RUXT8zrtmX/jsbnzvsUxtEG536+vSPSPmwSaheQBfftVaaBzdwdTCwMviEFCW3OEw/QeknLo8K68 d2NK5hnrao2nq77S9BXp8qbF/xLmnVN7IpNfncgQTM89d/HvjAu2oFZlXqQDauJq1DKCHyG/LvMu ZjpcaDqK+U5yd763PN/yhPCNRTICtbI1Sr+oOKK0KugiQdcAF612zXbVujiXSffQWV0F66pVTmZz cE5iVcxVRzcppUh1FYRSQtA9SilQ3VPSnSYrX314QuLS+28nLs4+3OO5W0/sFfZf3vlJ4vJjdxHT t1z/y7sO7hl3WF+PBi+ANJ9pH7I23rUFRK0tbFFPKbSzltraeXpBD2svWw/PCBhuHWEb7tE2yBss lOPRcREl9ItVg9GomMwWi9Fht9mcLrfH42xIlu0WwBNk2GizMhwf6URbCuhMo0F1EAIeQZaznB6H 0+mxGRUly2nDpM1qtFiCmtWhaVabYpQ9TsFi1ZBagtMocB7Ngm6kLFPUPh6bzWoF2ed2+7TOChkI QTDi1YkQB4EM3BtkIbrX20DW7ExrIp+3ohH9nEaft9HTr9vErl8166MmP4cpI7a20wRozSuu9Hp+ i1C/rDRrR47gpexIU+rKC7pBFnSDrOgG7bKpnobkhZRvFMHCfN03ArbJlfakzFiy2xgX4vgQTuyc qhApsuuuT5HdhshehO4PWzYi5NHELa9+luProBL3d+/2D/tbfvWnxA0vJt7MldyOxOs40eUP3P99 Dvdpoy/xw9/X1HPPo/GvWhuc2OPSY2y+RbQ23XG+jaR4r6x05PhOSkPy6902d7GMOG7GBO/FC8cu CrMqnhC79Zd4d0zweXixRfkWcr7a2sxPIVPEKYZPRV7gOU6UJUUUFZFTgqrBoaoGkRMVjD6JA+dM NBpEgqJIDA3UG1dUVeEoCqa5gXriilEZFFdrMdxqIHviJoPBGARuUH96N6Xo0e7ZRZh0evaazIdD 1TidsQtMPlEhpdBXTD7RZT1fZk1N4cpWMRmticBmiiVWsnU6DS996txIaj9boZONipHfnzwPXPK8 vo5fyRQZ0W2OoqBNkRF4dMd2epk5qWw2SyErKUr5pOhp0U6Nb/5AQgO6XTea+L9ofIHO5CoS3Rct mruO7Li8u/E+pHfy88RUVBbfY3Dlw5iknO1KgZfv0lnfaGnakeJQsQT4pxJTb7+d+S69k9/wfv5a yIP2JDN+l2JS8r0mX34LU34+RhbO9hkd83vlV5mq8qeZpuZXt1ltWtHiQddDvqdMzie8T+ft9b6Y d8R7LO9d5yd5clcXCbgDnlhBfnEpX1rQi+9ZMEyujE2Sp8bmG1caXzf+YvolZm1fbCa81jqn2F0Y cnjGtJjVgrbwtzaXm+82bzInzcIm8w7zj2bObPZz7gb6dNzlud/h90vQLVct9HOGFmO1sRAJ5TTQ 6+NabpxtGwSjbaI7okK0bSnTZIGscHGb0kOldHMpKXVHPNmtcw6Kx0QaEMtFKrbtwLYN2Hp2VU3s QtXZ82WNZ84wHXe6aQsB79akliOadhHYBgIGCRE9MmS2pr3+LSnOTS10X0t14+NyOh0udzjKsRVv TLIlhHYlXNmEfdN2HOgxt2fJ9JOTSVG3VYsXZtZ5bjh+x6qnB2iKO/uA3z3uyKxRhTOnTtkazVw6 tPszy/st6ecwm3w5EfWGltdU1nhq1vSJj+3dasG5S8uv6UA+yfNreRWte1Zf3/+am3AGV+AMsuhD g0w4EX+WCEZLjlAidBOE8kBdgAYC2f4i/3X+2YF1AbGjvcxV5uvr6uurkqtMIyxVrtG+afIM0xTL Da4bfIcCHxlPuk96v7D/4P7B+2XmqUAy4A0KrS2tHW2Ecktc6GsZIEwSTmb+zF/UjJrTzIsUMvyo KVSn32zw5Bw3EM0Qx6Cm1sAb5mF4AEVchNJDBP2CzaSOnCN8gJST/oQj3qwe7VPqEqP+Cq3xPLP4 Nbq5wT99KTglJjVzoCYURnuDJh79Xw3C2bkcWvjmPRzS8sn6OTvH7aiJJ3566cB0Wjz0nvnPPn7j /GeF/Y0/393/7jfmJn5MnHiErD84dM3RN4+/chQ104DkN9xZ5HofHI33UIwk4O9i7+IebB/srrZX ux+iD3EPmrZp23xG2eRVp9Gp3DThRuNsU63pCeMeZa+6x2h0YWT+JeXM2WMssyyLLZyFMGbt1UZf 6aiG2bAONsMpOIdBocViQEfB5jdIHj9v8FuIJcecnYG9yDHEAqhw0H708jtzjkkkIJVLVGqbUXxE 9w1q2B7XnPTBiX0o4KjEz845f3ZO08qZtbS1hq5S1ekm14i4GZNiZGNjDlGzP8SIxZXtzPzx+ZOJ f8z59o7n/hrY4V08ctXT25ZNu4ssd79wjGQS9VlCl+zYkjF9xp/eO3H4duSs7kilz9I7Aifiz6iU N0VMxaauJqHEUeIfToeogxyD/ZPpBGGiMt5R7T8UeF/4wP6J94z9jONH9/feMzoHuQKBmI+xXR8f 40GpFc0xtXJ1pCWmPrSbqbujl3+4Osw02XRG/Np1kZw3a8TJmQ2aBTnLIFkBWYszeIoIRKyWiKYd txLNGrdWW2utvHWeLeegdEz6TEpKPKNdf4mTvFnFA9KMVXEWWUrf3y87rfsxDH5lLSbUoRIm1CjV KYIhmxHHr6zFdZh4ZPEHN057f2n1+ta7G4PP3jj/8e23LNiy4tG1lx7bRLjVAztT88Xu1PbWGy+/ cvKtI0izPiiNWchZTqTZp/EJAfA76VCuSqhShhomctOFWcpEg6yBRjSaa/tIuOi44JPa2jp62/o7 2yp8nf0DbaO8g/xjbTN9Y/0LxAXOC/SCRwMXsZjc7gEu5rhxLr9lnbZZo5rGZ/hVCRjjKeR+OzKX O27Svbnc/OI6EzH5AmxxLhItZjieyTRjgARcRVqOFM/JL76CZGlZjFU0nsYQFO1eTUz3/RpP64yG oWlNWXpPMhWPkpo5TcyWCqYdUkh3CEkoqutFbvT+gr/t+zbxI3H89QNiJpe/UXctH7+28SQdaOww 7I5FT5Fh7sfqSQB1gZHkJT5N/KIFd+yfQu5f0WXKE8x7sKN5qsV4xw2741kOhVi8rb1tvHHvbO9D xodNT5lknynPVOc95OW9bHR5vkBxpmzijBa/Spw05rDznAjqJgdxJO1x3h3hgaP3En2VZXfbDsX6 aovqDxSvw7Ye83gPkP0QggtEBWb2MThkZl4rw9jkbFXK7LN9+lJran3aoVlFRRJlNCkaBrBgFS0Z JEZi+UuWkBgy1pwia7ikiO2IIl+hHDIxdBY5w9ZdmzbZfUvn9x2V0aFwUNdjx7gH19ZML+4+3PaI 2r163NrLk5CHrksM5L5DHsqCfDgXrzYYBEeBIeLoa+jmEJVMb2aBIeooCJca2jl6G7o7hkkjDFMM F9WfneZW4YLca8PX5vbNXVewuUBqF2rXorygu6F7qFuLIaEhLaZK40PjW1QX1BaczP0m9Lfwj7lW t0t0NtCd9Xl+u6RrMC2IYQ3TX7VwCI4D465b450Fv9+idsv2G1WXsyhSpEY8nuNuornj7mp3rZt3 z7OQCGQHcg5ajlk+syQtfMBSbumPWtEbK5gXYgIZ66cL5HkW3NWwgOcCO35zWj/5wHBZerGmxs22 c3TbmYvcRVOS6S5pWpm1XyGek3YYCrvMu3WVx0zm13187oZ37jxw8xMTP978x+82PnHrou3P3bxg +wjfwEjhhJHt69aQsk82ELJ2Q+3laf88tuAZLv+dQwff+tMrf8LZXwnAfaPHVDv3gQvZwuR0F0f4 Eq4bt9/E66ccctzeYrdsNVodnEDA4hckh0E1RpR4UbvipEIOKUTppwdh7uJ2xXWucy4627XZVedK ungXdUTSi/j48Dl2iieIlD0FPPRz9hjgSR9/0Vf5YufZmQbQNRUqKuZi6uxmFs1SxCwaM4hJRkYD thS3BGJVqSX+1BEGa9iqU0V0WlfW33Zo/vN96m+cPuDOMjSDP91bte3hxjF0y8pbBt91a+OLyGOr UMTK9HV/CW6NV/VX1imblTrlkPKZck6RQAkos5VaZVO66JSSVNSAgrZK4imHfvdt6N0LIq+KUkQA fhO/ma/jD/GnePEQf46nwAf545jj+X5y0wjnlOnne3BkpCnuYVM+p0Y/4ICjWFVfX89/f+zYJScf vXQShT+5NTGQdNT7aION8QpeiAid+CJhhSC4ZUGQeJ7ygh2IyUA5h5G3CgaJ9csgSn6rZR3KPcZs RqMpoqrrDCRgKDf0N3AGr93xXKhHE0Pqe1H9NBak1UB5BfM99D2o5i5ai4pWanJqu9Isa5aorKkZ RDFLGZCaBHa8q8hJUmdKWFQsIZeuqE9MyW4XaN+uvqjzA734b99555dbNpp73cuPurT5CPtBEWH0 5/7JdoPIW3GfJA4TRyqcxfR34YLIDeVuUqlNDNr1YOjcblsuC47O1SO2CXpBSC+IL8MSkceASGyv 9EDqiC3VEepN3I3qSe5LUXpCJGExKkXkUrGDUm7qb6rkK8URUqVyK79Q2Ki8Ir7LnxBPi99K/xB/ kZ02VRU4jqeiKGHoixmMfyOS6JAkkeP5iKA6BAEjKczIBOdXYDG5wQAq30Asu4RsGVE8HNT9F986 ND2GCNAI+n2AcUh/5Dev0fR5qMekX+muL/rUNK36pANkNM/uUrYDwLNgSsCoih2EknAG5DJOvyLP 6It1SkFmqSJnZpaJbBM9sxTR+7uCOtoZSi3LVeor+zUQi+kreWLy0K6QvjC+y8XQp7u0UjGF9JxR RzsNTTsDbLWbNWX7hCeyw4WtORxl+gVrXdjlYZV/2JmRepxUVerOKhNHdoouTCRkaPL0t4lp5OCn iS2LMVg+QOoS8xsn0MDNCXaacCmyQXudu9fuAwGNUvsOqc204pIUbtM2hbNTm23xCGolixAQNgmf CXx/vJwTuIAwW6gVkgKPWkWlXErRsDfpCseHFmgTkEPohtIrtA7fLJOxWEoqdeU7Rx8JG8HS+vSO G2pGMYqWKAyv7AMFA/POBhNqxtP8aeVz95mg8IFwIUjdcjCseDKCCseFs/yi029AESRi2OfV1OMR si6yOUIjKIvmyDr98FzVHk9kXQbJwFTcC7QoHCHHgTB/mQaAcQsH3pxIA1mw+1dBxRih8TSLwc9X NeprKhgWMJuMCkVnJav7yt1js9FhjzqM1gxiMzmb1KV+pBBH59QXC936qTldZ+rG+UrtuaXwiWnz Hwjc9sajT+8Oj7p29h/qR0zou6QjH72/35hxI/bv2NuYSx+ZMabj/dsaH6C7FiwY8OA9jR+l7chX SC0XvBW3C5xop9u1Bu1L7mv7Oe6CXeSZzLZFAi7UyAbtuOeUJ+nhg7LD7HDZ0KAQ0WVSTWajOceg WxUDwT9DP48+kcyqeM556GzPZk+d55CH93C0yOlKGxbbvxgWd5NROV+WinTRrOjri2VMxTXbFZdo VVRZlVRO1KJW0ZxBLKotTTC2UY7Co/O0s106xL2CYCu33vhJ9ZYBmlqfP73n3Cf56AM7us2uKLy1 cS5dccPMzve+1chOjHRFfzgXaWICL7wcr7JJqtfYQ+wpDxMr5cniVFku1jraOrpKPN20PrY+rm6e UcIoZZBWZatyDfLMFGYqE7SZtpmuCZ6biFMRBdP13BBhiHq9cQY3UZiozjCqbj8vWZHlHDn6mQx7 TqS4jURA0qQgurZtP2OMhuVe5vxi2pwDcXyEMRqFtj7m+OrnCdHprbpQVRVr3jli0YG+RDNYGKyM E8YpPMq4XWuPlIDUyjJc6Yt03XbHnz8mrlu+X/NZ4uy+XStX7Nq9fOUuaie5d81PfN549PvbSRYx vfXmW+/8+c03sOmVial8COliQy/vWPxxo9ZSu0bro/HlwbogDQRbGMOZhc7CzOsyZwfXBeWO7o4Z vd29Myrl642j3KMypsnTjVO1me7pGYeC7zk+8Xziey/rtON01qlgMugK8zEt5izhO2rd+d7aSO2M 4fvMhGawmjFyYMG66MJgHczenOMq0dS4Wq3Wqrw6j9iLaJEtAvBvw/UAhuvk38XresBuLb0yXLc3 CZnL6aDMacu1cleQauW2jvdOWXV82o2f3TLy7lbWJ+YveObJeXN3JqYKL60eOHBtcsNjiUtr+nZs vMRtO3rkzQ/efONDpFfPxFTuFNJLAz/8Mb7BQGM039OJ9qELjWK5s9zbx7sua3OWUGwvzijP6mrv moHBfMZ4+/iM6qzarPfFD2xfid8av/NoLWi2MeYspSXGXrS7cSSdSj8yfuz50vWt96uMy9RCeJPD h3GnWXRgOAVmt7kIWNRpIZolbqm21Fp4yzzrv4k6M7N+4+emnNzzZf9KH6gh1nSQ3i7t2f4m5CzI f2DoS4kfZ713259rtjaGnl0w94kd8298LDGVyp36kVZE2pxY+sRdF7twzx09+qdX3z/xKvMmlqO7 9ApSxwpL451a24nGkzBfzHfhB/OT+Hm8qFhlRVZMdqtiAk4mBp0NQFXy1slEzg7aiZ1mW/+PXqqt x5FmL/W0VnV+DjtPxAbFVq51Vwm011ea9d36qjlsLz01/6m4R0JdsXzrtVPLrx997XXXdRrtyOKj W2p6dnwyt0d59ZzG91n/y5PfcDux/23IR/Fb+GxHdkelt9I1Z1j2xOxFyl3Kspwn7M8UHOZMitvn cbfpU3DCLWTQoZRqhUT1jJJHKaPUUYZRxlGmafI0ZZo6zTDNOM1UH63PtbAdopwW7XJGqpWGCdEJ efPC83Jqc+5THzbem/dAwf1ttqlPGR/L3Za3O/rnqCuTbYrbskpHyrkRo8r7glEnb2iV6WOBkT/g Lff2947x7vAe84oWb8A7y/uZlw947/ZS74t0KEb8wOInjZ2r0Mhx9JKIRig73Lfb4SrWD/llma3F hLQalTkjk2b6nRLvb2UI+Igvxxu3e4q9DfT6XVJOPj75gr/0eD7J9xWyWlGM5qsLDxXS8sLaQlqo EUJyIJhjyf6s2blq2xTA11Sws/1z+ulKn8Xw52Pp5aIaDONjqM3n6II753TzkSt3yhTEc1tmhTHQ jFo1m2bXODHbFMwAJU/KIEJLvGQ5MBsyhzMgO2wyyi3QDc7LVVQxxmdAQMtkRiN10Eq/6EcF8mNL lrAopYa5+VXNZ7Bzo7mtMK5r1/5fdu3wy7a49UCvfJfljlsWLSiJ3PfKxv6dO+TfM/jWl0Za64xz py6a5nK1zlh28IFhU1+59dhH5Br/9DkTu14T9kQKey3p12NhXiDW85bJnkGjBrUP+zPtak5R50Wj Rm4a/izjtJzkTzRf2AhuqN0HKjvKFGXO9KF4Z0zUejHCMZpUwoFLU2IWFVUlZ7Bo2ZBNTLaIkSQl uZvSrVqaLdVK6yQe0MZsluqkQ9JxSZT202ngIe12TkoJi/4jE4zqTjMtcJbt6zEtgAGF9npq9zni Tq09sZUCa3srWx3Q99So5utbNm5GwbJlu/fsscfysrZs0q6duJWOX0ukGYk71zbeV1HgY2NZilJz Sv/XBF7aBz627oMeIg3aXWwr/ly8hc1RHLOTHNnuMhK7y4ACb8XhQJEr4nHrLoabHHITdz+fLvbM xfCd89HZvs2+Ol/Sx/swvm1WCBj7KUHlOEaCvNLP2xy2nm3yLlAz6Gu3ZSmNoLOUj9fMJouJ7d+x U57oY/DGDDDJ1lTwlJ+/BDUi2+hILcLlRvUAyv3rYSyufNEHox/rrxnqDdYbBg68q1P9w/U9Z/Yv mUvvbdx9Z9seAwffvYqWYrBIwMdieKSFSka/UIIhera1VGXSbLKWKuheFcvsQhuS3+1GTNJYZXtN SlaoGPLwgrlv4gp62+DCC+ZOxvfktSqGIF4sxhaQp0TVUihRe0IPdRgZRivlEcokMolOlacqC+Am chNdKC9QblJXkpV0BXeHtEperTwCG5R71Gdhq/oSvCDtVF+HP6sn4QP1B/hSvQTn1QIVBNUDLjUP omp7tT9gZCPEba5iIY6OoopBVkRRHYqiAkcxntJ3NDEOQ9Wtb0+KkqpwQITWRmLMluPxOMbsVGkg GXviGBZQAVNxJUjjJNvw3bv64Teft7GqscrnOXu6Kv0Tg+bgy1r6L2evMLCp+fWchH5Uomm30I5R zvOJGX88HQl4Yj/sS9zARxuXTZ41ZD5dxaL31O7fCzgjNrozrlkcJJ9vodLe1uutd1k5K+NPJRAq 1vyZqeg2/lwgp5gXjYpdzFC8NoEHXjQoBrNs08DOOSS/nGHIROctIuXLMXMxlEgd5U7mrlwPMS5V yH0MXSw9rL1t11sG2aZLE+TJtoXizdI8eZ+437LX9rN4SckzWPMgz5RrzrPk2lo7OkB7203yCnkD 94DxSbKdbjc8YdwDe8X95tcwKv5I+Yb/xvK17bx4UfHbOH0LWhIUVZUNRqOqWa0oX312C2ALNiR7 xSepFnPwT1ZJDkpWmy0mSBgqS2bVaIyYzA6TySxbLZaYKjuwOtuXTs8iUCLZeNliNZpNqlXlOZvJ aGTnjNm02izszJDquKCZCDvsWWviTA3kybga7K+SWepitn9Jh8aV/lYyy7rYyjb5h8YNmkCq9XiQ w4l/cg+5YL8wSTcL3orzVVUeVPv4xxigyvPv96TTHGHVr/+NLWnJrJUxYGkGfeoCg0fUm4LGID2Q PAUEwZw8Xg9tLEFbQ/KUvvup74D2qSsejCG5nDy+U2K/0sGC0OA+dUX6PoecPLVTCqZKbemjf+wg zvG9liB7t9yQPL5LasPeuAs60P2plppf3lzPrdezJk/tVoN8EFI7ryR9quf9vbZSKEBgCwZ2feM1 FQHrpwEZk+s8bnfr++FcLkf6JF7c/1Q5X/TUvk0l1+zdkah/8akWHyLTP3Ta+ga9oXHDm0fppEsn 6aI9l48h91tQH/0Hcr9GbnrBYiOWbK++2BDf6y0daVnPr5c3mh+0HBIOiYekNy2KJe4q9XF2xWny aSWko2EJucsgt7YN5yulSsMI8wNkg7rB8AJtML5meMP8lnaS+0B5x/Sxdka12USRk2RFIaKosJ1x g8WCStdELBaTZkCdTU0GzqipooVaVO0VeEWhWgQUB4DCUdMrJmKKGDmH0cipCobvVNRMyIWg9rcR Wy/TbcZs1TJWVG6Lq6hIXoiLA8Ra/WcxXeLmIHcbze6PA+1lXXQk/ZM2XbegatHOaOfP6oddf2Ux /ZeGaQZivzgExmsWy0pZZ5zUFRHjpuZVnnqzJ7PUoB9UzCw1ZrtLOQSW3xUq1fTle2cpyQ6VKnF/ 00EsNovocbAFGdRPRW6mqdqz9Rgul1jIssTGzx9r5S+I7P4wcQ9Z88nJjolvaR5J/NKjzXVFlxLG xrdJ78pEFdNeocRA7m84fz6ycrfFTyysF9v8pXmOYZYdKhc3xZGgwbw2xRq7SEbF5jJ5bLmGXGOu qZ2xnanEvNFqyLPl2Xu6Km2V9krnVNtU+1TnQnG+aaH1ZsfNzuWm1da1trX2Oxwb1O2GA9qL1v2O 79SvHT+bGrVfHEl/FqoAo4b6BDW/12G3R2yqAzMWIyqMiEF1GAyq3WYzGg0i5/dawK/5aWv/QT/1 N9DyPRZ73BZ3NNAhcUO5LW6jY2wHbdTWQK7bayHZ0C1DZbdslqAhHg8a2xj7G7kBxqSRGvGJ3a0t OFhaXp8RXITKw+fVGtkPlnBW2aFdj3b+tJf9aPOsz6Od1VPgYc5N0xTLV67bsTleqU8oagYzSqQH JfJFMCa/AUPyG3KFPDqSn+5tX6pmty81oxHe4yy1ps/WVbLfh6JI4nzac1PbAu31kyppE8R+9BjO XuzoVFDW022NCobEzMOfxLIDsS/rEzM657RZNKw4MfkpLS8nY7olk89r3HjjkkXz6fRLr+24rnIw m+c8lNP3cZ7NZFXcZGugr8vURgpTR1TejiuYINdm6Quxh+O9MdGC5imttVJSqvYi3Wl3uZfSXxtF htAh8khlgDaDjKfjMQS5hcyTb1HWkOXyHcov5Dz7AV6UtJBjSqn8uPwhkRj3vqA5iylqILR+78dz 0RWnHRWVyqoaIRQNBCXsl2p0rBDDIapjTWCKmVXaQCz1aCQEkZ1/KAAp27TZTMAcN1eba83nzIJ5 Hqi3EbIDSH+YBUm2lGbR5oWYiP668MqC09P67lb6B31n0Ds9o2+Mpj0AzXwkpv+kiO1lxVILoXta kKjM4pkUWWRGJMwdfoGRh9Eo9XOLmkr9aAtT45/usrDRpdE3L2SUKrIr4xpm7ne5WdE/46qrlDoQ fK5fJbiohIhhdv6NSO2KQs48um3uiER/bkLjy7MWTiPf38vJ4r03NY6+RXkI528G9y25RngdDDAv Hn1P+lKiO6U/SfQnmdwnb5HpXPl2mQ6VJ6KzhJGugQP5GYn9WDyLcL+goTVAGQHKlYHUQc7FiJcd 5TI+srDpRKnGVjnQe2+88mfigO47zKnBD6nRNy8cUuon44teDsSuL2hXwvH/fOfxFZ0GtujhGjOY nbHZBXfwYe4imAAdX1KY/qEpsKMkbrbi2BT+R+m0We/PTyT2vpBIzH9/VtXz40488MAH457nLs55 fw6WEfrC3Pfm9B1dN/qBEyceQITj//XdV72ZTr/h13f99g36P12DQN/54ZYVpzeOsZT9LGfI+r9o s/XL3HyG91yz67WLOxonax3lvvq/qkb0Gno96dpEP+iiwcUdiSKtY7q8+SPkieki9u8RpaGOfgij +bngROglZcJNwjAYQVbCSPo0LGLAZUKcfxbm4LNPY74z4v2sLj4/FOEzhDKEYQi+dFkFwliEwSyP z+5jdfEds9l7dDwXRsoBmCUMSzZie+uFV2ESwqOY3sp/CdvFUpiJ+W1Y7yAP0J49g3XWi0/DBix/ GO+Px7JHEY/A/BZMj8J6bdJpRboTvAwjiFjeAt+zJj3eXO5laMfPTX6OY6nEd/ZGWIFtDEDcHaEP PmNHfB3CSvIqrCKvJrfifcSwFNtfycoRuqZxT3zPcrxfjvVyML8U0z7sh4jYghBCyKPPAgoTHEDc Gsc/PDVuhFdhChtz85iw/+k+/Suk+tjnSsA2X0II09LkGcTKFX27GpZeBb24IqhFPB0hA2EgPQoz +b5AkF4bhTPAMUDOY3T6FOEafgL0wzzBfg4W6uFBlkeo0GFuspF/GDZz56ED3rtZXI/jmID0botw AVrTH6ClGIHFyF9d8f1LEB7Fd36j88MEGILtt0JcxJ/ReWgFwlps68cmOjHaYH4JzusgbOsykwis PxihB85LLcIM1h9svzWjOZt3MixRis+exmdGMcBytw44dsaTrA6rj++KpPlw668YtuIzdyJdTyHm EZysD02g81ka8N4r+B4vgoiQidAK4QzCVoTpCB0RXkDIw7YB2+V0fkWeYbyp8wfyhvAq0hD7pvNs agyP6vOZkpkt6XexdkLiszA9DSH2TiYvjGexLzub3s1kivFME9b5ezrje/IfbJyMp5oxyh7/PfRg fdBlEHmrCTO5wz4zeVhPh8IqxA8iHy9lPMv614QZXRiv6TRBmUjjsivG2kaXEcQcQDjN60ubcBMt mvEU2IbvrBbHoU7ZDD35edCTuwfG8eegK9cCWgltsAzHg8/W0e9hkHwIinAu+2N+41V4AwPpAzJN OITjfAbp+QE8gjSt4T+g2fwHRBCeSX4rAHldeIbepqf/BV8N5FDqHsMMrrz3Py3/vwF6QngGdeYz ye+ED5JJHM+9TCak70kbhGATxvJdCLUIGJuTDfJ00iANBU0EOI8wi49DRyEO7flDOD9O1PMoC1g+ VPgcDnJ3ov36IPkRqYVa+gGskJwwlq5HnYZt0ROwlAF7P+LZV/DRb3jual5qwk38ejVmOj/NUwHE Isrf22k4nYYLCD8jHz1GUm20Z/pZtw+ooxFWpPg1ebGZP1+HxxGvaeLPq/h0+lX8abyaL6/Gum1B /d4kp9iPO5rGz/Qj03FMRzI9x/RM0/NX4yvqr6ZPIx8zPXwURqblOjsNvbGPX6RlH/UwzvfwZFLs nnxSrE9u52zJ7WIhpv+CICSfxHEvaLapI5KJtD1t0WRLU+VgaLKjQhHMTOuzbbq++Qn+oNvRYXr/ FHEHLBYu4byjDtT7uzktg0hP7Pd0vhpp/iCsxXF4uZUoj1iOMIrRRJ8LAA+zC8wmcvcjnZktuhOW ch+jv8DqFoFVtxflMBz7/rpehjaVYVYmDIet4vdQyA9FXXsIJrC5YuNg/WFzL98IJtmJeuIDaMs/ hc84QcXnNus0iMOTOl+wutPR+0FaSONBQp7th8+w923R68TBlqbHNp0Wen30RRh/MVrgO0UnDNL9 ie9hkzAUhqMMbZFqYYs4FGXOCdvxHY9jvaGsL1jPp9vr++F6lK9VqJtWoc4Bnf9HJi9xz+B4FqBe R+BqkUbPgEeoRRpO18felU/p2JVMfrinIcp4RLwf9TDzJ+6H1XwMuonT4U4su1NAPYntrsGyZSi/ bVB278D6gbTeBmz7DixndcuZL8N8BCYvUhzsYq3uB4DeB+anYPvct7CF6w2rkI87y/cjHZZDS7QX BHkvC6FtCvT8bWlYmwK9TEthEuI0uFUvL4J36dOcAfmW2dB9/BKYyg+DQq4teHkrtOTfQVn9BR7i LDCGfwMe4htgLcvzdsjj6nD89ehbsvJjMICV03cxvwFG8mVYfxXcwI+BudxO5L33QeUn4VxjPeEu 5JMcrP8TvjcN5EsYyQ1D2VqB6V+Sz7Ln9Dbqk8MZ8D2hpV7vCtD72gRX9Zn2Qbr1xjnF/rL0b/qL fW3uZ1Mf/03/9HGy92I99gz/EPs3k5J/RYikcGIgvROeQdhMT0IXrgIWku2oYB6G7uQMwsNpeA56 6ngnwkC08SVkEUIrvgReQFiC6QLEf0TYkcqj71YCHyMsx3e/jHi3qC8KY7x1HbRjGMseRdiA8GbT vSuBtfXvyq8EASOq3+T3QC0Dcj7ZyODq55HO7bC9dvw1SE8E5MV1DMTFMFKaj/OHUSCfhe+8Ko/t FPJ7YNp/1Z//CsgxaKPTMAXxK8fYNB+IXf8N+OsVOMhw2jb8v+rf/w3g/C5GqNLp+zdwpnnITE5A NuJhiIdxN8ICBphvifnKJnqS88hrDLbDfXp58/ylypFXAP24a64uvzp/9bz+V3m6Gx6/Epr4oJkf 7oVlDPhyfB7h6rz8OixjIP4Z7/35X/P8k/8FjIR87kG9T6Dz2FV5sT/aTASag3316XXWMmjOH0NZ RmDP6vVNcCcDXXYRaD1MZdB8vwT1N8IVdG3H6Ipt6veb5qdpXq6eH+xfnH8bYSTairehDeLBiDs3 4Wb+TuuL3/D8wBS/N+eZLjlz1TO/ysSvsnGM2Zp//87/PwHKzhsIryK88r/dFtMyTEdoTE/8Ff2Q cvQjP0D/5Hp2HrERdcnl1ghPoB4agvhDLEPrnWiBYMK0FcsmI34E4NLPmJ6D5R+kIEn5DNic9iu9 WLY3XVdOv29wqv6l1wAuIkdd3JGqf+lphGmY/g+EWzH9CeKXEW/A57/DessQH07dbxyD+fkIBzD/ PeZnIIzA9DrETsQFCHYEG9Zfz4D5I/8Sh/5/jv99/PHfxeizjMd+BtiaF+JFV8cQ/23cNJ//Bb46 1mia//8KX7FmcBVO0QFjpi/Q76u7Mvb5z2KcJozzmbgS+KHJRvQpjcyPZr4s8591/zGN9fhN92Ox XQBHE2a+M/Nfme/M/FfEWxCvEgW9P0NZnM/6lV6onPE/gB9QC067Ar5ADZqHwFaf3k8BNw+15B9R qmz/CdzwryBVp0A+BKC8AqCeBjC8BWAchvAGgBltuxllyTIO4W8p0K4FsF4EsKMY2y+y/38iBS58 j/snDIcmYaiUnYIMWwr8t/8fYG8KshYABJ4FCL4LGBIChAcA5KD3GdkPEH0eIHcQhgGtAPLbIOB4 CyhAS/Q/WmFZ69EAbRYBtEXfsghlvRjluuQ2DJ2wfx3NAJ3eRlODbZTP/x3+tyHu+x1+h9/hX2D+ /zI8/zv8Dr/D7/A7/A6/w+/wO/wOv8Pv8Dv8Dv9jIOwkJV7KYTwIQEGD1nAd+z8/1EbggHYOg4Vz w48ISQQOAnhtjdAfYQzC3QibEET9OVYyC2ExwkGEc/qdOOfedW9RvAHRGh3tnjajUM+OTWVHVenZ 3cMrU7hiYAp37ZV6rGPqsbbFqeJW16VwbkEK2yKFtQyrpsJDnV2cC44jUJiNV0KPgIUQCMBmzgl1 CJQT0yVxzrY7J1q46SDHA+EoR2ACBJKHOLLLZC3srNIk/RFsEKB/o2dTd+jZ3WZr4abOvekXsAPh IAJHv8Dv5/RzWExPITUteC1H2IRwEOEYwo8IIj2F38/w+yn9FJ/6BFojlCOMQdiEcBDhRwSJfoJX jf6VzY1+ZelyBEr/ileNfozD+hivFnoSUyfpSezae7valxbu0xOx1ulEIJJOuDPSCZursIG+u+uX FoEG+uXuYCywuXMb+j7UIVB9eVlDCCIMQKhGmI0gYuoEpk5ALcI6hM0IdQgi1jmBdU5gnTcQ3kI4 AW0Q4ggDEGR6fBc200CP7YpeF+jsom/TV8GNRD1KX9PxW/QVHb9J/6zj1xFnIX6DvrIrKwCdDXgf sI6GWEPcGu8L9OXdObZAsrOVHkTyBPDaGqEcoT/CGIS7EUR6kGbvmhCw4UtehDdkwCd3wbc6fgK2 yhCfFohHuyCPBdkl2vEaTOFlU3BTlMaj6zdill2id92LKXaJLluLKXaJ3rwEU+wSnTEfU+wSnTAN U+wSHTkGU+wS7T8EU3hpoI++8P80djaxbRRRAJ63Ntl109ROKKlp1t51HRuabRsUUpzEIV4bmxT2 kDQJlbdEbX5kKaiHIm3SnAjTQyQi1AYJqaBy44Soqo4dFG2SSlTyiVy4gDjSAwc4lfRAycm8md2k rQgSu37zZt77Zubt7Ozah11P5ytaZuQK6PmwtIijtIijtIijtEiC0iLfyW6Qx/ZVrasLR+y2aZzs 0ugm0PtAx4B+DbQCdAnodaCDQC8BNYCqQONATaBb0IdDQcH87rlivxkFug30LlAHaBpoCmgnUB0y pislau+8LlRJqLU8v65QvznUE8YYEziiCZzWCbzsv8f0R5SGKJkI6Sc8+OU41yfWunJe+cxAz9X8 OamOFet4GurkV5QgnqA6TqM6NlLHBsKY5lAuozxAeYTSQGlC+gQGvirSMKbdKDmUyygfozxCaRLh PEKRyFU/xHsisG4/6BFekuq489WFE1LCjEXUiBE5F1hVIRyHkXgjLmVIezshpK1VaXWhZf1Jy99P WkgoH5JuSqskhifiM1+v1nZjmgtf1tJbWv4l+ILEgzjroJ+kIYW6jziifJaoCte9RJXuoO6pqRc0 /rc16VPaJhzhtda1XfU37Q/VlTD7u7ql/aK7QahpP6Plzrr2k7qi/dDtKmi5n3YB1aYu0A21T7u7 LdDr6Lhd05a4Wtc+Uoe1K6pwVDzHJQdLZlgbS1/UzmF7RXVGMx1sc13LqZe0QY86y+usa69hCIaX 7cJgT6qi02RcNPhexoU585R8Sy7LI/Ibco98Sk7ImhyTO+SjSpsSUY4oh5VDiqI0KUFFUohylP+F lcEf3j/aFBHvZgZ5GhT5iMRTyXu2XwJFIu8S9mLAkqzxAljswSyxZnT213jShUPnL7IXkgVgbRax Jgqsz7BcuTHGMobF5NH3y1WAmzZamfSJC2Si7EKDm5Y7+NKoGwSgdflGB9evLt+wbRJtv5aL5tqG WvvfLh6QTPnpM6+fRp/Lx9gta7zMvo3ZrIdnGjHbYp/ztVM34DH8WSpuwA5XdnkjMASPS2PcHhgq 2rblwgXBER12kMMZsyM4JU50zhFdiXvcbY9LYX3kOrlCLhQiKcGlQiHBBYFzVaezVKx2dgrmmE4c wTjH9GeZ7RQyqZRg2inZFsx2O+UMGxKIqiISVwUCx4kqEBWOC+TCU6TbR1b2kRXRUwCeMqrHtDzc Y1oeImP8361SMAxYy9qzk3zd2alkqYIyxT69NhdldEbXq7O2vyBtempmdo7r6Qqzk5Uim00W9Wp2 8gD3JHdnk8UqmSxNlKuTZqVYy5rZUnK6aK8Nj/ZmnutrZb+v3tEDGhvljfXyvoYzB7gz3D3M+8rw vjK8r2FzWPRFxBwfLVcVUrDfmvT0mtR8COfrVEfCLrRHPhwSkzebiC51bAb5wzXNhs0OJwusBYW7 TudP57kLrynuOsIXF/Zd0aVsomMTvvFdETS3JgvEmF9wFki09EHR+zi4oWl+gQ+4lxrOf23oKzFz uujME2KxrnGL5c5fLFdlGa1T/JDYwJ6tubnkNh54xjNoHODGQGAf5LZBbguFfPDf53/B1+KdLipt rYEZh3ni2AEWtyYkvBVM+Ku4buLPJf714Nh4gA4Y4Oy1IcIm/hvk/Hj3ZH7Bz/njMO9rrxZWcfaG Y3/DOnir+gdUQ1/CCmVuZHN0cmVhbQplbmRvYmoKMjAgMCBvYmoKPDwvRm9udEJCb3hbLTY2NCAt MzI0IDIwMjggMTAzN10vQ2FwSGVpZ2h0IDY5OS9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnRGaWxl MiAxOSAwIFIvU3RlbVYgODAvRGVzY2VudCAtMjEwL0ZsYWdzIDMyL0ZvbnROYW1lL0daRE9JWStB cmlhbE1UL0FzY2VudCA3MjgvSXRhbGljQW5nbGUgMD4+CmVuZG9iagoyMSAwIG9iago8PC9CYXNl Rm9udC9HWkRPSVkrQXJpYWxNVC9DSURTeXN0ZW1JbmZvPDwvT3JkZXJpbmcoSWRlbnRpdHkpL1Jl Z2lzdHJ5KEFkb2JlKS9TdXBwbGVtZW50IDA+Pi9XIFszWzI3N10xMVszMzMgMzMzXTE1WzI3NyAz MzMgMjc3IDI3N10yMFs1NTYgNTU2IDU1Nl0yOVsyNzddMzRbNTU2XTM2WzY2NiA2NjYgNzIyIDcy MiA2NjYgNjEwIDc3NyA3MjIgMjc3IDUwMF00N1s1NTYgODMzIDcyMiA3NzcgNjY2XTUzWzcyMiA2 NjYgNjEwIDcyMl01OFs5NDNdNjBbNjY2XTY2WzU1Nl02OFs1NTYgNTU2IDUwMCA1NTYgNTU2IDI3 NyA1NTYgNTU2IDIyMiAyMjIgNTAwIDIyMiA4MzMgNTU2IDU1NiA1NTYgNTU2IDMzMyA1MDAgMjc3 IDU1NiA1MDAgNzIyIDUwMCA1MDAgNTAwXTE4MlsyMjJdMzgwWzYwNF00MDRbNjA0XV0vVHlwZS9G b250L1N1YnR5cGUvQ0lERm9udFR5cGUyL0ZvbnREZXNjcmlwdG9yIDIwIDAgUi9EVyAxMDAwL0NJ RFRvR0lETWFwL0lkZW50aXR5Pj4KZW5kb2JqCjIyIDAgb2JqCjw8L0xlbmd0aCA1NTkvRmlsdGVy L0ZsYXRlRGVjb2RlPj5zdHJlYW0KeJxdlM3K20AMRfd+Ci9buog9I80kELRpKWTRH5q0dOuMx8HQ OMZxFnn72rqpPqghB3ydEZoj0Obj4dNh6Ody8326pWOey64f2infb48p5fKcL/1Q1K5s+zS/3pTp 2ozFZjl8fN7nfD0M3a3Y78vNj+XjfZ6e5bvT6feH6n2x+Ta1eeqHy5KQ+/lrSY6PcfyTr3mYy6oQ KdvcLaW+NOPX5prLjR58C0/PMZdO32t0kG5tvo9NylMzXHKxr5ZH9p+XR4o8tP99Dh6nzt3b370Y XSUancXotoiSGN0OUSdGlzSqKzG6FlEtRpcROTG6DhGJ0deIWIzeIQpi9B5RK0bfaORQWOlR3mlh kFDeaWGQUN5pYZBQ3kUxEiHaipEY0U6MFBA1YqSICD6VBKsuiZFg1bVipNeFOjESRHtVDBJE+1qM BNHeiZFgwnsxMqbtoVjJMOGhWMkw4dUByDDh1QHIMOEbMTKu7fV2IOOO5MTI6ItIjAETIhZjQF8U xBjQF0UxBvRFWzEG9EU7MQZMiBoxBrRKmI0yYEKUxBhe3bdiDJjQ4tsYzog6MQYMjSsxBgyNdVxg wNDYiTFADnsxRgyNSYwRvpjFGOGLMUFlhC+OYozwxZigMsIX78QY4YsxVGWEL1ZTYIQvxpyVEb5Y TYERvs7a0UpX1fqvOq5HlI6TKqx36+2US9TpOvu3t9bNti5dW5TpMU3LDtXNrJty3ZH9kG15j7dx PVUuv+IvKH5lqgplbmRzdHJlYW0KZW5kb2JqCjIgMCBvYmoKPDwvRGVzY2VuZGFudEZvbnRzWzIx IDAgUl0vQmFzZUZvbnQvR1pET0lZK0FyaWFsTVQvVHlwZS9Gb250L0VuY29kaW5nL0lkZW50aXR5 LUgvU3VidHlwZS9UeXBlMC9Ub1VuaWNvZGUgMjIgMCBSPj4KZW5kb2JqCjMgMCBvYmoKPDwvQmFz ZUZvbnQvVGltZXMtUm9tYW4vVHlwZS9Gb250L0VuY29kaW5nL1dpbkFuc2lFbmNvZGluZy9TdWJ0 eXBlL1R5cGUxPj4KZW5kb2JqCjUgMCBvYmoKPDwvSVRYVCgyLjEuNikvVHlwZS9QYWdlcy9Db3Vu dCA1L0tpZHNbNiAwIFIgOCAwIFIgMTAgMCBSIDEyIDAgUiAxNCAwIFJdPj4KZW5kb2JqCjIzIDAg b2JqCjw8L1R5cGUvTWV0YWRhdGEvU3VidHlwZS9YTUwvTGVuZ3RoIDI3NjE+PnN0cmVhbQo8P3hw YWNrZXQgYmVnaW49Iu+7vyIgaWQ9Ilc1TTBNcENlaGlIenJlU3pOVGN6a2M5ZCI/Pgo8eDp4bXBt ZXRhIHhtbG5zOng9ImFkb2JlOm5zOm1ldGEvIj4KPHJkZjpSREYgeG1sbnM6cmRmPSJodHRwOi8v d3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjIj4KPHJkZjpEZXNjcmlwdGlvbiBy ZGY6YWJvdXQ9IiIgeG1sbnM6ZGM9Imh0dHA6Ly9wdXJsLm9yZy9kYy9lbGVtZW50cy8xLjEvIj48 ZGM6Zm9ybWF0PmFwcGxpY2F0aW9uL3BkZjwvZGM6Zm9ybWF0PjwvcmRmOkRlc2NyaXB0aW9uPgo8 cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIiB4bWxuczpwZGY9Imh0dHA6Ly9ucy5hZG9iZS5j b20vcGRmLzEuMy8iPjxwZGY6UHJvZHVjZXI+aVRleHQgMi4xLjYgYnkgMVQzWFQ8L3BkZjpQcm9k dWNlcj48L3JkZjpEZXNjcmlwdGlvbj4KPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIgeG1s bnM6eG1wPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvIj48eG1wOkNyZWF0ZURhdGU+MjAx MC0wNi0wN1QxMjoyMDowNS0wNzowMDwveG1wOkNyZWF0ZURhdGU+PHhtcDpNb2RpZnlEYXRlPjIw MTAtMDYtMDdUMTI6MjA6MDUtMDc6MDA8L3htcDpNb2RpZnlEYXRlPjx4bXA6Q3JlYXRvclRvb2w+ UHVibGlzaG9yIDYuMS41IGJ5IERhdmlzb3IgKGh0dHA6Ly93d3cuZGF2aXNvci5jb20pPC94bXA6 Q3JlYXRvclRvb2w+PC9yZGY6RGVzY3JpcHRpb24+CjwvcmRmOlJERj48L3g6eG1wbWV0YT4KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IAo8P3hwYWNrZXQgZW5kPSJ3Ij8+CmVuZHN0cmVhbQplbmRvYmoKMjQgMCBvYmoKPDwvVHlwZS9D YXRhbG9nL01ldGFkYXRhIDIzIDAgUi9QYWdlcyA1IDAgUj4+CmVuZG9iagoyNSAwIG9iago8PC9D cmVhdG9yKFB1Ymxpc2hvciA2LjEuNSBieSBEYXZpc29yIFwoaHR0cDovL3d3dy5kYXZpc29yLmNv bVwpKS9Qcm9kdWNlcihpVGV4dCAyLjEuNiBieSAxVDNYVCkvTW9kRGF0ZShEOjIwMTAwNjA3MTIy MDA1LTA3JzAwJykvQ3JlYXRpb25EYXRlKEQ6MjAxMDA2MDcxMjIwMDUtMDcnMDAnKT4+CmVuZG9i agp4cmVmCjAgMjYKMDAwMDAwMDAwMCA2NTUzNSBmIAowMDAwMDYyMzgzIDAwMDAwIG4gCjAwMDAw ODMzNjIgMDAwMDAgbiAKMDAwMDA4MzQ5MSAwMDAwMCBuIAowMDAwMDAwMDE1IDAwMDAwIG4gCjAw MDAwODM1ODEgMDAwMDAgbiAKMDAwMDAxMjM2MSAwMDAwMCBuIAowMDAwMDEyNTM2IDAwMDAwIG4g CjAwMDAwMjI0MDAgMDAwMDAgbiAKMDAwMDAyMjU3NSAwMDAwMCBuIAowMDAwMDMwNjAyIDAwMDAw IG4gCjAwMDAwMzA3NzggMDAwMDAgbiAKMDAwMDAzNzgzOSAwMDAwMCBuIAowMDAwMDM4MDE2IDAw MDAwIG4gCjAwMDAwNDMzOTYgMDAwMDAgbiAKMDAwMDA0MzU3MyAwMDAwMCBuIAowMDAwMDYxMjYy IDAwMDAwIG4gCjAwMDAwNjE0NTMgMDAwMDAgbiAKMDAwMDA2MTg2MCAwMDAwMCBuIAowMDAwMDYy NTE3IDAwMDAwIG4gCjAwMDAwODIwNTMgMDAwMDAgbiAKMDAwMDA4MjIzNSAwMDAwMCBuIAowMDAw MDgyNzM1IDAwMDAwIG4gCjAwMDAwODM2NzEgMDAwMDAgbiAKMDAwMDA4NjUwOCAwMDAwMCBuIAow MDAwMDg2NTcwIDAwMDAwIG4gCnRyYWlsZXIKPDwvUm9vdCAyNCAwIFIvSUQgWzxmMDk3MjY4NTFk Y2QwYzI0NmRmY2RhZmQ1NzM2ZDIzMT48N2YxMzUwNjk3MzViMWI0NTBjMjM1OTE2MzViMWNhN2I+ XS9JbmZvIDI1IDAgUi9TaXplIDI2Pj4Kc3RhcnR4cmVmCjg2NzU2CiUlRU9GCg== --000e0cd1a89a6e7a66048875a5f1-- From hardjono@mit.edu Mon Jun 7 13:24:12 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E1A53A6822 for ; Mon, 7 Jun 2010 13:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.019 X-Spam-Level: X-Spam-Status: No, score=-1.019 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QEIKvSWkxlwg for ; Mon, 7 Jun 2010 13:24:06 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (DMZ-MAILSEC-SCANNER-2.MIT.EDU [18.9.25.13]) by core3.amsl.com (Postfix) with ESMTP id E441A3A65A6 for ; Mon, 7 Jun 2010 13:24:05 -0700 (PDT) X-AuditID: 1209190d-b7bf0ae0000059a7-50-4c0d55652722 Received: from mailhub-auth-1.mit.edu (MAILHUB-AUTH-1.MIT.EDU [18.9.21.35]) by dmz-mailsec-scanner-2.mit.edu (Symantec Brightmail Gateway) with SMTP id 1F.6F.22951.5655D0C4; Mon, 7 Jun 2010 16:24:06 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-EXCHANGE-2.MIT.EDU [18.9.28.16]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id o57KO5ER004964; Mon, 7 Jun 2010 16:24:05 -0400 Received: from w92exedge4.exchange.mit.edu (W92EXEDGE4.EXCHANGE.MIT.EDU [18.7.73.16]) ) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id o57KO4CF029463; Mon, 7 Jun 2010 16:24:05 -0400 Received: from oc11exhub5.exchange.mit.edu (18.9.3.15) by w92exedge4.exchange.mit.edu (18.7.73.16) with Microsoft SMTP Server (TLS) id 8.1.393.1; Mon, 7 Jun 2010 16:23:28 -0400 Received: from EXPO10.exchange.mit.edu ([18.9.4.15]) by oc11exhub5.exchange.mit.edu ([18.9.3.15]) with mapi; Mon, 7 Jun 2010 16:24:04 -0400 From: Thomas Hardjono To: Dick Hardt , Luke Shepard Date: Mon, 7 Jun 2010 16:24:02 -0400 Thread-Topic: [OAUTH-WG] Username and Password flow: no captcha? Thread-Index: AcsGcOvY/OtQh/yPRj2o2PQlAzt0RwADWVOA Message-ID: References: <067D69D3-6E06-4B53-B9AB-A39B3DE9E957@facebook.com> <82D12A9F-B304-439D-80F9-943ECB5F8BBF@gmail.com> In-Reply-To: <82D12A9F-B304-439D-80F9-943ECB5F8BBF@gmail.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_DADD7EAD88AB484D8CCC328D40214CCD0179258EFDEXPO10exchang_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Username and Password flow: no captcha? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 20:24:12 -0000 --_000_DADD7EAD88AB484D8CCC328D40214CCD0179258EFDEXPO10exchang_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable What if the username/password (or PIN) was used to release a secret (locate= d in an OTP dongle) or to exercise a secret key (symmetric or asymmetric) l= ocated in a smartcard or TPM chip? Reading Section 3.8, it seems it covers these cases already (or am I readin= g the wrong section). In Figure 6, the "Client" would be the code contained= in the auth-device (or the code that invokes the underlying auth-device). Section 3.7 on device flows does not look as if it was written with these p= ortable auth-devices in mind. /thomas/ __________________________________________ From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of D= ick Hardt Sent: Monday, June 07, 2010 2:40 PM To: Luke Shepard Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Username and Password flow: no captcha? Background: The username / password flow can be used to brute force attack = a system to find valid credentials. A captcha is presented to slow the atta= ck down -- similar to what happens when you log in with an invalid password= on a webpage. The captcha would be displayed by the app for the user to enter in if the A= S thinks it is getting attacked from that IP or whatever. The captcha does = not require a web browser -- it actually does make sense for most of the Fa= cebook clients. The captcha was dropped because there were a number of aspects that had not= been standardized, so it was decided to drop it from the core. On 2010-06-07, at 11:30 AM, Luke Shepard wrote: The username/password flow is designed to work in a situation where there i= s no web browser available. At least at Facebook, none of our clients imple= ment captcha - it doesn't really make sense in many contexts. A provider is still welcome to offer a non-standard captcha support but it = shouldn't be part of the core spec. On Jun 7, 2010, at 8:40 AM, Andrew Arnott andrewarnott@gmail.com wrote: In WRAP, there was a CAPTCHA in this profile, but I don't see it in the lat= est OAuth 2.0 draft. Since I've already implemented the CAPTCHA stuff from= WRAP, I'll leave it there if the OAuth 2.0 is likely to pick it up, or rip= it out now if OAuth 2.0 decided it wasn't necessary. Does anyone from the WG have something they can say on the subject? -- 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 --_000_DADD7EAD88AB484D8CCC328D40214CCD0179258EFDEXPO10exchang_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

What if the username/password (or PIN) was used to release a secret (located in an OTP dongle) or to exercise a secret key (symmetric or= asymmetric) located in a smartcard or TPM chip?

 

Reading Section 3.8, it seems it covers these cases already = (or am I reading the wrong section). In Figure 6, the “Client” woul= d be the code contained in the auth-device (or the code that invokes the underly= ing auth-device).

 

Section 3.7 on device flows does not look as if it was writt= en with these portable auth-devices in mind.

 

/thomas/

 

 

__________________________________________=

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of = Dick Hardt
Sent: Monday, June 07, 2010 2:40 PM
To: Luke Shepard
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Username and Password flow: no captcha?=

 

Background: The username / password flow can be used t= o brute force attack a system to find valid credentials. A captcha is present= ed to slow the attack down -- similar to what happens when you log in with an invalid password on a webpage.

 

The captcha would be displayed by the app for the user= to enter in if the AS thinks it is getting attacked from that IP or whatever. = The captcha does not require a web browser -- it actually does make sense for m= ost of the Facebook clients. 

 

The captcha was dropped because there were a number of aspects that had not been standardized, so it was decided to drop it from t= he core.

 

 

On 2010-06-07, at 11:30 AM, Luke Shepard wrote:



The username/password flow is designed to work in a situation where there is no web browser available. At least at Facebook, no= ne of our clients implement captcha - it doesn't really make sense in many contexts.

 

A provider is still welcome to offer a non-standard ca= ptcha support but it shouldn't be part of the core spec.

 

On Jun 7, 2010, at 8:40 AM, Andrew Arnott andrewarnott@gmail.com wrote:



In WRAP, there was a CAPTCHA in this profile, but I do= n't see it in the latest OAuth 2.0 draft.  Since I've already implemented = the CAPTCHA stuff from WRAP, I'll leave it there if the OAuth 2.0 is likely to = pick it up, or rip it out now if OAuth 2.0 decided it wasn't necessary.

Does anyone from the WG have something they can say on the subject?
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the d= eath your right to say it." - S. G. Tallentyre


<ATT00001..txt>

 

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

 

--_000_DADD7EAD88AB484D8CCC328D40214CCD0179258EFDEXPO10exchang_-- From mscurtescu@google.com Mon Jun 7 16:38:14 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC1973A68BE for ; Mon, 7 Jun 2010 16:38:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.747 X-Spam-Level: X-Spam-Status: No, score=-99.747 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZ9jPQD8OM1C for ; Mon, 7 Jun 2010 16:38:13 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 540C03A68B1 for ; Mon, 7 Jun 2010 16:36:52 -0700 (PDT) Received: from kpbe11.cbf.corp.google.com (kpbe11.cbf.corp.google.com [172.25.105.75]) by smtp-out.google.com with ESMTP id o57Naokc001804 for ; Mon, 7 Jun 2010 16:36:50 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1275953811; bh=RdOO2kt1GVrroZwboZMLxOWaEug=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=g8K5SAK398YXzEoDX+2dfwSjVGK8A6JmJUMf0z2hsbfp8Jy+1TNhEbSPPJHq+2Cgd 8qU9t/NjXlj3WTV98RHQg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding; b=u9WRVZYyCPe1rcO+6N7jBMomUNjjmDFkkljn+ymMQJ3Jwfba6FpcwZyrLQ1u/Ipi5 6TUO+9XrweaZXRMJXRdvQ== Received: from pzk33 (pzk33.prod.google.com [10.243.19.161]) by kpbe11.cbf.corp.google.com with ESMTP id o57Nanxl019636 for ; Mon, 7 Jun 2010 16:36:49 -0700 Received: by pzk33 with SMTP id 33so4710674pzk.17 for ; Mon, 07 Jun 2010 16:36:49 -0700 (PDT) Received: by 10.140.55.12 with SMTP id d12mr12448426rva.164.1275953809102; Mon, 07 Jun 2010 16:36:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.124.13 with HTTP; Mon, 7 Jun 2010 16:36:29 -0700 (PDT) In-Reply-To: References: From: Marius Scurtescu Date: Mon, 7 Jun 2010 16:36:29 -0700 Message-ID: To: Andrew Arnott Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] User-agent flow and pre-registered redirect_uri X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 23:38:15 -0000 On Fri, Jun 4, 2010 at 9:49 PM, Andrew Arnott wrot= e: > The user agent flow indicates that the redirect_uri SHOULD be preregister= ed > with the auth server for a given client.=A0 I would like to suggest that = the > SHOULD here be changed to MUST.=A0 Unless I'm missing something, without = a > preregistered redirect_uri any arbitrary client can obtain an access toke= n > under the pretense of being another client, and thereby perhaps altogethe= r > skip a user authorization prompt. > > As there will likely be a few popular client_id's in use, it will actuall= y > make it trivially easy to obtain elevated access to private user data as = a > rogue application.=A0 This danger is unique to the user-agent flow becaus= e in > this flow the client_secret is not required to obtain the access token, > whereas it is for other flows. > > Thoughts? Not sure registration buys you too much. An arbitrary client cannot pretend being another client, client in this case is the redirect_uri. It is up to the end user to trust this redirect_uri. For example, bad.example.com/back cannot pretend it is good.example.com/back because the redirect with the access token will go to good.example.com/back and not to bad.example.com/back. What can happen is that exmple.com/back can pretend to be example.com/back, but registration does not help in this case. The only case where registration really helps is if example.com allows people to create their own pages and as a result someone could create a JavaScript client at example.com/pages/bad. Since you can have several clients under the same domain, the user will be confused. In this case if example.com registers its own redirect_uri no one else under the same domain could potentially use one. But this is a particular case, and up to example.com to enforce. Also, if example.com wants to allow clients installed at different paths, then again, registration does not help. Marius > -- > 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 > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From James.H.Manger@team.telstra.com Mon Jun 7 17:25:56 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3203D3A6844 for ; Mon, 7 Jun 2010 17:25:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.698 X-Spam-Level: * X-Spam-Status: No, score=1.698 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Os58z+lEOczP for ; Mon, 7 Jun 2010 17:25:55 -0700 (PDT) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by core3.amsl.com (Postfix) with ESMTP id 9EA8C3A6842 for ; Mon, 7 Jun 2010 17:25:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,381,1272808800"; d="scan'208";a="4028163" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipoavi.tcif.telstra.com.au with ESMTP; 08 Jun 2010 10:25:47 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6006"; a="2916027" Received: from wsmsg3751.srv.dir.telstra.com ([172.49.40.172]) by ipcavi.tcif.telstra.com.au with ESMTP; 08 Jun 2010 10:25:48 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3751.srv.dir.telstra.com ([172.49.40.172]) with mapi; Tue, 8 Jun 2010 10:25:48 +1000 From: "Manger, James H" To: John Kemp Date: Tue, 8 Jun 2010 10:25:46 +1000 Thread-Topic: [OAUTH-WG] Partially standardized format for access tokens? Thread-Index: AcsGX/Rca8ZktcuzTNG45QqHt/RqgwAPZnaQ Message-ID: <255B9BB34FB7D647A506DC292726F6E11263EBF638@WSMSG3153V.srv.dir.telstra.com> References: <4C090B6C.9030707@aol.com> <4C0930B2.80802@aol.com> <255B9BB34FB7D647A506DC292726F6E11263E5DA7C@WSMSG3153V.srv.dir.telstra.com> <383A9188-1AA6-49FE-95FC-5D6316BD18CD@jkemp.net> In-Reply-To: <383A9188-1AA6-49FE-95FC-5D6316BD18CD@jkemp.net> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Partially standardized format for access tokens? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 00:25:56 -0000 Sm9obiwNCg0KPj4gIGFjY2Vzc190b2tlbj1zYW1sLmZoSEZoZ2Y2NTc1ZmhnRkdyeXRyDQoNCj4g V2hhdCBpcyB0aGUgYWR2YW50YWdlIG9mIGRvaW5nIGl0IHRoaXMgd2F5IG92ZXIgaGF2aW5nIGEg c2VwYXJhdGUgZmllbGQ/DQoNCkNsaWVudCBzaW1wbGljaXR5IChjb2RlIGFuZCBtZW50YWwgbW9k ZWwpLg0KDQo+IFdoYXQgaWYgdGhlIGZvcm1hdCBpcyBhIFVSST8NCg0KVGhhdCBpcyBhIGNob2lj ZSBiZXR3ZWVuIHRoZSBBUyBhbmQgUFIgdGhhdCBpcyBpcnJlbGV2YW50IHRvIHRoZSBjbGllbnQg YXBwIC0tIHNvIHdoeSBzaG91bGQgdGhlIGNsaWVudCBhcHAgaGF2ZSB0byB3b3JyeSBhYm91dCBp dCAoYW5kIGFueSBleHRyYSBlc2NhcGluZyBpdCBlbnRhaWxzKS4NCg0KDQo+PiBUaGVyZSBjYW4g YmUgYW4gSUFOQSByZWdpc3RyeSBmb3IgcHJlZml4ZXMgaWYgdGhhdCBpcyBoZWxwZnVsLg0KDQo+ IFBlcnNvbmFsbHksIEknZCBsaWtlIHRvIHNlZSB0aGlzIHNvbHV0aW9uIGJlIGEgYml0IG1vcmUg ZGlzdHJpYnV0ZWQsIGFuZCBhIHJlZ2lzdHJ5IGlzbid0Lg0KDQpJIGhvcGUgdGhlcmUgYXJlbid0 IHNvIG1hbnkgY29tbW9uLCBzaGFyZWQgZm9ybWF0cyB0aGF0IGEgZGlzdHJpYnV0ZWQgc29sdXRp b24gaXMgbmVjZXNzYXJ5LiBCdXQgeW91IGNhbiBtYWtlIHRoZSBwcmVmaXggYSBkb21haW4gbmFt ZSwgb3IgYSBiYXNlNjR1cmwtZW5jb2RlZCBVUkksIG9yIGEgaGFzaCBvZiBhIFVSSSBldGMgaWYg eW91IHJlYWxseSB3YW50IGl0IGRpc3RyaWJ1dGVkLg0KDQoNCkFuZHJldyBBcm5vdHQgc2FpZDoN Cj4gQnV0IHRva2VuX2Zvcm1hdCBpcyBub3QgdGhlIGlkZWEgSSB0aGluay4gIEl0J3MgbW9yZSBs aWtlIHRva2VuX29yaWdpbi4NCg0KSSBob3BlIHdlIGRvbid0IG5lZWQgYSAzcmQgIm9wYXF1ZSBz dHJpbmciIGZvciB0aGUgY2xpZW50IGFwcCB0byB0cmFuc2ZlciBmcm9tIHRoZSBBUyB0byBQUi4N Cg0KLS0NCkphbWVzIE1hbmdlcg0KDQo= From cmortimore@salesforce.com Mon Jun 7 17:31:28 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 600AE3A68B1 for ; Mon, 7 Jun 2010 17:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.109 X-Spam-Level: X-Spam-Status: No, score=-5.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JCD6S9r5Ddlk for ; Mon, 7 Jun 2010 17:31:17 -0700 (PDT) Received: from exprod8og105.obsmtp.com (exprod8og105.obsmtp.com [64.18.3.90]) by core3.amsl.com (Postfix) with SMTP id A0D9E3A68C0 for ; Mon, 7 Jun 2010 17:31:14 -0700 (PDT) Received: from source ([204.14.239.239]) by exprod8ob105.postini.com ([64.18.7.12]) with SMTP ID DSNKTA2PU8h8TJ1e/X8ssIrkSz8B8qIRWhD0@postini.com; Mon, 07 Jun 2010 17:31:16 PDT Received: from EXSFM-MB01.internal.salesforce.com ([10.1.127.45]) by exsfm-hub4.internal.salesforce.com ([10.1.127.8]) with mapi; Mon, 7 Jun 2010 17:31:14 -0700 From: Chuck Mortimore To: Marius Scurtescu , Andrew Arnott Date: Mon, 7 Jun 2010 17:31:13 -0700 Thread-Topic: [OAUTH-WG] User-agent flow and pre-registered redirect_uri Thread-Index: AcsGmoLaMIpNOjF4RSuRfgsmyJt5/gAB2M/q Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C832DD616AD3cmortimoresalesforcecom_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] User-agent flow and pre-registered redirect_uri X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 00:31:28 -0000 --_000_C832DD616AD3cmortimoresalesforcecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Note sure I follow this Marius: "What can happen is that exmple.com/back can pretend to be example.com/back, but registration does not help in this case." I believe it does help in this case, as the Authorization server can valida= te the registered redirect_uri vs. the requested redirect_uri. Hence the = server would not issue a token to exmple.com in this case. Am I missing s= omething? -cmort On 6/7/10 4:36 PM, "Marius Scurtescu" wrote: On Fri, Jun 4, 2010 at 9:49 PM, Andrew Arnott wrot= e: > The user agent flow indicates that the redirect_uri SHOULD be preregister= ed > with the auth server for a given client. I would like to suggest that th= e > SHOULD here be changed to MUST. Unless I'm missing something, without a > preregistered redirect_uri any arbitrary client can obtain an access toke= n > under the pretense of being another client, and thereby perhaps altogethe= r > skip a user authorization prompt. > > As there will likely be a few popular client_id's in use, it will actuall= y > make it trivially easy to obtain elevated access to private user data as = a > rogue application. This danger is unique to the user-agent flow because = in > this flow the client_secret is not required to obtain the access token, > whereas it is for other flows. > > Thoughts? Not sure registration buys you too much. An arbitrary client cannot pretend being another client, client in this case is the redirect_uri. It is up to the end user to trust this redirect_uri. For example, bad.example.com/back cannot pretend it is good.example.com/back because the redirect with the access token will go to good.example.com/back and not to bad.example.com/back. What can happen is that exmple.com/back can pretend to be example.com/back, but registration does not help in this case. The only case where registration really helps is if example.com allows people to create their own pages and as a result someone could create a JavaScript client at example.com/pages/bad. Since you can have several clients under the same domain, the user will be confused. In this case if example.com registers its own redirect_uri no one else under the same domain could potentially use one. But this is a particular case, and up to example.com to enforce. Also, if example.com wants to allow clients installed at different paths, then again, registration does not help. Marius > -- > 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 > > _______________________________________________ > OAuth mailing 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_C832DD616AD3cmortimoresalesforcecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] User-agent flow and pre-registered redirect_uri</TITL= E> </HEAD> <BODY> <FONT FACE=3D"Lucida Grande"><SPAN STYLE=3D'font-size:11pt'>Note sure I fol= low this Marius:<BR> <BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Lucida Grande"><SPAN STYLE=3D'font-= size:11pt'>“What can happen is that exmple.com/back can pretend to be= <BR> example.com/back, but registration does not help in this case.”<BR> </SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Lucida Grande"><SPAN STYLE=3D'font= -size:11pt'><BR> I believe it does help in this case, as the Authorization server can valida= te the registered redirect_uri vs. the requested redirect_uri.   = Hence the server would not issue a token to exmple.com in this case.  =  Am I missing something?<BR> <BR> -cmort<BR> <BR> <BR> On 6/7/10 4:36 PM, "Marius Scurtescu" <<a href=3D"mscurtescu@g= oogle.com">mscurtescu@google.com</a>> wrote:<BR> <BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Lucida Grande"><SPAN STYLE=3D'font-= size:11pt'>On Fri, Jun 4, 2010 at 9:49 PM, Andrew Arnott <<a href=3D"and= rewarnott@gmail.com">andrewarnott@gmail.com</a>> wrote:<BR> > The user agent flow indicates that the redirect_uri SHOULD be preregis= tered<BR> > with the auth server for a given client.=A0 I would like to suggest th= at the<BR> > SHOULD here be changed to MUST.=A0 Unless I'm missing something, witho= ut a<BR> > preregistered redirect_uri any arbitrary client can obtain an access t= oken<BR> > under the pretense of being another client, and thereby perhaps altoge= ther<BR> > skip a user authorization prompt.<BR> ><BR> > As there will likely be a few popular client_id's in use, it will actu= ally<BR> > make it trivially easy to obtain elevated access to private user data = as a<BR> > rogue application.=A0 This danger is unique to the user-agent flow bec= ause in<BR> > this flow the client_secret is not required to obtain the access token= ,<BR> > whereas it is for other flows.<BR> ><BR> > Thoughts?<BR> <BR> Not sure registration buys you too much.<BR> <BR> An arbitrary client cannot pretend being another client, client in<BR> this case is the redirect_uri. It is up to the end user to trust this<BR> redirect_uri.<BR> <BR> For example, bad.example.com/back cannot pretend it is<BR> good.example.com/back because the redirect with the access token will<BR> go to good.example.com/back and not to bad.example.com/back.<BR> <BR> What can happen is that exmple.com/back can pretend to be<BR> example.com/back, but registration does not help in this case.<BR> <BR> The only case where registration really helps is if example.com allows<BR> people to create their own pages and as a result someone could create<BR> a JavaScript client at example.com/pages/bad. Since you can have<BR> several clients under the same domain, the user will be confused. In<BR> this case if example.com registers its own redirect_uri no one else<BR> under the same domain could potentially use one. But this is a<BR> particular case, and up to example.com to enforce. Also, if<BR> example.com wants to allow clients installed at different paths, then<BR> again, registration does not help.<BR> <BR> Marius<BR> <BR> <BR> > --<BR> > Andrew Arnott<BR> > "I [may] not agree with what you have to say, but I'll defend to = the death<BR> > your right to say it." - S. G. Tallentyre<BR> ><BR> > _______________________________________________<BR> > OAuth mailing list<BR> > <a href=3D"OAuth@ietf.org">OAuth@ietf.org</a><BR> > <a href=3D"https://www.ietf.org/mailman/listinfo/oauth">https://www.ie= tf.org/mailman/listinfo/oauth</a><BR> ><BR> ><BR> _______________________________________________<BR> OAuth mailing list<BR> <a href=3D"OAuth@ietf.org">OAuth@ietf.org</a><BR> <a href=3D"https://www.ietf.org/mailman/listinfo/oauth">https://www.ietf.or= g/mailman/listinfo/oauth</a><BR> <BR> </SPAN></FONT></BLOCKQUOTE> </BODY> </HTML> --_000_C832DD616AD3cmortimoresalesforcecom_-- From dick.hardt@gmail.com Mon Jun 7 18:20:23 2010 Return-Path: <dick.hardt@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A5453A68BE for <oauth@core3.amsl.com>; Mon, 7 Jun 2010 18:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[AWL=0.681, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hR3Zng2KQeYv for <oauth@core3.amsl.com>; Mon, 7 Jun 2010 18:20:13 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id A3B5C3A68E4 for <oauth@ietf.org>; Mon, 7 Jun 2010 18:20:05 -0700 (PDT) Received: by pxi19 with SMTP id 19so1612214pxi.31 for <oauth@ietf.org>; Mon, 07 Jun 2010 18:20:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:message-id:references:to :x-mailer; bh=tiINb3/Dq2tTRmP/lbXkNAH2oM9lntYQ94zTXOAaMMk=; b=RUYqHGr06I4vXciyR9F+7FcNvlldArN8TtCyoaTOYsA/7tICLoAkg7YBqAdMpCO31l Tv0ZfQatkiVj7XsFJx5edk9DxQcpFnoQVqovD2yxhKF4LImk0lXJCXmmZZwvsJcdECnx 7ccZllzPpwLe3IEV/rWq7mpk+mqWq81p+Ro7E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; b=CFxXsRx+lYvv31i20Mfbe+M/CGbvoRXaLP2a5RfsERKKhbwLFAQMtrqWdQu7lnfiEq Q+ZUGoTV8/0VWaoQVodVviPxOR74HpgL7ooy6eHd1slpq+dHNnmruDVYXh1Q+aKwsZal 01lWS458G5sof9i8ECjTOrSo2lCrajRyh/Hoc= Received: by 10.141.101.21 with SMTP id d21mr12605080rvm.95.1275960001399; Mon, 07 Jun 2010 18:20:01 -0700 (PDT) Received: from [10.0.1.15] (c-24-130-32-55.hsd1.ca.comcast.net [24.130.32.55]) by mx.google.com with ESMTPS id k17sm5216006rvh.17.2010.06.07.18.20.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 07 Jun 2010 18:20:00 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/alternative; boundary=Apple-Mail-5--847428150 From: Dick Hardt <dick.hardt@gmail.com> In-Reply-To: <C832DD61.6AD3%cmortimore@salesforce.com> Date: Mon, 7 Jun 2010 18:19:58 -0700 Message-Id: <4C32F5FB-5A05-49AD-9A9C-9157B93A815E@gmail.com> References: <C832DD61.6AD3%cmortimore@salesforce.com> To: Chuck Mortimore <cmortimore@salesforce.com> X-Mailer: Apple Mail (2.1078) Cc: "oauth@ietf.org" <oauth@ietf.org> Subject: Re: [OAUTH-WG] User-agent flow and pre-registered redirect_uri X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 08 Jun 2010 01:20:23 -0000 --Apple-Mail-5--847428150 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 You are pointing out Marius point -- he wants to require registration. = If the redirect_uri is not registered, the only party that can detect = that it is the right URI is the user. The AS can only show the user the = redirect_uri passed over. -- Dick On 2010-06-07, at 5:31 PM, Chuck Mortimore wrote: > Note sure I follow this Marius: >=20 > =93What can happen is that exmple.com/back can pretend to be > example.com/back, but registration does not help in this case.=94 >=20 > I believe it does help in this case, as the Authorization server can = validate the registered redirect_uri vs. the requested redirect_uri. = Hence the server would not issue a token to exmple.com in this case. = Am I missing something? >=20 > -cmort >=20 >=20 > On 6/7/10 4:36 PM, "Marius Scurtescu" <mscurtescu@google.com> wrote: >=20 > On Fri, Jun 4, 2010 at 9:49 PM, Andrew Arnott <andrewarnott@gmail.com> = wrote: > > The user agent flow indicates that the redirect_uri SHOULD be = preregistered > > with the auth server for a given client. I would like to suggest = that the > > SHOULD here be changed to MUST. Unless I'm missing something, = without a > > preregistered redirect_uri any arbitrary client can obtain an access = token > > under the pretense of being another client, and thereby perhaps = altogether > > skip a user authorization prompt. > > > > As there will likely be a few popular client_id's in use, it will = actually > > make it trivially easy to obtain elevated access to private user = data as a > > rogue application. This danger is unique to the user-agent flow = because in > > this flow the client_secret is not required to obtain the access = token, > > whereas it is for other flows. > > > > Thoughts? >=20 > Not sure registration buys you too much. >=20 > An arbitrary client cannot pretend being another client, client in > this case is the redirect_uri. It is up to the end user to trust this > redirect_uri. >=20 > For example, bad.example.com/back cannot pretend it is > good.example.com/back because the redirect with the access token will > go to good.example.com/back and not to bad.example.com/back. >=20 > What can happen is that exmple.com/back can pretend to be > example.com/back, but registration does not help in this case. >=20 > The only case where registration really helps is if example.com allows > people to create their own pages and as a result someone could create > a JavaScript client at example.com/pages/bad. Since you can have > several clients under the same domain, the user will be confused. In > this case if example.com registers its own redirect_uri no one else > under the same domain could potentially use one. But this is a > particular case, and up to example.com to enforce. Also, if > example.com wants to allow clients installed at different paths, then > again, registration does not help. >=20 > Marius >=20 >=20 > > -- > > 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 > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-5--847428150 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 <html><head></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">You = are pointing out Marius point -- he wants to require registration. If = the redirect_uri is not registered, the only party that can detect that = it is the right URI is the user. The AS can only show the user the = redirect_uri passed over.<div><br></div><div>-- = Dick<br><div><br><div><div>On 2010-06-07, at 5:31 PM, Chuck Mortimore = wrote:</div><br class=3D"Apple-interchange-newline"><blockquote = type=3D"cite"><div> <font face=3D"Lucida Grande"><span style=3D"font-size:11pt">Note sure I = follow this Marius:<br> <br> </span></font><blockquote><font face=3D"Lucida Grande"><span = style=3D"font-size:11pt">=93What can happen is that <a = href=3D"http://exmple.com/back">exmple.com/back</a> can pretend to = be<br> <a href=3D"http://example.com/back">example.com/back</a>, but = registration does not help in this case.=94<br> </span></font></blockquote><font face=3D"Lucida Grande"><span = style=3D"font-size:11pt"><br> I believe it does help in this case, as the Authorization server can = validate the registered redirect_uri vs. the requested redirect_uri. =   Hence the server would not issue a token to <a = href=3D"http://exmple.com">exmple.com</a> in this case.   Am I = missing something?<br> <br> -cmort<br> <br> <br> On 6/7/10 4:36 PM, "Marius Scurtescu" <<a = href=3D"x-msg://55/mscurtescu@google.com">mscurtescu@google.com</a>> = wrote:<br> <br> </span></font><blockquote><font face=3D"Lucida Grande"><span = style=3D"font-size:11pt">On Fri, Jun 4, 2010 at 9:49 PM, Andrew Arnott = <<a = href=3D"x-msg://55/andrewarnott@gmail.com">andrewarnott@gmail.com</a>> = wrote:<br> > The user agent flow indicates that the redirect_uri SHOULD be = preregistered<br> > with the auth server for a given client.  I would like to = suggest that the<br> > SHOULD here be changed to MUST.  Unless I'm missing something, = without a<br> > preregistered redirect_uri any arbitrary client can obtain an = access token<br> > under the pretense of being another client, and thereby perhaps = altogether<br> > skip a user authorization prompt.<br> ><br> > As there will likely be a few popular client_id's in use, it will = actually<br> > make it trivially easy to obtain elevated access to private user = data as a<br> > rogue application.  This danger is unique to the user-agent = flow because in<br> > this flow the client_secret is not required to obtain the access = token,<br> > whereas it is for other flows.<br> ><br> > Thoughts?<br> <br> Not sure registration buys you too much.<br> <br> An arbitrary client cannot pretend being another client, client in<br> this case is the redirect_uri. It is up to the end user to trust = this<br> redirect_uri.<br> <br> For example, <a = href=3D"http://bad.example.com/back">bad.example.com/back</a> cannot = pretend it is<br> <a href=3D"http://good.example.com/back">good.example.com/back</a> = because the redirect with the access token will<br> go to <a href=3D"http://good.example.com/back">good.example.com/back</a> = and not to <a = href=3D"http://bad.example.com/back">bad.example.com/back</a>.<br> <br> What can happen is that <a = href=3D"http://exmple.com/back">exmple.com/back</a> can pretend to = be<br> <a href=3D"http://example.com/back">example.com/back</a>, but = registration does not help in this case.<br> <br> The only case where registration really helps is if <a = href=3D"http://example.com">example.com</a> allows<br> people to create their own pages and as a result someone could = create<br> a JavaScript client at <a = href=3D"http://example.com/pages/bad">example.com/pages/bad</a>. Since = you can have<br> several clients under the same domain, the user will be confused. In<br> this case if <a href=3D"http://example.com">example.com</a> registers = its own redirect_uri no one else<br> under the same domain could potentially use one. But this is a<br> particular case, and up to <a href=3D"http://example.com">example.com</a> = to enforce. Also, if<br> <a href=3D"http://example.com">example.com</a> wants to allow clients = installed at different paths, then<br> again, registration does not help.<br> <br> Marius<br> <br> <br> > --<br> > Andrew Arnott<br> > "I [may] not agree with what you have to say, but I'll defend to = the death<br> > your right to say it." - S. G. Tallentyre<br> ><br> > _______________________________________________<br> > OAuth mailing list<br> > <a href=3D"x-msg://55/OAuth@ietf.org">OAuth@ietf.org</a><br> > <a = href=3D"https://www.ietf.org/mailman/listinfo/oauth">https://www.ietf.org/= mailman/listinfo/oauth</a><br> ><br> ><br> _______________________________________________<br> OAuth mailing list<br> <a href=3D"x-msg://55/OAuth@ietf.org">OAuth@ietf.org</a><br> <a = href=3D"https://www.ietf.org/mailman/listinfo/oauth">https://www.ietf.org/= mailman/listinfo/oauth</a><br> <br> </span></font></blockquote> </div> _______________________________________________<br>OAuth mailing = list<br><a = href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a><br>https://www.ietf.org/= mailman/listinfo/oauth<br></blockquote></div><br></div></div></body></html= >= --Apple-Mail-5--847428150-- From dick.hardt@gmail.com Mon Jun 7 18:21:33 2010 Return-Path: <dick.hardt@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 146F43A68E9 for <oauth@core3.amsl.com>; Mon, 7 Jun 2010 18:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[AWL=0.511, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3FQHyk0YhrHq for <oauth@core3.amsl.com>; Mon, 7 Jun 2010 18:21:32 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id 2606B3A68E0 for <oauth@ietf.org>; Mon, 7 Jun 2010 18:21:32 -0700 (PDT) Received: by pxi19 with SMTP id 19so1612675pxi.31 for <oauth@ietf.org>; Mon, 07 Jun 2010 18:21:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:message-id:references:to :x-mailer; bh=He0/AQWqHLcmxz/y2SHjnsN7PfiiRlT0GfztOkY/jHw=; b=QGeE2esITU19Dg8igufE4QyzLFGtnBw+CdtqWUI1B9ajaXruwZ1rWZFZcaVLmz0keM 9jT9/zeD6AGFmNJqgvLT3vKa3OSp1X+CIcQerngcZTCmDjhcI+bQCBi/3V5fk5jzCFpX ROP5d5fHiGIMQBmyla9/VLUrrGrq6UCIn39WA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; b=KMjGJnFMydRyt84xbq1F/nr1Nnywrine0IlNbZ0EMcGyb42Y65NHNFsZy2cbhHzcmI utljRVbZPKclqgDclmZv4JoqSni8d7UtpO00yqDmXNSQWStEzWP/8UdbbiB7hc1oreQa Sf5KeM8WfKj2qQVAXkiMSG+9ofuNsHyOnPty0= Received: by 10.115.39.40 with SMTP id r40mr12278343waj.183.1275960090013; Mon, 07 Jun 2010 18:21:30 -0700 (PDT) Received: from [10.0.1.15] ([24.130.32.55]) by mx.google.com with ESMTPS id d20sm43603222waa.15.2010.06.07.18.21.28 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 07 Jun 2010 18:21:29 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/alternative; boundary=Apple-Mail-6--847339051 From: Dick Hardt <dick.hardt@gmail.com> In-Reply-To: <DADD7EAD88AB484D8CCC328D40214CCD0179258EFD@EXPO10.exchange.mit.edu> Date: Mon, 7 Jun 2010 18:21:27 -0700 Message-Id: <4B4E144D-A3E9-4EDD-B010-FDA700C2BCF8@gmail.com> References: <AANLkTint78W8GC5Jctc0je5dsmuY-Ket2aqI00tjl-NC@mail.gmail.com> <AANLkTilXJM7rphv02DvFsmMgSdjO0twY1nVIPGwduC6m@mail.gmail.com> <067D69D3-6E06-4B53-B9AB-A39B3DE9E957@facebook.com> <82D12A9F-B304-439D-80F9-943ECB5F8BBF@gmail.com> <DADD7EAD88AB484D8CCC328D40214CCD0179258EFD@EXPO10.exchange.mit.edu> To: Thomas Hardjono <hardjono@MIT.EDU> X-Mailer: Apple Mail (2.1078) Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Username and Password flow: no captcha? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 08 Jun 2010 01:21:33 -0000 --Apple-Mail-6--847339051 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 2010-06-07, at 1:24 PM, Thomas Hardjono wrote: > What if the username/password (or PIN) was used to release a secret = (located in an OTP dongle) or to exercise a secret key (symmetric or = asymmetric) located in a smartcard or TPM chip? > =20 > Reading Section 3.8, it seems it covers these cases already (or am I = reading the wrong section). In Figure 6, the =93Client=94 would be the = code contained in the auth-device (or the code that invokes the = underlying auth-device). > =20 > Section 3.7 on device flows does not look as if it was written with = these portable auth-devices in mind. Correct, it was not.=20 --Apple-Mail-6--847339051 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 <html><head><base href=3D"x-msg://57/"></head><body style=3D"word-wrap: = break-word; -webkit-nbsp-mode: space; -webkit-line-break: = after-white-space; "><div><br><div><div>On 2010-06-07, at 1:24 PM, = Thomas Hardjono wrote:</div><br = class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><span = class=3D"Apple-style-span" style=3D"border-collapse: separate; = font-family: Helvetica; font-size: medium; font-style: normal; = font-variant: normal; font-weight: normal; letter-spacing: normal; = line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; = white-space: normal; widows: 2; word-spacing: 0px; = -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: = 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: = auto; -webkit-text-stroke-width: 0px; "><div lang=3D"EN-US" link=3D"blue" = vlink=3D"purple" style=3D"word-wrap: break-word; -webkit-nbsp-mode: = space; -webkit-line-break: after-white-space; "><div = class=3D"Section1"><div style=3D"margin-top: 0in; margin-right: 0in; = margin-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; font-family: = 'Times New Roman', serif; "><span style=3D"font-size: 11pt; font-family: = 'Courier New'; color: rgb(31, 73, 125); ">What if the username/password = (or PIN) was used to release a secret (located in an OTP dongle) or to = exercise a secret key (symmetric or asymmetric) located in a smartcard = or TPM chip?<o:p></o:p></span></div><div style=3D"margin-top: 0in; = margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: = 12pt; font-family: 'Times New Roman', serif; "><span style=3D"font-size: = 11pt; font-family: 'Courier New'; color: rgb(31, 73, 125); = "><o:p> </o:p></span></div><div style=3D"margin-top: 0in; = margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: = 12pt; font-family: 'Times New Roman', serif; "><span style=3D"font-size: = 11pt; font-family: 'Courier New'; color: rgb(31, 73, 125); ">Reading = Section 3.8, it seems it covers these cases already (or am I reading the = wrong section). In Figure 6, the =93Client=94 would be the code = contained in the auth-device (or the code that invokes the underlying = auth-device).<o:p></o:p></span></div><div style=3D"margin-top: 0in; = margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: = 12pt; font-family: 'Times New Roman', serif; "><span style=3D"font-size: = 11pt; font-family: 'Courier New'; color: rgb(31, 73, 125); = "><o:p> </o:p></span></div><div style=3D"margin-top: 0in; = margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: = 12pt; font-family: 'Times New Roman', serif; "><span style=3D"font-size: = 11pt; font-family: 'Courier New'; color: rgb(31, 73, 125); ">Section 3.7 = on device flows does not look as if it was written with these portable = auth-devices in = mind.<o:p></o:p></span></div></div></div></span></blockquote></div><br></d= iv><div>Correct, it was not. </div><div><br></div></body></html>= --Apple-Mail-6--847339051-- From mscurtescu@google.com Mon Jun 7 18:23:33 2010 Return-Path: <mscurtescu@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6BFC3A68E9 for <oauth@core3.amsl.com>; Mon, 7 Jun 2010 18:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.563 X-Spam-Level: X-Spam-Status: No, score=-103.563 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Xexm4OE-ug9 for <oauth@core3.amsl.com>; Mon, 7 Jun 2010 18:23:32 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 938F33A68E0 for <oauth@ietf.org>; Mon, 7 Jun 2010 18:23:32 -0700 (PDT) Received: from hpaq5.eem.corp.google.com (hpaq5.eem.corp.google.com [172.25.149.5]) by smtp-out.google.com with ESMTP id o581NWGh007627 for <oauth@ietf.org>; Mon, 7 Jun 2010 18:23:32 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1275960213; bh=to6fynawJpQ3WUoQaAj4KRq3oPw=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=gSxgN7M9fq+KuQYfAhuem9UFA22GTT+aLdKxdOz3LjxcPLzvHARtaVulexHQaMLk3 ROYqby09NyhI04fR7z6Lw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding; b=To9Ykx4sCznkAhkfw7h9ud5JTHEmwMz2EQGhj7V5xYqxJdTXIKe9v53AeO5ebbt+n k/3G2+gzKwVmTRQPGo/Lg== Received: from pvc7 (pvc7.prod.google.com [10.241.209.135]) by hpaq5.eem.corp.google.com with ESMTP id o581NTnh016630 for <oauth@ietf.org>; Mon, 7 Jun 2010 18:23:31 -0700 Received: by pvc7 with SMTP id 7so1839000pvc.29 for <oauth@ietf.org>; Mon, 07 Jun 2010 18:23:29 -0700 (PDT) Received: by 10.141.187.15 with SMTP id o15mr12492511rvp.174.1275960209157; Mon, 07 Jun 2010 18:23:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.124.13 with HTTP; Mon, 7 Jun 2010 18:23:09 -0700 (PDT) In-Reply-To: <C832DD61.6AD3%cmortimore@salesforce.com> References: <AANLkTil-xDEwMVbV-J7MC1ivoH9w-egOwo5Q2ata94Cc@mail.gmail.com> <C832DD61.6AD3%cmortimore@salesforce.com> From: Marius Scurtescu <mscurtescu@google.com> Date: Mon, 7 Jun 2010 18:23:09 -0700 Message-ID: <AANLkTingSGlJNZ5e_stPd1qU5I4gfbh3rQhqYUmqXvdB@mail.gmail.com> To: Chuck Mortimore <cmortimore@salesforce.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "oauth@ietf.org" <oauth@ietf.org> Subject: Re: [OAUTH-WG] User-agent flow and pre-registered redirect_uri X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 08 Jun 2010 01:23:34 -0000 On Mon, Jun 7, 2010 at 5:31 PM, Chuck Mortimore <cmortimore@salesforce.com> wrote: > Note sure I follow this Marius: > > =93What can happen is that exmple.com/back can pretend to be > example.com/back, but registration does not help in this case.=94 > > I believe it does help in this case, as the Authorization server can > validate the registered redirect_uri vs. the requested redirect_uri. =A0= =A0Hence > the server would not issue a token to exmple.com in this case. =A0=A0Am I > missing something? What stops exmple.com from registering? Unless the authz wants to operate only with a short list of human verified clients. The current spec allows that. But if registration cannot be controlled like that, and all it does it proves that the client owns a domain, then it does not help. I don't think registration should/can be enforced. Marius From sakimura@gmail.com Mon Jun 7 19:53:38 2010 Return-Path: <sakimura@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F15A03A67E9 for <oauth@core3.amsl.com>; Mon, 7 Jun 2010 19:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JxD-zh4JWtX7 for <oauth@core3.amsl.com>; Mon, 7 Jun 2010 19:53:37 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id DE8C23A67ED for <oauth@ietf.org>; Mon, 7 Jun 2010 19:53:36 -0700 (PDT) Received: by iwn42 with SMTP id 42so4138924iwn.31 for <oauth@ietf.org>; Mon, 07 Jun 2010 19:53:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=SfFySIW7jmJif55WFUxCMUWW22hIpWZGmOv3v2uwmXA=; b=OoF1UZjRWWrfKfSwvDBYyz1WWlMDi7hTa/qz6fBGedoSTzdtG50TWQ3cmc7mpgqvVf Y2nHjKwifBqgqBQ4XaUL6V1MZcJSgeFXt+h5/9QshPXKmyDmNIo54vW/3Kf5PH1pn5TH VnDnscxwWGPnzfZyEn/UL43ocnNweGp6GVqco= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=JHF7S5vlUi4/RrAXfWz4q0yPwpKHWRKpX4SFht33VZLSrWbIfwYj8t/eXJpA3CptO1 qLlheSd3GaXrvVkqJpEQ+lbSzBcOqGJhhROBVmdHznt4zLMXitDAO9dnQXxe8OSm+P4h ZLQShLjnEx84J5v+WU5o/Oi8rVoYEVdRf3tAg= MIME-Version: 1.0 Received: by 10.231.130.137 with SMTP id t9mr5521656ibs.142.1275965615136; Mon, 07 Jun 2010 19:53:35 -0700 (PDT) Received: by 10.231.15.133 with HTTP; Mon, 7 Jun 2010 19:53:34 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11262FEE7D8@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E11262FEE7D8@WSMSG3153V.srv.dir.telstra.com> Date: Tue, 8 Jun 2010 11:53:34 +0900 Message-ID: <AANLkTimIXMReEaB3ShbZIjWjiBH-VUjrvHgKHCzgVOu0@mail.gmail.com> From: Nat Sakimura <sakimura@gmail.com> To: "Manger, James H" <James.H.Manger@team.telstra.com> Content-Type: multipart/alternative; boundary=001485f9a7043c60e704887be59b Cc: oauth <oauth@ietf.org> Subject: Re: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 08 Jun 2010 02:53:38 -0000 --001485f9a7043c60e704887be59b Content-Type: text/plain; charset=ISO-8859-1 I fully agree on it. Instead of doing as a flow, defining request_url as one of the core variable would be better. The question then is, whether this community accepts the idea. On Mon, Jun 7, 2010 at 10:51 PM, Manger, James H < James.H.Manger@team.telstra.com> wrote: > Nat, > > > On the other hand, you are starting to think of it as a generic "include" > mechanism, are you? > > Yes. That feels like the simplest mental model for this functionality, and > the simplest way to specify it. > > -- > James Manger > -- Nat Sakimura (=nat) http://www.sakimura.org/en/ http://twitter.com/_nat_en --001485f9a7043c60e704887be59b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I fully agree on it.=A0<div><br></div><div>Instead of doing as a flow, defi= ning request_url as one of the core variable would be better.=A0</div><div>= The question then is, whether this community accepts the idea.=A0<br><br><d= iv class=3D"gmail_quote"> On Mon, Jun 7, 2010 at 10:51 PM, Manger, James H <span dir=3D"ltr"><<a h= ref=3D"mailto:James.H.Manger@team.telstra.com">James.H.Manger@team.telstra.= com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"mar= gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> Nat,<br> <div class=3D"im"><br> > On the other hand, you are starting to think of it as a generic "= include" mechanism, are you?<br> <br> </div>Yes. That feels like the simplest mental model for this functionality= , and the simplest way to specify it.<br> <br> --<br> <font color=3D"#888888">James Manger<br> </font></blockquote></div><br><br clear=3D"all"><br>-- <br>Nat Sakimura (= =3Dnat)<br><a href=3D"http://www.sakimura.org/en/">http://www.sakimura.org/= en/</a><br><a href=3D"http://twitter.com/_nat_en">http://twitter.com/_nat_e= n</a><br> </div> --001485f9a7043c60e704887be59b-- From sakimura@gmail.com Mon Jun 7 20:10:33 2010 Return-Path: <sakimura@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 498AB3A68FA for <oauth@core3.amsl.com>; Mon, 7 Jun 2010 20:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OygrcqmU4c1b for <oauth@core3.amsl.com>; Mon, 7 Jun 2010 20:10:31 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 827D53A690F for <oauth@ietf.org>; Mon, 7 Jun 2010 20:10:31 -0700 (PDT) Received: by iwn42 with SMTP id 42so4152962iwn.31 for <oauth@ietf.org>; Mon, 07 Jun 2010 20:10:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=17+VmAHDC8zOKGCqZhtRuTNXGIj47kkjUj2M/PDSsmw=; b=bYD2K0gliGNJuwrNffN4bQ2RB/wSj3Y+aImkzp/YMS1LBrc9ogK6F/l/6r0XKthVOw jInVTEPTg9YeqdVT6lPhr/CFekuyEVgkW26LRGtAIf5uCzjhwEVpNoeMmTPB0HbMyEBk oDu5A2PS4HSL0GJYyCGBk70Wq3bESnbIv7n14= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=IysU9pVKFf36ihwcEeS/9139jEC2rzvJhTrqMHP8HJOypJDVAnWoOWzjgXPp15jxMo PYa/RF/aWcNJEmjUsuGwJ2HanG0lS9UcRErez3VHPsGQVy3Wsc4SI7QkkJv704jsIi/a X2Z8/F1v6tjnH3njDEqRdEy8vc8Pvsy5rNLFg= MIME-Version: 1.0 Received: by 10.231.185.6 with SMTP id cm6mr1048402ibb.72.1275966629956; Mon, 07 Jun 2010 20:10:29 -0700 (PDT) Received: by 10.231.15.133 with HTTP; Mon, 7 Jun 2010 20:10:29 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF6898@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF6898@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Tue, 8 Jun 2010 12:10:29 +0900 Message-ID: <AANLkTimBfbOPU7aj2dD5vHjqOR7xpAZmBDoh5KZOG_-w@mail.gmail.com> From: Nat Sakimura <sakimura@gmail.com> To: Eran Hammer-Lahav <eran@hueniverse.com> Content-Type: multipart/alternative; boundary=0050450171eeb94e4a04887c21a6 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Next draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 08 Jun 2010 03:10:33 -0000 --0050450171eeb94e4a04887c21a6 Content-Type: text/plain; charset=ISO-8859-1 I have proposed Mobile WebApp Flow (aka artifact binding). There are two ways to approach it. 1) Do it as a Flow like I proposed. (I have even sent XML manuscript). 2) Get the "request_url" into the current flows. The approach 2) may be more logical but affects every flow. Changes with 1) is localized. I actually prefer 2), but can live with 1). Also, having a section or paragraph about how extension parameters may be defined for the requests and responses are useful. For example, we do not know whether it is OK to send other parameters with OAuth request or not. Hopefully, it is OK to send anything as long as the Authorization server understands. =nat On Tue, Jun 8, 2010 at 12:44 AM, Eran Hammer-Lahav <eran@hueniverse.com>wrote: > I still need to catch up on the list (I took a little break). I plan to > post a new draft this week incorporating many editorial changes discussed at > the interim meeting. I am also planning of removing some non-stable features > (such as discovery and signatures) from the draft and moving them to new > drafts. As soon as -06 is published, I plan to issue informal last-calls for > each section so that we can lock down the normative portions of the draft. > > If you have any must-happen changes for -05 that were not already posted to > the list, please let me know. > > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Nat Sakimura (=nat) http://www.sakimura.org/en/ http://twitter.com/_nat_en --0050450171eeb94e4a04887c21a6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I have proposed Mobile WebApp Flow (aka artifact binding).=A0<div><br></div= ><div>There are two ways to approach it.=A0</div><div><br></div><div>1) Do = it as a Flow like I proposed. (I have even sent XML manuscript).=A0</div><d= iv> 2) Get the "request_url" into the current flows.=A0</div><div><br= ></div><div>The approach 2) may be more logical but affects every flow. Cha= nges with 1) is localized.=A0</div><div>I actually prefer 2), but can live = with 1).=A0</div> <div><br></div><div>Also, having a section or paragraph about how extension= parameters may be defined=A0</div><div>for the requests and responses are = useful. For example, we do not know whether=A0</div><div>it is OK to send o= ther parameters with OAuth request or not. Hopefully, it is OK to=A0</div> <div>send anything as long as the Authorization server understands.=A0</div= ><div><br></div><div>=3Dnat</div><div><br><br><div class=3D"gmail_quote">On= Tue, Jun 8, 2010 at 12:44 AM, Eran Hammer-Lahav <span dir=3D"ltr"><<a h= ref=3D"mailto:eran@hueniverse.com">eran@hueniverse.com</a>></span> wrote= :<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex;">I still need to catch up on the list (I too= k a little break). I plan to post a new draft this week incorporating many = editorial changes discussed at the interim meeting. I am also planning of r= emoving some non-stable features (such as discovery and signatures) from th= e draft and moving them to new drafts. As soon as -06 is published, I plan = to issue informal last-calls for each section so that we can lock down the = normative portions of the draft.<br> <br> If you have any must-happen changes for -05 that were not already posted to= the list, please let me know.<br> <br> EHL<br> _______________________________________________<br> OAuth mailing list<br> <a href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_blank">h= ttps://www.ietf.org/mailman/listinfo/oauth</a><br> </blockquote></div><br><br clear=3D"all"><br>-- <br>Nat Sakimura (=3Dnat)<b= r><a href=3D"http://www.sakimura.org/en/">http://www.sakimura.org/en/</a><b= r><a href=3D"http://twitter.com/_nat_en">http://twitter.com/_nat_en</a><br> </div> --0050450171eeb94e4a04887c21a6-- From sakimura@gmail.com Mon Jun 7 20:30:00 2010 Return-Path: <sakimura@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4A883A6905 for <oauth@core3.amsl.com>; Mon, 7 Jun 2010 20:30:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rdbZPkAVHXKo for <oauth@core3.amsl.com>; Mon, 7 Jun 2010 20:29:59 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 928763A67E9 for <oauth@ietf.org>; Mon, 7 Jun 2010 20:29:59 -0700 (PDT) Received: by iwn42 with SMTP id 42so4167802iwn.31 for <oauth@ietf.org>; Mon, 07 Jun 2010 20:29:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=Z0f8GVpPPQJo8KjvrCOlKSqopzQQi9pYSS+F5Te9h5g=; b=OW04QzkOoa16xr9Psp8XKT3fJTIHZjEYEFblOgR5uEkgHkirCcSAg1TBPBw+FUdw44 9Gf5FXzmV6OWWeQSZmy9ZlmP98enxJyB8VULWeVHlBzegDRRqHT1NWjNBc1qsp0juZJc Nwhh8y43DRE+eLsYmElgrIE9l5i3lIpWstahQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=bbsC2Tix0QgvEFJrCnhhcTZPo+5eZX9dR5labv3NmlbFQP8OOO1zTJv4Sag6Lx4BPp SDw+TuHaFruuq530VW3y0TX+4eqw+I3R5kh3EaS8j3UQdLONd40vA8E44/ssQQut3Lys KINXukQPuyAXwavZF3j1wj+nOoLsKvJece6Rc= MIME-Version: 1.0 Received: by 10.231.185.6 with SMTP id cm6mr1069003ibb.72.1275967797482; Mon, 07 Jun 2010 20:29:57 -0700 (PDT) Received: by 10.231.15.133 with HTTP; Mon, 7 Jun 2010 20:29:57 -0700 (PDT) In-Reply-To: <AANLkTinTOMNN1SfWrs2SQWp6OX9vjpX_wRgCB673xUUy@mail.gmail.com> References: <AANLkTinQTV9JJPiftquRbvdqAOHxUXk7QQKCMrmQ4LLK@mail.gmail.com> <B549E6C4-A24D-4032-8A26-89ED58EBAA34@facebook.com> <4C090B6C.9030707@aol.com> <B6D1E6FF-D65F-4FD6-B148-C17550421FC9@facebook.com> <1275664996.7068.102.camel@localhost.localdomain> <AANLkTinTOMNN1SfWrs2SQWp6OX9vjpX_wRgCB673xUUy@mail.gmail.com> Date: Tue, 8 Jun 2010 12:29:57 +0900 Message-ID: <AANLkTinostD5SEMmh9NwwL2JdEZgj-YoosL9tHkTVwz9@mail.gmail.com> From: Nat Sakimura <sakimura@gmail.com> To: Dick Hardt <dick.hardt@gmail.com> Content-Type: multipart/alternative; boundary=0050450171ee5071ca04887c6763 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Partially standardized format for access tokens? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 08 Jun 2010 03:30:00 -0000 --0050450171ee5071ca04887c6763 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Jun 5, 2010 at 12:37 AM, Dick Hardt <dick.hardt@gmail.com> wrote: > On Fri, Jun 4, 2010 at 8:23 AM, Justin Richer <jricher@mitre.org> wrote: > >> > We should solve one problem at a time. It's easy to layer structure >> > on top of an opaque blob in a separate spec. >> >> +1 to this. Token structure seems like a nice idea, but it's outside >> what should be dictated by the OAuth spec. We want people to be able to >> use OAuth to shuttle their existing tokens around, or create hexblobs >> that mean nothing to anyone else, or encode 37 fields in a structured >> format that's signed with a private key, or whatever else they want to >> do, and still have all of that be OAuth. If someone wants to say "we use >> OAuth and our tokens are UberTokens so they're compatible with everyone >> else", that's fine; but you should be fully able to do OAuth without >> adding *any* structure to your tokens whatsoever. > > > Token format has been out of scope of WRAP and OAuth 2.0. > > A separate spec defining standard tokens has been discussed. > Where is it being done? I am very interested in it. > > Luke was commenting on not supporting multiple AS. That *IS* in scope and > was a design objective and *IS* being implemented. > > -- DIck > >> > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- Nat Sakimura (=nat) http://www.sakimura.org/en/ http://twitter.com/_nat_en --0050450171ee5071ca04887c6763 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <br><br><div class=3D"gmail_quote">On Sat, Jun 5, 2010 at 12:37 AM, Dick Ha= rdt <span dir=3D"ltr"><<a href=3D"mailto:dick.hardt@gmail.com">dick.hard= t@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" styl= e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div><div class=3D"gmail_quote"><div class=3D"im">On Fri, Jun 4, 2010 at 8:= 23 AM, Justin Richer <span dir=3D"ltr"><<a href=3D"mailto:jricher@mitre.= org" target=3D"_blank">jricher@mitre.org</a>></span> wrote:<br><blockquo= te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so= lid;padding-left:1ex"> <div>> We should solve one problem at a time. It's easy to layer str= ucture<br> > on top of an opaque blob in a separate spec.<br> <br> </div>+1 to this. Token structure seems like a nice idea, but it's outs= ide<br> what should be dictated by the OAuth spec. We want people to be able to<br> use OAuth to shuttle their existing tokens around, or create hexblobs<br> that mean nothing to anyone else, or encode 37 fields in a structured<br> format that's signed with a private key, or whatever else they want to<= br> do, and still have all of that be OAuth. If someone wants to say "we u= se<br> OAuth and our tokens are UberTokens so they're compatible with everyone= <br> else", that's fine; but you should be fully able to do OAuth witho= ut<br> adding *any* structure to your tokens whatsoever.</blockquote><div><br></di= v></div>Token format has been out of scope of WRAP and OAuth 2.0.<div><br><= /div><div>A separate spec defining standard tokens has been discussed.</div= > </div></div></blockquote><div><br></div><div>Where is it being done?=A0</di= v><div>I am very interested in it.=A0</div><div>=A0</div><blockquote class= =3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd= ing-left:1ex;"> <div><div class=3D"gmail_quote"> <div><br></div><div>Luke was commenting on not supporting multiple AS. That= *IS* in scope and was a design objective and *IS* being implemented.</div>= <div><br></div><div>-- DIck=A0</div><blockquote class=3D"gmail_quote" style= =3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> =A0</blockquote></div><br></div> <br>_______________________________________________<br> OAuth mailing list<br> <a href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_blank">h= ttps://www.ietf.org/mailman/listinfo/oauth</a><br> <br></blockquote></div><br><br clear=3D"all"><br>-- <br>Nat Sakimura (=3Dna= t)<br><a href=3D"http://www.sakimura.org/en/">http://www.sakimura.org/en/</= a><br><a href=3D"http://twitter.com/_nat_en">http://twitter.com/_nat_en</a>= <br> --0050450171ee5071ca04887c6763-- From sakimura@gmail.com Mon Jun 7 21:45:59 2010 Return-Path: <sakimura@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81BBC3A6959 for <oauth@core3.amsl.com>; Mon, 7 Jun 2010 21:45:59 -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=-0.975, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BJCmA7QB94fD for <oauth@core3.amsl.com>; Mon, 7 Jun 2010 21:45:58 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id DCD003A6955 for <oauth@ietf.org>; Mon, 7 Jun 2010 21:45:57 -0700 (PDT) Received: by iwn42 with SMTP id 42so4224395iwn.31 for <oauth@ietf.org>; Mon, 07 Jun 2010 21:45:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=vny3EKu4j7txBDJcF2hXPbfwS09OcFt6cE08/6LvLRU=; b=SplAZ1R3j2QCX6IrxyL/a1R+fmGi9DmuGs6cZ4RzlGexdoVm1X/jfHMZS47Ov/NRaH vFDPMRlAi5Hvu7V1lp1Ol/x1Q5r3drfKZah3ghNYjvkbfoJGELzQGbuahJZ7WfxWidoE e2WAPzxtFsbtHkDgajbOPZptdVo1CWF9diZyw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=vwiccLXOnZgnhz8j+o9gywLUzjoXFi8NNfbNlzkV2IUg/+PrFjvYTun56MLNvlxxc0 /1Y39tX0h1iHvsFTNH7T5BgpOsTaG4JPtNwUBsdmaazL+Uuw4T16posxZaOaKVdRY+3i GkmGhE+0p3EarFwv/GGHzJsINYXEoc3YaobgI= MIME-Version: 1.0 Received: by 10.231.171.13 with SMTP id f13mr5673994ibz.103.1275972352760; Mon, 07 Jun 2010 21:45:52 -0700 (PDT) Received: by 10.231.15.133 with HTTP; Mon, 7 Jun 2010 21:45:52 -0700 (PDT) Date: Tue, 8 Jun 2010 13:45:52 +0900 Message-ID: <AANLkTik71Izx8JF0I24hp7Vwx8LnKGpoEDhQRq9TxMyE@mail.gmail.com> From: Nat Sakimura <sakimura@gmail.com> To: oauth <oauth@ietf.org> Content-Type: multipart/alternative; boundary=001636c9246bd45abc04887d76b7 Subject: [OAUTH-WG] Extension Mechanism X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 08 Jun 2010 04:45:59 -0000 --001636c9246bd45abc04887d76b7 Content-Type: text/plain; charset=ISO-8859-1 Defining an Extension Mechanism for both request and response would generally be useful. Some basic design principles: - no name space through type URI: fixed registered string for extensions. e.g., for Open Graph, perhaps use og:variable_names OR og_variable names where either "og:" or "og_" is the type prefix. (I kind of prefer ":" over "_" as a separator since in CGI "-" and "_" will be identical, and in PHP GPC parameters "." and "_" are identical. Also, we are using "_" in the variable names already. ) - no cross interactions with other extensions I think it should be added as Chapter 7 or so, which means Security Considerations will be chapter 8. Following is the straw-man. 7. Extension Mechanism Additional parameters MAY be defined for any request and response. The parameter names MUST start with a parameter prefix separated by a colon ":". For example: pape:max_auth_age Each extension MUST define its own error messages and MUST return them through the prefixed "error" parameter. For example: "pape:error":"Invalid max_auth_age format." cheers, Nat -- Nat Sakimura (=nat) http://www.sakimura.org/en/ http://twitter.com/_nat_en --001636c9246bd45abc04887d76b7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Defining an Extension Mechanism for both request and response would general= ly be useful.=A0<div><br></div><div>Some basic design principles:=A0</div><= div><br></div><div>- no name space through type URI: fixed registered strin= g for extensions.=A0</div> <div>=A0=A0 e.g., for Open Graph, perhaps use og:variable_names OR og_varia= ble names=A0</div><div>=A0=A0 =A0where either "og:" or "og_&= quot; is the type prefix. (I kind of prefer ":" over "_"= ; as=A0</div> <div>=A0=A0 =A0a separator since in CGI "-" and "_" wil= l be identical, and in PHP GPC parameters</div><div>=A0=A0 =A0"."= and "_"=A0=A0are identical. Also, we are using "_" in = the variable names already. )</div> <div>- no cross interactions with other extensions</div><div><br></div><div= >I think it should be added as Chapter 7 or so, which means Security Consid= erations will be chapter 8.=A0</div><div><br></div><div>Following is the st= raw-man.=A0</div> <div><br></div><div>7. Extension Mechanism</div><div><br></div><div>Additio= nal parameters MAY be defined for any request and response.=A0</div><div>Th= e parameter names MUST start with a parameter prefix separated by a colon &= quot;:".=A0</div> <div><br></div><div>For example:=A0</div><div><br></div><div><span class=3D= "Apple-style-span" style=3D"font-family: verdana, charcoal, helvetica, aria= l, sans-serif; ">pape:max_auth_age</span></div><div><font class=3D"Apple-st= yle-span" face=3D"verdana, charcoal, helvetica, arial, sans-serif"><br> </font></div><div><font class=3D"Apple-style-span" face=3D"verdana, charcoa= l, helvetica, arial, sans-serif">Each extension MUST define its own error m= essages and MUST return them through=A0</font></div><div><font class=3D"App= le-style-span" face=3D"verdana, charcoal, helvetica, arial, sans-serif">the= prefixed "error" parameter.=A0</font></div> <div><font class=3D"Apple-style-span" face=3D"verdana, charcoal, helvetica,= arial, sans-serif"><br></font></div><div><font class=3D"Apple-style-span" = face=3D"verdana, charcoal, helvetica, arial, sans-serif">For example:=A0</f= ont></div> <div><font class=3D"Apple-style-span" face=3D"verdana, charcoal, helvetica,= arial, sans-serif"><br></font></div><div><font class=3D"Apple-style-span" = face=3D"verdana, charcoal, helvetica, arial, sans-serif">"pape:error&q= uot;:"Invalid max_auth_age format."</font></div> <div><font class=3D"Apple-style-span" face=3D"verdana, charcoal, helvetica,= arial, sans-serif"><br></font></div><div><font class=3D"Apple-style-span" = face=3D"verdana, charcoal, helvetica, arial, sans-serif"><br></font></div><= div> cheers,=A0</div><div><br></div><div>Nat</div><div><br></div><div><br></div>= <div><br><div><br></div><div><br clear=3D"all"><br>-- <br>Nat Sakimura (=3D= nat)<br><a href=3D"http://www.sakimura.org/en/">http://www.sakimura.org/en/= </a><br> <a href=3D"http://twitter.com/_nat_en">http://twitter.com/_nat_en</a><br> </div></div> --001636c9246bd45abc04887d76b7-- From sakimura@gmail.com Mon Jun 7 23:06:36 2010 Return-Path: <sakimura@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D28D3A694D for <oauth@core3.amsl.com>; Mon, 7 Jun 2010 23:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.334 X-Spam-Level: X-Spam-Status: No, score=-1.334 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-4VVXqz0fW7 for <oauth@core3.amsl.com>; Mon, 7 Jun 2010 23:06:34 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id C3B473A698A for <oauth@ietf.org>; Mon, 7 Jun 2010 23:06:33 -0700 (PDT) Received: by iwn42 with SMTP id 42so4279137iwn.31 for <oauth@ietf.org>; Mon, 07 Jun 2010 23:06:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=kYkLTkKsoISXO6LF+pNc7F+j78gA+uAPl5gKVk+ClMg=; b=qg9Oh33uLb8yxZ+r1wERb6oLzsRS0lZ7cayG1jnlWw44+H892ichYz8mFOPTVN8/hD Dan3HGOkh6l6gpLT2qaHMNawFVS/e0nVZJ1uH+JtXiob6NCYuYHMcfawMgouKJEjZnhr iVSul27jDmN1O/uOVLbph/uOLaHRhGbP0QyFU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=CNmwiX37Hz7EdQ/6USh8Wy7dzFlWtcxd2ibXlMmyPiDHf1hKrn2HkDoocrEgbcuCPs iUJ8Dk75J6hajkiz4xzpBpVDlMZvf5cV2sBrvpKyNtYhQaQXV1VqqNb1nIWV/JgTaqQG bKbs9TvQVNYujsenmVn9Y87w3mbyxt8eph2iM= MIME-Version: 1.0 Received: by 10.231.188.156 with SMTP id da28mr5667250ibb.196.1275977192156; Mon, 07 Jun 2010 23:06:32 -0700 (PDT) Received: by 10.231.15.133 with HTTP; Mon, 7 Jun 2010 23:06:32 -0700 (PDT) In-Reply-To: <4C0930B2.80802@aol.com> References: <AANLkTinQTV9JJPiftquRbvdqAOHxUXk7QQKCMrmQ4LLK@mail.gmail.com> <B549E6C4-A24D-4032-8A26-89ED58EBAA34@facebook.com> <4C090B6C.9030707@aol.com> <B6D1E6FF-D65F-4FD6-B148-C17550421FC9@facebook.com> <AANLkTilj0xG6SjHrzkd9Ca-N67J7IlsTNAOkyFdjQ62I@mail.gmail.com> <ED86A2AA-56D5-4DC6-B896-48A850EED3B2@facebook.com> <4C0930B2.80802@aol.com> Date: Tue, 8 Jun 2010 15:06:32 +0900 Message-ID: <AANLkTikE59M-BbyYyoMFjR_akT--JdfHKojKIeUivOZe@mail.gmail.com> From: Nat Sakimura <sakimura@gmail.com> To: George Fletcher <gffletch@aol.com> Content-Type: multipart/alternative; boundary=001636c5a79c47aced04887e978f Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Partially standardized format for access tokens? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 08 Jun 2010 06:06:36 -0000 --001636c5a79c47aced04887e978f Content-Type: text/plain; charset=ISO-8859-1 +1 FYI, OpenID Artifact Binding Draft (which is OpenID on OAuth) defined a "server_id" variable to tell from where it was issued. It can be used as token_origin, but not limited to it. It also can show where the response came from (in the record). =nat On Sat, Jun 5, 2010 at 1:58 AM, George Fletcher <gffletch@aol.com> wrote: > Could I conclude then that "we" are all in "agreement"? :) > > 1. OAuth 2.0 should not require a structured token (i.e. don't break > existing use cases) > 2. OAuth 2.0 should not prohibit resource owners supporting multiple > Authentication Servers > 3. OAuth 2.0 should allow for structured tokens via a separate spec > 4. OAuth 2.0 should consider specifying an additional, optional parameter > that is opaque to the client but identifies the "token format" > > Thanks, > George > > > On 6/4/10 12:45 PM, Luke Shepard wrote: > >> On Jun 4, 2010, at 8:41 AM, Dick Hardt wrote: >> >> >> >>> There is more to the web than the social web Luke, and supporting >>> multiple AS has been a design goal of WRAP and OAuth 2.0 and is being >>> implemented. >>> >>> >> Whoa, I didn't say there wasn't. I agree that supporting multiple >> authorization servers is a reasonable design goal and there are some people >> who are making that work. >> >> I was just pointing that that a common case, today, is to have a single >> authorization server for a given resource - I mentioned several examples of >> services that work this way now. OAuth 2.0 needs to support that use case in >> a clean way.= >> >> >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Nat Sakimura (=nat) http://www.sakimura.org/en/ http://twitter.com/_nat_en --001636c5a79c47aced04887e978f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div>+1=A0</div><div><br></div>FYI, OpenID Artifact Binding Draft (which is= OpenID on OAuth) defined a=A0<div>"server_id" variable to tell f= rom where it was issued. It can be used as token_origin,=A0</div><div>but n= ot limited to it. It also can show where the response came from (in the rec= ord).=A0</div> <div><br></div><div>=3Dnat<br><br><div class=3D"gmail_quote">On Sat, Jun 5,= 2010 at 1:58 AM, George Fletcher <span dir=3D"ltr"><<a href=3D"mailto:g= ffletch@aol.com">gffletch@aol.com</a>></span> wrote:<br><blockquote clas= s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad= ding-left:1ex;"> Could I conclude then that "we" are all in "agreement"?= :)<br> <br> 1. OAuth 2.0 should not require a structured token (i.e. don't break ex= isting use cases)<br> 2. OAuth 2.0 should not prohibit resource owners supporting multiple Authen= tication Servers<br> 3. OAuth 2.0 should allow for structured tokens via a separate spec<br> 4. OAuth 2.0 should consider specifying an additional, optional parameter t= hat is opaque to the client but identifies the "token format"<br> <br> Thanks,<br><font color=3D"#888888"> George</font><div><div></div><div class=3D"h5"><br> <br> On 6/4/10 12:45 PM, Luke Shepard wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> On Jun 4, 2010, at 8:41 AM, Dick Hardt wrote:<br> <br> =A0 <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> There is more to the web than the social web Luke, and supporting multiple = AS has been a design goal of WRAP and OAuth 2.0 and is being implemented.<b= r> =A0 =A0 <br> </blockquote> Whoa, I didn't say there wasn't. I agree that supporting multiple a= uthorization servers is a reasonable design goal and there are some people = who are making that work.<br> <br> I was just pointing that that a common case, today, is to have a single aut= horization server for a given resource - I mentioned several examples of se= rvices that work this way now. OAuth 2.0 needs to support that use case in = a clean way.=3D<br> <br> =A0 <br> </blockquote> _______________________________________________<br> OAuth mailing list<br> <a href=3D"mailto:OAuth@ietf.org" target=3D"_blank">OAuth@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_blank">h= ttps://www.ietf.org/mailman/listinfo/oauth</a><br> </div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Nat Sakimur= a (=3Dnat)<br><a href=3D"http://www.sakimura.org/en/">http://www.sakimura.o= rg/en/</a><br><a href=3D"http://twitter.com/_nat_en">http://twitter.com/_na= t_en</a><br> </div> --001636c5a79c47aced04887e978f-- From john@jkemp.net Tue Jun 8 03:45:23 2010 Return-Path: <john@jkemp.net> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C6E528C14B for <oauth@core3.amsl.com>; Tue, 8 Jun 2010 03:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.335 X-Spam-Level: X-Spam-Status: No, score=0.335 tagged_above=-999 required=5 tests=[BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OkvqS9mDW4Np for <oauth@core3.amsl.com>; Tue, 8 Jun 2010 03:45:22 -0700 (PDT) Received: from cpoproxy1-pub.bluehost.com (cpoproxy1-pub.bluehost.com [69.89.21.11]) by core3.amsl.com (Postfix) with SMTP id 4F15E28C10C for <oauth@ietf.org>; Tue, 8 Jun 2010 03:45:22 -0700 (PDT) Received: (qmail 12856 invoked by uid 0); 8 Jun 2010 10:45:23 -0000 Received: from unknown (HELO box320.bluehost.com) (69.89.31.120) by cpoproxy1.bluehost.com with SMTP; 8 Jun 2010 10:45:23 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=jkemp.net; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-Identified-User; b=WO+pZf1vAMBagWrJoEpdlalCm74ORa6f1Fa2tdifimN/zq8l9uHB7TQYupt4IEg3brZddE7stgvbMBGS2yNCIYBixa6xqvM6WrjRt12shV6oATKLWjhF2p6ty3rQ04UY; Received: from cpe-69-205-56-47.nycap.res.rr.com ([69.205.56.47] helo=[192.168.1.103]) by box320.bluehost.com with esmtpa (Exim 4.69) (envelope-from <john@jkemp.net>) id 1OLwJ8-0008Ph-WF; Tue, 08 Jun 2010 04:45:23 -0600 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: John Kemp <john@jkemp.net> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11263EBF638@WSMSG3153V.srv.dir.telstra.com> Date: Tue, 8 Jun 2010 06:45:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <50227268-61DB-401E-A2AA-F8A984C1B6B3@jkemp.net> References: <AANLkTinQTV9JJPiftquRbvdqAOHxUXk7QQKCMrmQ4LLK@mail.gmail.com> <B549E6C4-A24D-4032-8A26-89ED58EBAA34@facebook.com> <4C090B6C.9030707@aol.com> <B6D1E6FF-D65F-4FD6-B148-C17550421FC9@facebook.com> <AANLkTilj0xG6SjHrzkd9Ca-N67J7IlsTNAOkyFdjQ62I@mail.gmail.com> <ED86A2AA-56D5-4DC6-B896-48A850EED3B2@facebook.com> <4C0930B2.80802@aol.com> <AANLkTimupEDpBUjg4iwwhPQ41ZKcryMcpVjJumXNIjP0@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E11263E5DA7C@WSMSG3153V.srv.dir.telstra.com> <383A9188-1AA6-49FE-95FC-5D6316BD18CD@jkemp.net> <255B9BB34FB7D647A506DC292726F6E11263EBF638@WSMSG3153V.srv.dir.telstra.com> To: "Manger, James H" <James.H.Manger@team.telstra.com> X-Mailer: Apple Mail (2.1078) X-Identified-User: {1122:box320.bluehost.com:jkempnet:jkemp.net} {sentby:smtp auth 69.205.56.47 authed with john+jkemp.net} Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Partially standardized format for access tokens? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 08 Jun 2010 10:45:23 -0000 On Jun 7, 2010, at 8:25 PM, Manger, James H wrote: > John, >=20 >>> access_token=3Dsaml.fhHFhgf6575fhgFGrytr >=20 >> What is the advantage of doing it this way over having a separate = field? >=20 > Client simplicity (code and mental model). I think the difference in simplicity between one parameter and two is = not such that it requires munging the two together. The token_string and the token_format are two different parts of the = token. - johnk >=20 >> What if the format is a URI? >=20 > That is a choice between the AS and PR that is irrelevant to the = client app -- so why should the client app have to worry about it (and = any extra escaping it entails). >=20 >=20 >>> There can be an IANA registry for prefixes if that is helpful. >=20 >> Personally, I'd like to see this solution be a bit more distributed, = and a registry isn't. >=20 > I hope there aren't so many common, shared formats that a distributed = solution is necessary. But you can make the prefix a domain name, or a = base64url-encoded URI, or a hash of a URI etc if you really want it = distributed. >=20 >=20 > Andrew Arnott said: >> But token_format is not the idea I think. It's more like = token_origin. >=20 > I hope we don't need a 3rd "opaque string" for the client app to = transfer from the AS to PR. >=20 > -- > James Manger >=20 From lshepard@facebook.com Tue Jun 8 06:59:18 2010 Return-Path: <lshepard@facebook.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66AB528C1D0 for <oauth@core3.amsl.com>; Tue, 8 Jun 2010 06:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.128 X-Spam-Level: X-Spam-Status: No, score=-1.128 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_40=-0.185, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w491gM2jIk+H for <oauth@core3.amsl.com>; Tue, 8 Jun 2010 06:59:17 -0700 (PDT) Received: from mailout-snc1.facebook.com (mailout-snc1.facebook.com [69.63.179.25]) by core3.amsl.com (Postfix) with ESMTP id 66A8F28C1AB for <oauth@ietf.org>; Tue, 8 Jun 2010 06:59:17 -0700 (PDT) Received: from mail.thefacebook.com ([192.168.18.212]) by pp01.snc1.tfbnw.net (8.14.3/8.14.3) with ESMTP id o58DwjLm019047 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 8 Jun 2010 06:58:49 -0700 Received: from sc-hub05.TheFacebook.com (192.168.18.82) by sc-hub04.TheFacebook.com (192.168.18.212) with Microsoft SMTP Server (TLS) id 14.0.694.1; Tue, 8 Jun 2010 06:58:25 -0700 Received: from SC-MBXC1.TheFacebook.com ([192.168.18.102]) by sc-hub05.TheFacebook.com ([192.168.18.82]) with mapi; Tue, 8 Jun 2010 06:58:09 -0700 From: Luke Shepard <lshepard@facebook.com> To: John Kemp <john@jkemp.net> Date: Tue, 8 Jun 2010 06:58:07 -0700 Thread-Topic: [OAUTH-WG] Partially standardized format for access tokens? Thread-Index: AcsHEqAoUJ4Q5/txRsClQjeZil3+sA== Message-ID: <6E69B6CE-FACA-4428-B6BA-48CF5B1E15C9@facebook.com> References: <AANLkTinQTV9JJPiftquRbvdqAOHxUXk7QQKCMrmQ4LLK@mail.gmail.com> <B549E6C4-A24D-4032-8A26-89ED58EBAA34@facebook.com> <4C090B6C.9030707@aol.com> <B6D1E6FF-D65F-4FD6-B148-C17550421FC9@facebook.com> <AANLkTilj0xG6SjHrzkd9Ca-N67J7IlsTNAOkyFdjQ62I@mail.gmail.com> <ED86A2AA-56D5-4DC6-B896-48A850EED3B2@facebook.com> <4C0930B2.80802@aol.com> <AANLkTimupEDpBUjg4iwwhPQ41ZKcryMcpVjJumXNIjP0@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E11263E5DA7C@WSMSG3153V.srv.dir.telstra.com> <383A9188-1AA6-49FE-95FC-5D6316BD18CD@jkemp.net> <255B9BB34FB7D647A506DC292726F6E11263EBF638@WSMSG3153V.srv.dir.telstra.com> <50227268-61DB-401E-A2AA-F8A984C1B6B3@jkemp.net> In-Reply-To: <50227268-61DB-401E-A2AA-F8A984C1B6B3@jkemp.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-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-06-08_05:2010-02-06, 2010-06-08, 2010-06-08 signatures=0 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Partially standardized format for access tokens? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 08 Jun 2010 13:59:18 -0000 >> Client simplicity (code and mental model). >=20 > I think the difference in simplicity between one parameter and two is not= such that it requires munging the two together. >=20 > The token_string and the token_format are two different parts of the toke= n. If you look through my emails, I provided code samples to illustrate that t= wo parameters is in fact more complex than one. Much of the simplicity of O= Auth 2.0 is achieved by unifying myriad parameters into a single access tok= en. Much of that is lost by splitting it apart again. We can't even agree what we want or how to split it - some want origin, som= e want format, still others probably want something else. No, the whole poi= nt is it's up to the provider and the resource to unify them and it's opaqu= e to the client. Again: can you provide a specific, real-world example where this is necessa= ry? I'd rather not deal in hypotheticals. I've already answered the case of= a hypothetical endpoint that accepts both SAML and JSON-encoded tokens. From gffletch@aol.com Tue Jun 8 07:17:56 2010 Return-Path: <gffletch@aol.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D70528C1F0 for <oauth@core3.amsl.com>; Tue, 8 Jun 2010 07:17:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7DjyECe-jIL for <oauth@core3.amsl.com>; Tue, 8 Jun 2010 07:17:55 -0700 (PDT) Received: from imr-db03.mx.aol.com (imr-db03.mx.aol.com [205.188.91.97]) by core3.amsl.com (Postfix) with ESMTP id EC4EF28C1D1 for <oauth@ietf.org>; Tue, 8 Jun 2010 07:17:43 -0700 (PDT) Received: from mtaout-ma03.r1000.mx.aol.com (mtaout-ma03.r1000.mx.aol.com [172.29.41.3]) by imr-db03.mx.aol.com (8.14.1/8.14.1) with ESMTP id o58EHGNP016601; Tue, 8 Jun 2010 10:17:16 -0400 Received: from palantir.local (unknown [10.181.183.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-ma03.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 8E7ECE000083; Tue, 8 Jun 2010 10:17:11 -0400 (EDT) Message-ID: <4C0E50E7.5040909@aol.com> Date: Tue, 08 Jun 2010 10:17:11 -0400 From: George Fletcher <gffletch@aol.com> Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Luke Shepard <lshepard@facebook.com> References: <AANLkTinQTV9JJPiftquRbvdqAOHxUXk7QQKCMrmQ4LLK@mail.gmail.com> <B549E6C4-A24D-4032-8A26-89ED58EBAA34@facebook.com> <4C090B6C.9030707@aol.com> <B6D1E6FF-D65F-4FD6-B148-C17550421FC9@facebook.com> <AANLkTilj0xG6SjHrzkd9Ca-N67J7IlsTNAOkyFdjQ62I@mail.gmail.com> <ED86A2AA-56D5-4DC6-B896-48A850EED3B2@facebook.com> <4C0930B2.80802@aol.com> <AANLkTimupEDpBUjg4iwwhPQ41ZKcryMcpVjJumXNIjP0@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E11263E5DA7C@WSMSG3153V.srv.dir.telstra.com> <383A9188-1AA6-49FE-95FC-5D6316BD18CD@jkemp.net> <255B9BB34FB7D647A506DC292726F6E11263EBF638@WSMSG3153V.srv.dir.telstra.com> <50227268-61DB-401E-A2AA-F8A984C1B6B3@jkemp.net> <6E69B6CE-FACA-4428-B6BA-48CF5B1E15C9@facebook.com> In-Reply-To: <6E69B6CE-FACA-4428-B6BA-48CF5B1E15C9@facebook.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit x-aol-global-disposition: G X-AOL-SCOLL-SCORE: 0:2:313055360:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d29034c0e50e7062c X-AOL-IP: 10.181.183.108 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Partially standardized format for access tokens? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 08 Jun 2010 14:17:56 -0000 On 6/8/10 9:58 AM, Luke Shepard wrote: > Again: can you provide a specific, real-world example where this is > necessary? I'd rather not deal in hypotheticals. I've already answered > the case of a hypothetical endpoint that accepts both SAML and > JSON-encoded tokens. I believe one such case is person-to-person sharing where person A is NOT part of the same network as person B. If I have a protected resource at photos.example.com and I want to share with someone who is NOT a member of photos.example.com there are only a couple of options... 1. Today's method: security by obscurity with "non-guessable" URLs emailed to person B 2. Use OpenID and force Person B to "sign in" to photos.example.com (effectively establishing a relationship with photos.example.com that they might not want) 3. Have photos.example.com be able to accept a token from person B's authorization service saying this is person B when accessing the protected resource. Option 3 is a much better experience for the user and simpler to implement for any client that person B is using. However, this requires that photos.example.com be able to read and understand the token from person B's authorization server (AS). Hence we need some way to associate origin and format with the token. Personally, I think that using XRD the origin server could expose a "dumb mode" token validator such that resource owners that don't now how to process the token natively could still validate the token and get some minimal information. Thanks, George Some additional thoughts and links: http://practicalid.blogspot.com/2010/05/identity-as-attribute.html From beaton@google.com Tue Jun 8 08:32:09 2010 Return-Path: <beaton@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11DDE3A6805 for <oauth@core3.amsl.com>; Tue, 8 Jun 2010 08:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0O9XW7fDXVdQ for <oauth@core3.amsl.com>; Tue, 8 Jun 2010 08:32:08 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 402453A697D for <oauth@ietf.org>; Tue, 8 Jun 2010 08:32:07 -0700 (PDT) Received: from hpaq7.eem.corp.google.com (hpaq7.eem.corp.google.com [172.25.149.7]) by smtp-out.google.com with ESMTP id o58FW7Q3012059 for <oauth@ietf.org>; Tue, 8 Jun 2010 08:32:07 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1276011127; bh=dnmfiWtqQMdtQDM8Mg6y4uB8ZQQ=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=bhOZsVWaAj7k1bAEkkLu6D7uXsjvuNGB+xqfuNmgN2eMCLPKAckktZ/6ThVeoF7wI wQTpwN0SiAzZ81cJ7hqMw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type; b=hX4oQ2k0L0wra/gC5S7MIMwGb3rc8A2CJ6xsZzB/IwB09uCgWyIV/KFB2Ef6rjbYV jnpeP2auXMwBN9fUs8isw== Received: from pwj4 (pwj4.prod.google.com [10.241.219.68]) by hpaq7.eem.corp.google.com with ESMTP id o58FW5tg013311 for <oauth@ietf.org>; Tue, 8 Jun 2010 08:32:06 -0700 Received: by pwj4 with SMTP id 4so2034146pwj.34 for <oauth@ietf.org>; Tue, 08 Jun 2010 08:32:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.87.2 with SMTP id p2mr12127682wfl.323.1276011125075; Tue, 08 Jun 2010 08:32:05 -0700 (PDT) Received: by 10.142.207.21 with HTTP; Tue, 8 Jun 2010 08:32:04 -0700 (PDT) In-Reply-To: <4C0E50E7.5040909@aol.com> References: <AANLkTinQTV9JJPiftquRbvdqAOHxUXk7QQKCMrmQ4LLK@mail.gmail.com> <B549E6C4-A24D-4032-8A26-89ED58EBAA34@facebook.com> <4C090B6C.9030707@aol.com> <B6D1E6FF-D65F-4FD6-B148-C17550421FC9@facebook.com> <AANLkTilj0xG6SjHrzkd9Ca-N67J7IlsTNAOkyFdjQ62I@mail.gmail.com> <ED86A2AA-56D5-4DC6-B896-48A850EED3B2@facebook.com> <4C0930B2.80802@aol.com> <AANLkTimupEDpBUjg4iwwhPQ41ZKcryMcpVjJumXNIjP0@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E11263E5DA7C@WSMSG3153V.srv.dir.telstra.com> <383A9188-1AA6-49FE-95FC-5D6316BD18CD@jkemp.net> <255B9BB34FB7D647A506DC292726F6E11263EBF638@WSMSG3153V.srv.dir.telstra.com> <50227268-61DB-401E-A2AA-F8A984C1B6B3@jkemp.net> <6E69B6CE-FACA-4428-B6BA-48CF5B1E15C9@facebook.com> <4C0E50E7.5040909@aol.com> Date: Tue, 8 Jun 2010 08:32:04 -0700 Message-ID: <AANLkTinnHC3qAl6DEs2Myk-Kp9823T0HsS97n4FLCohr@mail.gmail.com> From: Brian Eaton <beaton@google.com> To: George Fletcher <gffletch@aol.com> Content-Type: text/plain; charset=ISO-8859-1 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Partially standardized format for access tokens? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 08 Jun 2010 15:32:09 -0000 On Tue, Jun 8, 2010 at 7:17 AM, George Fletcher <gffletch@aol.com> > 2. Use OpenID and force Person B to "sign in" to photos.example.com > (effectively establishing a relationship with photos.example.com that they > might not want) > > 3. Have photos.example.com be able to accept a token from person B's > authorization service saying this is person B when accessing the protected > resource. These two options seem equivalent to me. They certainly bring up the same user experience challenges. From beaton@google.com Tue Jun 8 08:35:51 2010 Return-Path: <beaton@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25D183A69C3 for <oauth@core3.amsl.com>; Tue, 8 Jun 2010 08:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.677 X-Spam-Level: X-Spam-Status: No, score=-100.677 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cG43ncF-S-NF for <oauth@core3.amsl.com>; Tue, 8 Jun 2010 08:35:50 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id BF9363A697D for <oauth@ietf.org>; Tue, 8 Jun 2010 08:35:49 -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 o58FZl0M016888 for <oauth@ietf.org>; Tue, 8 Jun 2010 08:35:47 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1276011348; bh=RlG7e3uPEDIqvQy8x4cg9atsEOY=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=B449DlC40HKnwrP2+XMCbO3EJiWEWmQHstV/q2i9o5pifufLpdRfUkRgyYIdnqN4a tb1pPGSMipxW+0vsmx43Q== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding; b=slI/pLv8oOm8K5nzYdJlS5xvH1I0tg5RYAjcqwFnNM1T9k7vSUe6nW9VBSkScRrcV ZlNcISdGRZGPckfU/b/5g== Received: from pwj10 (pwj10.prod.google.com [10.241.219.74]) by hpaq11.eem.corp.google.com with ESMTP id o58FZkH1015004 for <oauth@ietf.org>; Tue, 8 Jun 2010 08:35:46 -0700 Received: by pwj10 with SMTP id 10so310123pwj.24 for <oauth@ietf.org>; Tue, 08 Jun 2010 08:35:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.5.29 with SMTP id 29mr877205wfe.102.1276011345598; Tue, 08 Jun 2010 08:35:45 -0700 (PDT) Received: by 10.142.207.21 with HTTP; Tue, 8 Jun 2010 08:35:45 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11263E5DA7C@WSMSG3153V.srv.dir.telstra.com> References: <AANLkTinQTV9JJPiftquRbvdqAOHxUXk7QQKCMrmQ4LLK@mail.gmail.com> <B549E6C4-A24D-4032-8A26-89ED58EBAA34@facebook.com> <4C090B6C.9030707@aol.com> <B6D1E6FF-D65F-4FD6-B148-C17550421FC9@facebook.com> <AANLkTilj0xG6SjHrzkd9Ca-N67J7IlsTNAOkyFdjQ62I@mail.gmail.com> <ED86A2AA-56D5-4DC6-B896-48A850EED3B2@facebook.com> <4C0930B2.80802@aol.com> <AANLkTimupEDpBUjg4iwwhPQ41ZKcryMcpVjJumXNIjP0@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E11263E5DA7C@WSMSG3153V.srv.dir.telstra.com> Date: Tue, 8 Jun 2010 08:35:45 -0700 Message-ID: <AANLkTinXiBNBkiPbhELtoIUSGF08S9t3WSDH4OQfP8EW@mail.gmail.com> From: Brian Eaton <beaton@google.com> To: "Manger, James H" <James.H.Manger@team.telstra.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Partially standardized format for access tokens? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 08 Jun 2010 15:35:51 -0000 On Sun, Jun 6, 2010 at 8:14 PM, Manger, James H > Defining an optional prefix for access_token values to indicate the format would work well. > I suggest a plain text label separated by, say, a "." from the rest of th= e value. For example: > =A0access_token=3Dsaml.fhHFhgf6575fhgFGrytr > There can be an IANA registry for prefixes if that is helpful. > A service currently supporting a single token format can start its access= _token values with "." so at least they will not accidentally clash with an= y future values that do specify a format. > =A0access_token=3D.6786345_JGJSgfjhsgfhj-ss_s > A service that will never need token format interop doesn't need to using= any prefix (empty or otherwise), and can use dots however it wants. Slick! Andrew brought up a good point about interop between multiple token issuers. But that can be solved by data *inside* the access token. If a server really needs to crack open tokens from multiple issuers, it would work like this: parse the format off the front decode the rest of the token according to the format crack open the token to find a pointer to the issuer use that information to verify the token I don't think the prefix needs any kind of URI or namespacing. New token formats should be extremely rare. Cheers, Brian From gffletch@aol.com Tue Jun 8 08:41:57 2010 Return-Path: <gffletch@aol.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 693BE3A697D for <oauth@core3.amsl.com>; Tue, 8 Jun 2010 08:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.369 X-Spam-Level: X-Spam-Status: No, score=-0.369 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wVUAfLsvm5Pf for <oauth@core3.amsl.com>; Tue, 8 Jun 2010 08:41:56 -0700 (PDT) Received: from imr-da03.mx.aol.com (imr-da03.mx.aol.com [205.188.105.145]) by core3.amsl.com (Postfix) with ESMTP id 648EF3A6917 for <oauth@ietf.org>; Tue, 8 Jun 2010 08:41:56 -0700 (PDT) Received: from mtaout-mb01.r1000.mx.aol.com (mtaout-mb01.r1000.mx.aol.com [172.29.41.65]) by imr-da03.mx.aol.com (8.14.1/8.14.1) with ESMTP id o58FelrT001707; Tue, 8 Jun 2010 11:41:07 -0400 Received: from palantir.local (unknown [10.181.183.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-mb01.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id AC709E0000BF; Tue, 8 Jun 2010 11:41:06 -0400 (EDT) Message-ID: <4C0E6482.2080109@aol.com> Date: Tue, 08 Jun 2010 11:40:50 -0400 From: George Fletcher <gffletch@aol.com> Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Brian Eaton <beaton@google.com> References: <AANLkTinQTV9JJPiftquRbvdqAOHxUXk7QQKCMrmQ4LLK@mail.gmail.com> <B549E6C4-A24D-4032-8A26-89ED58EBAA34@facebook.com> <4C090B6C.9030707@aol.com> <B6D1E6FF-D65F-4FD6-B148-C17550421FC9@facebook.com> <AANLkTilj0xG6SjHrzkd9Ca-N67J7IlsTNAOkyFdjQ62I@mail.gmail.com> <ED86A2AA-56D5-4DC6-B896-48A850EED3B2@facebook.com> <4C0930B2.80802@aol.com> <AANLkTimupEDpBUjg4iwwhPQ41ZKcryMcpVjJumXNIjP0@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E11263E5DA7C@WSMSG3153V.srv.dir.telstra.com> <383A9188-1AA6-49FE-95FC-5D6316BD18CD@jkemp.net> <255B9BB34FB7D647A506DC292726F6E11263EBF638@WSMSG3153V.srv.dir.telstra.com> <50227268-61DB-401E-A2AA-F8A984C1B6B3@jkemp.net> <6E69B6CE-FACA-4428-B6BA-48CF5B1E15C9@facebook.com> <4C0E50E7.5040909@aol.com> <AANLkTinnHC3qAl6DEs2Myk-Kp9823T0HsS97n4FLCohr@mail.gmail.com> In-Reply-To: <AANLkTinnHC3qAl6DEs2Myk-Kp9823T0HsS97n4FLCohr@mail.gmail.com> Content-Type: multipart/alternative; boundary="------------020500090804040200000900" x-aol-global-disposition: G X-AOL-SCOLL-SCORE: 0:2:443297376:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d29414c0e6492666e X-AOL-IP: 10.181.183.108 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Partially standardized format for access tokens? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 08 Jun 2010 15:41:57 -0000 This is a multi-part message in MIME format. --------------020500090804040200000900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Here is where I see the differences... #2 forces "person B" to go through an authentication event at photos.example.com while #3 allows the client "person B" is using to get the access token at time of authentication to the client. So, for #2 "person B" will likely have to do 2 authentication events (1 to the client and 1 to photos.example.com). While with #3, "person B" only has to do 1 authentication event (to the client). Thanks, George On 6/8/10 11:32 AM, Brian Eaton wrote: > On Tue, Jun 8, 2010 at 7:17 AM, George Fletcher<gffletch@aol.com> > > 2. Use OpenID and force Person B to "sign in" to photos.example.com > >> (effectively establishing a relationship with photos.example.com that they >> might not want) >> >> 3. Have photos.example.com be able to accept a token from person B's >> authorization service saying this is person B when accessing the protected >> resource. >> > These two options seem equivalent to me. > > They certainly bring up the same user experience challenges. > > --------------020500090804040200000900 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> <font face="Helvetica, Arial, sans-serif">Here is where I see the differences...<br> <br> #2 forces "person B" to go through an authentication event at photos.example.com<br> <br> while #3 allows the client "person B" is using to get the access token at time of authentication to the client.</font><br> <br> So, for #2 "person B" will likely have to do 2 authentication events (1 to the client and 1 to photos.example.com). While with #3, "person B" only has to do 1 authentication event (to the client).<br> <br> Thanks,<br> George<br> <br> On 6/8/10 11:32 AM, Brian Eaton wrote: <blockquote cite="mid:AANLkTinnHC3qAl6DEs2Myk-Kp9823T0HsS97n4FLCohr@mail.gmail.com" type="cite"> <pre wrap="">On Tue, Jun 8, 2010 at 7:17 AM, George Fletcher <a class="moz-txt-link-rfc2396E" href="mailto:gffletch@aol.com"><gffletch@aol.com></a> > 2. Use OpenID and force Person B to "sign in" to photos.example.com </pre> <blockquote type="cite"> <pre wrap="">(effectively establishing a relationship with photos.example.com that they might not want) 3. Have photos.example.com be able to accept a token from person B's authorization service saying this is person B when accessing the protected resource. </pre> </blockquote> <pre wrap=""> These two options seem equivalent to me. They certainly bring up the same user experience challenges. </pre> </blockquote> </body> </html> --------------020500090804040200000900-- From cmortimore@salesforce.com Tue Jun 8 10:40:59 2010 Return-Path: <cmortimore@salesforce.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A33013A680D for <oauth@core3.amsl.com>; Tue, 8 Jun 2010 10:40:59 -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=-2.555, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KPRUM1cnUuPS for <oauth@core3.amsl.com>; Tue, 8 Jun 2010 10:40:54 -0700 (PDT) Received: from exprod8og103.obsmtp.com (exprod8og103.obsmtp.com [64.18.3.86]) by core3.amsl.com (Postfix) with SMTP id D5F083A6938 for <oauth@ietf.org>; Tue, 8 Jun 2010 10:40:53 -0700 (PDT) Received: from source ([204.14.239.238]) by exprod8ob103.postini.com ([64.18.7.12]) with SMTP ID DSNKTA6ApvxUX09s7WBOGoNqTDRikcIEZ333@postini.com; Tue, 08 Jun 2010 10:40:55 PDT Received: from EXSFM-MB01.internal.salesforce.com ([10.1.127.45]) by exsfm-hub3.internal.salesforce.com ([10.1.127.7]) with mapi; Tue, 8 Jun 2010 10:40:54 -0700 From: Chuck Mortimore <cmortimore@salesforce.com> To: Marius Scurtescu <mscurtescu@google.com> Date: Tue, 8 Jun 2010 10:40:52 -0700 Thread-Topic: [OAUTH-WG] User-agent flow and pre-registered redirect_uri Thread-Index: AcsGqn4uUV085I26R1WFBouFIpjaggAhz8RH Message-ID: <C833CEB4.6B81%cmortimore@salesforce.com> In-Reply-To: <AANLkTingSGlJNZ5e_stPd1qU5I4gfbh3rQhqYUmqXvdB@mail.gmail.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C833CEB46B81cmortimoresalesforcecom_" MIME-Version: 1.0 Cc: "oauth@ietf.org" <oauth@ietf.org> Subject: Re: [OAUTH-WG] User-agent flow and pre-registered redirect_uri X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 08 Jun 2010 17:40:59 -0000 --_000_C833CEB46B81cmortimoresalesforcecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks - I get your line of reasoning now. I believe it would still help = in preventing certain types of attack. These are especially apparent arou= nd immediate. 1) User initially grants access to example.com 2) User goes to an evil site 3) Without the user's knowledge, the malicious site issues an immediate use= r_agent flow https://authzserver.com/authorize?type=3Duser_agent&immediate=3Dtrue&client= _id=3D<Example.com's Client ID>&redirect_uri=3D<Evil URL> 4) Evil site is handed an access token based upon the previous grant to exa= mple.com This would be prevented with a redirect_url whitelist. -cmort On 6/7/10 6:23 PM, "Marius Scurtescu" <mscurtescu@google.com> wrote: On Mon, Jun 7, 2010 at 5:31 PM, Chuck Mortimore <cmortimore@salesforce.com> wrote: > Note sure I follow this Marius: > > "What can happen is that exmple.com/back can pretend to be > example.com/back, but registration does not help in this case." > > I believe it does help in this case, as the Authorization server can > validate the registered redirect_uri vs. the requested redirect_uri. He= nce > the server would not issue a token to exmple.com in this case. Am I > missing something? What stops exmple.com from registering? Unless the authz wants to operate only with a short list of human verified clients. The current spec allows that. But if registration cannot be controlled like that, and all it does it proves that the client owns a domain, then it does not help. I don't think registration should/can be enforced. Marius --_000_C833CEB46B81cmortimoresalesforcecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <HTML> <HEAD> <TITLE>Re: [OAUTH-WG] User-agent flow and pre-registered redirect_uri</TITL= E> </HEAD> <BODY> <FONT FACE=3D"Lucida Grande"><SPAN STYLE=3D'font-size:11pt'>Thanks – = I get your line of reasoning now.   I believe it would still help= in preventing certain types of attack.   These are especially ap= parent around immediate. <BR> <BR> 1) User initially grants access to example.com<BR> 2) User goes to an evil site<BR> 3) Without the user’s knowledge, the malicious site issues an immedia= te user_agent flow<BR> <BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Times, Times New Roman"><SPAN STYLE= =3D'font-size:12pt'><a href=3D"https://authzserver.com/authorize?type=3Duse= r_agent&immediate=3Dtrue&client_id=3D<Example.com’s">https= ://authzserver.com/authorize?type=3Duser_agent&immediate=3Dtrue&cli= ent_id=3D<Example.com’s</a> Client ID>&redirect_uri=3D<E= vil URL> <BR> </SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Times, Times New Roman"><SPAN STYL= E=3D'font-size:12pt'><BR> 4) Evil site is handed an access token based upon the previous grant to exa= mple.com<BR> <BR> This would be prevented with a redirect_url whitelist.<BR> <BR> <BR> <BR> -cmort<BR> <BR> </SPAN></FONT><FONT FACE=3D"Lucida Grande"><SPAN STYLE=3D'font-size:11pt'><= BR> <BR> <BR> On 6/7/10 6:23 PM, "Marius Scurtescu" <<a href=3D"mscurtescu@g= oogle.com">mscurtescu@google.com</a>> wrote:<BR> <BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Lucida Grande"><SPAN STYLE=3D'font-= size:11pt'>On Mon, Jun 7, 2010 at 5:31 PM, Chuck Mortimore<BR> <<a href=3D"cmortimore@salesforce.com">cmortimore@salesforce.com</a>>= wrote:<BR> > Note sure I follow this Marius:<BR> ><BR> > “What can happen is that exmple.com/back can pretend to be<BR> > example.com/back, but registration does not help in this case.”<= BR> ><BR> > I believe it does help in this case, as the Authorization server can<B= R> > validate the registered redirect_uri vs. the requested redirect_uri. = =A0=A0Hence<BR> > the server would not issue a token to exmple.com in this case. =A0=A0A= m I<BR> > missing something?<BR> <BR> What stops exmple.com from registering? Unless the authz wants to<BR> operate only with a short list of human verified clients. The current<BR> spec allows that. But if registration cannot be controlled like that,<BR> and all it does it proves that the client owns a domain, then it does<BR> not help.<BR> <BR> I don't think registration should/can be enforced.<BR> <BR> Marius<BR> <BR> </SPAN></FONT></BLOCKQUOTE> </BODY> </HTML> --_000_C833CEB46B81cmortimoresalesforcecom_-- From mscurtescu@google.com Tue Jun 8 10:46:44 2010 Return-Path: <mscurtescu@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AB323A69EF for <oauth@core3.amsl.com>; Tue, 8 Jun 2010 10:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.562 X-Spam-Level: X-Spam-Status: No, score=-99.562 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5HwxsyDeCZL for <oauth@core3.amsl.com>; Tue, 8 Jun 2010 10:46:43 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id C497C3A69CD for <oauth@ietf.org>; Tue, 8 Jun 2010 10:46:42 -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 o58HkeXA001159 for <oauth@ietf.org>; Tue, 8 Jun 2010 10:46:41 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1276019201; bh=6mO8gBMg58yZZdiMYUAG+apeOm0=; h=MIME-Version:From:Date:Message-ID:Subject:To:Cc:Content-Type: Content-Transfer-Encoding; b=swkz9/tT0RflN7zjLREr28DRdqp+FH2Pz4uu0/Z8QZolT+TXm4O2duukErukTlzYS a9IfGOK/lHTrf1DDsgGHA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:from:date:message-id:subject:to:cc: content-type:content-transfer-encoding; b=uzcNDD4IfdO/bItHIRWhV5Pd4Cz/h+DnMdoIzoWOegJeo6Z/2QA2SAxpbGpenGcGD xv7+E6P3oGEpCcP2EX50A== Received: from pxi15 (pxi15.prod.google.com [10.243.27.15]) by kpbe20.cbf.corp.google.com with ESMTP id o58HkMTt017002 for <oauth@ietf.org>; Tue, 8 Jun 2010 10:46:40 -0700 Received: by pxi15 with SMTP id 15so1872214pxi.16 for <oauth@ietf.org>; Tue, 08 Jun 2010 10:46:39 -0700 (PDT) Received: by 10.141.22.19 with SMTP id z19mr13476008rvi.250.1276019199642; Tue, 08 Jun 2010 10:46:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.124.13 with HTTP; Tue, 8 Jun 2010 10:46:19 -0700 (PDT) From: Marius Scurtescu <mscurtescu@google.com> Date: Tue, 8 Jun 2010 10:46:19 -0700 Message-ID: <AANLkTikkG3T_DYKhjMbyYayi7SzZel3RJXFSguxq7SSZ@mail.gmail.com> To: Eran Hammer-Lahav <eran@hueniverse.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: [OAUTH-WG] native app support (was: Next draft) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 08 Jun 2010 17:46:44 -0000 In order to properly support native applications I suggest the following changes: 1. client_name In all flows when client_id is sent also allow for an optional client_name. This optional parameter is meant as a display name for the client, and it is useful in all unregistered cases, not only for native apps. If the client is unregistered then most likely the authz server will require that client_id be set to a predefined value like "anonymous". The approval page does need a client name so it can tell the user who it is granting access for. 2. optional redirect_uri (default result page) Some native apps do not have a redirect_uri, as a result two things are nee= ded: 2.1 Either make redirect_uri optional or define a standard value that signals that the client does not have such a page. 2.2 The authz server must supply a default result page, if there is no redirect_uri. Also, this page should put the verification code and the client state (code and state) in the page title in a standard way such that the native app can extract them from the window title. WRAP defined how the title should be formed. 3. device flow should be able to start user-agent The device flow can be used by native apps in which case there is a browser on the device. This flow should be able to start a browser and directly take the user to the end-user verification URI with the user code added as a query parameter (so the user is not required to do any manual entry). This is sort of possible right now, but the handler behind verification_uri must expect an optional user_code (in which case it should not prompt the user). 4. section with guidance for native apps I think the spec needs a section that explains how native apps can be used with OAuth 2. Not sure if it is worth getting into pros and cons for each flow, but all flows can be used. Marius On Mon, Jun 7, 2010 at 8:44 AM, Eran Hammer-Lahav <eran@hueniverse.com> wro= te: > I still need to catch up on the list (I took a little break). I plan to p= ost a new draft this week incorporating many editorial changes discussed at= the interim meeting. I am also planning of removing some non-stable featur= es (such as discovery and signatures) from the draft and moving them to new= drafts. As soon as -06 is published, I plan to issue informal last-calls f= or each section so that we can lock down the normative portions of the draf= t. > > If you have any must-happen changes for -05 that were not already posted = to the list, please let me know. > > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From mscurtescu@google.com Tue Jun 8 11:04:41 2010 Return-Path: <mscurtescu@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 294AF3A6827 for <oauth@core3.amsl.com>; Tue, 8 Jun 2010 11:04:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.871 X-Spam-Level: X-Spam-Status: No, score=-99.871 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GMMKqN4E3QZA for <oauth@core3.amsl.com>; Tue, 8 Jun 2010 11:04:40 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id D77C03A6893 for <oauth@ietf.org>; Tue, 8 Jun 2010 11:04:39 -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 o58I4clK025914 for <oauth@ietf.org>; Tue, 8 Jun 2010 11:04:39 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1276020279; bh=vTLUIIdWPaU1Ib8gv5nh9TilFQA=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=K2AWyp1CGvS3slFh/XfBhGzxtmHYOxm0VSFHgLIc9aVr4pdyhVowMSRNkewdEOUgk Oe8lYPI6zmNdzRi55mEIA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding; b=noRCoA/Kwgrmy7v11NIrRLEFuZNbTozQxf9NTqoCfgidQhJNMQ7xfhwTt01St0Y+a xOgfq41mPapzXO/9viwuw== Received: from pvg12 (pvg12.prod.google.com [10.241.210.140]) by hpaq14.eem.corp.google.com with ESMTP id o58I4IUx022238 for <oauth@ietf.org>; Tue, 8 Jun 2010 11:04:37 -0700 Received: by pvg12 with SMTP id 12so198970pvg.37 for <oauth@ietf.org>; Tue, 08 Jun 2010 11:04:36 -0700 (PDT) Received: by 10.141.188.22 with SMTP id q22mr11626431rvp.238.1276020275612; Tue, 08 Jun 2010 11:04:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.124.13 with HTTP; Tue, 8 Jun 2010 11:04:15 -0700 (PDT) In-Reply-To: <C833CEB4.6B81%cmortimore@salesforce.com> References: <AANLkTingSGlJNZ5e_stPd1qU5I4gfbh3rQhqYUmqXvdB@mail.gmail.com> <C833CEB4.6B81%cmortimore@salesforce.com> From: Marius Scurtescu <mscurtescu@google.com> Date: Tue, 8 Jun 2010 11:04:15 -0700 Message-ID: <AANLkTinVQEPBVzmiHEGgHhzaILL0nRSvZpjIlrVEJwTw@mail.gmail.com> To: Chuck Mortimore <cmortimore@salesforce.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "oauth@ietf.org" <oauth@ietf.org> Subject: Re: [OAUTH-WG] User-agent flow and pre-registered redirect_uri X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 08 Jun 2010 18:04:41 -0000 On Tue, Jun 8, 2010 at 10:40 AM, Chuck Mortimore <cmortimore@salesforce.com> wrote: > Thanks =96 I get your line of reasoning now. =A0=A0I believe it would sti= ll help > in preventing certain types of attack. =A0=A0These are especially apparen= t > around immediate. I do agree that requiring registration may be a good idea in many cases, all I am saying is that this should not be enforced. Some authz servers may want to allow unregistered clients, and that's fine. I think the current SHOULD is good enough and changing it to MUST would be going too far. > 1) User initially grants access to example.com > 2) User goes to an evil site > 3) Without the user=92s knowledge, the malicious site issues an immediate > user_agent flow > > https://authzserver.com/authorize?type=3Duser_agent&immediate=3Dtrue&clie= nt_id=3D<Example.com=92s > Client ID>&redirect_uri=3D<Evil URL> > > 4) Evil site is handed an access token based upon the previous grant to > example.com I don't think this attack will work. If exmple.com was not registered, then it has not client_id, so the previous approval should be remembered for example.com's redirect_uri. Evil site needs to use its own redirect_uri, so immediate will not work. Marius From mscurtescu@google.com Tue Jun 8 11:16:57 2010 Return-Path: <mscurtescu@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C897A3A68BC for <oauth@core3.amsl.com>; Tue, 8 Jun 2010 11:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.562 X-Spam-Level: X-Spam-Status: No, score=-99.562 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4WgfQ5PNOiAZ for <oauth@core3.amsl.com>; Tue, 8 Jun 2010 11:16:57 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id D95413A68E3 for <oauth@ietf.org>; Tue, 8 Jun 2010 11:16:56 -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 o58IGscL008795 for <oauth@ietf.org>; Tue, 8 Jun 2010 11:16:54 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1276021014; bh=mTbohf/Q1mZpbz84qIFK6G+xVmw=; h=MIME-Version:From:Date:Message-ID:Subject:To:Content-Type; b=ZJ5BM2J2DmPBSfEXparOx+YUaSTBcNpczjuCXL/umkCOTo3gxtLGN2Ap2TsATKHeo HS5MVE0kY882gEPtGQ0Kw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:from:date:message-id:subject:to:content-type; b=agqPtmnJ6vo7wGnkWGZ0+9nKlRzsGbUg/uA0yTDtV4sZ7Oq1ws486f4Tw1PmVkWAP qYY7kwbkdFUL8Mr4+jM1g== Received: from pwi5 (pwi5.prod.google.com [10.241.219.5]) by hpaq14.eem.corp.google.com with ESMTP id o58IGLrv000677 for <oauth@ietf.org>; Tue, 8 Jun 2010 11:16:54 -0700 Received: by pwi5 with SMTP id 5so163526pwi.26 for <oauth@ietf.org>; Tue, 08 Jun 2010 11:16:53 -0700 (PDT) Received: by 10.141.101.16 with SMTP id d16mr13514030rvm.169.1276021013495; Tue, 08 Jun 2010 11:16:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.124.13 with HTTP; Tue, 8 Jun 2010 11:16:33 -0700 (PDT) From: Marius Scurtescu <mscurtescu@google.com> Date: Tue, 8 Jun 2010 11:16:33 -0700 Message-ID: <AANLkTilDRHVUgD7YCjW670qQpMzrLgUNcNI1XHW95JnV@mail.gmail.com> To: OAuth WG <oauth@ietf.org> Content-Type: text/plain; charset=ISO-8859-1 Subject: [OAUTH-WG] OAuth 2 delegation flow names X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 08 Jun 2010 18:16:57 -0000 Hi, I find the names of the user delegation flows a bit misleading. These flows are currently named: "User-Agent", "Web Server" and "Device". The names are pointing to the typical client for these flows, but these are not the only use cases, and this is where it can be misleading. For example: - "User-Agent" can also be used use by native apps and web apps - "Web Server" can also be used by JavaScript based clients and native apps - "Device" can also be used by native apps and web apps Instead of naming them after a typical client, maybe we can name them based on some technical characteristics of the flow. The "User-Agent" flow is characterized by the fact that the access token is returned directly to the client, no verification code step is used. The "Web Server" flow is characterized by the fact that a verification code is first returned which then needs to be exchanged for tokens with a direct call from client to authz server. The "Device" flow is mainly characterized by the fact that a polling mechanism is used to retrieve the tokens. How about the following names: - "Web Server" -> "Verification Code" - "Device" -> "Polling" Not sure about the User-Agent flow. Since this flow does not have any direct calls from client to authz server, everything is passed through the browser, "User-Agent" could be the right name? Thoughts? Marius From recordond@gmail.com Tue Jun 8 11:45:41 2010 Return-Path: <recordond@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AFDD3A6893 for <oauth@core3.amsl.com>; Tue, 8 Jun 2010 11:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LT3bvi7dPCGZ for <oauth@core3.amsl.com>; Tue, 8 Jun 2010 11:45:40 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id D63343A6890 for <oauth@ietf.org>; Tue, 8 Jun 2010 11:45:37 -0700 (PDT) Received: by gyh4 with SMTP id 4so3491473gyh.31 for <oauth@ietf.org>; Tue, 08 Jun 2010 11:45:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=f73SMCIbwCj+eq2KlpB8qPEwsxW3hV8phC8BLXA+7s0=; b=F3zlXLzo9yBSj8Dm1dddiOVa/gEIea/vEKm/LxcmHd4eod2+GnP4bSGSCaKt5CGTtk p8nMvESeEBfMhwUXDOAIznBv1+7BiJ6Guf9hHygcXDJYXOdAxL+KZK7SWne49arq+Qdp QqdEr5p8l5yN01PLwgISay0VNSORbPdOxCruI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=j5jVRQlaWXP8RQbooQ7VfhvBr6Y4fr1RbIIXHnhI2hLsp3StAXmZ541CZpIhA8MQnc xpcf6UM+Mz5/a4VPU1kwAd5oFEE8oOPYVptCN0BHRShbDoSRZz+I7AaN5yBbRjEtxaIp S/mk5cszRFM53XPZV2mU40McP45vHrGB26CtQ= MIME-Version: 1.0 Received: by 10.100.50.17 with SMTP id x17mr17127743anx.11.1276022733504; Tue, 08 Jun 2010 11:45:33 -0700 (PDT) Received: by 10.231.192.4 with HTTP; Tue, 8 Jun 2010 11:45:33 -0700 (PDT) In-Reply-To: <AANLkTikkG3T_DYKhjMbyYayi7SzZel3RJXFSguxq7SSZ@mail.gmail.com> References: <AANLkTikkG3T_DYKhjMbyYayi7SzZel3RJXFSguxq7SSZ@mail.gmail.com> Date: Tue, 8 Jun 2010 11:45:33 -0700 Message-ID: <AANLkTimKWnuYd1j6b-sH_Ctt0ZYK67jj0ga64lrcv_Tt@mail.gmail.com> From: David Recordon <recordond@gmail.com> To: Marius Scurtescu <mscurtescu@google.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] native app support (was: Next draft) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 08 Jun 2010 18:45:41 -0000 Hey Marius, 1) Feels like this should be in an unregistered client spec. 3) Why would a device which intends to open a web browser use the device flow to start? Wouldn't it just use the user agent flow? 4) Yes, but should be a separate document. Thanks, --David On Tue, Jun 8, 2010 at 10:46 AM, Marius Scurtescu <mscurtescu@google.com> w= rote: > In order to properly support native applications I suggest the > following changes: > > 1. client_name > > In all flows when client_id is sent also allow for an optional > client_name. This optional parameter is meant as a display name for > the client, and it is useful in all unregistered cases, not only for > native apps. > > If the client is unregistered then most likely the authz server will > require that client_id be set to a predefined value like "anonymous". > The approval page does need a client name so it can tell the user who > it is granting access for. > > > 2. optional redirect_uri (default result page) > > Some native apps do not have a redirect_uri, as a result two things are n= eeded: > > 2.1 Either make redirect_uri optional or define a standard value that > signals that the client does not have such a page. > > 2.2 The authz server must supply a default result page, if there is no > redirect_uri. Also, this page should put the verification code and the > client state (code and state) in the page title in a standard way such > that the native app can extract them from the window title. WRAP > defined how the title should be formed. > > > 3. device flow should be able to start user-agent > > The device flow can be used by native apps in which case there is a > browser on the device. This flow should be able to start a browser and > directly take the user to the end-user verification URI with the user > code added as a query parameter (so the user is not required to do any > manual entry). This is sort of possible right now, but the handler > behind verification_uri must expect an optional user_code (in which > case it should not prompt the user). > > > 4. section with guidance for native apps > > I think the spec needs a section that explains how native apps can be > used with OAuth 2. Not sure if it is worth getting into pros and cons > for each flow, but all flows can be used. > > > Marius > > > > On Mon, Jun 7, 2010 at 8:44 AM, Eran Hammer-Lahav <eran@hueniverse.com> w= rote: >> I still need to catch up on the list (I took a little break). I plan to = post a new draft this week incorporating many editorial changes discussed a= t the interim meeting. I am also planning of removing some non-stable featu= res (such as discovery and signatures) from the draft and moving them to ne= w drafts. As soon as -06 is published, I plan to issue informal last-calls = for each section so that we can lock down the normative portions of the dra= ft. >> >> If you have any must-happen changes for -05 that were not already posted= to the list, please let me know. >> >> 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 recordond@gmail.com Tue Jun 8 11:47:34 2010 Return-Path: <recordond@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A585C3A695F for <oauth@core3.amsl.com>; Tue, 8 Jun 2010 11:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.092 X-Spam-Level: X-Spam-Status: No, score=-0.092 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZO9+V5mwhSnf for <oauth@core3.amsl.com>; Tue, 8 Jun 2010 11:47:19 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 24C533A6829 for <oauth@ietf.org>; Tue, 8 Jun 2010 11:47:18 -0700 (PDT) Received: by iwn42 with SMTP id 42so4905757iwn.31 for <oauth@ietf.org>; Tue, 08 Jun 2010 11:47:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=zAJmw7xhzcDF8uITZVjOrSfw8EgahLjMR0rEhDgYSPU=; b=UjyP8fECjZSUaioYpUVm0EZJHgrMjxjP1btxbg6VAqgdqOkCCc3rU8AGbau2iAtGZq iM+pC7ka1cF1zgmtsXf7S2jDNh0C8vE9OROMI2AEX7QPu+fgXYyJ57axmGqIuft9mKfx uSr1CWKduhFAPyrXIvUyeFSDSSMW0G+SsdyUI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=N1QJT01XXtjcUxcsr/ZDk+vpJqcGaqmcygJi1JNt29HGBUKq7crpxeqGMuDIxmHh5n cGHbs2QSOts4jirYFQEZZg50jNfsFGKBy2B4DL3BBPJcYNKjBusPxDz7DGfadzWrMJ1X CYGTChNLe8w9ug8GADmlgDPg0jOdLvEpgsOSg= MIME-Version: 1.0 Received: by 10.42.7.142 with SMTP id e14mr6978385ice.1.1276022836529; Tue, 08 Jun 2010 11:47:16 -0700 (PDT) Received: by 10.231.192.4 with HTTP; Tue, 8 Jun 2010 11:47:16 -0700 (PDT) In-Reply-To: <AANLkTilDRHVUgD7YCjW670qQpMzrLgUNcNI1XHW95JnV@mail.gmail.com> References: <AANLkTilDRHVUgD7YCjW670qQpMzrLgUNcNI1XHW95JnV@mail.gmail.com> Date: Tue, 8 Jun 2010 11:47:16 -0700 Message-ID: <AANLkTik6OAC4KgBgDAAGUUDH-g434HU6HHuKCr5Ih1ko@mail.gmail.com> From: David Recordon <recordond@gmail.com> To: Marius Scurtescu <mscurtescu@google.com> Content-Type: text/plain; charset=ISO-8859-1 Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] OAuth 2 delegation flow names X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 08 Jun 2010 18:47:35 -0000 I'd strongly prefer them to be named based on where they're largely intended for us. "Polling" has become a bad word especially with the advent of PubSubHubbub and doesn't describe that it's meant for us on hardware devices. --David On Tue, Jun 8, 2010 at 11:16 AM, Marius Scurtescu <mscurtescu@google.com> wrote: > Hi, > > I find the names of the user delegation flows a bit misleading. These > flows are currently named: "User-Agent", "Web Server" and "Device". > The names are pointing to the typical client for these flows, but > these are not the only use cases, and this is where it can be > misleading. > > For example: > - "User-Agent" can also be used use by native apps and web apps > - "Web Server" can also be used by JavaScript based clients and native apps > - "Device" can also be used by native apps and web apps > > Instead of naming them after a typical client, maybe we can name them > based on some technical characteristics of the flow. > > The "User-Agent" flow is characterized by the fact that the access > token is returned directly to the client, no verification code step is > used. > > The "Web Server" flow is characterized by the fact that a verification > code is first returned which then needs to be exchanged for tokens > with a direct call from client to authz server. > > The "Device" flow is mainly characterized by the fact that a polling > mechanism is used to retrieve the tokens. > > How about the following names: > - "Web Server" -> "Verification Code" > - "Device" -> "Polling" > > Not sure about the User-Agent flow. Since this flow does not have any > direct calls from client to authz server, everything is passed through > the browser, "User-Agent" could be the right name? > > Thoughts? > > Marius > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From recordond@gmail.com Tue Jun 8 11:47:37 2010 Return-Path: <recordond@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05ADF3A67C1 for <oauth@core3.amsl.com>; Tue, 8 Jun 2010 11:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.139 X-Spam-Level: X-Spam-Status: No, score=-0.139 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l2bJHpKsQPoU for <oauth@core3.amsl.com>; Tue, 8 Jun 2010 11:47:27 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id CC4DA3A6893 for <oauth@ietf.org>; Tue, 8 Jun 2010 11:47:26 -0700 (PDT) Received: by yxt33 with SMTP id 33so985695yxt.31 for <oauth@ietf.org>; Tue, 08 Jun 2010 11:47:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=bzSnEjuu6ObuKkEAbERuB371tT9T3j5k7ZEJQNWml6M=; b=iZHNiEAIGWmToxeB8aN9jZZD8EprXyG/BMe/NmulhowZU9ByBptatPCERizkQ7x5aP 4x94PU017L8wrrrj7G1E2GpRj1grWBGwkLmhoQLP6AcsIplkuyD8C5jN8YExq1ngXxBe dqjhCbfzuX8SNCwwY4g1M8YzJY4WYI9IWy0dI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Gh51sjBEdTZrnlCLcP04P5ORQJNXuUsPbCg6lMa7KwoTvF1Wx8I3Lght28S4qc/BW/ WnMbYQijmTRZvl6jSensFf6xBW7c+BAeSoYNrvio+QTBnfNoL3K5969DehMgqpeYQuAH kG6HofkTnln7wfjkm41WGAvU0MDLsRRNUAu20= MIME-Version: 1.0 Received: by 10.150.166.13 with SMTP id o13mr15687388ybe.370.1276022843334; Tue, 08 Jun 2010 11:47:23 -0700 (PDT) Received: by 10.231.192.4 with HTTP; Tue, 8 Jun 2010 11:47:23 -0700 (PDT) In-Reply-To: <AANLkTik6OAC4KgBgDAAGUUDH-g434HU6HHuKCr5Ih1ko@mail.gmail.com> References: <AANLkTilDRHVUgD7YCjW670qQpMzrLgUNcNI1XHW95JnV@mail.gmail.com> <AANLkTik6OAC4KgBgDAAGUUDH-g434HU6HHuKCr5Ih1ko@mail.gmail.com> Date: Tue, 8 Jun 2010 11:47:23 -0700 Message-ID: <AANLkTilj22nt9lvpfz55CfS-qm5DHYT4mMjy4Jr0KQy1@mail.gmail.com> From: David Recordon <recordond@gmail.com> To: Marius Scurtescu <mscurtescu@google.com> Content-Type: text/plain; charset=ISO-8859-1 Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] OAuth 2 delegation flow names X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 08 Jun 2010 18:47:37 -0000 s/us/use/ On Tue, Jun 8, 2010 at 11:47 AM, David Recordon <recordond@gmail.com> wrote: > I'd strongly prefer them to be named based on where they're largely > intended for us. "Polling" has become a bad word especially with the > advent of PubSubHubbub and doesn't describe that it's meant for us on > hardware devices. > > --David > > > On Tue, Jun 8, 2010 at 11:16 AM, Marius Scurtescu <mscurtescu@google.com> wrote: >> Hi, >> >> I find the names of the user delegation flows a bit misleading. These >> flows are currently named: "User-Agent", "Web Server" and "Device". >> The names are pointing to the typical client for these flows, but >> these are not the only use cases, and this is where it can be >> misleading. >> >> For example: >> - "User-Agent" can also be used use by native apps and web apps >> - "Web Server" can also be used by JavaScript based clients and native apps >> - "Device" can also be used by native apps and web apps >> >> Instead of naming them after a typical client, maybe we can name them >> based on some technical characteristics of the flow. >> >> The "User-Agent" flow is characterized by the fact that the access >> token is returned directly to the client, no verification code step is >> used. >> >> The "Web Server" flow is characterized by the fact that a verification >> code is first returned which then needs to be exchanged for tokens >> with a direct call from client to authz server. >> >> The "Device" flow is mainly characterized by the fact that a polling >> mechanism is used to retrieve the tokens. >> >> How about the following names: >> - "Web Server" -> "Verification Code" >> - "Device" -> "Polling" >> >> Not sure about the User-Agent flow. Since this flow does not have any >> direct calls from client to authz server, everything is passed through >> the browser, "User-Agent" could be the right name? >> >> Thoughts? >> >> Marius >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > From gffletch@aol.com Tue Jun 8 12:58:55 2010 Return-Path: <gffletch@aol.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B8FC3A68BC for <oauth@core3.amsl.com>; Tue, 8 Jun 2010 12:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id izCK9kPKOUlH for <oauth@core3.amsl.com>; Tue, 8 Jun 2010 12:58:54 -0700 (PDT) Received: from imr-ma01.mx.aol.com (imr-ma01.mx.aol.com [64.12.206.39]) by core3.amsl.com (Postfix) with ESMTP id C51E03A683F for <oauth@ietf.org>; Tue, 8 Jun 2010 12:58:53 -0700 (PDT) Received: from mtaout-mb01.r1000.mx.aol.com (mtaout-mb01.r1000.mx.aol.com [172.29.41.65]) by imr-ma01.mx.aol.com (8.14.1/8.14.1) with ESMTP id o58Jw6Pn030619; Tue, 8 Jun 2010 15:58:18 -0400 Received: from palantir.local (unknown [10.181.183.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-mb01.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 3806DE00029B; Tue, 8 Jun 2010 15:58:18 -0400 (EDT) Message-ID: <4C0EA0D8.6060407@aol.com> Date: Tue, 08 Jun 2010 15:58:16 -0400 From: George Fletcher <gffletch@aol.com> Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Nat Sakimura <sakimura@gmail.com> References: <AANLkTik71Izx8JF0I24hp7Vwx8LnKGpoEDhQRq9TxMyE@mail.gmail.com> In-Reply-To: <AANLkTik71Izx8JF0I24hp7Vwx8LnKGpoEDhQRq9TxMyE@mail.gmail.com> Content-Type: multipart/alternative; boundary="------------070304040901030300030007" x-aol-global-disposition: G X-AOL-SCOLL-SCORE: 0:2:483851552:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d29414c0ea0da4a83 X-AOL-IP: 10.181.183.108 Cc: oauth <oauth@ietf.org> Subject: Re: [OAUTH-WG] Extension Mechanism X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 08 Jun 2010 19:58:55 -0000 This is a multi-part message in MIME format. --------------070304040901030300030007 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit +1 for a defined extension mechanism maybe I didn't understand but I would have thought the "pape:error" would be... "pape:error"="Invalid max_auth_age format." does the message itself need to be namespaced? Thanks, George On 6/8/10 12:45 AM, Nat Sakimura wrote: > Defining an Extension Mechanism for both request and response would > generally be useful. > > Some basic design principles: > > - no name space through type URI: fixed registered string for extensions. > e.g., for Open Graph, perhaps use og:variable_names OR og_variable > names > where either "og:" or "og_" is the type prefix. (I kind of prefer > ":" over "_" as > a separator since in CGI "-" and "_" will be identical, and in PHP > GPC parameters > "." and "_" are identical. Also, we are using "_" in the variable > names already. ) > - no cross interactions with other extensions > > I think it should be added as Chapter 7 or so, which means Security > Considerations will be chapter 8. > > Following is the straw-man. > > 7. Extension Mechanism > > Additional parameters MAY be defined for any request and response. > The parameter names MUST start with a parameter prefix separated by a > colon ":". > > For example: > > pape:max_auth_age > > Each extension MUST define its own error messages and MUST return them > through > the prefixed "error" parameter. > > For example: > > "pape:error":"Invalid max_auth_age format." > > > cheers, > > Nat > > > > > > > -- > Nat Sakimura (=nat) > http://www.sakimura.org/en/ > http://twitter.com/_nat_en > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------070304040901030300030007 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=windows-1252" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> +1 for a defined extension mechanism<br> <br> maybe I didn't understand but I would have thought the "pape:error" would be...<br> <br> <font class="Apple-style-span" face="verdana, charcoal, helvetica, arial, sans-serif">"pape:error"="Invalid max_auth_age format."</font><br> <br> does the message itself need to be namespaced?<br> <br> Thanks,<br> George<br> <br> On 6/8/10 12:45 AM, Nat Sakimura wrote: <blockquote cite="mid:AANLkTik71Izx8JF0I24hp7Vwx8LnKGpoEDhQRq9TxMyE@mail.gmail.com" type="cite">Defining an Extension Mechanism for both request and response would generally be useful.  <div><br> </div> <div>Some basic design principles: </div> <div><br> </div> <div>- no name space through type URI: fixed registered string for extensions. </div> <div>   e.g., for Open Graph, perhaps use og:variable_names OR og_variable names </div> <div>    where either "og:" or "og_" is the type prefix. (I kind of prefer ":" over "_" as </div> <div>    a separator since in CGI "-" and "_" will be identical, and in PHP GPC parameters</div> <div>    "." and "_"  are identical. Also, we are using "_" in the variable names already. )</div> <div>- no cross interactions with other extensions</div> <div><br> </div> <div>I think it should be added as Chapter 7 or so, which means Security Considerations will be chapter 8. </div> <div><br> </div> <div>Following is the straw-man. </div> <div><br> </div> <div>7. Extension Mechanism</div> <div><br> </div> <div>Additional parameters MAY be defined for any request and response. </div> <div>The parameter names MUST start with a parameter prefix separated by a colon ":". </div> <div><br> </div> <div>For example: </div> <div><br> </div> <div><span class="Apple-style-span" style="font-family: verdana,charcoal,helvetica,arial,sans-serif;">pape:max_auth_age</span></div> <div><font class="Apple-style-span" face="verdana, charcoal, helvetica, arial, sans-serif"><br> </font></div> <div><font class="Apple-style-span" face="verdana, charcoal, helvetica, arial, sans-serif">Each extension MUST define its own error messages and MUST return them through </font></div> <div><font class="Apple-style-span" face="verdana, charcoal, helvetica, arial, sans-serif">the prefixed "error" parameter. </font></div> <div><font class="Apple-style-span" face="verdana, charcoal, helvetica, arial, sans-serif"><br> </font></div> <div><font class="Apple-style-span" face="verdana, charcoal, helvetica, arial, sans-serif">For example: </font></div> <div><font class="Apple-style-span" face="verdana, charcoal, helvetica, arial, sans-serif"><br> </font></div> <div><font class="Apple-style-span" face="verdana, charcoal, helvetica, arial, sans-serif">"pape:error":"Invalid max_auth_age format."</font></div> <div><font class="Apple-style-span" face="verdana, charcoal, helvetica, arial, sans-serif"><br> </font></div> <div><font class="Apple-style-span" face="verdana, charcoal, helvetica, arial, sans-serif"><br> </font></div> <div>cheers, </div> <div><br> </div> <div>Nat</div> <div><br> </div> <div><br> </div> <div><br> <div><br> </div> <div><br clear="all"> <br> -- <br> Nat Sakimura (=nat)<br> <a moz-do-not-send="true" href="http://www.sakimura.org/en/">http://www.sakimura.org/en/</a><br> <a moz-do-not-send="true" href="http://twitter.com/_nat_en">http://twitter.com/_nat_en</a><br> </div> </div> <pre wrap=""> <fieldset class="mimeAttachmentHeader"></fieldset> _______________________________________________ OAuth mailing list <a class="moz-txt-link-abbreviated" href="mailto:OAuth@ietf.org">OAuth@ietf.org</a> <a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/oauth">https://www.ietf.org/mailman/listinfo/oauth</a></pre> </blockquote> </body> </html> --------------070304040901030300030007-- From balfanz@google.com Tue Jun 8 13:24:10 2010 Return-Path: <balfanz@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75C4F3A6823 for <oauth@core3.amsl.com>; Tue, 8 Jun 2010 13:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.562 X-Spam-Level: X-Spam-Status: No, score=-99.562 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VT3vzk-wgESa for <oauth@core3.amsl.com>; Tue, 8 Jun 2010 13:24:05 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id BF46C3A684D for <oauth@ietf.org>; Tue, 8 Jun 2010 13:23:44 -0700 (PDT) Received: from hpaq1.eem.corp.google.com (hpaq1.eem.corp.google.com [172.25.149.1]) by smtp-out.google.com with ESMTP id o58KNhrd000937 for <oauth@ietf.org>; Tue, 8 Jun 2010 13:23:43 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1276028623; bh=6rbf8MFe/2QTasYvUahfEsVvLcw=; h=MIME-Version:Date:Message-ID:Subject:From:To:Content-Type; b=hztZtGH/bfuJNPLXTNNhE4/TiILgyxDoF7He4FJeLVzZq9NUeBHJujPiz7R10xQfQ 4AdJ2DFvKu8Qz2wbvJ2GQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:date:message-id:subject:from:to:content-type; b=dk0TQ0PrKqHM+qTMrNVNya/ThtYdex+bAoQsAJGqis2mYlmLbkE2SkzqnFHd4ZhzC 7naYrnxpT5m4vuAs2qTFw== Received: from iwn3 (iwn3.prod.google.com [10.241.68.67]) by hpaq1.eem.corp.google.com with ESMTP id o58KNgna016555 for <oauth@ietf.org>; Tue, 8 Jun 2010 13:23:43 -0700 Received: by iwn3 with SMTP id 3so1961166iwn.30 for <oauth@ietf.org>; Tue, 08 Jun 2010 13:23:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.3.202 with SMTP id 10mr717363icp.35.1276028622050; Tue, 08 Jun 2010 13:23:42 -0700 (PDT) Received: by 10.231.68.144 with HTTP; Tue, 8 Jun 2010 13:23:41 -0700 (PDT) Date: Tue, 8 Jun 2010 13:23:41 -0700 Message-ID: <AANLkTimOXzscoFDtf-PO8965xuchEBJvqALiWM3O9fMl@mail.gmail.com> From: Dirk Balfanz <balfanz@google.com> To: OAuth WG <oauth@ietf.org> Content-Type: multipart/alternative; boundary=00163691fd97bd94c404888a9048 Subject: [OAUTH-WG] polling in the device flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 08 Jun 2010 20:24:10 -0000 --00163691fd97bd94c404888a9048 Content-Type: text/plain; charset=ISO-8859-1 Hi guys, currently, we specify how polling should work in the device flow as part of the OAuth2 spec. I would argue that that polling should be handled at a lower layer of the stack, and that OAuth2 should be silent on the issue of polling. The benefit will be a simpler spec. HTTP specifies the 503 response code with the (optional) Retry-After response header. ASs could just use that mechanism to throttle clients, instead of handling it at the OAuth layer. The OAuth spec could say something like: "The client requests the access token after the user approves or rejects authorization. If the client cannot determine when the user has approved or rejected the authorization, the client MAY poll the server. The server MAY use throttling mechanisms such as 503 HTTP response codes and Retry-After response headers which, if used, the client MUST obey." What do you guys think? BTW, there is some precedence for this. Google's APIs use 503 response codes to throttle servers, e.g. http://code.google.com/googleapps/domain/gdata_provisioning_api_v2.0_reference.html Dirk. --00163691fd97bd94c404888a9048 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi guys, <br><br>currently, we specify how polling should work in the devic= e flow as part of the OAuth2 spec.<br><br>I would argue that that polling s= hould be handled at a lower layer of the stack, and that OAuth2 should be s= ilent on the issue of polling. The benefit will be a simpler spec.<br> <br>HTTP specifies the 503 response code with the (optional) Retry-After re= sponse header. ASs could just use that mechanism to throttle clients, inste= ad of handling it at the OAuth layer. <br><br>The OAuth spec could say some= thing like: "The client requests the access token after the user appro= ves or rejects authorization. If the client cannot determine when the user = has approved or rejected the authorization, the client MAY poll the server.= The server MAY use throttling mechanisms such as 503 HTTP response codes a= nd Retry-After response headers which, if used, the client MUST obey."= <br> <br>What do you guys think?<br><br>BTW, there is some precedence for this. = Google's APIs use 503 response codes to throttle servers, e.g. <a href= =3D"http://code.google.com/googleapps/domain/gdata_provisioning_api_v2.0_re= ference.html">http://code.google.com/googleapps/domain/gdata_provisioning_a= pi_v2.0_reference.html</a><br> <br>Dirk.<br><br> --00163691fd97bd94c404888a9048-- From mscurtescu@google.com Tue Jun 8 13:29:10 2010 Return-Path: <mscurtescu@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 181223A6817 for <oauth@core3.amsl.com>; Tue, 8 Jun 2010 13:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.825 X-Spam-Level: X-Spam-Status: No, score=-100.825 tagged_above=-999 required=5 tests=[AWL=1.152, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CpV5SbbSWF22 for <oauth@core3.amsl.com>; Tue, 8 Jun 2010 13:29:09 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id E77923A6836 for <oauth@ietf.org>; Tue, 8 Jun 2010 13:29:08 -0700 (PDT) Received: from kpbe14.cbf.corp.google.com (kpbe14.cbf.corp.google.com [172.25.105.78]) by smtp-out.google.com with ESMTP id o58KT895001378 for <oauth@ietf.org>; Tue, 8 Jun 2010 13:29:08 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1276028949; bh=FtgM7Pa+ULFuujJQBWlpSPkxMhs=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=Dv1b0Oskt72DdpNxTLppmdFGD5nVYMFkB2BTkECfZ4EbpYKJY7R0vUePf1DtkhjDH CUk4njTGGAenGyr96yr0A== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type; b=NTHtTOW5I+tYTa1VQw/JXR7auR7sF4thHk/oqEwO1olXF5Ye7Tm76G//pB3C9s/2Q gStbkh+u6ItaAFKuKMmfw== Received: from pwj7 (pwj7.prod.google.com [10.241.219.71]) by kpbe14.cbf.corp.google.com with ESMTP id o58KSwIl009510 for <oauth@ietf.org>; Tue, 8 Jun 2010 13:29:04 -0700 Received: by pwj7 with SMTP id 7so285558pwj.35 for <oauth@ietf.org>; Tue, 08 Jun 2010 13:28:58 -0700 (PDT) Received: by 10.141.187.12 with SMTP id o12mr2189501rvp.43.1276028938497; Tue, 08 Jun 2010 13:28:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.124.13 with HTTP; Tue, 8 Jun 2010 13:28:38 -0700 (PDT) In-Reply-To: <AANLkTimKWnuYd1j6b-sH_Ctt0ZYK67jj0ga64lrcv_Tt@mail.gmail.com> References: <AANLkTikkG3T_DYKhjMbyYayi7SzZel3RJXFSguxq7SSZ@mail.gmail.com> <AANLkTimKWnuYd1j6b-sH_Ctt0ZYK67jj0ga64lrcv_Tt@mail.gmail.com> From: Marius Scurtescu <mscurtescu@google.com> Date: Tue, 8 Jun 2010 13:28:38 -0700 Message-ID: <AANLkTilTlyqGDNPb5nxfeWI-vCmGvM7ZsCK72ekoAcrj@mail.gmail.com> To: David Recordon <recordond@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] native app support (was: Next draft) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 08 Jun 2010 20:29:10 -0000 On Tue, Jun 8, 2010 at 11:45 AM, David Recordon <recordond@gmail.com> wrote: > Hey Marius, > > 1) Feels like this should be in an unregistered client spec. Not sure. Does the core spec always assume registered? > 3) Why would a device which intends to open a web browser use the > device flow to start? Wouldn't it just use the user agent flow? Two reasons: - User-Agent flow probably does not return a refresh token - much harder to capture the response from User-Agent or Web Server (embed browser, watch title, ...), with device flow all this goes away > 4) Yes, but should be a separate document. Maybe. Native apps are a main use case, more important than devices IMO. Why keep devices in core and move out native apps? Marius From eran@hueniverse.com Tue Jun 8 15:10:25 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 960103A680E for <oauth@core3.amsl.com>; Tue, 8 Jun 2010 15:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QkhQIM4ff7Dh for <oauth@core3.amsl.com>; Tue, 8 Jun 2010 15:10:23 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 416293A67B1 for <oauth@ietf.org>; Tue, 8 Jun 2010 15:10:23 -0700 (PDT) Received: (qmail 6350 invoked from network); 8 Jun 2010 22:10:24 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 8 Jun 2010 22:10:24 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 8 Jun 2010 15:10:24 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: Yaron Goland <yarong@microsoft.com>, "oauth@ietf.org" <oauth@ietf.org> Date: Tue, 8 Jun 2010 15:10:30 -0700 Thread-Topic: Questions about sections 3.2/3.3 Thread-Index: Acr4TV5Gu7PqT32USNegznSs4LRTdwPBQssA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF6E13@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <7C01E631FF4B654FA1E783F1C0265F8C578D67E6@TK5EX14MBXC113.redmond.corp.microsoft.com> In-Reply-To: <7C01E631FF4B654FA1E783F1C0265F8C578D67E6@TK5EX14MBXC113.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Questions about sections 3.2/3.3 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 08 Jun 2010 22:10:25 -0000 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Yaron Goland > Sent: Thursday, May 20, 2010 12:20 PM > To: oauth@ietf.org > Subject: [OAUTH-WG] Questions about sections 3.2/3.3 >=20 > I was reading through the spec and had some questions about 3.2 and 3.3 > that I list below. > =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 Yaron > Section 3.2/3.3 - Handling requests without supported transport layer > security >=20 > Although optional in section 3.2 and mandatory in section 3.3 both sectio= ns > have a similar challenge - what happens if someone makes a request > without the transport layer security required by the endpoint? What HTTP > error is to be returned? 401? 403? 404 Not found. The server provides the absolute URI of the endpoint. If you= ask for something else that doesn't exist, you get a 404. Note that the en= dpoint in 3.2 is really a web-site, not a web service. It is a browser-spec= ific endpoint and should support the strongest protection provided by suppo= rted browsers. > A further complication is that both sections explicitly allow for transpo= rt layer > security solutions other than TLS/SSL. Doesn't this mean that we need to > extend section 6.1's definition of the www-authenticate response header t= o > also specify what transport layer security mechanisms are supported? Neither section uses the header because these endpoints are not OAuth-prote= cted. They might use something else but that's outside the scope. In general, I think we just need to say what support is required and leave = the rest for servers to decide. There is no value in saying that other meth= ods may be used (there is no standards police and when you do that, you bre= ak interop anyway). =20 > Section 3.3 - Is TLS/SSL mandatory or optional? And if so, what version o= f > TLS/SSL? Is it ok to require TLS 1.2? > The specification currently states: >=20 > =A0=A0 .the > =A0=A0 authorization server MUST require the use of a transport-layer > =A0=A0 mechanism such as TLS/SSL (or a secure channel with equivalent > =A0=A0 protections) when sending requests to the token endpoints. >=20 > To me this text implies that an OAuth server could be conformant and not > implement TLS/SSL but instead implement some other transport-layer > security mechanism (say a VPN protocol). From an interoperability > perspective that seems problematic since it means clients can't know what > transport-layer solution the token endpoint will support. Wouldn't it be > reasonable to put in a requirement that all OAuth endpoints MUST support > RFC 5246 and RFC 5746? 5246 makes sense. I don't know enough to say about 5746. =20 > In other words the language could read: ".the authorization server MUST > require the use of a transport-layer mechanism when sending requests to > the token endpoints. Specifically, authorization servers MUST support > version 1.2 of TLS as defined in RFC 5246 and extended in RFC 5746 and MA= Y > support other equivalent secure channel mechanisms". >=20 > Section 3.3.1 - What error is returned if clients provide credentials in = both > the header and the body? 400 Bad Request. > Section 3.3.1 explicitly prohibits submitting client credentials using mu= ltiple > schemes but it doesn't define what error to return if this requirement is > violated. Given the requirement in section 3.3.2.2 to include the "error"= field > wouldn't it be useful to define URIs that map to specific errors defined = in the > specification? For example, "If the client does include multiple client > credential schemes then, per section 3.3.2.2, a 400 Bad Request response > MUST be sent with an error code of urn:ietf:rfc:X:multiple-client- > credentials". Why a URI? What's wrong with simple text strings? Are you expecting collisi= on of error messages? > Section 3.3.1 - How exactly are client credentials passed via HTTP Basic > authentication? Client id -> username, client secret -> password. > Although section 3.3.1 states that HTTP basic authentication is to be > supported, it doesn't specify how. I realize the mapping is pretty obviou= s but > standards are one area where it pays off to be pedantic. Would it be usef= ul > to add language such as?: >=20 > "The authorization server MUST accept the client credentials using both t= he > request parameters and the HTTP Basic authentication scheme as defined in > [RFC2617]. When using HTTP Basic the client id MUST be mapped to the HTTP > Basic userid and the client secret MUST be mapped to the HTTP Basic > password. The realm value can either be discovered by sending an > unauthenticated request and examining the returned realm value in the > www-Authenticate header or by reading the authorization service's > documentation." I changed to: The client MAY include the client credentials using an HTTP aut= hentication scheme which supports authenticating using a username and password, in= stead of using the 'client_id' and 'client_secret' request parameters. Including t= he client credentials using an HTTP authentication scheme fulfills the requirements of including the parameters as= defined by the various flows. Which I think does the trick. EHL From sakimura@gmail.com Tue Jun 8 17:09:52 2010 Return-Path: <sakimura@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 882E13A682A for <oauth@core3.amsl.com>; Tue, 8 Jun 2010 17:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.041 X-Spam-Level: X-Spam-Status: No, score=-2.041 tagged_above=-999 required=5 tests=[AWL=0.557, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mg-n5ZprHNIr for <oauth@core3.amsl.com>; Tue, 8 Jun 2010 17:09:51 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 17DB53A6407 for <oauth@ietf.org>; Tue, 8 Jun 2010 17:09:51 -0700 (PDT) Received: by iwn42 with SMTP id 42so5210586iwn.31 for <oauth@ietf.org>; Tue, 08 Jun 2010 17:09:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=594W/FBHVlpH01MJK3i/MHj3FLrrfyPaSTy37A98wok=; b=DRoeMtGoS8rT/wnJr2qaf/pbvxozvfL33mBP+L9Al3/tp94qjSmTrIwccmncI2SMsO rkpMW2tA1xtuBdPQPm+hADrw08eAma4CvF6iW8IuC2J/w+2z++cXA0p8DHgSHyvP4sYd +/2WWF8nmbWPL/vw8lSXUHP3fspclbSYfcu5w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=RveGShQMYqbcDxiMO/VCDrNL9VYHPewq+IWTZKc6ICAxP0ibOTdG9DLxQ0Nd3KMmEV P1yI65QNIP8ari96ulrh14eimxmcmGFFYQYBkMzJwBLpCokbKdxZ71EaxNW94PUsanCX ylSlrlBZoklCCHAQzhNLWYpsB/O0LNI+CBhqs= MIME-Version: 1.0 Received: by 10.231.79.4 with SMTP id n4mr11520661ibk.16.1276042189255; Tue, 08 Jun 2010 17:09:49 -0700 (PDT) Received: by 10.231.15.133 with HTTP; Tue, 8 Jun 2010 17:09:49 -0700 (PDT) In-Reply-To: <4C0EA0D8.6060407@aol.com> References: <AANLkTik71Izx8JF0I24hp7Vwx8LnKGpoEDhQRq9TxMyE@mail.gmail.com> <4C0EA0D8.6060407@aol.com> Date: Wed, 9 Jun 2010 09:09:49 +0900 Message-ID: <AANLkTimU9YnUZEpPzCQ-QengOnDpIk70N1L0Q4TNzom-@mail.gmail.com> From: Nat Sakimura <sakimura@gmail.com> To: George Fletcher <gffletch@aol.com> Content-Type: multipart/alternative; boundary=0016e64ba55468b5f204888db92d Cc: oauth <oauth@ietf.org> Subject: Re: [OAUTH-WG] Extension Mechanism X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 09 Jun 2010 00:09:52 -0000 --0016e64ba55468b5f204888db92d Content-Type: text/plain; charset=ISO-8859-1 If the error message was returned as the Form Encoding, then it would pape%3Aerror=Invalid%20max_auth_age%20format If it was returned as JSON, the following will be inserted into JSON. "pape:error":"Invalid max_auth_age format." Whether it is better to have the "error" prefixed is a good question. We have two options: "pape:error":"Invalid max_auth_age format." AND "error":"pape:Invalid max_auth_age format." I have thought of both ways, and opted to prefix it because then the extension would have less interaction with other parts of the server program. In the second way, the core module has to collect all the errors from the extensions, which is slightly harder. From the point of view of the client, if every error is collected in the "error" variable, it has to parse it, and it makes it a little harder as well. That's what I thought. On Wed, Jun 9, 2010 at 4:58 AM, George Fletcher <gffletch@aol.com> wrote: > +1 for a defined extension mechanism > > maybe I didn't understand but I would have thought the "pape:error" would > be... > > > "pape:error"="Invalid max_auth_age format." > > does the message itself need to be namespaced? > > Thanks, > George > > > On 6/8/10 12:45 AM, Nat Sakimura wrote: > > Defining an Extension Mechanism for both request and response would > generally be useful. > > Some basic design principles: > > - no name space through type URI: fixed registered string for > extensions. > e.g., for Open Graph, perhaps use og:variable_names OR og_variable > names > where either "og:" or "og_" is the type prefix. (I kind of prefer ":" > over "_" as > a separator since in CGI "-" and "_" will be identical, and in PHP GPC > parameters > "." and "_" are identical. Also, we are using "_" in the variable > names already. ) > - no cross interactions with other extensions > > I think it should be added as Chapter 7 or so, which means Security > Considerations will be chapter 8. > > Following is the straw-man. > > 7. Extension Mechanism > > Additional parameters MAY be defined for any request and response. > The parameter names MUST start with a parameter prefix separated by a colon > ":". > > For example: > > pape:max_auth_age > > Each extension MUST define its own error messages and MUST return them > through > the prefixed "error" parameter. > > For example: > > "pape:error":"Invalid max_auth_age format." > > > cheers, > > Nat > > > > > > > -- > Nat Sakimura (=nat) > http://www.sakimura.org/en/ > http://twitter.com/_nat_en > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > -- Nat Sakimura (=nat) http://www.sakimura.org/en/ http://twitter.com/_nat_en --0016e64ba55468b5f204888db92d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div>If the error message was returned as the Form Encoding, then it would= =A0</div><div><br></div><div><span class=3D"Apple-style-span" style=3D"font= -family: 'Lucida Grande'; font-size: 11px; white-space: pre-wrap; -= webkit-border-horizontal-spacing: 2px; -webkit-border-vertical-spacing: 2px= ; ">pape%3Aerror=3DInvalid%20max_auth_age%20format</span></div> <div><br></div><div>If it was returned as JSON, the following will be inser= ted into JSON.=A0</div><div><br></div><div><span class=3D"Apple-style-span"= style=3D"font-family: verdana, charcoal, helvetica, arial, sans-serif; fon= t-size: 13px; border-collapse: collapse; ">"pape:error":"Inv= alid max_auth_age format."</span></div> <div><br></div>Whether it is better to have the "error" prefixed = is a good question.=A0<div>We have two options:=A0</div><div><br></div><div= ><span class=3D"Apple-style-span" style=3D"font-family: verdana, charcoal, = helvetica, arial, sans-serif; font-size: 13px; border-collapse: collapse; "= >"pape:error":"Invalid max_auth_age format." AND=A0</sp= an></div> <div><span class=3D"Apple-style-span" style=3D"font-size: 13px; "></span><f= ont class=3D"Apple-style-span" face=3D"verdana, charcoal, helvetica, arial,= sans-serif"><span class=3D"Apple-style-span" style=3D"border-collapse: col= lapse;">"error":"pape:Invalid max_auth_age format."</sp= an></font></div> <div><font class=3D"Apple-style-span" face=3D"verdana, charcoal, helvetica,= arial, sans-serif"><span class=3D"Apple-style-span" style=3D"border-collap= se: collapse;"><br></span></font><div>I have thought of both ways, and opte= d to prefix it because then the=A0</div> <div>extension would have less interaction with other parts of the server p= rogram.=A0</div><div>In the second way, the core module has to collect all = the errors from the=A0</div><div>extensions, which is slightly harder. From= the point of view of the=A0</div> <div>client, if every error is collected in the "error" variable,= it has to parse it,=A0</div><div>and it makes it a little harder as well. = That's what I thought.=A0<br><div><br><div class=3D"gmail_quote">On Wed= , Jun 9, 2010 at 4:58 AM, George Fletcher <span dir=3D"ltr"><<a href=3D"= mailto:gffletch@aol.com">gffletch@aol.com</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex;"> =20 <div bgcolor=3D"#ffffff" text=3D"#000000"> +1 for a defined extension mechanism<br> <br> maybe I didn't understand but I would have thought the "pape:error= " would be...<div class=3D"im"><br> <br> <font face=3D"verdana, charcoal, helvetica, arial, sans-serif">"pape:e= rror"=3D"Invalid max_auth_age format."</font><br> <br></div> does the message itself need to be namespaced?<br> <br> Thanks,<br> George<div><div></div><div class=3D"h5"><br> <br> On 6/8/10 12:45 AM, Nat Sakimura wrote: </div></div><blockquote type=3D"cite"><div><div></div><div class=3D"h5">Def= ining an Extension Mechanism for both request and response would generally be useful.=A0 <div><br> </div> <div>Some basic design principles:=A0</div> <div><br> </div> <div>- no name space through type URI: fixed registered string for extensions.=A0</div> <div>=A0=A0 e.g., for Open Graph, perhaps use og:variable_names OR og_variable names=A0</div> <div>=A0=A0 =A0where either "og:" or "og_" is the typ= e prefix. (I kind of prefer ":" over "_" as=A0</div> <div>=A0=A0 =A0a separator since in CGI "-" and "_" w= ill be identical, and in PHP GPC parameters</div> <div>=A0=A0 =A0"." and "_"=A0=A0are identical. Also, = we are using "_" in the variable names already. )</div> <div>- no cross interactions with other extensions</div> <div><br> </div> <div>I think it should be added as Chapter 7 or so, which means Security Considerations will be chapter 8.=A0</div> <div><br> </div> <div>Following is the straw-man.=A0</div> <div><br> </div> <div>7. Extension Mechanism</div> <div><br> </div> <div>Additional parameters MAY be defined for any request and response.=A0</div> <div>The parameter names MUST start with a parameter prefix separated by a colon ":".=A0</div> <div><br> </div> <div>For example:=A0</div> <div><br> </div> <div><span style=3D"font-family:verdana,charcoal,helvetica,arial,sans-ser= if">pape:max_auth_age</span></div> <div><font face=3D"verdana, charcoal, helvetica, arial, sans-serif"><br> </font></div> <div><font face=3D"verdana, charcoal, helvetica, arial, sans-serif">Each = extension MUST define its own error messages and MUST return them through=A0</font></= div> <div><font face=3D"verdana, charcoal, helvetica, arial, sans-serif">the p= refixed "error" parameter.=A0</font></div> <div><font face=3D"verdana, charcoal, helvetica, arial, sans-serif"><br> </font></div> <div><font face=3D"verdana, charcoal, helvetica, arial, sans-serif">For e= xample:=A0</font></div> <div><font face=3D"verdana, charcoal, helvetica, arial, sans-serif"><br> </font></div> <div><font face=3D"verdana, charcoal, helvetica, arial, sans-serif">"= ;pape:error":"Invalid max_auth_age format."</font></div> <div><font face=3D"verdana, charcoal, helvetica, arial, sans-serif"><br> </font></div> <div><font face=3D"verdana, charcoal, helvetica, arial, sans-serif"><br> </font></div> <div>cheers,=A0</div> <div><br> </div> <div>Nat</div> <div><br> </div> <div><br> </div> <div><br> <div><br> </div> <div><br clear=3D"all"> <br> -- <br> Nat Sakimura (=3Dnat)<br> <a href=3D"http://www.sakimura.org/en/" target=3D"_blank">http://www.saki= mura.org/en/</a><br> <a href=3D"http://twitter.com/_nat_en" target=3D"_blank">http://twitter.c= om/_nat_en</a><br> </div> </div> </div></div><pre><fieldset></fieldset> _______________________________________________ OAuth mailing list <div class=3D"im"><a href=3D"mailto:OAuth@ietf.org" target=3D"_blank">OAuth= @ietf.org</a> <a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_blank">h= ttps://www.ietf.org/mailman/listinfo/oauth</a></div></pre> </blockquote> </div> </blockquote></div><br><br clear=3D"all"><br>-- <br>Nat Sakimura (=3Dnat)<b= r><a href=3D"http://www.sakimura.org/en/">http://www.sakimura.org/en/</a><b= r><a href=3D"http://twitter.com/_nat_en">http://twitter.com/_nat_en</a><br> </div></div></div> --0016e64ba55468b5f204888db92d-- From eran@hueniverse.com Tue Jun 8 23:17:40 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAA953A68BA for <oauth@core3.amsl.com>; Tue, 8 Jun 2010 23:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-gIwR6Ej-Am for <oauth@core3.amsl.com>; Tue, 8 Jun 2010 23:17:39 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 2D4E13A677D for <oauth@ietf.org>; Tue, 8 Jun 2010 23:17:39 -0700 (PDT) Received: (qmail 9649 invoked from network); 9 Jun 2010 06:17:36 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 9 Jun 2010 06:17:34 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Tue, 8 Jun 2010 23:17:35 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: Brian Eaton <beaton@google.com> Date: Tue, 8 Jun 2010 23:17:24 -0700 Thread-Topic: [OAUTH-WG] proposal for factoring out request signing in OAuth 2 Thread-Index: AcsAQOuWZ8vnc+/WTui3jk2pAveNrAHWVjGA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF6E8E@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <AANLkTim-Wc3t9CkTEx2HkhRDB5eGgmqBgqaiDO25TDYB@mail.gmail.com> <AANLkTins7-cUV6Ly6mDjRYHJTuWPWWsLe3DvUbLnfPwO@mail.gmail.com> <AANLkTikjNTqsk64pC9UyMuKFHBScyNBpsgkkt0OKlU3X@mail.gmail.com> <1CD74F85-52F4-4024-9CF7-5FC6A9DBEDB0@lodderstedt.net> <AANLkTilJ5l7aOLB4CQlr7R6Br-2oqo-rFs0S5QMJAAMI@mail.gmail.com> <4C02B4AE.4000200@lodderstedt.net> <AANLkTik2dVLWQHwhlBy2YDeWxFsLxFBfBURVgC5Hv5f0@mail.gmail.com> In-Reply-To: <AANLkTik2dVLWQHwhlBy2YDeWxFsLxFBfBURVgC5Hv5f0@mail.gmail.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 <oauth@ietf.org> Subject: Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 2 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 09 Jun 2010 06:17:40 -0000 We are clearly not making any progress on signatures (for over a year). 1. I agree with Brian (it does happen on occasion) that this is an impossib= le list to turn into a single solution. 2. I'm tired of having this discussion - mostly because we are unable to ag= ree on the requirements. 3. We already decided not to mandate TLS for bearer tokens, just make it a = strong suggestion. I consider this my decision as editor (but feel free to disagree with the d= ecision or the powers I granted myself): 1. I am going to move all the signature stuff out of the core spec. 2. I am going to draft a new (individual submission) signature proposal usi= ng the current signature parameters and method. 3. I expect Brian, Dirk, and others to submit their own separate signature = proposals as individual submissions. 4. The WG can decide if any of the proposals qualify for "upgrade" to WG it= ems and the chairs can decide who will edit these if they become WG items. = The WG can also decide if any of those accepted as WG items should stay in = separate specs or merged into the core spec. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Brian Eaton > Sent: Sunday, May 30, 2010 2:42 PM > To: Torsten Lodderstedt > Cc: OAuth WG > Subject: Re: [OAUTH-WG] proposal for factoring out request signing in OAu= th > 2 >=20 > On Sun, May 30, 2010 at 11:55 AM, Torsten Lodderstedt > <torsten@lodderstedt.net> wrote: > > Regarding client secrets: One of the major obstacles when using OAuth > > 1.0 in large deployments is the need for sharing client secrets > > between authz server and resource server. Overcoming that obstacle was > > an important requirement for OAuth2 from the beginning, expressed by a > lot of people. >=20 > There are actually a bunch of fundamentally conflicting requirements for > signatures from the various folks contributing to this working group. >=20 > - no shared secrets with protected resources at all >=20 > - no permanent shared secrets with protected resources >=20 > - no shared secrets with clients >=20 > - allow access tokens to be used by multiple clients without sharing cons= umer > secrets >=20 > - don't allow access tokens to be shared by multiple clients >=20 > - don't use public key, because it's slow >=20 > - use public key, because it makes key distribution easier >=20 > - don't use cryptography at all, because it's too complicated >=20 > - don't use bearer tokens at all, because they might leak >=20 > - keep access tokens short >=20 > - encode lots of information in the access token >=20 > I'm sure I'm forgetting some. >=20 > For the record, I think *every single one* of those requirements makes > sense in certain contexts. >=20 > I'm pretty sure we're going to be able to agree on the cryptographic > primitives without too much trouble. >=20 > But we're going to have to split out profiles to deal with the different = key > distribution challenges. >=20 > Cheers, > Brian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From andrewarnott@gmail.com Tue Jun 8 23:20:58 2010 Return-Path: <andrewarnott@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6AD03A681D for <oauth@core3.amsl.com>; Tue, 8 Jun 2010 23:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.431 X-Spam-Level: X-Spam-Status: No, score=-0.431 tagged_above=-999 required=5 tests=[AWL=-0.433, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BgQroxVPiCaI for <oauth@core3.amsl.com>; Tue, 8 Jun 2010 23:20:55 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id B51A03A68E1 for <oauth@ietf.org>; Tue, 8 Jun 2010 23:20:55 -0700 (PDT) Received: by pxi19 with SMTP id 19so2356956pxi.31 for <oauth@ietf.org>; Tue, 08 Jun 2010 23:20:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=Axk67CO4nrnscRTgVerdjB9DHKWz9JhbAJxc+ujJB0k=; b=L1edWwLyxGGAk9V04Y1uZXm5MTpG8uHI0zpP7NYLvDlNiAucPiQM2nRfYP9MutEwnc gb/7Zq0p1b1xzEWVxDSccA5Rn//8Xt760FsQnftnLF+cLaCxP7bSll++P56SUrCSCami q5jdY/3z2rg4BqFJ3u8AL5DwjDWSWo+NMMXJY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=iejgbwHZZ4p93DWpG21wndJUpEK2NuDypctpeJeY7Kl+BX4ZrQMlv8R/H6KaJjmeMg Z8ZWYdeRDVMoWvj9/Q3HyNOd0ipNuVRbszP5lklqRl+WyJN3WtE7rD78NM61qcL5hjm+ akzzh941n+GLo7sQnuW7kdg0Z59Axu/ANQ74o= MIME-Version: 1.0 Received: by 10.114.251.32 with SMTP id y32mr13905294wah.149.1276064453886; Tue, 08 Jun 2010 23:20:53 -0700 (PDT) Received: by 10.115.16.10 with HTTP; Tue, 8 Jun 2010 23:20:53 -0700 (PDT) In-Reply-To: <AANLkTinVQEPBVzmiHEGgHhzaILL0nRSvZpjIlrVEJwTw@mail.gmail.com> References: <AANLkTingSGlJNZ5e_stPd1qU5I4gfbh3rQhqYUmqXvdB@mail.gmail.com> <C833CEB4.6B81%cmortimore@salesforce.com> <AANLkTinVQEPBVzmiHEGgHhzaILL0nRSvZpjIlrVEJwTw@mail.gmail.com> Date: Tue, 8 Jun 2010 23:20:53 -0700 Message-ID: <AANLkTil1j7vl8PU2tgCzlWY0U6KiWPmRKiVOxvsctB00@mail.gmail.com> From: Andrew Arnott <andrewarnott@gmail.com> To: Marius Scurtescu <mscurtescu@google.com> Content-Type: multipart/alternative; boundary=0016367f92697c022f048892e823 Cc: "oauth@ietf.org" <oauth@ietf.org> Subject: Re: [OAUTH-WG] User-agent flow and pre-registered redirect_uri X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 09 Jun 2010 06:20:59 -0000 --0016367f92697c022f048892e823 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Marius, You seem to be coming from the perspective that the auth server stores authorizations (that would eliminate the need for the user to interactively approve an authorization) based on redirect_url rather than client_id. Is that right? I've always considered an authorization as a tuple of client_id,user,scope,issue_date. If an authorization has been approved, an= d another request for authorization for a subset of the scope previously issued comes in, the auth server can skip the interactive user authorizatio= n and just approve the request since nothing new is being issued. If my tuple is correct, then the user agent flow allows any random client t= o submit a trusted client_id as if it was them, but with an evil redirect_url so they can obtain user authorization without the user noticing at all (if an authorization already existed). But if redirect_url belongs in that tuple, then that would be the mitigation I guess. But we could avoid extra user prompts if we just forced clients to register their redirect_url's in order to be enabled for user agent flows, thus protecting the user from bad clients sending in evil redirect_urls in order to steal access tokens. -- 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, Jun 8, 2010 at 11:04 AM, Marius Scurtescu <mscurtescu@google.com>wr= ote: > On Tue, Jun 8, 2010 at 10:40 AM, Chuck Mortimore > <cmortimore@salesforce.com> wrote: > > Thanks =96 I get your line of reasoning now. I believe it would still > help > > in preventing certain types of attack. These are especially apparent > > around immediate. > > I do agree that requiring registration may be a good idea in many > cases, all I am saying is that this should not be enforced. Some authz > servers may want to allow unregistered clients, and that's fine. I > think the current SHOULD is good enough and changing it to MUST would > be going too far. > > > > 1) User initially grants access to example.com > > 2) User goes to an evil site > > 3) Without the user=92s knowledge, the malicious site issues an immedia= te > > user_agent flow > > > > > https://authzserver.com/authorize?type=3Duser_agent&immediate=3Dtrue&clie= nt_id=3D > <Example.com=92s > > Client ID>&redirect_uri=3D<Evil URL> > > > > 4) Evil site is handed an access token based upon the previous grant to > > example.com > > I don't think this attack will work. If exmple.com was not registered, > then it has not client_id, so the previous approval should be > remembered for example.com's redirect_uri. Evil site needs to use its > own redirect_uri, so immediate will not work. > > > Marius > --0016367f92697c022f048892e823 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Marius,<br><br>You seem to be coming from the perspective that the auth ser= ver stores authorizations (that would eliminate the need for the user to in= teractively approve an authorization) based on redirect_url rather than cli= ent_id.=A0 Is that right?<br> <br>I've always considered an authorization as a tuple of client_id,use= r,scope,issue_date.=A0 If an authorization has been approved, and another r= equest for authorization for a subset of the scope previously issued comes = in, the auth server can skip the interactive user authorization and just ap= prove the request since nothing new is being issued.<br> <br>If my tuple is correct, then the user agent flow allows any random clie= nt to submit a trusted client_id as if it was them, but with an evil redire= ct_url so they can obtain user authorization without the user noticing at a= ll (if an authorization already existed).=A0 But if redirect_url belongs in= that tuple, then that would be the mitigation I guess.=A0 But we could avo= id extra user prompts if we just forced clients to register their redirect_= url's in order to be enabled for user agent flows, thus protecting the = user from bad clients sending in evil redirect_urls in order to steal acces= s tokens.<br> <br clear=3D"all">--<br>Andrew Arnott<br>"I [may] not agree with what = you have to say, but I'll defend to the death your right to say it.&quo= t; - S. G. Tallentyre<br> <br><br><div class=3D"gmail_quote">On Tue, Jun 8, 2010 at 11:04 AM, Marius = Scurtescu <span dir=3D"ltr"><<a href=3D"mailto:mscurtescu@google.com">ms= curtescu@google.com</a>></span> wrote:<br><blockquote class=3D"gmail_quo= te" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204= , 204); padding-left: 1ex;"> <div class=3D"im">On Tue, Jun 8, 2010 at 10:40 AM, Chuck Mortimore<br> <<a href=3D"mailto:cmortimore@salesforce.com">cmortimore@salesforce.com<= /a>> wrote:<br> > Thanks =96 I get your line of reasoning now. =A0=A0I believe it would = still help<br> > in preventing certain types of attack. =A0=A0These are especially appa= rent<br> > around immediate.<br> <br> </div>I do agree that requiring registration may be a good idea in many<br> cases, all I am saying is that this should not be enforced. Some authz<br> servers may want to allow unregistered clients, and that's fine. I<br> think the current SHOULD is good enough and changing it to MUST would<br> be going too far.<br> <div class=3D"im"><br> <br> > 1) User initially grants access to <a href=3D"http://example.com" targ= et=3D"_blank">example.com</a><br> > 2) User goes to an evil site<br> > 3) Without the user=92s knowledge, the malicious site issues an immedi= ate<br> > user_agent flow<br> ><br> > <a href=3D"https://authzserver.com/authorize?type=3Duser_agent&imm= ediate=3Dtrue&client_id=3D" target=3D"_blank">https://authzserver.com/a= uthorize?type=3Duser_agent&immediate=3Dtrue&client_id=3D</a><Exa= mple.com=92s<br> > Client ID>&redirect_uri=3D<Evil URL><br> ><br> > 4) Evil site is handed an access token based upon the previous grant t= o<br> > <a href=3D"http://example.com" target=3D"_blank">example.com</a><br> <br> </div>I don't think this attack will work. If <a href=3D"http://exmple.= com" target=3D"_blank">exmple.com</a> was not registered,<br> then it has not client_id, so the previous approval should be<br> remembered for <a href=3D"http://example.com" target=3D"_blank">example.com= </a>'s redirect_uri. Evil site needs to use its<br> own redirect_uri, so immediate will not work.<br> <font color=3D"#888888"><br> <br> Marius<br> </font></blockquote></div><br> --0016367f92697c022f048892e823-- From andrewarnott@gmail.com Tue Jun 8 23:24:30 2010 Return-Path: <andrewarnott@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBFFB3A681D for <oauth@core3.amsl.com>; Tue, 8 Jun 2010 23:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.648 X-Spam-Level: X-Spam-Status: No, score=-0.648 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hErqyJn88Zbr for <oauth@core3.amsl.com>; Tue, 8 Jun 2010 23:24:30 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 04DDE3A68DD for <oauth@ietf.org>; Tue, 8 Jun 2010 23:24:29 -0700 (PDT) Received: by pvd12 with SMTP id 12so341867pvd.31 for <oauth@ietf.org>; Tue, 08 Jun 2010 23:24:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=TbYfeUAU+de0mOpwkSX1QWr8pej+AciyEC6mmzUoh40=; b=r8YCU3H6MVrB4tPevqLdKRE9vVllgGgWfxTCaUyGJEAt479Idm9QxNg4SuN+OpI8mt 75hcL50flNE/2Z1JMMHjAIwrssJw6rvngwLo+J/ApwwqGiS3IceQPNkeWEzLyIMCPP6p oId/p+jse0nu8yP1A/NFo9IT5xFR3+ZA0fXH4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=nix2Duja/ERYEF1UMYUnB/jyACKdWGlMlAURu4OD39xfkmTywoNi9GiRTbPp97DciL cjMn1zrMTYp52V0ohnduqCTXo4kSE3wY35t+TNoP8Lr1sfOd16tYGHAwpV3j3BiH81+l PkWjnQ/B6scQ+V97SeyusZ7VWJGozNtt9/MBw= MIME-Version: 1.0 Received: by 10.115.66.33 with SMTP id t33mr552483wak.199.1276064583211; Tue, 08 Jun 2010 23:23:03 -0700 (PDT) Received: by 10.115.16.10 with HTTP; Tue, 8 Jun 2010 23:23:03 -0700 (PDT) Date: Tue, 8 Jun 2010 23:23:03 -0700 Message-ID: <AANLkTinc9wu_D81-NQYZZEFVxxFfNauLCFx3Qd-EoqSn@mail.gmail.com> From: Andrew Arnott <andrewarnott@gmail.com> To: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org> Content-Type: multipart/alternative; boundary=0016e64ce5e8315d36048892f07d Subject: [OAUTH-WG] DotNetOpenAuth preview with OAuth 2.0 support available X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 09 Jun 2010 06:24:31 -0000 --0016e64ce5e8315d36048892f07d Content-Type: text/plain; charset=ISO-8859-1 In case anyone is interested in trying out a preview build of DotNetOpenAuth that supports OAuth 2.0, they can contact me offline to arrange it. It currently features web server flow support (client, auth server and resource server), and user agent flow support (just client at the moment). The other flows are partly there, but not yet functional. I'd also be interested in hearing what you're most interested in seeing support for in the short-term that isn't listed above. Although I'm trying to only implement those areas of the spec least likely to change before it's finalized. -- 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 --0016e64ce5e8315d36048892f07d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable In case anyone is interested in trying out a preview build of DotNetOpenAut= h that supports OAuth 2.0, they can contact me offline to arrange it.<br><b= r>It currently features web server flow support (client, auth server and re= source server), and user agent flow support (just client at the moment).=A0= The other flows are partly there, but not yet functional.<br> <br>I'd also be interested in hearing what you're most interested i= n seeing support for in the short-term that isn't listed above.=A0 Alth= ough I'm trying to only implement those areas of the spec least likely = to change before it's finalized.<br clear=3D"all"> --<br>Andrew Arnott<br>"I [may] not agree with what you have to say, b= ut I'll defend to the death your right to say it." - S. G. Tallent= yre<br> --0016e64ce5e8315d36048892f07d-- From root@core3.amsl.com Wed Jun 9 00:15:02 2010 Return-Path: <root@core3.amsl.com> X-Original-To: oauth@ietf.org Delivered-To: oauth@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 796153A68D7; Wed, 9 Jun 2010 00:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100609071502.796153A68D7@core3.amsl.com> Date: Wed, 9 Jun 2010 00:15:02 -0700 (PDT) Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-06.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 09 Jun 2010 07:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Authentication Protocol Working Group of the IETF. Title : The OAuth 2.0 Protocol Author(s) : E. Hammer-Lahav, et al. Filename : draft-ietf-oauth-v2-06.txt Pages : 51 Date : 2010-06-09 This specification describes the OAuth 2.0 protocol. OAuth provides a method for making authenticated HTTP requests using a token - an string used to denote an access grant with specific scope, duration, and other attributes. Tokens are issued to third-party clients by an authorization server with the approval of the resource owner. OAuth defines multiple flows for obtaining a token to support a wide range of client types and user experience. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-oauth-v2-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-06-09000945.I-D@ietf.org> --NextPart-- From eran@hueniverse.com Wed Jun 9 00:16:54 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 697F83A6918 for <oauth@core3.amsl.com>; Wed, 9 Jun 2010 00:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ICHXcnNj9Dxj for <oauth@core3.amsl.com>; Wed, 9 Jun 2010 00:16:53 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 6EE0528C0D7 for <oauth@ietf.org>; Wed, 9 Jun 2010 00:16:53 -0700 (PDT) Received: (qmail 23536 invoked from network); 9 Jun 2010 07:16:54 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 9 Jun 2010 07:16:54 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 9 Jun 2010 00:16:54 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org> Date: Wed, 9 Jun 2010 00:16:43 -0700 Thread-Topic: draft-ietf-oauth-v2-06 Thread-Index: AcsHo7bRM8rhlrHeSOiOcYim1/yYSQ== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF6E95@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-06 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 09 Jun 2010 07:16:54 -0000 (Should show up any minute.) This is mostly pre-meeting feedback, plus some big removals of signatures a= nd discovery. o Editorial changes, corrections, clarifications, etc. o Removed conformance section. o Moved authors section to contributors appendix. o Added section on native applications. o Changed error response to use the requested format. Added support fo= r HTTP "Accept" header. o Flipped the order of the web server and user-agent flows. o Renamed assertion flow "format" parameter name to "assertion_format" = to resolve conflict. o Removed the term identifier from token definitions. Added a cryptogr= aphic token definition. o Added figure titles. o Added server response 401 when client tried to authenticate using mul= tiple credentials. o Clarified support for TLS alternatives, and added requirement for TLS= 1.2 support for token endpoint. o Removed all signature and cryptography. o Removed all discovery. o Updated HTML4 reference. There is going to be another draft this week so if you are very busy, just = wait. EHL From torsten@lodderstedt.net Wed Jun 9 00:17:32 2010 Return-Path: <torsten@lodderstedt.net> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A3E128C0D8 for <oauth@core3.amsl.com>; Wed, 9 Jun 2010 00:17:32 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8xIiVWBjLwD for <oauth@core3.amsl.com>; Wed, 9 Jun 2010 00:17:31 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.36]) by core3.amsl.com (Postfix) with ESMTP id C09FC28B23E for <oauth@ietf.org>; Wed, 9 Jun 2010 00:17:30 -0700 (PDT) Received: from p4fff1dc2.dip.t-dialin.net ([79.255.29.194] helo=[127.0.0.1]) by smtprelay02.ispgateway.de with esmtpa (Exim 4.68) (envelope-from <torsten@lodderstedt.net>) id 1OMFXV-0002XQ-Hv; Wed, 09 Jun 2010 09:17:29 +0200 Message-ID: <4C0F3FFF.2050209@lodderstedt.net> Date: Wed, 09 Jun 2010 09:17:19 +0200 From: Torsten Lodderstedt <torsten@lodderstedt.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Dirk Balfanz <balfanz@google.com> References: <AANLkTimOXzscoFDtf-PO8965xuchEBJvqALiWM3O9fMl@mail.gmail.com> In-Reply-To: <AANLkTimOXzscoFDtf-PO8965xuchEBJvqALiWM3O9fMl@mail.gmail.com> Content-Type: multipart/alternative; boundary="------------060400060100080106040700" X-Df-Sender: 141509 Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] polling in the device flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 09 Jun 2010 07:17:32 -0000 This is a multi-part message in MIME format. --------------060400060100080106040700 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit using mechanisms provided by the HTTP protocol sound reasonable to me. I see two questions: 1) Is 503 intended for that purpose? http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html says: "The server is currently unable to handle the request due to a temporary overloading or maintenance of the server" 2) Do HTTP clients supports the Retry-After header? regards, Torsten. Am 08.06.2010 22:23, schrieb Dirk Balfanz: > Hi guys, > > currently, we specify how polling should work in the device flow as > part of the OAuth2 spec. > > I would argue that that polling should be handled at a lower layer of > the stack, and that OAuth2 should be silent on the issue of polling. > The benefit will be a simpler spec. > > HTTP specifies the 503 response code with the (optional) Retry-After > response header. ASs could just use that mechanism to throttle > clients, instead of handling it at the OAuth layer. > > The OAuth spec could say something like: "The client requests the > access token after the user approves or rejects authorization. If the > client cannot determine when the user has approved or rejected the > authorization, the client MAY poll the server. The server MAY use > throttling mechanisms such as 503 HTTP response codes and Retry-After > response headers which, if used, the client MUST obey." > > What do you guys think? > > BTW, there is some precedence for this. Google's APIs use 503 response > codes to throttle servers, e.g. > http://code.google.com/googleapps/domain/gdata_provisioning_api_v2.0_reference.html > > Dirk. > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --------------060400060100080106040700 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> <title> using mechanisms provided by the HTTP protocol sound reasonable to me.

I see two questions:

1) Is 503 intended for that purpose? http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html says: "The server is currently unable to handle the request due to a temporary overloading or maintenance of the server"
2) Do HTTP clients supports the Retry-After header?

regards,
Torsten.

Am 08.06.2010 22:23, schrieb Dirk Balfanz:
Hi guys,

currently, we specify how polling should work in the device flow as part of the OAuth2 spec.

I would argue that that polling should be handled at a lower layer of the stack, and that OAuth2 should be silent on the issue of polling. The benefit will be a simpler spec.

HTTP specifies the 503 response code with the (optional) Retry-After response header. ASs could just use that mechanism to throttle clients, instead of handling it at the OAuth layer.

The OAuth spec could say something like: "The client requests the access token after the user approves or rejects authorization. If the client cannot determine when the user has approved or rejected the authorization, the client MAY poll the server. The server MAY use throttling mechanisms such as 503 HTTP response codes and Retry-After response headers which, if used, the client MUST obey."

What do you guys think?

BTW, there is some precedence for this. Google's APIs use 503 response codes to throttle servers, e.g. http://code.google.com/googleapps/domain/gdata_provisioning_api_v2.0_reference.html

Dirk.


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--------------060400060100080106040700-- From James.H.Manger@team.telstra.com Wed Jun 9 00:30:27 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BEAC3A691A for ; Wed, 9 Jun 2010 00:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.311 X-Spam-Level: ** X-Spam-Status: No, score=2.311 tagged_above=-999 required=5 tests=[AWL=-0.613, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_AU=0.377, HTML_MESSAGE=0.001, RDNS_NONE=0.1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qx4IxBQUsymI for ; Wed, 9 Jun 2010 00:30:01 -0700 (PDT) Received: from ipxbvo.tcif.telstra.com.au (unknown [203.35.135.204]) by core3.amsl.com (Postfix) with ESMTP id 6DEFC3A6907 for ; Wed, 9 Jun 2010 00:30:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,389,1272808800"; d="scan'208,217";a="4044741" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipobvi.tcif.telstra.com.au with ESMTP; 09 Jun 2010 17:29:56 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6007"; a="3007223" Received: from wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) by ipcdvi.tcif.telstra.com.au with ESMTP; 09 Jun 2010 17:29:57 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) with mapi; Wed, 9 Jun 2010 17:29:56 +1000 From: "Manger, James H" To: Torsten Lodderstedt , Dirk Balfanz Date: Wed, 9 Jun 2010 17:29:55 +1000 Thread-Topic: [OAUTH-WG] polling in the device flow Thread-Index: AcsHo9laAfx079cPSM+mCFS2fVjH1QAAHa1A Message-ID: <255B9BB34FB7D647A506DC292726F6E11263F7B9FB@WSMSG3153V.srv.dir.telstra.com> References: <4C0F3FFF.2050209@lodderstedt.net> In-Reply-To: <4C0F3FFF.2050209@lodderstedt.net> 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: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E11263F7B9FBWSMSG3153Vsrv_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] polling in the device flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 07:30:27 -0000 --_000_255B9BB34FB7D647A506DC292726F6E11263F7B9FBWSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmlnaHQgb24gY3VlIGEgbmV3IGludGVybmV0LWRyYWZ0IGNvdmVyaW5nIHRoZSBIVFRQIHBvbGxp bmcgaXNzdWUgaGFzIGp1c3QgYXBwZWFyZWQ6DQoNCg0KDQogIEh5cGVydGV4dCBUcmFuc2ZlciBQ cm90b2NvbCAoSFRUUCkgVGltZW91dHM8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt bG9yZXRvLWh0dHAtdGltZW91dD4NCg0KICBkcmFmdC1sb3JldG8taHR0cC10aW1lb3V0IFtKdW5l IDIwMTBdDQoNCg0KDQpTZWUgYWxzbzoNCg0KICBCZXN0IFByYWN0aWNlcyBmb3IgdGhlIFVzZSBv ZiBMb25nIFBvbGxpbmcgYW5kIFN0cmVhbWluZyBpbiBCaWRpcmVjdGlvbmFsIEhUVFA8aHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbG9yZXRvLWh0dHAtYmlkaXJlY3Rpb25hbD4NCg0K ICBkcmFmdC1sb3JldG8taHR0cC1iaWRpcmVjdGlvbmFsIFtGZWIgMjAxMF0NCg0KDQoNCi0tDQoN CkphbWVzIE1hbmdlcg0KDQoNCg0KQW0gMDguMDYuMjAxMCAyMjoyMywgc2NocmllYiBEaXJrIEJh bGZhbno6DQoNCkhpIGd1eXMsDQoNCmN1cnJlbnRseSwgd2Ugc3BlY2lmeSBob3cgcG9sbGluZyBz aG91bGQgd29yayBpbiB0aGUgZGV2aWNlIGZsb3cgYXMgcGFydCBvZiB0aGUgT0F1dGgyIHNwZWMu DQoNCkkgd291bGQgYXJndWUgdGhhdCB0aGF0IHBvbGxpbmcgc2hvdWxkIGJlIGhhbmRsZWQgYXQg YSBsb3dlciBsYXllciBvZiB0aGUgc3RhY2ssIGFuZCB0aGF0IE9BdXRoMiBzaG91bGQgYmUgc2ls ZW50IG9uIHRoZSBpc3N1ZSBvZiBwb2xsaW5nLiBUaGUgYmVuZWZpdCB3aWxsIGJlIGEgc2ltcGxl ciBzcGVjLg0KDQpIVFRQIHNwZWNpZmllcyB0aGUgNTAzIHJlc3BvbnNlIGNvZGUgd2l0aCB0aGUg KG9wdGlvbmFsKSBSZXRyeS1BZnRlciByZXNwb25zZSBoZWFkZXIuIEFTcyBjb3VsZCBqdXN0IHVz ZSB0aGF0IG1lY2hhbmlzbSB0byB0aHJvdHRsZSBjbGllbnRzLCBpbnN0ZWFkIG9mIGhhbmRsaW5n IGl0IGF0IHRoZSBPQXV0aCBsYXllci4NCg0KVGhlIE9BdXRoIHNwZWMgY291bGQgc2F5IHNvbWV0 aGluZyBsaWtlOiAiVGhlIGNsaWVudCByZXF1ZXN0cyB0aGUgYWNjZXNzIHRva2VuIGFmdGVyIHRo ZSB1c2VyIGFwcHJvdmVzIG9yIHJlamVjdHMgYXV0aG9yaXphdGlvbi4gSWYgdGhlIGNsaWVudCBj YW5ub3QgZGV0ZXJtaW5lIHdoZW4gdGhlIHVzZXIgaGFzIGFwcHJvdmVkIG9yIHJlamVjdGVkIHRo ZSBhdXRob3JpemF0aW9uLCB0aGUgY2xpZW50IE1BWSBwb2xsIHRoZSBzZXJ2ZXIuIFRoZSBzZXJ2 ZXIgTUFZIHVzZSB0aHJvdHRsaW5nIG1lY2hhbmlzbXMgc3VjaCBhcyA1MDMgSFRUUCByZXNwb25z ZSBjb2RlcyBhbmQgUmV0cnktQWZ0ZXIgcmVzcG9uc2UgaGVhZGVycyB3aGljaCwgaWYgdXNlZCwg dGhlIGNsaWVudCBNVVNUIG9iZXkuIg0KDQpXaGF0IGRvIHlvdSBndXlzIHRoaW5rPw0KDQpCVFcs IHRoZXJlIGlzIHNvbWUgcHJlY2VkZW5jZSBmb3IgdGhpcy4gR29vZ2xlJ3MgQVBJcyB1c2UgNTAz IHJlc3BvbnNlIGNvZGVzIHRvIHRocm90dGxlIHNlcnZlcnMsIGUuZy4gaHR0cDovL2NvZGUuZ29v Z2xlLmNvbS9nb29nbGVhcHBzL2RvbWFpbi9nZGF0YV9wcm92aXNpb25pbmdfYXBpX3YyLjBfcmVm ZXJlbmNlLmh0bWwNCg0KRGlyay4NCg0KDQoNCg== --_000_255B9BB34FB7D647A506DC292726F6E11263F7B9FBWSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl Pg0KPCEtLQ0KIC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCiBAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6 MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KIC8qIFN0eWxlIERlZmluaXRpb25zICovDQogcC5Nc29O b3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dl ZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNv LXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5 OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFNlY3Rpb24xDQoJe3NpemU6 NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0K ZGl2LlNlY3Rpb24xDQoJe3BhZ2U6U2VjdGlvbjE7fQ0KLS0+DQo8L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQogIDxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KIDwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1BVSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj5SaWdodCBvbiBjdWUgYSBuZXcgaW50 ZXJuZXQtZHJhZnQgY292ZXJpbmcgdGhlIEhUVFAgcG9sbGluZyBpc3N1ZSBoYXMganVzdCBhcHBl YXJlZDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7DQpjb2xvcjojMUY0OTdEIj4mbmJzcDsNCjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWxvcmV0by1odHRwLXRpbWVvdXQiPkh5cGVydGV4dCBUcmFuc2ZlciBQcm90 b2NvbCAoSFRUUCkgVGltZW91dHM8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+ Jm5ic3A7IGRyYWZ0LWxvcmV0by1odHRwLXRpbWVvdXQgW0p1bmUgMjAxMF08bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7DQpjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdE Ij5TZWUgYWxzbzo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj4mbmJzcDsNCjxhIGhy ZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxvcmV0by1odHRwLWJpZGlyZWN0 aW9uYWwiPkJlc3QgUHJhY3RpY2VzIGZvciB0aGUgVXNlIG9mIExvbmcgUG9sbGluZyBhbmQgU3Ry ZWFtaW5nIGluIEJpZGlyZWN0aW9uYWwgSFRUUDwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjoj MUY0OTdEIj4mbmJzcDsgZHJhZnQtbG9yZXRvLWh0dHAtYmlkaXJlY3Rpb25hbCBbRmViIDIwMTBd PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OzsNCmNvbG9yOiMxRjQ5N0QiPi0tDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdE Ij5KYW1lcyBNYW5nZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPkFtIDA4LjA2LjIwMTAgMjI6MjMsIHNjaHJpZWIgRGlyayBCYWxm YW56Og0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij5IaSBndXlzLCA8YnI+DQo8YnI+DQpjdXJyZW50bHksIHdlIHNwZWNpZnkg aG93IHBvbGxpbmcgc2hvdWxkIHdvcmsgaW4gdGhlIGRldmljZSBmbG93IGFzIHBhcnQgb2YgdGhl IE9BdXRoMiBzcGVjLjxicj4NCjxicj4NCkkgd291bGQgYXJndWUgdGhhdCB0aGF0IHBvbGxpbmcg c2hvdWxkIGJlIGhhbmRsZWQgYXQgYSBsb3dlciBsYXllciBvZiB0aGUgc3RhY2ssIGFuZCB0aGF0 IE9BdXRoMiBzaG91bGQgYmUgc2lsZW50IG9uIHRoZSBpc3N1ZSBvZiBwb2xsaW5nLiBUaGUgYmVu ZWZpdCB3aWxsIGJlIGEgc2ltcGxlciBzcGVjLjxicj4NCjxicj4NCkhUVFAgc3BlY2lmaWVzIHRo ZSA1MDMgcmVzcG9uc2UgY29kZSB3aXRoIHRoZSAob3B0aW9uYWwpIFJldHJ5LUFmdGVyIHJlc3Bv bnNlIGhlYWRlci4gQVNzIGNvdWxkIGp1c3QgdXNlIHRoYXQgbWVjaGFuaXNtIHRvIHRocm90dGxl IGNsaWVudHMsIGluc3RlYWQgb2YgaGFuZGxpbmcgaXQgYXQgdGhlIE9BdXRoIGxheWVyLg0KPGJy Pg0KPGJyPg0KVGhlIE9BdXRoIHNwZWMgY291bGQgc2F5IHNvbWV0aGluZyBsaWtlOiAmcXVvdDtU aGUgY2xpZW50IHJlcXVlc3RzIHRoZSBhY2Nlc3MgdG9rZW4gYWZ0ZXIgdGhlIHVzZXIgYXBwcm92 ZXMgb3IgcmVqZWN0cyBhdXRob3JpemF0aW9uLiBJZiB0aGUgY2xpZW50IGNhbm5vdCBkZXRlcm1p bmUgd2hlbiB0aGUgdXNlciBoYXMgYXBwcm92ZWQgb3IgcmVqZWN0ZWQgdGhlIGF1dGhvcml6YXRp b24sIHRoZSBjbGllbnQgTUFZIHBvbGwgdGhlIHNlcnZlci4gVGhlIHNlcnZlcg0KIE1BWSB1c2Ug dGhyb3R0bGluZyBtZWNoYW5pc21zIHN1Y2ggYXMgNTAzIEhUVFAgcmVzcG9uc2UgY29kZXMgYW5k IFJldHJ5LUFmdGVyIHJlc3BvbnNlIGhlYWRlcnMgd2hpY2gsIGlmIHVzZWQsIHRoZSBjbGllbnQg TVVTVCBvYmV5LiZxdW90Ozxicj4NCjxicj4NCldoYXQgZG8geW91IGd1eXMgdGhpbms/PGJyPg0K PGJyPg0KQlRXLCB0aGVyZSBpcyBzb21lIHByZWNlZGVuY2UgZm9yIHRoaXMuIEdvb2dsZSdzIEFQ SXMgdXNlIDUwMyByZXNwb25zZSBjb2RlcyB0byB0aHJvdHRsZSBzZXJ2ZXJzLCBlLmcuDQo8YSBo cmVmPSJodHRwOi8vY29kZS5nb29nbGUuY29tL2dvb2dsZWFwcHMvZG9tYWluL2dkYXRhX3Byb3Zp c2lvbmluZ19hcGlfdjIuMF9yZWZlcmVuY2UuaHRtbCI+DQpodHRwOi8vY29kZS5nb29nbGUuY29t L2dvb2dsZWFwcHMvZG9tYWluL2dkYXRhX3Byb3Zpc2lvbmluZ19hcGlfdjIuMF9yZWZlcmVuY2Uu aHRtbDwvYT48YnI+DQo8YnI+DQpEaXJrLjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_255B9BB34FB7D647A506DC292726F6E11263F7B9FBWSMSG3153Vsrv_-- From torsten@lodderstedt.net Wed Jun 9 00:42:38 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85AB828C0D9 for ; Wed, 9 Jun 2010 00:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.042 X-Spam-Level: X-Spam-Status: No, score=-1.042 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2blbzbE53ZaB for ; Wed, 9 Jun 2010 00:42:37 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.27]) by core3.amsl.com (Postfix) with ESMTP id 426203A6916 for ; Wed, 9 Jun 2010 00:42:36 -0700 (PDT) Received: from p4fff1dc2.dip.t-dialin.net ([79.255.29.194] helo=[127.0.0.1]) by smtprelay04.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OMFvp-0000VG-62; Wed, 09 Jun 2010 09:42:37 +0200 Message-ID: <4C0F45EC.4050707@lodderstedt.net> Date: Wed, 09 Jun 2010 09:42:36 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Marius Scurtescu References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] native app support (was: Next draft) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 07:42:38 -0000 1) +1 2) +1 - Oauth 1.0a had "oob", why not for that purpose 3) I would rather add the user_code as optional URL parameter to the device flow. 4) What about an additional best practices document? regards, Torsten. Am 08.06.2010 19:46, schrieb Marius Scurtescu: > In order to properly support native applications I suggest the > following changes: > > 1. client_name > > In all flows when client_id is sent also allow for an optional > client_name. This optional parameter is meant as a display name for > the client, and it is useful in all unregistered cases, not only for > native apps. > > If the client is unregistered then most likely the authz server will > require that client_id be set to a predefined value like "anonymous". > The approval page does need a client name so it can tell the user who > it is granting access for. > > > 2. optional redirect_uri (default result page) > > Some native apps do not have a redirect_uri, as a result two things are needed: > > 2.1 Either make redirect_uri optional or define a standard value that > signals that the client does not have such a page. > > 2.2 The authz server must supply a default result page, if there is no > redirect_uri. Also, this page should put the verification code and the > client state (code and state) in the page title in a standard way such > that the native app can extract them from the window title. WRAP > defined how the title should be formed. > > > 3. device flow should be able to start user-agent > > The device flow can be used by native apps in which case there is a > browser on the device. This flow should be able to start a browser and > directly take the user to the end-user verification URI with the user > code added as a query parameter (so the user is not required to do any > manual entry). This is sort of possible right now, but the handler > behind verification_uri must expect an optional user_code (in which > case it should not prompt the user). > > > 4. section with guidance for native apps > > I think the spec needs a section that explains how native apps can be > used with OAuth 2. Not sure if it is worth getting into pros and cons > for each flow, but all flows can be used. > > > Marius > > > > On Mon, Jun 7, 2010 at 8:44 AM, Eran Hammer-Lahav wrote: > >> I still need to catch up on the list (I took a little break). I plan to post a new draft this week incorporating many editorial changes discussed at the interim meeting. I am also planning of removing some non-stable features (such as discovery and signatures) from the draft and moving them to new drafts. As soon as -06 is published, I plan to issue informal last-calls for each section so that we can lock down the normative portions of the draft. >> >> If you have any must-happen changes for -05 that were not already posted to the list, please let me know. >> >> 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 torsten@lodderstedt.net Wed Jun 9 00:58:58 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEB853A691A for ; Wed, 9 Jun 2010 00:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.345 X-Spam-Level: X-Spam-Status: No, score=-0.345 tagged_above=-999 required=5 tests=[AWL=-0.697, BAYES_50=0.001, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jWFs9hgVmcUi for ; Wed, 9 Jun 2010 00:58:58 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.38]) by core3.amsl.com (Postfix) with ESMTP id 886453A691B for ; Wed, 9 Jun 2010 00:58:57 -0700 (PDT) Received: from p4fff1dc2.dip.t-dialin.net ([79.255.29.194] helo=[127.0.0.1]) by smtprelay04.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OMGBY-0004Pm-31; Wed, 09 Jun 2010 09:58:52 +0200 Message-ID: <4C0F49BB.3030706@lodderstedt.net> Date: Wed, 09 Jun 2010 09:58:51 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Manger, James H" References: <4C0F3FFF.2050209@lodderstedt.net> <255B9BB34FB7D647A506DC292726F6E11263F7B9FB@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11263F7B9FB@WSMSG3153V.srv.dir.telstra.com> Content-Type: multipart/alternative; boundary="------------010200040501020401040000" X-Df-Sender: 141509 Cc: OAuth WG Subject: Re: [OAUTH-WG] polling in the device flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 07:58:59 -0000 This is a multi-part message in MIME format. --------------010200040501020401040000 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit What conclusions would you draw from this internet-draft? Shall we move for long polling and "Timeout" headers? regards, Torsten. Am 09.06.2010 09:29, schrieb Manger, James H: > > Right on cue a new internet-draft covering the HTTP polling issue has > just appeared: > > Hypertext Transfer Protocol (HTTP) Timeouts > > > draft-loreto-http-timeout [June 2010] > > See also: > > Best Practices for the Use of Long Polling and Streaming in > Bidirectional HTTP > > > draft-loreto-http-bidirectional [Feb 2010] > > -- > > James Manger > > Am 08.06.2010 22:23, schrieb Dirk Balfanz: > > Hi guys, > > currently, we specify how polling should work in the device flow as > part of the OAuth2 spec. > > I would argue that that polling should be handled at a lower layer of > the stack, and that OAuth2 should be silent on the issue of polling. > The benefit will be a simpler spec. > > HTTP specifies the 503 response code with the (optional) Retry-After > response header. ASs could just use that mechanism to throttle > clients, instead of handling it at the OAuth layer. > > The OAuth spec could say something like: "The client requests the > access token after the user approves or rejects authorization. If the > client cannot determine when the user has approved or rejected the > authorization, the client MAY poll the server. The server MAY use > throttling mechanisms such as 503 HTTP response codes and Retry-After > response headers which, if used, the client MUST obey." > > What do you guys think? > > BTW, there is some precedence for this. Google's APIs use 503 response > codes to throttle servers, e.g. > http://code.google.com/googleapps/domain/gdata_provisioning_api_v2.0_reference.html > > Dirk. > --------------010200040501020401040000 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit What conclusions would you draw from this internet-draft? Shall we move for long polling and "Timeout" headers?

regards,
Torsten.

Am 09.06.2010 09:29, schrieb Manger, James H:

Right on cue a new internet-draft covering the HTTP polling issue has just appeared:

 

  Hypertext Transfer Protocol (HTTP) Timeouts

  draft-loreto-http-timeout [June 2010]

 

See also:

  Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP

  draft-loreto-http-bidirectional [Feb 2010]

 

--

James Manger

 

Am 08.06.2010 22:23, schrieb Dirk Balfanz:

Hi guys,

currently, we specify how polling should work in the device flow as part of the OAuth2 spec.

I would argue that that polling should be handled at a lower layer of the stack, and that OAuth2 should be silent on the issue of polling. The benefit will be a simpler spec.

HTTP specifies the 503 response code with the (optional) Retry-After response header. ASs could just use that mechanism to throttle clients, instead of handling it at the OAuth layer.

The OAuth spec could say something like: "The client requests the access token after the user approves or rejects authorization. If the client cannot determine when the user has approved or rejected the authorization, the client MAY poll the server. The server MAY use throttling mechanisms such as 503 HTTP response codes and Retry-After response headers which, if used, the client MUST obey."

What do you guys think?

BTW, there is some precedence for this. Google's APIs use 503 response codes to throttle servers, e.g. http://code.google.com/googleapps/domain/gdata_provisioning_api_v2.0_reference.html

Dirk.

--------------010200040501020401040000-- From torsten@lodderstedt.net Wed Jun 9 03:19:17 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EED9D28C0E3 for ; Wed, 9 Jun 2010 03:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.113 X-Spam-Level: X-Spam-Status: No, score=-0.113 tagged_above=-999 required=5 tests=[AWL=-0.464, BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29RlZXae817h for ; Wed, 9 Jun 2010 03:19:11 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.41]) by core3.amsl.com (Postfix) with ESMTP id 024263A6963 for ; Wed, 9 Jun 2010 03:19:10 -0700 (PDT) Received: from p4fff1dc2.dip.t-dialin.net ([79.255.29.194] helo=[127.0.0.1]) by smtprelay03.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OMINJ-0004fj-CE for oauth@ietf.org; Wed, 09 Jun 2010 12:19:09 +0200 Message-ID: <4C0F6A9C.2060607@lodderstedt.net> Date: Wed, 09 Jun 2010 12:19:08 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "OAuth WG (oauth@ietf.org)" References: <4BFAA6AB.8040809@lodderstedt.net> <4BFC3142.6010506@lodderstedt.net> <4BFC371A.5040109@lodderstedt.net> <4C07F407.4050305@lodderstedt.net> <1275663845.7068.94.camel@localhost.localdomain> <4C09732B.5040800@lodderstedt.net> In-Reply-To: <4C09732B.5040800@lodderstedt.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Subject: [OAUTH-WG] proposal: multiple access tokens from a single authorization flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 10:19:17 -0000 Hi all, I would like to see support in OAuth2 for the authorization of arbitrary scopes in a single authorization flow for all kinds of deployments. In some deployments this may require to issue multiple access tokens at once. Therefore, I would like to propose the following addition to section 2.3.2.1. (Access Token Response): Add an optional parameter "additional_access_tokens". additional_access_tokens OPTIONAL. Array of access tokens issued by the authorization server along with respective expiration and scope. Used if the authorization server decides to issue more than one access token. The scopes of the different tokens may not overlap. Example: HTTP/1.1 200 OK Content-Type: application/json Cache-Control: no-store { "access_token":"SlAV32hkKG", "expires_in":3600, "refresh_token":"8xLOxBtZp8", scope:"https://imap.example.com", additional_access_tokens:[ { "access_token":"SlAV32hkKG2", "expires_in":3600, scope:"https://sip.example.com" }, { "access_token":"SlAV32hkKG3", "expires_in":3600, scope:"https://contacts.example.com/read" }, { "access_token":"SlAV32hkKG4", "expires_in":3600, scope:"https://webdav.example.com/read" } ] } --- Some motivation --- I think we will see more and more clients integrating different end-user services (like mashups). Based on the current draft, some OAuth authorization servers may not be able to support such clients with an acceptable user experiences. Suppose a communication client integrating the following services: - e-Mail via IMAP - Voice over IP using the SIP protocol - Contacts via SyncML over HTTP - Webstorage access (e.g. for e-Mail attachments) using HTTP/WebDAV For a particular end-user, the client may discover that all of the end-user's services rely on the same OAuth2-based authorization server because they are provided by the same organization (e.g. an isp or a telco). The services are distinguished at the authorization server by different scopes (probably including permissions as well), e.g. : imap - https://imap.example.com sip - https://sip.example.com contacts - https://contacts.example.com/read webstorage - https://contacts.example.com/read Some providers may want to issue different service-specific tokens in such a setup (Deutsche Telekom does it already), for the following reasons: 1) Security a) minimize impact of token abuse - tokens may leak in many ways, e.g. through log files, proxies or HTTP referer. If a provider just uses a single token for all services, the impact of token leakage is much higher. For example, if a token gets exposed by the _contacts_ service via HTTP referer, an adversary may place long-distance calls using that token on the _VoIP_ service at the expense of the end-user. This threat holds for all kinds of tokens (handles and self-contained tokens). b) use a shared secret between authz server and a single service only - a major critism from the operational security perspective to OAuth 1.0a was the need to spread client secrets to resource servers. Using the same shared secret to sign/encrypt tokens for different services is a comparable problem. This aspect is relevant for self-contained tokens, only. 2) Privacy - the provider wants to restrict access of services to personal data to the data a particular service is allowed and authorized to see. This is good style (IMHO), it might also be required by law (e.g. German Federal Data Protection Act). This aspect is relevant for self-contained tokens, only. 3) Bandwith efficiency - putting only the data required by the services into the token saves bandwith. This aspect is relevant for self-contained tokens, only. In my opinion, most of these aspects are just a consequence of the decoupling of authorization server and resource server(s) in OAuth2. If a single authorization server is responsible for several resource servers, it has to ensure privacy protection and prevention of token abuse for all of its services. This should also include some separation between services, no matter if one uses self-contained tokens or handles. Without the change I proposed, the authorization server in the example scenario would need to force the client to perform _four_ subsequent authorization flows in order to obtain all required tokens. Moreover, the client would need to manage four refresh tokens. I would kindly ask you to support my proposal. In my opinion, it significantly improves the applicability of OAuth2 while the change to the current draft is minimal. Moreover, deployments w/o the need to issue multiple tokens are not affected at all. Any thoughts? regards, Torsten. From hardjono@mit.edu Wed Jun 9 06:30:37 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 630883A6879 for ; Wed, 9 Jun 2010 06:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.925 X-Spam-Level: X-Spam-Status: No, score=-0.925 tagged_above=-999 required=5 tests=[AWL=-0.186, BAYES_20=-0.74, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29sAdZWMktwW for ; Wed, 9 Jun 2010 06:30:36 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (DMZ-MAILSEC-SCANNER-1.MIT.EDU [18.9.25.12]) by core3.amsl.com (Postfix) with ESMTP id CB9FC3A6837 for ; Wed, 9 Jun 2010 06:30:35 -0700 (PDT) X-AuditID: 1209190c-b7bd2ae000005d05-44-4c0f977c4c92 Received: from mailhub-auth-1.mit.edu (MAILHUB-AUTH-1.MIT.EDU [18.9.21.35]) by dmz-mailsec-scanner-1.mit.edu (Symantec Brightmail Gateway) with SMTP id 82.62.23813.C779F0C4; Wed, 9 Jun 2010 09:30:36 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-EXCHANGE-2.MIT.EDU [18.9.28.16]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id o59DUaE3002885; Wed, 9 Jun 2010 09:30:36 -0400 Received: from oc11exedge1.exchange.mit.edu (OC11EXEDGE1.EXCHANGE.MIT.EDU [18.9.3.17]) ) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id o59DUYKp031923; Wed, 9 Jun 2010 09:30:35 -0400 Received: from oc11exhub5.exchange.mit.edu (18.9.3.15) by oc11exedge1.exchange.mit.edu (18.9.3.17) with Microsoft SMTP Server (TLS) id 8.1.393.1; Wed, 9 Jun 2010 09:30:04 -0400 Received: from EXPO10.exchange.mit.edu ([18.9.4.15]) by oc11exhub5.exchange.mit.edu ([18.9.3.15]) with mapi; Wed, 9 Jun 2010 09:30:35 -0400 From: Thomas Hardjono To: Eran Hammer-Lahav , "OAuth WG (oauth@ietf.org)" Date: Wed, 9 Jun 2010 09:30:33 -0400 Thread-Topic: draft-ietf-oauth-v2-06 Thread-Index: AcsHo7bRM8rhlrHeSOiOcYim1/yYSQAM740g Message-ID: References: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF6E95@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF6E95@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-Brightmail-Tracker: AAAAAA== Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-06 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 13:30:37 -0000 Is there a diff version of this draft (eg. a marked PDF say)? ps. I know the IETF doesn't do PDFs, but I thought I'd ask anyways :) /thomas/ __________________________________________ > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of > Eran Hammer-Lahav > Sent: Wednesday, June 09, 2010 3:17 AM > To: OAuth WG (oauth@ietf.org) > Subject: [OAUTH-WG] draft-ietf-oauth-v2-06 >=20 > (Should show up any minute.) >=20 > This is mostly pre-meeting feedback, plus some big removals of signatures= and > discovery. >=20 > o Editorial changes, corrections, clarifications, etc. > o Removed conformance section. > o Moved authors section to contributors appendix. > o Added section on native applications. > o Changed error response to use the requested format. Added support = for > HTTP "Accept" header. > o Flipped the order of the web server and user-agent flows. > o Renamed assertion flow "format" parameter name to "assertion_format= " to > resolve conflict. > o Removed the term identifier from token definitions. Added a > cryptographic token definition. > o Added figure titles. > o Added server response 401 when client tried to authenticate using > multiple credentials. > o Clarified support for TLS alternatives, and added requirement for T= LS > 1.2 support for token endpoint. > o Removed all signature and cryptography. > o Removed all discovery. > o Updated HTML4 reference. >=20 > There is going to be another draft this week so if you are very busy, jus= t > wait. >=20 > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From stpeter@stpeter.im Wed Jun 9 07:03:30 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F0B43A6974 for ; Wed, 9 Jun 2010 07:03:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QbOTgucHlCkl for ; Wed, 9 Jun 2010 07:03:28 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 8FB7D3A679F for ; Wed, 9 Jun 2010 07:03:28 -0700 (PDT) Received: from squire.local (dsl-228-47.dynamic-dsl.frii.net [216.17.228.47]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 637CF40CFD for ; Wed, 9 Jun 2010 08:03:29 -0600 (MDT) Message-ID: <4C0F9F30.9080407@stpeter.im> Date: Wed, 09 Jun 2010 08:03:28 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: oauth@ietf.org References: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF6E95@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070308000605060201050301" Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-06 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 14:03:30 -0000 This is a cryptographically signed message in MIME format. --------------ms070308000605060201050301 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 6/9/10 7:30 AM, Thomas Hardjono wrote: > Is there a diff version of this draft (eg. a marked PDF say)? Check the two "diff" links at the top of the page here: http://tools.ietf.org/html/draft-ietf-oauth-v2-06 /psa --------------ms070308000605060201050301 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDYwOTE0MDMyOFowIwYJKoZIhvcNAQkEMRYEFMP/2GejrnILG+EOejsv sqZn5qXpMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEABRvt4p2Mw2KERo4J6EL8kHpFWPoVcYdHGDS3X6qQ vfPi6/pHgDVNjSbhhOOiSy5Pojn010MRCj7/DZ7zeiKmtObSzikVXgL21nTE/j+GVIi/tJbk ZPpS79YN+VxHezzhVjeADFFtL4AQZ/A8yjDOphEqhEHqqjz2ADAdKIOr5a1V9CmDIu74WZfk c1fLkQ14GGlSGIczFNt/WUzPuMvE8bb/Ya44F1mHDL1tVvFwdlWGyyvdVHEK5QL52pfOa9I9 YYKAOwvw6hOa8kjO7wyx+F8OxU6RZOQn5gNqGGLCo/js7z9YuB/yquyUdgKsIv2NLT6vkO8W 3YjboFH6QBXChwAAAAAAAA== --------------ms070308000605060201050301-- From James.H.Manger@team.telstra.com Wed Jun 9 07:06:32 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 023483A6981 for ; Wed, 9 Jun 2010 07:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.852 X-Spam-Level: * X-Spam-Status: No, score=1.852 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_50=0.001, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1vlH9T7yDtIg for ; Wed, 9 Jun 2010 07:06:30 -0700 (PDT) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by core3.amsl.com (Postfix) with ESMTP id E9D573A690C for ; Wed, 9 Jun 2010 07:06:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,391,1272808800"; d="scan'208,217";a="4064293" Received: from unknown (HELO ipccni.tcif.telstra.com.au) ([10.97.216.208]) by ipobni.tcif.telstra.com.au with ESMTP; 10 Jun 2010 00:06:28 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6007"; a="3123406" Received: from wsmsg3702.srv.dir.telstra.com ([172.49.40.170]) by ipccni.tcif.telstra.com.au with ESMTP; 10 Jun 2010 00:06:29 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3702.srv.dir.telstra.com ([172.49.40.170]) with mapi; Thu, 10 Jun 2010 00:06:29 +1000 From: "Manger, James H" To: Torsten Lodderstedt Date: Thu, 10 Jun 2010 00:06:27 +1000 Thread-Topic: [OAUTH-WG] polling in the device flow Thread-Index: AcsHqaGAjmAvsrqySnGklTJk9sFqAQAMmabg Message-ID: <255B9BB34FB7D647A506DC292726F6E11263F7BAD2@WSMSG3153V.srv.dir.telstra.com> References: <4C0F3FFF.2050209@lodderstedt.net> <255B9BB34FB7D647A506DC292726F6E11263F7B9FB@WSMSG3153V.srv.dir.telstra.com> <4C0F49BB.3030706@lodderstedt.net> In-Reply-To: <4C0F49BB.3030706@lodderstedt.net> 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: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E11263F7BAD2WSMSG3153Vsrv_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] polling in the device flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 14:06:32 -0000 --_000_255B9BB34FB7D647A506DC292726F6E11263F7BAD2WSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBXaGF0IGNvbmNsdXNpb25zIHdvdWxkIHlvdSBkcmF3IGZyb20gdGhpcyBpbnRlcm5ldC1kcmFm dD8NCg0KPiBTaGFsbCB3ZSBtb3ZlIGZvciBsb25nIHBvbGxpbmcgYW5kICJUaW1lb3V0IiBoZWFk ZXJzPw0KDQoNCg0KSSBoYXZlIG5vdCBiZWVuIGZvbGxvd2luZyB0aGUgcG9sbGluZyBpc3N1ZSBk ZWVwbHksIGJ1dCBJIGFncmVlIHdpdGggRGlyayB0aGF0IE9BdXRoMiBzaG91bGQgdHJ5IGxlYXZl IHRoZSBwb2xsaW5nIGlzc3VlIHRvIG90aGVyIHNwZWNzIGFzIG11Y2ggYXMgcG9zc2libGUuDQoN ClN1Z2dlc3RpbmcgbG9uZyBwb2xsaW5nIGJlIHVzZWQsIHdpdGggYSAoaW5mb3JtYXRpdmUpIHJl ZmVyZW5jZSB0byB0aG9zZSAyIGRyYWZ0cywgd291bGQgYmUgYSBkZWNlbnQgc29sdXRpb24gZm9y IE9BdXRoMi4NCg0KDQoNCi0tDQoNCkphbWVzIE1hbmdlcg0KDQoNCg0KRnJvbTogVG9yc3RlbiBM b2RkZXJzdGVkdCBbbWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0XQ0KU2VudDogV2VkbmVz ZGF5LCA5IEp1bmUgMjAxMCA1OjU5IFBNDQpUbzogTWFuZ2VyLCBKYW1lcyBIDQpDYzogRGlyayBC YWxmYW56OyBPQXV0aCBXRw0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gcG9sbGluZyBpbiB0aGUg ZGV2aWNlIGZsb3cNCg0KDQoNCldoYXQgY29uY2x1c2lvbnMgd291bGQgeW91IGRyYXcgZnJvbSB0 aGlzIGludGVybmV0LWRyYWZ0PyBTaGFsbCB3ZSBtb3ZlIGZvciBsb25nIHBvbGxpbmcgYW5kICJU aW1lb3V0IiBoZWFkZXJzPw0KDQpyZWdhcmRzLA0KVG9yc3Rlbi4NCg0KQW0gMDkuMDYuMjAxMCAw OToyOSwgc2NocmllYiBNYW5nZXIsIEphbWVzIEg6DQoNClJpZ2h0IG9uIGN1ZSBhIG5ldyBpbnRl cm5ldC1kcmFmdCBjb3ZlcmluZyB0aGUgSFRUUCBwb2xsaW5nIGlzc3VlIGhhcyBqdXN0IGFwcGVh cmVkOg0KDQoNCg0KICBIeXBlcnRleHQgVHJhbnNmZXIgUHJvdG9jb2wgKEhUVFApIFRpbWVvdXRz PGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxvcmV0by1odHRwLXRpbWVvdXQ+DQoN CiAgZHJhZnQtbG9yZXRvLWh0dHAtdGltZW91dCBbSnVuZSAyMDEwXQ0KDQoNCg0KU2VlIGFsc286 DQoNCiAgQmVzdCBQcmFjdGljZXMgZm9yIHRoZSBVc2Ugb2YgTG9uZyBQb2xsaW5nIGFuZCBTdHJl YW1pbmcgaW4gQmlkaXJlY3Rpb25hbCBIVFRQPGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWxvcmV0by1odHRwLWJpZGlyZWN0aW9uYWw+DQoNCiAgZHJhZnQtbG9yZXRvLWh0dHAtYmlk aXJlY3Rpb25hbCBbRmViIDIwMTBdDQoNCg0KDQotLQ0KDQpKYW1lcyBNYW5nZXINCg0KDQoNCkFt IDA4LjA2LjIwMTAgMjI6MjMsIHNjaHJpZWIgRGlyayBCYWxmYW56Og0KDQpIaSBndXlzLA0KDQpj dXJyZW50bHksIHdlIHNwZWNpZnkgaG93IHBvbGxpbmcgc2hvdWxkIHdvcmsgaW4gdGhlIGRldmlj ZSBmbG93IGFzIHBhcnQgb2YgdGhlIE9BdXRoMiBzcGVjLg0KDQpJIHdvdWxkIGFyZ3VlIHRoYXQg dGhhdCBwb2xsaW5nIHNob3VsZCBiZSBoYW5kbGVkIGF0IGEgbG93ZXIgbGF5ZXIgb2YgdGhlIHN0 YWNrLCBhbmQgdGhhdCBPQXV0aDIgc2hvdWxkIGJlIHNpbGVudCBvbiB0aGUgaXNzdWUgb2YgcG9s bGluZy4gVGhlIGJlbmVmaXQgd2lsbCBiZSBhIHNpbXBsZXIgc3BlYy4NCg0KSFRUUCBzcGVjaWZp ZXMgdGhlIDUwMyByZXNwb25zZSBjb2RlIHdpdGggdGhlIChvcHRpb25hbCkgUmV0cnktQWZ0ZXIg cmVzcG9uc2UgaGVhZGVyLiBBU3MgY291bGQganVzdCB1c2UgdGhhdCBtZWNoYW5pc20gdG8gdGhy b3R0bGUgY2xpZW50cywgaW5zdGVhZCBvZiBoYW5kbGluZyBpdCBhdCB0aGUgT0F1dGggbGF5ZXIu DQoNClRoZSBPQXV0aCBzcGVjIGNvdWxkIHNheSBzb21ldGhpbmcgbGlrZTogIlRoZSBjbGllbnQg cmVxdWVzdHMgdGhlIGFjY2VzcyB0b2tlbiBhZnRlciB0aGUgdXNlciBhcHByb3ZlcyBvciByZWpl Y3RzIGF1dGhvcml6YXRpb24uIElmIHRoZSBjbGllbnQgY2Fubm90IGRldGVybWluZSB3aGVuIHRo ZSB1c2VyIGhhcyBhcHByb3ZlZCBvciByZWplY3RlZCB0aGUgYXV0aG9yaXphdGlvbiwgdGhlIGNs aWVudCBNQVkgcG9sbCB0aGUgc2VydmVyLiBUaGUgc2VydmVyIE1BWSB1c2UgdGhyb3R0bGluZyBt ZWNoYW5pc21zIHN1Y2ggYXMgNTAzIEhUVFAgcmVzcG9uc2UgY29kZXMgYW5kIFJldHJ5LUFmdGVy IHJlc3BvbnNlIGhlYWRlcnMgd2hpY2gsIGlmIHVzZWQsIHRoZSBjbGllbnQgTVVTVCBvYmV5LiIN Cg0KV2hhdCBkbyB5b3UgZ3V5cyB0aGluaz8NCg0KQlRXLCB0aGVyZSBpcyBzb21lIHByZWNlZGVu Y2UgZm9yIHRoaXMuIEdvb2dsZSdzIEFQSXMgdXNlIDUwMyByZXNwb25zZSBjb2RlcyB0byB0aHJv dHRsZSBzZXJ2ZXJzLCBlLmcuIGh0dHA6Ly9jb2RlLmdvb2dsZS5jb20vZ29vZ2xlYXBwcy9kb21h aW4vZ2RhdGFfcHJvdmlzaW9uaW5nX2FwaV92Mi4wX3JlZmVyZW5jZS5odG1sDQoNCkRpcmsuDQoN Cg0KDQoNCg== --_000_255B9BB34FB7D647A506DC292726F6E11263F7BAD2WSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl Pg0KPCEtLQ0KIC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCiBAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIg MTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7 DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KIC8qIFN0eWxlIERlZmluaXRpb25z ICovDQogcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46 MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBj bTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFByZWZvcm1hdHRl ZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0K CWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTE5 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBTZWN0aW9uMQ0KCXtzaXpl OjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30N CmRpdi5TZWN0aW9uMQ0KCXtwYWdlOlNlY3Rpb24xO30NCi0tPg0KPC9zdHlsZT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86 c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KICA8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCiA8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tQVUiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUi Pg0KPGRpdiBjbGFzcz0iU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+Jmd0Ow0KPC9zcGFuPldoYXQgY29u Y2x1c2lvbnMgd291bGQgeW91IGRyYXcgZnJvbSB0aGlzIGludGVybmV0LWRyYWZ0PzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyBTaGFsbCB3ZSBtb3ZlIGZvciBsb25n IHBvbGxpbmcgYW5kICZxdW90O1RpbWVvdXQmcXVvdDsgaGVhZGVycz88YnI+DQo8YnI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0K Y29sb3I6IzFGNDk3RCI+SSBoYXZlIG5vdCBiZWVuIGZvbGxvd2luZyB0aGUgcG9sbGluZyBpc3N1 ZSBkZWVwbHksIGJ1dCBJIGFncmVlIHdpdGggRGlyayB0aGF0IE9BdXRoMiBzaG91bGQgdHJ5IGxl YXZlIHRoZSBwb2xsaW5nIGlzc3VlIHRvIG90aGVyIHNwZWNzIGFzIG11Y2ggYXMgcG9zc2libGUu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+U3VnZ2VzdGluZyBsb25nIHBvbGxpbmcg YmUgdXNlZCwgd2l0aCBhIChpbmZvcm1hdGl2ZSkgcmVmZXJlbmNlIHRvIHRob3NlIDIgZHJhZnRz LCB3b3VsZCBiZSBhIGRlY2VudCBzb2x1dGlvbiBmb3IgT0F1dGgyLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsN CmNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0 OTdEIj4tLQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+SmFtZXMgTWFuZ2VyPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjp3aW5kb3d0ZXh0 Ij4NCiBUb3JzdGVuIExvZGRlcnN0ZWR0IFttYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXRd IDxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIDkgSnVuZSAyMDEwIDU6NTkgUE08YnI+DQo8 Yj5Ubzo8L2I+IE1hbmdlciwgSmFtZXMgSDxicj4NCjxiPkNjOjwvYj4gRGlyayBCYWxmYW56OyBP QXV0aCBXRzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBwb2xsaW5nIGluIHRo ZSBkZXZpY2UgZmxvdzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PldoYXQgY29uY2x1c2lvbnMgd291bGQgeW91IGRyYXcgZnJvbSB0aGlzIGludGVybmV0LWRyYWZ0 PyBTaGFsbCB3ZSBtb3ZlIGZvciBsb25nIHBvbGxpbmcgYW5kICZxdW90O1RpbWVvdXQmcXVvdDsg aGVhZGVycz88YnI+DQo8YnI+DQpyZWdhcmRzLDxicj4NClRvcnN0ZW4uPGJyPg0KPGJyPg0KQW0g MDkuMDYuMjAxMCAwOToyOSwgc2NocmllYiBNYW5nZXIsIEphbWVzIEg6IDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7DQpmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmlnaHQgb24gY3VlIGEgbmV3 IGludGVybmV0LWRyYWZ0IGNvdmVyaW5nIHRoZSBIVFRQIHBvbGxpbmcgaXNzdWUgaGFzIGp1c3Qg YXBwZWFyZWQ6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7DQpm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7DQpmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7DQo8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1sb3JldG8taHR0cC10aW1lb3V0Ij5IeXBlcnRleHQgVHJhbnNmZXIgUHJv dG9jb2wgKEhUVFApIFRpbWVvdXRzPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ow0KZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyBkcmFmdC1sb3JldG8taHR0cC10aW1l b3V0IFtKdW5lIDIwMTBdPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7DQpmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7DQpmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U2VlIGFsc286PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7DQpmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7DQo8YSBocmVmPSJo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1sb3JldG8taHR0cC1iaWRpcmVjdGlvbmFs Ij5CZXN0IFByYWN0aWNlcyBmb3IgdGhlIFVzZSBvZiBMb25nIFBvbGxpbmcgYW5kIFN0cmVhbWlu ZyBpbiBCaWRpcmVjdGlvbmFsIEhUVFA8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7DQpmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7IGRyYWZ0LWxvcmV0by1odHRwLWJp ZGlyZWN0aW9uYWwgW0ZlYiAyMDEwXTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ow0KZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsNCmZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tLQ0KPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7DQpmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SmFtZXMgTWFu Z2VyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsN CmZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij5BbSAwOC4wNi4yMDEwIDIyOjIzLCBz Y2hyaWViIERpcmsgQmFsZmFuejoNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdCI+SGkgZ3V5cywgPGJyPg0KPGJyPg0KY3VycmVu dGx5LCB3ZSBzcGVjaWZ5IGhvdyBwb2xsaW5nIHNob3VsZCB3b3JrIGluIHRoZSBkZXZpY2UgZmxv dyBhcyBwYXJ0IG9mIHRoZSBPQXV0aDIgc3BlYy48YnI+DQo8YnI+DQpJIHdvdWxkIGFyZ3VlIHRo YXQgdGhhdCBwb2xsaW5nIHNob3VsZCBiZSBoYW5kbGVkIGF0IGEgbG93ZXIgbGF5ZXIgb2YgdGhl IHN0YWNrLCBhbmQgdGhhdCBPQXV0aDIgc2hvdWxkIGJlIHNpbGVudCBvbiB0aGUgaXNzdWUgb2Yg cG9sbGluZy4gVGhlIGJlbmVmaXQgd2lsbCBiZSBhIHNpbXBsZXIgc3BlYy48YnI+DQo8YnI+DQpI VFRQIHNwZWNpZmllcyB0aGUgNTAzIHJlc3BvbnNlIGNvZGUgd2l0aCB0aGUgKG9wdGlvbmFsKSBS ZXRyeS1BZnRlciByZXNwb25zZSBoZWFkZXIuIEFTcyBjb3VsZCBqdXN0IHVzZSB0aGF0IG1lY2hh bmlzbSB0byB0aHJvdHRsZSBjbGllbnRzLCBpbnN0ZWFkIG9mIGhhbmRsaW5nIGl0IGF0IHRoZSBP QXV0aCBsYXllci4NCjxicj4NCjxicj4NClRoZSBPQXV0aCBzcGVjIGNvdWxkIHNheSBzb21ldGhp bmcgbGlrZTogJnF1b3Q7VGhlIGNsaWVudCByZXF1ZXN0cyB0aGUgYWNjZXNzIHRva2VuIGFmdGVy IHRoZSB1c2VyIGFwcHJvdmVzIG9yIHJlamVjdHMgYXV0aG9yaXphdGlvbi4gSWYgdGhlIGNsaWVu dCBjYW5ub3QgZGV0ZXJtaW5lIHdoZW4gdGhlIHVzZXIgaGFzIGFwcHJvdmVkIG9yIHJlamVjdGVk IHRoZSBhdXRob3JpemF0aW9uLCB0aGUgY2xpZW50IE1BWSBwb2xsIHRoZSBzZXJ2ZXIuIFRoZSBz ZXJ2ZXINCiBNQVkgdXNlIHRocm90dGxpbmcgbWVjaGFuaXNtcyBzdWNoIGFzIDUwMyBIVFRQIHJl c3BvbnNlIGNvZGVzIGFuZCBSZXRyeS1BZnRlciByZXNwb25zZSBoZWFkZXJzIHdoaWNoLCBpZiB1 c2VkLCB0aGUgY2xpZW50IE1VU1Qgb2JleS4mcXVvdDs8YnI+DQo8YnI+DQpXaGF0IGRvIHlvdSBn dXlzIHRoaW5rPzxicj4NCjxicj4NCkJUVywgdGhlcmUgaXMgc29tZSBwcmVjZWRlbmNlIGZvciB0 aGlzLiBHb29nbGUncyBBUElzIHVzZSA1MDMgcmVzcG9uc2UgY29kZXMgdG8gdGhyb3R0bGUgc2Vy dmVycywgZS5nLg0KPGEgaHJlZj0iaHR0cDovL2NvZGUuZ29vZ2xlLmNvbS9nb29nbGVhcHBzL2Rv bWFpbi9nZGF0YV9wcm92aXNpb25pbmdfYXBpX3YyLjBfcmVmZXJlbmNlLmh0bWwiPg0KaHR0cDov L2NvZGUuZ29vZ2xlLmNvbS9nb29nbGVhcHBzL2RvbWFpbi9nZGF0YV9wcm92aXNpb25pbmdfYXBp X3YyLjBfcmVmZXJlbmNlLmh0bWw8L2E+PGJyPg0KPGJyPg0KRGlyay48YnI+DQo8YnI+DQo8YnI+ DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_255B9BB34FB7D647A506DC292726F6E11263F7BAD2WSMSG3153Vsrv_-- From mrkrcsmith@googlemail.com Tue Jun 8 09:31:37 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFB0328C186 for ; Tue, 8 Jun 2010 09:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.724 X-Spam-Level: * X-Spam-Status: No, score=1.724 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, FROM_LOCAL_NOVOWEL=0.5, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pXYdn2qCRY5n for ; Tue, 8 Jun 2010 09:31:36 -0700 (PDT) Received: from mail-fx0-f66.google.com (mail-fx0-f66.google.com [209.85.161.66]) by core3.amsl.com (Postfix) with ESMTP id 6EAFD28C1A6 for ; Tue, 8 Jun 2010 09:31:06 -0700 (PDT) Received: by fxm7 with SMTP id 7so1500330fxm.1 for ; Tue, 08 Jun 2010 09:31:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=lp3dJWROB4jw3/6xnA6jiotdhahAbaSqZ269iM7uLJ8=; b=AgGBP6P9YuZAYlZxHodGT8CTrbbBy4T5iFv+ge9hQN55OpfoLbDhcYpMKmArJehmP2 ZIVZh1JHL5qYrEJPs7nq+KCyNTi+oAucyMTWVpY+QQmGgr7lQdUl92LwkIFqqaobtC/w sG6bSDoYdpyY3rz3qlwOnC7JUQV79EuLGBK9U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=etPTV+r8c3TIwKizew7R5x15VyBj65n8N8Q4WRSdoXvKU64ICnYLWu1jhIDGIlIm5o 1TyYrv3dHaUQte3da4+MrsrysP5HZzAVXKVqGbbC3OeCnW6+cNgcsPd0B73OHwYvW8rF EtNUEUcrOpl1GNCQCIU0ML1+mWWRz1huK4NSw= MIME-Version: 1.0 Received: by 10.239.182.7 with SMTP id o7mr1231624hbg.79.1276014662393; Tue, 08 Jun 2010 09:31:02 -0700 (PDT) Received: by 10.239.175.145 with HTTP; Tue, 8 Jun 2010 09:31:02 -0700 (PDT) In-Reply-To: References: <042e8761-8bb6-44b5-8b6f-5507bf254abf@e35g2000yqm.googlegroups.com> Date: Tue, 8 Jun 2010 17:31:02 +0100 Message-ID: From: Kevin Smith To: oauth-wrap-wg@googlegroups.com Content-Type: multipart/alternative; boundary=001485f27162ae2122048887506a X-Mailman-Approved-At: Wed, 09 Jun 2010 08:42:06 -0700 Cc: OAuth WG Subject: Re: [OAUTH-WG] [WRAP] WRAP in GSMA OneAPI X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 14:52:15 -0000 --001485f27162ae2122048887506a Content-Type: text/plain; charset=ISO-8859-1 Hi David, Blaine, We (the OneAPI group) have been looking further into OAUTH 2.0 and would like to see how it can work in a mobile network scenario: for example, a desktop Web application wants to locate a mobile user to plot their location on a map. So the client is the Web application and the server is an HTTP platform sitting on top of the mobile core network. It seems that the Web application could register a client ID and client secret with the OneAPI-implementing server. When location is requested by this client, the server would prompt the user, and if permission were received, would enable the client to access the location via an access token/secret. One difference to the regular OAUTH flow is that 'post-pay' contract network subscribers would not have to enter a username/password to identify themselves since they would be implicitly identified on the network anyway; they would just need to confirm authorisation ('Allow/Block'). We are not sure how to handle pre-pay users that buy phone credits in advance. In case either of you (or any other OAUTH expert) would be available to lead a discussion on the technology, and to answer questions from mobile operators and platform vendors, we are having a meeting next Tuesday in London. The meeting is also accessible over Webex. Please let me know if you would be willing to do so, as I'm sure it will help kick-start our implementation work. Cheers! Kevin On Thu, May 6, 2010 at 6:13 AM, David Recordon wrote: > +OAuth IETF list > -WRAP list to BCC > > Hi Kevin, > OAuth 2.0 should be pretty simple for you to implement and any feedback > your team has would be really appreciated! There are already implementations > in Cocoa, Python, and Ruby list on the wiki at > http://wiki.oauth.net/OAuth-2.0 and you find find the spec at > http://tools.ietf.org/html/draft-hammer-oauth2-00. > > You may also be interested in the mobile web implementation we've built at > Facebook. http://developers.facebook.com/docs/guides/mobile/ > > I'm also cc'ing Blaine Cook who lives in Ireland and might be able to > present. > > Cheers, > --David > > > On Tue, May 4, 2010 at 4:20 AM, Kevin Smith, Vodafone < > mrkrcsmith@googlemail.com> wrote: > >> Dear OAUTH WRAP group, >> >> My name is Kevin Smith of Vodafone R&D, and I lead a cross-mobile >> operator project called OneAPI ('Open Network Enablers') [1]. The aim >> is to provide a RESTful API to expose network functions such as >> location, messaging, payments and more to developers; with the >> reckoning that this will make it far easier to mash-up Web >> applications with network capabilities and reduce the time to reach >> all mobile subscribers in a territory. Thus far we have a live pilot >> implementation across the 3 major Canadian operators [2] and a non- >> commercial test site connected to >> 12 European operators [3], and will be releasing v1.0 specifications >> backed by the OMA this month. >> >> For the first release we did not attempt to prescribe an AAA model to >> operators, instead leaving them to reuse their own SDP AAA >> implementation for OneAPI. For our second phase now underway we would >> like to provide a recommended reference implementation AAA model for >> operators who are unsure how to allow secure API access whilst >> allowing user consent and privacy to be respected. Therefore we have >> discussed OAUTH as an ideal candidate that will be well-known to Web >> developers. >> >> My question regards the suitability of WRAP for such a reference >> implementation: the decoupling of authentication is good sense and >> would be welcome by operators, however it appears that WRAP is >> deprecated and is intended to be replaced by OAUTH 2.0 - is that >> right? Please could you provide any details on the plans for if/how >> the two will interoperate? If it's at all possible, we would very much >> welcome a member of the group to present on WRAP at one of our face-to- >> face meetings in London - if that is of interest please let me know >> and I can make arrangements. >> >> Thanks for your time and look forward to your advice. >> >> Kind regards, >> Kevin >> >> [1] http://www.gsmworld.com/oneapi >> [2] http://canada.oneapi.gsmworld.com/ >> [3] http://oneapi.aepona.com/ >> >> Kevin Smith >> Senior Technology Strategist, R&D >> Vodafone Technology >> >> E-mail: kevin.smith@vodafone.com >> >> -- >> You received this message because you are subscribed to the Google Groups >> "OAuth WRAP WG" group. >> To post to this group, send email to oauth-wrap-wg@googlegroups.com. >> To unsubscribe from this group, send email to >> oauth-wrap-wg+unsubscribe@googlegroups.com >> . >> For more options, visit this group at >> http://groups.google.com/group/oauth-wrap-wg?hl=en. >> >> > -- > You received this message because you are subscribed to the Google Groups > "OAuth WRAP WG" group. > To post to this group, send email to oauth-wrap-wg@googlegroups.com. > To unsubscribe from this group, send email to > oauth-wrap-wg+unsubscribe@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/oauth-wrap-wg?hl=en. > --001485f27162ae2122048887506a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi David, Blaine,

We (the OneAPI group) have been looking further into OAUTH 2.0 and would like to see how it can work in a mobile network scenario: for example, a desktop Web application wants to locate a mobile user to plot their=20 location on a map. So the client is the Web application and the server is an HTTP platform sitting on top of the mobile core network.

=A0It seems that the Web application could register a client ID and client secret with the OneAPI-implementing server. When location is requested=20 by this client, the server would prompt the user, and if permission were received, would enable the client to access the location via an access=20 token/secret.

One difference to the regular OAUTH flow is that=A0 'post-pay' = contract network subscribers would not have to enter a=20 username/password to identify themselves since they would be implicitly=20 identified on the network anyway; they would just need to confirm=20 authorisation ('Allow/Block'). We are not sure how to handle pre-pa= y users that buy phone credits in advance.

In case either of you (or any other OAUTH expert) would be available to lea= d a discussion on the technology, and to answer questions from mobile opera= tors and platform vendors, we are having a meeting next Tuesday in London. = The meeting is also accessible over Webex. Please let me know if you would = be willing to do so, as I'm sure it will help kick-start our implementa= tion work.

Cheers!
Kevin

On Thu, May 6, 2010 = at 6:13 AM, David Recordon <recordond@gmail.com> wrote:
+OAuth IETF list
-WRAP list to BCC

Hi Ke= vin,
OAuth 2.0 should be pretty simple for you to implement and any fee= dback your team has would be really appreciated! There are already implemen= tations in Cocoa, Python, and Ruby list on the wiki at=A0http://wiki.oauth.net/OAuth-2.0= and you find find the spec at=A0http://tools.ietf.org/html/draft-= hammer-oauth2-00.

You may also be interested in the mobile web implementa= tion we've built at Facebook.=A0http://developers.facebook.com/do= cs/guides/mobile/

I'm also cc'ing Blaine Cook who lives in Irelan= d and might be able to present.

Cheers,
= --David


On Tue, May 4, 2010 at 4:20 AM, Kevin Smith, Vodafone <= ;mrkrcsmith@= googlemail.com> wrote:
Dear OAUTH WRAP g= roup,

My name is Kevin Smith of Vodafone R&D, and I lead a cross-mobile
operator project called OneAPI ('Open Network Enablers') [1]. The a= im
is to provide a RESTful API to expose network functions such as
location, messaging, payments and more to developers; with the
reckoning that this will make it far easier to mash-up Web
applications with network capabilities and reduce the time to reach
all mobile subscribers in a territory. Thus far we have a live pilot
implementation across the 3 major Canadian operators [2] and a non-
commercial test site connected to
12 European operators [3], and will be releasing v1.0 specifications
backed by the OMA this month.

For the first release we did not attempt to prescribe an AAA model to
operators, instead leaving them to reuse their own SDP AAA
implementation for OneAPI. For our second phase now underway we would
like to provide a recommended reference implementation AAA model for
operators who are unsure how to allow secure API access whilst
allowing user consent and privacy to be respected. Therefore we have
discussed OAUTH as an ideal candidate that will be well-known to Web
developers.

My question regards the suitability of WRAP for such a reference
implementation: the decoupling of authentication is good sense and
would be welcome by operators, however it appears that WRAP is
deprecated and is intended to be replaced by OAUTH 2.0 - is that
right? =A0Please could you provide any details on the plans for if/how
the two will interoperate? If it's at all possible, we would very much<= br> welcome a member of the group to present on WRAP at one of our face-to-
face meetings in London - if that is of interest please let me know
and I can make arrangements.

Thanks for your time and look forward to your advice.

Kind regards,
Kevin

[1] http://www= .gsmworld.com/oneapi
[2] http:/= /canada.oneapi.gsmworld.com/
[3] http://oneapi.a= epona.com/

Kevin Smith
Senior Technology Strategist, R&D
Vodafone Technology

E-mail: kevin= .smith@vodafone.com

--
You received this message because you are subscribed to the Google Groups &= quot;OAuth WRAP WG" group.
To post to this group, send email to oauth-wrap-wg@googlegroups.com.
To unsubscribe from this group, send email to oauth-wrap-wg+unsubscr= ibe@googlegroups.com.
For more options, visit this group at http://groups.google.com/grou= p/oauth-wrap-wg?hl=3Den.


--
You received this message because you are subscribed to the Google Groups &= quot;OAuth WRAP WG" group.
To post to this group, send email to oauth-wrap-wg@googlegroups.com.
To unsubscribe from this group, send email to oauth-wrap-wg+unsubscr= ibe@googlegroups.com.
For more options, visit this group at http://groups.google.com/grou= p/oauth-wrap-wg?hl=3Den.

--001485f27162ae2122048887506a-- From mscurtescu@google.com Wed Jun 9 09:36:33 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 275EF3A6994 for ; Wed, 9 Jun 2010 09:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.84 X-Spam-Level: X-Spam-Status: No, score=-103.84 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pV94GHlGNCjW for ; Wed, 9 Jun 2010 09:36:31 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id C46D53A6992 for ; Wed, 9 Jun 2010 09:36:31 -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 o59GaUsL014422 for ; Wed, 9 Jun 2010 09:36:30 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1276101391; bh=JFP39HTpaYauRATo895bTAUOrsA=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=J/nBMLURkRTha5v8050furLklHnxHFdp24YDWzELM5ASiExev1SDZB2OnNoMbGWf1 qMjfQEQhfLy3DX2u9Whkw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding; b=g9ndKmFed3ZYfVAhT5VLyQbdHZboUqUd+7n8MP4U67b86qx9KwUShckO0L/srRnDK WeAKl0AsTuqQ0U7yDmXHg== Received: from pwj10 (pwj10.prod.google.com [10.241.219.74]) by hpaq11.eem.corp.google.com with ESMTP id o59GaMcR028250 for ; Wed, 9 Jun 2010 09:36:24 -0700 Received: by pwj10 with SMTP id 10so1132628pwj.24 for ; Wed, 09 Jun 2010 09:36:07 -0700 (PDT) Received: by 10.141.108.10 with SMTP id k10mr14770037rvm.113.1276101366536; Wed, 09 Jun 2010 09:36:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.124.13 with HTTP; Wed, 9 Jun 2010 09:35:46 -0700 (PDT) In-Reply-To: References: From: Marius Scurtescu Date: Wed, 9 Jun 2010 09:35:46 -0700 Message-ID: To: Andrew Arnott Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] User-agent flow and pre-registered redirect_uri X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 16:36:33 -0000 On Tue, Jun 8, 2010 at 11:20 PM, Andrew Arnott wro= te: > Marius, > > You seem to be coming from the perspective that the auth server stores > authorizations (that would eliminate the need for the user to interactive= ly > approve an authorization) based on redirect_url rather than client_id.=A0= Is > that right? Only for the unregistered case. If the client did register with the authz server then you can use the client_id, but then you also have to match the registered redirect_uri with the actual one (and how matching is done is still not defined). > I've always considered an authorization as a tuple of > client_id,user,scope,issue_date.=A0 If an authorization has been approved= , and > another request for authorization for a subset of the scope previously > issued comes in, the auth server can skip the interactive user authorizat= ion > and just approve the request since nothing new is being issued. The tuple seems right, except for the issue date, why would you add that? > If my tuple is correct, then the user agent flow allows any random client= to > submit a trusted client_id as if it was them, but with an evil redirect_u= rl > so they can obtain user authorization without the user noticing at all (i= f > an authorization already existed).=A0 But if redirect_url belongs in that > tuple, then that would be the mitigation I guess.=A0 But we could avoid e= xtra > user prompts if we just forced clients to register their redirect_url's i= n > order to be enabled for user agent flows, thus protecting the user from b= ad > clients sending in evil redirect_urls in order to steal access tokens. I think you are saying the same thing. Basically, registered and unregistered behave differently, and the spec should allow for both I think. Marius > > -- > 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 Tue, Jun 8, 2010 at 11:04 AM, Marius Scurtescu > wrote: >> >> On Tue, Jun 8, 2010 at 10:40 AM, Chuck Mortimore >> wrote: >> > Thanks =96 I get your line of reasoning now. =A0=A0I believe it would = still >> > help >> > in preventing certain types of attack. =A0=A0These are especially appa= rent >> > around immediate. >> >> I do agree that requiring registration may be a good idea in many >> cases, all I am saying is that this should not be enforced. Some authz >> servers may want to allow unregistered clients, and that's fine. I >> think the current SHOULD is good enough and changing it to MUST would >> be going too far. >> >> >> > 1) User initially grants access to example.com >> > 2) User goes to an evil site >> > 3) Without the user=92s knowledge, the malicious site issues an immedi= ate >> > user_agent flow >> > >> > >> > https://authzserver.com/authorize?type=3Duser_agent&immediate=3Dtrue&c= lient_id=3D> > Client ID>&redirect_uri=3D >> > >> > 4) Evil site is handed an access token based upon the previous grant t= o >> > example.com >> >> I don't think this attack will work. If exmple.com was not registered, >> then it has not client_id, so the previous approval should be >> remembered for example.com's redirect_uri. Evil site needs to use its >> own redirect_uri, so immediate will not work. >> >> >> Marius > > From mscurtescu@google.com Wed Jun 9 09:45:35 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E318928C11E for ; Wed, 9 Jun 2010 09:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.017 X-Spam-Level: X-Spam-Status: No, score=-101.017 tagged_above=-999 required=5 tests=[AWL=0.960, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cEeHFhX8QAvA for ; Wed, 9 Jun 2010 09:45:35 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id C411C28C111 for ; Wed, 9 Jun 2010 09:45:34 -0700 (PDT) Received: from kpbe18.cbf.corp.google.com (kpbe18.cbf.corp.google.com [172.25.105.82]) by smtp-out.google.com with ESMTP id o59GjYqw011966 for ; Wed, 9 Jun 2010 09:45:34 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1276101935; bh=wRaucBxKKoGte3VMnH2+8lwMJQs=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=N3tdCvT21aBi+eHi0/GMoq2eW0n6eXmZW35aipW0xr+SvhK65IVQuNS0s1lynDYur i+nc78ipuU9NVdwz2Rr8Q== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type; b=NnbkOl1qVcWZIcTvgivQZ4JROZjcUPJMDYv9TF+7meYh1g9/dF+MHF+SPThgEFz5u 6vhPVfCj6Eotwi2qr0ZLA== Received: from pxi8 (pxi8.prod.google.com [10.243.27.8]) by kpbe18.cbf.corp.google.com with ESMTP id o59GjWm1005136 for ; Wed, 9 Jun 2010 09:45:33 -0700 Received: by pxi8 with SMTP id 8so4768842pxi.5 for ; Wed, 09 Jun 2010 09:45:32 -0700 (PDT) Received: by 10.140.55.8 with SMTP id d8mr1214884rva.216.1276101932511; Wed, 09 Jun 2010 09:45:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.124.13 with HTTP; Wed, 9 Jun 2010 09:45:11 -0700 (PDT) In-Reply-To: <4C0F45EC.4050707@lodderstedt.net> References: <4C0F45EC.4050707@lodderstedt.net> From: Marius Scurtescu Date: Wed, 9 Jun 2010 09:45:11 -0700 Message-ID: To: Torsten Lodderstedt Content-Type: text/plain; charset=ISO-8859-1 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] native app support (was: Next draft) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 16:45:36 -0000 On Wed, Jun 9, 2010 at 12:42 AM, Torsten Lodderstedt wrote: > 3) I would rather add the user_code as optional URL parameter to the device > flow. Are you suggesting the same thing? That the endpoint at verification_uri should accept an optional user_code query parameter? Marius From torsten@lodderstedt.net Wed Jun 9 09:57:38 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B611D3A699E for ; Wed, 9 Jun 2010 09:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.297 X-Spam-Level: X-Spam-Status: No, score=-1.297 tagged_above=-999 required=5 tests=[AWL=0.952, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NXnRxp9P-Yim for ; Wed, 9 Jun 2010 09:57:38 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.14]) by core3.amsl.com (Postfix) with ESMTP id EAA0A3A6992 for ; Wed, 9 Jun 2010 09:57:37 -0700 (PDT) Received: from p4fff1dc2.dip.t-dialin.net ([79.255.29.194] helo=[127.0.0.1]) by smtprelay02.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OMOav-0001Oe-DS; Wed, 09 Jun 2010 18:57:37 +0200 Message-ID: <4C0FC800.5040404@lodderstedt.net> Date: Wed, 09 Jun 2010 18:57:36 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Marius Scurtescu References: <4C0F45EC.4050707@lodderstedt.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] native app support (was: Next draft) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 16:57:38 -0000 Oops, I misread this point. So +1 for 3), too. regards, Torsten. Am 09.06.2010 18:45, schrieb Marius Scurtescu: > On Wed, Jun 9, 2010 at 12:42 AM, Torsten Lodderstedt > wrote: > >> 3) I would rather add the user_code as optional URL parameter to the device >> flow. >> > Are you suggesting the same thing? That the endpoint at > verification_uri should accept an optional user_code query parameter? > > Marius > From recordond@gmail.com Wed Jun 9 10:59:28 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2911A3A67E7 for ; Wed, 9 Jun 2010 10:59:28 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nHFezM-+MmVA for ; Wed, 9 Jun 2010 10:59:27 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 141133A659C for ; Wed, 9 Jun 2010 10:59:27 -0700 (PDT) Received: by gwj16 with SMTP id 16so634476gwj.31 for ; Wed, 09 Jun 2010 10:59:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=5ZWKIdRby2r4+M//ctymR0sxoHJ0G9Y3QOyRtDGxLdY=; b=bxvs16wqfGS42CCHhnv284TKMiO7QN69owKH/8rTIwIjArTPlBJU0ntfgbzjHsdPiZ H7xhZ9pXkICivKJVA4UH2oyTyHzfZ95mvVzAUORqPjPCWaDgz6gqueyovuaOSRIRQBn2 C/W+A01zw/sxd+IpLwxK+sd2tSegANzPk3rsc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=wuYNnZvHOlS4ZB55hSc8xMOfRooCiZ0uf7W5+Xk8ApVfgOAti740OnFk5I+O53Nnxf aNs8Lk9W4TAz0Q0QKw0DNwt/AlVnfZI8q6oHjaTE0sUyb82xLmlyC179LjvxfDSOAzyk 0+K7YuucXyBYgfXRfu/+dhL2iZWNmDdlUAgCI= MIME-Version: 1.0 Received: by 10.90.255.5 with SMTP id c5mr235079agi.195.1276106350869; Wed, 09 Jun 2010 10:59:10 -0700 (PDT) Received: by 10.231.192.4 with HTTP; Wed, 9 Jun 2010 10:59:09 -0700 (PDT) In-Reply-To: References: Date: Wed, 9 Jun 2010 10:59:09 -0700 Message-ID: From: David Recordon To: Marius Scurtescu Content-Type: text/plain; charset=ISO-8859-1 Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth 2 for Native Apps X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 17:59:28 -0000 Want to put this on the wiki http://wiki.oauth.net/? On Mon, Jun 7, 2010 at 12:25 PM, Marius Scurtescu wrote: > Hi, > > I attached a document that summaries how native applications can use OAuth 2. > > Feedback more than welcome, especially if you have experience with > native apps and OAuth. > > The current Web Server and Device flows need small changes and > clarifications in order to properly support native apps, I will start > a separate thread on that. > > Marius > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From mscurtescu@google.com Wed Jun 9 11:03:00 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C367A3A67B4 for ; Wed, 9 Jun 2010 11:03:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.154 X-Spam-Level: X-Spam-Status: No, score=-101.154 tagged_above=-999 required=5 tests=[AWL=0.823, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ISaTXUTD3Zbc for ; Wed, 9 Jun 2010 11:02:59 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 94F083A67E7 for ; Wed, 9 Jun 2010 11:02:59 -0700 (PDT) Received: from hpaq3.eem.corp.google.com (hpaq3.eem.corp.google.com [172.25.149.3]) by smtp-out.google.com with ESMTP id o59I2xbX029179 for ; Wed, 9 Jun 2010 11:02:59 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1276106579; bh=32yM5XpO3XXtKbtvQeuQDTVfftI=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=ebtF82J1+KEVXEq0bJDYYLID32YUT31HOnadkx3Msl2IgO5BVlZRdu/y08CjoqThB Ykr9sJ/9Q6c1i/hgVepeg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type; b=R0R3qj2bIif8oopok7UcIUWFRXNn1xxH58w8/n0KMc1xXZ6AacOzFguLojqS0IHur 2bwrmthEuA9dz+OxN6KtA== Received: from pwj6 (pwj6.prod.google.com [10.241.219.70]) by hpaq3.eem.corp.google.com with ESMTP id o59I2uYh015646 for ; Wed, 9 Jun 2010 11:02:58 -0700 Received: by pwj6 with SMTP id 6so848526pwj.36 for ; Wed, 09 Jun 2010 11:02:56 -0700 (PDT) Received: by 10.141.124.18 with SMTP id b18mr2233585rvn.202.1276106575416; Wed, 09 Jun 2010 11:02:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.124.13 with HTTP; Wed, 9 Jun 2010 11:02:35 -0700 (PDT) In-Reply-To: References: From: Marius Scurtescu Date: Wed, 9 Jun 2010 11:02:35 -0700 Message-ID: To: David Recordon Content-Type: text/plain; charset=ISO-8859-1 Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth 2 for Native Apps X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 18:03:00 -0000 Sure, will do that. Marius On Wed, Jun 9, 2010 at 10:59 AM, David Recordon wrote: > Want to put this on the wiki http://wiki.oauth.net/? > > > On Mon, Jun 7, 2010 at 12:25 PM, Marius Scurtescu wrote: >> Hi, >> >> I attached a document that summaries how native applications can use OAuth 2. >> >> Feedback more than welcome, especially if you have experience with >> native apps and OAuth. >> >> The current Web Server and Device flows need small changes and >> clarifications in order to properly support native apps, I will start >> a separate thread on that. >> >> Marius >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > From recordond@gmail.com Wed Jun 9 11:04:40 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CF473A67B4 for ; Wed, 9 Jun 2010 11:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.617 X-Spam-Level: X-Spam-Status: No, score=-0.617 tagged_above=-999 required=5 tests=[AWL=0.494, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BkaStYDWNZKa for ; Wed, 9 Jun 2010 11:04:36 -0700 (PDT) Received: from mail-yw0-f179.google.com (mail-yw0-f179.google.com [209.85.211.179]) by core3.amsl.com (Postfix) with ESMTP id B7AA03A6767 for ; Wed, 9 Jun 2010 11:04:32 -0700 (PDT) Received: by ywh9 with SMTP id 9so6473655ywh.17 for ; Wed, 09 Jun 2010 11:04:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=j5ekKXnOFk+O6z6T/61qXJF9+mB/x1ZP/BSXfVK/OTk=; b=LPez9l82UVGTyhaurg0ZgHbNBSzr35CH72rPyGrGazoZtK0DO7tR7eIm7N5amVdJh7 8gLVITU4P/N+EZ3/4Pv87fC/OCxuI4yfhBR02y9AFJxZLs0jaqdNo3yEmKAIgrCL7FSX S3krTvRx8FE78AaM1Rcs/qV9oUuXMnEeitTLg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Noidl2JmuMghrwHs6yMbItQoLkem7NtQ9erV7Kc4U32ZJkmaPqsGOhR6JpHZyt+lw0 WY4hIjGzv0Bc1XjKD/yulp9KXfqYkrk9QFuFk2NAluQfJss8L8BNZPlSorwje/KBsnB1 cGsc6CksR3Iqx4pB1bRIjYgIEqbg4Ek8GALyQ= MIME-Version: 1.0 Received: by 10.150.207.16 with SMTP id e16mr72017ybg.342.1276106293679; Wed, 09 Jun 2010 10:58:13 -0700 (PDT) Received: by 10.231.192.4 with HTTP; Wed, 9 Jun 2010 10:58:13 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11263F7B9FB@WSMSG3153V.srv.dir.telstra.com> References: <4C0F3FFF.2050209@lodderstedt.net> <255B9BB34FB7D647A506DC292726F6E11263F7B9FB@WSMSG3153V.srv.dir.telstra.com> Date: Wed, 9 Jun 2010 10:58:13 -0700 Message-ID: From: David Recordon To: "Manger, James H" , Dirk Balfanz Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: OAuth WG Subject: Re: [OAUTH-WG] polling in the device flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 18:04:40 -0000 Unless I'm misreading the Timeouts spec, it defines a HTTP request header which the client uses to tell the server how long it will wait. That's a different problem from the server telling the client to back off it's request rate. A 503 with a Retry-After header seems reasonable. We should specify this interaction given that 503 headers will be new to many developers. --David On Wed, Jun 9, 2010 at 12:29 AM, Manger, James H wrote: > Right on cue a new internet-draft covering the HTTP polling issue has jus= t > appeared: > > > > =A0 Hypertext Transfer Protocol (HTTP) Timeouts > > =A0 draft-loreto-http-timeout [June 2010] > > > > See also: > > =A0 Best Practices for the Use of Long Polling and Streaming in Bidirecti= onal > HTTP > > =A0 draft-loreto-http-bidirectional [Feb 2010] > > > > -- > > James Manger > > > > Am 08.06.2010 22:23, schrieb Dirk Balfanz: > > Hi guys, > > currently, we specify how polling should work in the device flow as part = of > the OAuth2 spec. > > I would argue that that polling should be handled at a lower layer of the > stack, and that OAuth2 should be silent on the issue of polling. The bene= fit > will be a simpler spec. > > HTTP specifies the 503 response code with the (optional) Retry-After > response header. ASs could just use that mechanism to throttle clients, > instead of handling it at the OAuth layer. > > The OAuth spec could say something like: "The client requests the access > token after the user approves or rejects authorization. If the client can= not > determine when the user has approved or rejected the authorization, the > client MAY poll the server. The server MAY use throttling mechanisms such= as > 503 HTTP response codes and Retry-After response headers which, if used, = the > client MUST obey." > > What do you guys think? > > BTW, there is some precedence for this. Google's APIs use 503 response co= des > to throttle servers, e.g. > http://code.google.com/googleapps/domain/gdata_provisioning_api_v2.0_refe= rence.html > > Dirk. > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From recordond@gmail.com Wed Jun 9 12:06:27 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2AC63A6784 for ; Wed, 9 Jun 2010 12:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.184 X-Spam-Level: X-Spam-Status: No, score=-0.184 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gwRm8mjUPLbN for ; Wed, 9 Jun 2010 12:06:26 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 4425B3A6768 for ; Wed, 9 Jun 2010 12:06:26 -0700 (PDT) Received: by iwn42 with SMTP id 42so6105984iwn.31 for ; Wed, 09 Jun 2010 12:06:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ceyOMj+GTR5AfKEKF3HwNHkBXjjAEnF2EMcH2wXGhrE=; b=RuWifjQMMgH7+T9c28FiJZH+LtjnsYNxDyDrz3w0waClEv/DAwJE/XwmMPE6n90H3+ 11tj8lrTZdPn7UE0BNhTikWcOX8OhymMeS1jyf/shFlXYK2+v38vxykPV7Lq37Oewk7v FjKkjrg3vc9sZNMZOx4/SWfbeZjpfsONB0uiA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=sjJ1JGYTB2h6BcB1iq8o1IQuTPHkS3c7u2++PaJ2lVtsrm6OS7ZgF6JfX0b2kD7HnM DPLX0k/wCXx5xiH1zqV3+0Bcv5SncyR/k24vgBibchnRMzWt7q5rOFJxr7xvSaz88Di4 C3pf4cd9KVmCvRazUncxoz2tHaiGiJvifPnjE= MIME-Version: 1.0 Received: by 10.42.7.72 with SMTP id d8mr9341354icd.11.1276110384410; Wed, 09 Jun 2010 12:06:24 -0700 (PDT) Received: by 10.231.192.4 with HTTP; Wed, 9 Jun 2010 12:06:24 -0700 (PDT) In-Reply-To: References: Date: Wed, 9 Jun 2010 12:06:24 -0700 Message-ID: From: David Recordon To: Eran Hammer-Lahav , Allen Tom , Breno de Medeiros , Luke Shepard Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: OAuth WG Subject: Re: [OAUTH-WG] A display parameter for user authorization requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 19:06:27 -0000 First draft of the UX Extension is at http://github.com/daveman692/OAuth-2.0/raw/master/draft-recordon-oauth-v2-u= x-00.txt. Eran, I'm more than happy to have you take over as editor. I included Allen and Breno as authors since I followed Allen's suggestion and adopted the language preference parameter from the OpenID extension. I also included Luke as an author since he wrote the first pass of a display parameter. That said, none of them have seen this draft yet. --David On Tue, Apr 13, 2010 at 12:36 PM, Allen Tom wrote: > At least with regards to the language preference, how about if we just co= py > the openid.ui.lang parameter from the OpenID UI Extension? > > http://svn.openid.net/repos/specifications/user_interface/1.0/trunk/openi= d-user-interface-extension-1_0.html#anchor3 > > In flows in which the client redirects the user=92s web browser to author= ize > access, the client MAY send the Authorization Server a hint regarding the > user=92s preferred language by sending the following parameter: > > =A0=A0=A0=A0lang > =A0=A0=A0=A0=A0=A0=A0=A0The user=92s preferred languages as a [BCP 47] la= nguage priority list, > represented as a comma-separated list of BCP 47 basic language ranges in > decending priority order. For instance, the value =93fr-CA,fr-FR,en-CA=94 > represents the preference for French spoken in Canada, French spoken in > France, followed by English spoken in Canada. > > The language preference hint SHOULD take precedence over the Accept-Langu= age > HTTP header sent by the user=92s browser, and SHOULD take precedence over= the > language preference inferred by the user=92s IP Address. > > BCP 47: =A0http://tools.ietf.org/html/bcp47 > > Allen > > > On 4/12/10 1:32 PM, "Eran Hammer-Lahav" wrote: > > Between language preferences, display configuration, and immediate check,= I > think it might be worth to move that work to another draft. Timeline-wise= , > this has the potential of slowing us down. I also fear getting what is no= w a > pretty simple spec much more complicated. > > Anyone cares to try a first draft or outline? I can do the editorial work= if > needed, but someone needs to write something first. > > EHL > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From hardjono@mit.edu Wed Jun 9 12:17:56 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D72673A67EF for ; Wed, 9 Jun 2010 12:17:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.809 X-Spam-Level: X-Spam-Status: No, score=-1.809 tagged_above=-999 required=5 tests=[AWL=0.790, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O1skzsqR0cvu for ; Wed, 9 Jun 2010 12:17:55 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (DMZ-MAILSEC-SCANNER-7.MIT.EDU [18.7.68.36]) by core3.amsl.com (Postfix) with ESMTP id 8EB623A676A for ; Wed, 9 Jun 2010 12:17:55 -0700 (PDT) X-AuditID: 12074424-b7b9dae000002832-4a-4c0fe8e4de6a Received: from mailhub-auth-1.mit.edu (MAILHUB-AUTH-1.MIT.EDU [18.9.21.35]) by dmz-mailsec-scanner-7.mit.edu (Symantec Brightmail Gateway) with SMTP id E8.59.10290.4E8EF0C4; Wed, 9 Jun 2010 15:17:56 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-EXCHANGE-1.MIT.EDU [18.9.28.15]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id o59JHuZo009412 for ; Wed, 9 Jun 2010 15:17:56 -0400 Received: from oc11exedge2.exchange.mit.edu (OC11EXEDGE2.EXCHANGE.MIT.EDU [18.9.3.18]) ) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id o59JHoig007899 for ; Wed, 9 Jun 2010 15:17:56 -0400 Received: from oc11exhub4.exchange.mit.edu (18.9.3.14) by oc11exedge2.exchange.mit.edu (18.9.3.18) with Microsoft SMTP Server (TLS) id 8.1.393.1; Wed, 9 Jun 2010 15:17:41 -0400 Received: from EXPO10.exchange.mit.edu ([18.9.4.15]) by oc11exhub4.exchange.mit.edu ([18.9.3.14]) with mapi; Wed, 9 Jun 2010 15:17:41 -0400 From: Thomas Hardjono To: OAuth WG Date: Wed, 9 Jun 2010 15:17:38 -0400 Thread-Topic: draft-hardjono-oauth-kerberos-00.txt Thread-Index: AcsIBpL7X4EGb1s5RwersbAKjLl6pQAAOmrw Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_000A_01CB07E6.E572A740" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [OAUTH-WG] draft-hardjono-oauth-kerberos-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 19:17:56 -0000 ------=_NextPart_000_000A_01CB07E6.E572A740 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I was prompted to write this draft after the OATH WG meeting at the last IETF in March, in which several folks in the room were comparing OAuth = with Kerberos. Some people also suggested to me that a comparative doc might = be useful. http://www.ietf.org/internet-drafts/draft-hardjono-oauth-kerberos-00.txt The hope is that if OAuth 2.0 wanted to use the Needham-Schroeder = (Kerberos) authentication paradigm, that OAuth could learn from the two decades of Kerberos development. /thomas/ __________________________________________ --- On Wed, 6/9/10, Internet-Drafts@ietf.org wrote: > From: Internet-Drafts@ietf.org > Subject: I-D Action:draft-hardjono-oauth-kerberos-00.txt > To: i-d-announce@ietf.org > Date: Wednesday, June 9, 2010, 12:00 PM > A New Internet-Draft is available > from the on-line Internet-Drafts directories. >=20 > =A0=A0=A0 Title=A0 =A0 =A0 =A0 > =A0=A0=A0: OAuth 2.0 support for the Kerberos V5 > Authentication Protocol > =A0=A0=A0 Author(s)=A0 =A0 > =A0=A0=A0: T. Hardjono > =A0=A0=A0 Filename: draft-hardjono-oauth-kerberos-00.txt > =A0=A0=A0 Pages=A0 =A0 =A0 =A0 > =A0=A0=A0: 21 > =A0=A0=A0 Date=A0 =A0 =A0 =A0 =A0 > =A0 : 2010-06-09 >=20 > This draft proposes an OAuth2.0 profile for Kerberos > v5.=A0 We compare > the Kerberos protocol flow with the OAuth protocol flow and > as far as > possible map the relevant parameters in Kerberos to OAuth > parameters. > We propose the use of the OAuth 2.0 message flows and its > tokens to > carry Kerberos TGTs and Service Tickets in an opaque > manner. >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-hardjono-oauth-kerberos-00.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail > reader > implementation to automatically retrieve the ASCII version > of the > Internet-Draft. >=20 > -----Inline Attachment Follows----- >=20 > _______________________________________________ > 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.ietf.org/ietf/1shadow-sites.txt >=20 ------=_NextPart_000_000A_01CB07E6.E572A740 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILazCCAj0w ggGmAhEAzbp/VvDf5LxU/iKss3KqVTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMjgwODAxMjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBAOUZv22jVmEtmUhx9mfeuY3rt56GgAqRDvo4Ja9GiILlc6igmyRdDR/MZW4MsNBWhBiH mgabEKFz37RYOWtuwfYV1aioP6oSBo0xrH+wNNePNGeICc0UEeJORVZpH3gCgNrcR5EpuzbJY1zF 4Ncth3uhtzKwezC6Ki8xqu6jZ9rbAgMBAAEwDQYJKoZIhvcNAQECBQADgYEATD+4i8Zo3+5DMw5d 6abLB4RNejP/khv0Nq3YlSI2aBFsfELM85wuxAc/FLAPT/+Qknb54rxK6Y/NoIAK98Up8YIiXbix 3YEjo3slFUYweRb46gVLlH8dwhzI47f0EEA8E8NfH1PoSOSGtHuhNbB7Jbq4046rPzidADQAmPPR cZQwggRGMIIDr6ADAgECAhBm/Ufjwhnk6JrNmd31OsskMA0GCSqGSIb3DQEBBQUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNTEwMjgwMDAwMDBaFw0xNTEwMjcy MzU5NTlaMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g RzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDJ36zn6vj4AxTEAJLVwX42wjzvfHIV y8CrjD0clc5vHhAsPwDtlybmtsfmrUMdP6SHR0dMPlT4bPjH/LGevTBwvJexAwXqlfGtQMVEeksF ovJg/Nc6ZWLv/xB7ola7xU5wLdaiHzztsELoXo1XIaymmdkR6dIaB8B0R0IL/MU06v3muiTRHQgV N6LXc88BQS9jsjo/vqUabvTJSls9laYVuzUCGfnU77yPDnF2WbtLtj7W/FoW9NYOifJJ/mwM7RXp 2Yh1nHnOYCfdua11zi9zlXpAOoV1SbC432i8q80TgoURUKPgPAuuwApTzdcwb4UyRhvkSRDCbOKv H3n/27S1AgMBAAGjgf8wgfwwEgYDVR0TAQH/BAgwBgEB/wIBADBEBgNVHSAEPTA7MDkGC2CGSAGG +EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0P BAQDAgEGMBEGCWCGSAGG+EIBAQQEAwIBBjAuBgNVHREEJzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0 ZUxhYmVsMy0yMDQ4LTE1NTAdBgNVHQ4EFgQUEX1eGX08BN9qbNaiiho/Mdg7lFIwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwDQYJKoZIhvcNAQEFBQAD gYEAPKPaAmM6xJOqq3LT3K1QOB4MnhZKiLfu69n/D42VoNa7+moLrmGE2GhHie9PrLIfSUGbSTN2 k4uebrlDHGC9wtyKLYfBRcARcgQaayQqbG/n/AcTKdB3OiPn9cGFaBm/xgFUIBmuNYLMYjxhCcb0 1euwD6afM4Wa03GOUI+Z3WIwggTcMIIDxKADAgECAhAdbJ7qJ1t3pQoJyWI9GoXNMA0GCSqGSIb3 DQEBBQUAMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g RzIwHhcNMTAwMjE3MDAwMDAwWhcNMTEwMzA2MjM1OTU5WjCCARMxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4w HAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQgQ2xhc3Mg MSAtIE1pY3Jvc29mdCBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD1Rob21hcyBIYXJkam9ubzEfMB0G CSqGSIb3DQEJARYQaGFyZGpvbm9AbWl0LmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 5IPN5gsvYs8ugsfq1ndIZqRJXlbGSKsX+IH45pbnLeWPFWzfG7mxch4QhqOD0RUs2GCI1YNHPS8C sFyj1V05XnT0p/1eHa8eHOV2V3RVljq3P5R2+vhskoGE2Nwm1wi8YP9ce0Cs2Qf4wiPm9oL2ls5M yvOCR0aWfBkXD231vBUCAwEAAaOB4jCB3zAJBgNVHRMEAjAAMEQGA1UdIAQ9MDswOQYLYIZIAYb4 RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBQGCmCGSAGG+EUBBgcEBhYETm9u ZTBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlzaWduLmNv bS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAJrdkpPOIr2sXpSrE9hlj36x FOukzUivx4QwmsyLSFvMrkSQ/7NCGQ73O6DMlmJZbtQPMdIpqc9ZwPYhOkyQ9AaKz10yHVO8TkW2 CAN0Atk1ZfAF78C1h/jch429nYmjADnDZyDuyRUi2yW4ouJkX84Suj1SYaC5ptZVmmMUyRwcNV6/ iHewW8wsIf0mOqtP79RMAJ6oGh0XlUmzlahqtMbi3JX02D9gAVW9j8zXqtI0pHSpMNkNzkFp8GRd 5bxaCdQzszNIPfQGNIM0x7w97ZbF8z+F2yCRSL0+4G9kQxGRpxkd1OWjov5OJfmPvOyTZkkX9cmd Sivi3+fEDBgv0kIxggTEMIIEwAIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1 YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAdbJ7qJ1t3pQoJyWI9GoXNMAkGBSsOAwIaBQCgggMnMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDYwOTE5MTczOFowIwYJ KoZIhvcNAQkEMRYEFENwXkzb/7WNUsH/Jg9dDUMzFcl/MIG3BgkqhkiG9w0BCQ8xgakwgaYwCwYJ YIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcN AwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAsG CWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMAoGCCqGSIb3DQIFMIIBAwYJKwYB BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzICEB1snuonW3elCgnJYj0ahc0wggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAdbJ7qJ1t3pQoJ yWI9GoXNMA0GCSqGSIb3DQEBAQUABIGANr6txPIRj2h2UNdKl+lyUQPvSaRovlBGJa86UWan9ffr 697Caw8hb8nTDGHQr+cGkT2QJK22L64XKzXT54VenH+szD/gVfoL3pEHZYyq6ZMuX/9XKA42PTva hBtNxrAxuDAfQpCPEXDXRDaySvxR3CoIpc3mQnfRuaLKDR/tv98AAAAAAAA= ------=_NextPart_000_000A_01CB07E6.E572A740-- From breno@google.com Wed Jun 9 12:23:56 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 454FE3A67E7 for ; Wed, 9 Jun 2010 12:23:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.563 X-Spam-Level: X-Spam-Status: No, score=-103.563 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dpqakU1oAu5p for ; Wed, 9 Jun 2010 12:23:54 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 42EE33A67CF for ; Wed, 9 Jun 2010 12:23:54 -0700 (PDT) Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id o59JNtxZ007943 for ; Wed, 9 Jun 2010 12:23:55 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1276111435; bh=HjAGM7liiiE19LMLzwWKALLxIGM=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=c5FxldP3YU+kDLteQNRfzgOmNO3wGpAF5xn4xeelTorTogTpgdKZRI5uPJ5atWlxQ eDE+mpaHAphDXb8e3BsYw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding; b=mN32C+lUHnc2hU2Jpgmxp4FPSW09iaMMTj3wLmFWwh6/3auJrdYEOYN0H+k+knqmt 3VzrKKHKs3gR85e0SFyGQ== Received: from vws15 (vws15.prod.google.com [10.241.21.143]) by wpaz17.hot.corp.google.com with ESMTP id o59JNsoF029045 for ; Wed, 9 Jun 2010 12:23:54 -0700 Received: by vws15 with SMTP id 15so1328136vws.29 for ; Wed, 09 Jun 2010 12:23:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.117.1 with SMTP id p1mr208709ybc.274.1276111433382; Wed, 09 Jun 2010 12:23:53 -0700 (PDT) Received: by 10.151.118.9 with HTTP; Wed, 9 Jun 2010 12:23:53 -0700 (PDT) In-Reply-To: References: Date: Wed, 9 Jun 2010 12:23:53 -0700 Message-ID: From: Breno de Medeiros To: David Recordon Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 09 Jun 2010 12:27:18 -0700 Cc: OAuth WG Subject: Re: [OAUTH-WG] A display parameter for user authorization requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 19:23:56 -0000 On Wed, Jun 9, 2010 at 12:06, David Recordon wrote: > First draft of the UX Extension is at > http://github.com/daveman692/OAuth-2.0/raw/master/draft-recordon-oauth-v2= -ux-00.txt. > > Eran, I'm more than happy to have you take over as editor. > > I included Allen and Breno as authors since I followed Allen's > suggestion and adopted the language preference parameter from the > OpenID extension. I also included Luke as an author since he wrote the > first pass of a display parameter. That said, none of them have seen > this draft yet. Thanks. At a higher-level, is the extension model of OAuth2 to add new parameters at the top-level namespace? Works fine for extensions such as this one that are probably of interest to a large part of the community, but I wonder if we should give guidance for a generic approach to doing this (even if not adhering to it in the 'main' extensions). > > --David > > > On Tue, Apr 13, 2010 at 12:36 PM, Allen Tom wrote: >> At least with regards to the language preference, how about if we just c= opy >> the openid.ui.lang parameter from the OpenID UI Extension? >> >> http://svn.openid.net/repos/specifications/user_interface/1.0/trunk/open= id-user-interface-extension-1_0.html#anchor3 >> >> In flows in which the client redirects the user=92s web browser to autho= rize >> access, the client MAY send the Authorization Server a hint regarding th= e >> user=92s preferred language by sending the following parameter: >> >> =A0=A0=A0=A0lang >> =A0=A0=A0=A0=A0=A0=A0=A0The user=92s preferred languages as a [BCP 47] l= anguage priority list, >> represented as a comma-separated list of BCP 47 basic language ranges in >> decending priority order. For instance, the value =93fr-CA,fr-FR,en-CA= =94 >> represents the preference for French spoken in Canada, French spoken in >> France, followed by English spoken in Canada. >> >> The language preference hint SHOULD take precedence over the Accept-Lang= uage >> HTTP header sent by the user=92s browser, and SHOULD take precedence ove= r the >> language preference inferred by the user=92s IP Address. >> >> BCP 47: =A0http://tools.ietf.org/html/bcp47 >> >> Allen >> >> >> On 4/12/10 1:32 PM, "Eran Hammer-Lahav" wrote: >> >> Between language preferences, display configuration, and immediate check= , I >> think it might be worth to move that work to another draft. Timeline-wis= e, >> this has the potential of slowing us down. I also fear getting what is n= ow a >> pretty simple spec much more complicated. >> >> Anyone cares to try a first draft or outline? I can do the editorial wor= k if >> needed, but someone needs to write something first. >> >> EHL >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > --=20 --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) From recordond@gmail.com Wed Jun 9 12:27:37 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB07D3A6784 for ; Wed, 9 Jun 2010 12:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.447 X-Spam-Level: X-Spam-Status: No, score=-1.447 tagged_above=-999 required=5 tests=[AWL=1.152, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lsq1QwGMPgxj for ; Wed, 9 Jun 2010 12:27:35 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 59EB63A6878 for ; Wed, 9 Jun 2010 12:27:35 -0700 (PDT) Received: by iwn42 with SMTP id 42so6125518iwn.31 for ; Wed, 09 Jun 2010 12:27:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=q6CwmaCOUPDR8GoO7/mu1hIrL5CNXaemSj+cKPLbx5k=; b=SLtOxkVlle+VaAInWs/ah6OEQ3Wdr+3wkbxi8E0z7XkuNV6SXcfxV9twHLbwymnf3U 163h52uXSF8J+OUOTHFtL2s68VQ6mlZRlS+jlErGo8NDzrCV5WIx4Xwn21Wd5Elri4+v BCiHSryKeteu1xiE/Z0U/Z3uQGr91kQdSarJU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ca5K/JH8CUkIb4Vn+Vnyn8bEDK4N/X2yhJ/xOpPY4sQp+DHT2pAJCkaP+f4FZCa0Mx hgvaTuZ0imEDSaGKZwYkEjDZCNgm11jvzpi/1NMHn5jDeZi/k3Pc9i67hMuAULV1ub3X 4s/6rM9D7FznknoRnkoe68gbRAZsNVh7rOVgw= MIME-Version: 1.0 Received: by 10.42.7.72 with SMTP id d8mr9367424icd.11.1276111652127; Wed, 09 Jun 2010 12:27:32 -0700 (PDT) Received: by 10.231.192.4 with HTTP; Wed, 9 Jun 2010 12:27:32 -0700 (PDT) In-Reply-To: References: Date: Wed, 9 Jun 2010 12:27:32 -0700 Message-ID: From: David Recordon To: Breno de Medeiros Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: OAuth WG Subject: Re: [OAUTH-WG] A display parameter for user authorization requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 19:27:37 -0000 I believe that Eran is separately working on documenting the extension model. Let's leave that discussion for another thread. On Wed, Jun 9, 2010 at 12:23 PM, Breno de Medeiros wrote= : > On Wed, Jun 9, 2010 at 12:06, David Recordon wrote: >> First draft of the UX Extension is at >> http://github.com/daveman692/OAuth-2.0/raw/master/draft-recordon-oauth-v= 2-ux-00.txt. >> >> Eran, I'm more than happy to have you take over as editor. >> >> I included Allen and Breno as authors since I followed Allen's >> suggestion and adopted the language preference parameter from the >> OpenID extension. I also included Luke as an author since he wrote the >> first pass of a display parameter. That said, none of them have seen >> this draft yet. > > Thanks. > > At a higher-level, is the extension model of OAuth2 to add new > parameters at the top-level namespace? Works fine for extensions such > as this one that are probably of interest to a large part of the > community, but I wonder if we should give guidance for a generic > approach to doing this (even if not adhering to it in the 'main' > extensions). > >> >> --David >> >> >> On Tue, Apr 13, 2010 at 12:36 PM, Allen Tom wrote: >>> At least with regards to the language preference, how about if we just = copy >>> the openid.ui.lang parameter from the OpenID UI Extension? >>> >>> http://svn.openid.net/repos/specifications/user_interface/1.0/trunk/ope= nid-user-interface-extension-1_0.html#anchor3 >>> >>> In flows in which the client redirects the user=92s web browser to auth= orize >>> access, the client MAY send the Authorization Server a hint regarding t= he >>> user=92s preferred language by sending the following parameter: >>> >>> =A0=A0=A0=A0lang >>> =A0=A0=A0=A0=A0=A0=A0=A0The user=92s preferred languages as a [BCP 47] = language priority list, >>> represented as a comma-separated list of BCP 47 basic language ranges i= n >>> decending priority order. For instance, the value =93fr-CA,fr-FR,en-CA= =94 >>> represents the preference for French spoken in Canada, French spoken in >>> France, followed by English spoken in Canada. >>> >>> The language preference hint SHOULD take precedence over the Accept-Lan= guage >>> HTTP header sent by the user=92s browser, and SHOULD take precedence ov= er the >>> language preference inferred by the user=92s IP Address. >>> >>> BCP 47: =A0http://tools.ietf.org/html/bcp47 >>> >>> Allen >>> >>> >>> On 4/12/10 1:32 PM, "Eran Hammer-Lahav" wrote: >>> >>> Between language preferences, display configuration, and immediate chec= k, I >>> think it might be worth to move that work to another draft. Timeline-wi= se, >>> this has the potential of slowing us down. I also fear getting what is = now a >>> pretty simple spec much more complicated. >>> >>> Anyone cares to try a first draft or outline? I can do the editorial wo= rk if >>> needed, but someone needs to write something first. >>> >>> EHL >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> > > > > -- > --Breno > > +1 (650) 214-1007 desk > +1 (408) 212-0135 (Grand Central) > MTV-41-3 : 383-A > PST (GMT-8) / PDT(GMT-7) > From breno@google.com Wed Jun 9 12:31:35 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 091033A680D for ; Wed, 9 Jun 2010 12:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14cUTO5NGnSl for ; Wed, 9 Jun 2010 12:31:25 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id C64043A67B7 for ; Wed, 9 Jun 2010 12:30:56 -0700 (PDT) Received: from hpaq5.eem.corp.google.com (hpaq5.eem.corp.google.com [172.25.149.5]) by smtp-out.google.com with ESMTP id o59JUr47021928 for ; Wed, 9 Jun 2010 12:30:53 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1276111853; bh=ZEAR6hTfluSIFHje8fE2weL2ayo=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=iy1VEOjQ6QpYxvIxf64Q9F46AD119jLuy0vEn/EyrADU/f7FoSwv13QD0jV3I9Dde j9u9ukQtdFJxTw19oZPDA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding; b=YUVZFWl9YFdTLW54TkO0kWlRiSWAitIjqehtzFYwTj5jjkHczj/ACGwVPBArp1dcI BpD2uTdLPan4l+mKTGTnQ== Received: from ywh16 (ywh16.prod.google.com [10.192.8.16]) by hpaq5.eem.corp.google.com with ESMTP id o59JUQlA027449 for ; Wed, 9 Jun 2010 12:30:52 -0700 Received: by ywh16 with SMTP id 16so5177017ywh.32 for ; Wed, 09 Jun 2010 12:30:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.209.21 with SMTP id h21mr763957ybg.118.1276111851745; Wed, 09 Jun 2010 12:30:51 -0700 (PDT) Received: by 10.151.118.9 with HTTP; Wed, 9 Jun 2010 12:30:51 -0700 (PDT) In-Reply-To: References: Date: Wed, 9 Jun 2010 12:30:51 -0700 Message-ID: From: Breno de Medeiros To: David Recordon Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: OAuth WG Subject: Re: [OAUTH-WG] A display parameter for user authorization requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 19:31:35 -0000 On Wed, Jun 9, 2010 at 12:27, David Recordon wrote: > I believe that Eran is separately working on documenting the extension > model. Let's leave that discussion for another thread. Sounds good. > > > On Wed, Jun 9, 2010 at 12:23 PM, Breno de Medeiros wro= te: >> On Wed, Jun 9, 2010 at 12:06, David Recordon wrote= : >>> First draft of the UX Extension is at >>> http://github.com/daveman692/OAuth-2.0/raw/master/draft-recordon-oauth-= v2-ux-00.txt. >>> >>> Eran, I'm more than happy to have you take over as editor. >>> >>> I included Allen and Breno as authors since I followed Allen's >>> suggestion and adopted the language preference parameter from the >>> OpenID extension. I also included Luke as an author since he wrote the >>> first pass of a display parameter. That said, none of them have seen >>> this draft yet. >> >> Thanks. >> >> At a higher-level, is the extension model of OAuth2 to add new >> parameters at the top-level namespace? Works fine for extensions such >> as this one that are probably of interest to a large part of the >> community, but I wonder if we should give guidance for a generic >> approach to doing this (even if not adhering to it in the 'main' >> extensions). >> >>> >>> --David >>> >>> >>> On Tue, Apr 13, 2010 at 12:36 PM, Allen Tom wrote: >>>> At least with regards to the language preference, how about if we just= copy >>>> the openid.ui.lang parameter from the OpenID UI Extension? >>>> >>>> http://svn.openid.net/repos/specifications/user_interface/1.0/trunk/op= enid-user-interface-extension-1_0.html#anchor3 >>>> >>>> In flows in which the client redirects the user=92s web browser to aut= horize >>>> access, the client MAY send the Authorization Server a hint regarding = the >>>> user=92s preferred language by sending the following parameter: >>>> >>>> =A0=A0=A0=A0lang >>>> =A0=A0=A0=A0=A0=A0=A0=A0The user=92s preferred languages as a [BCP 47]= language priority list, >>>> represented as a comma-separated list of BCP 47 basic language ranges = in >>>> decending priority order. For instance, the value =93fr-CA,fr-FR,en-CA= =94 >>>> represents the preference for French spoken in Canada, French spoken i= n >>>> France, followed by English spoken in Canada. >>>> >>>> The language preference hint SHOULD take precedence over the Accept-La= nguage >>>> HTTP header sent by the user=92s browser, and SHOULD take precedence o= ver the >>>> language preference inferred by the user=92s IP Address. >>>> >>>> BCP 47: =A0http://tools.ietf.org/html/bcp47 >>>> >>>> Allen >>>> >>>> >>>> On 4/12/10 1:32 PM, "Eran Hammer-Lahav" wrote: >>>> >>>> Between language preferences, display configuration, and immediate che= ck, I >>>> think it might be worth to move that work to another draft. Timeline-w= ise, >>>> this has the potential of slowing us down. I also fear getting what is= now a >>>> pretty simple spec much more complicated. >>>> >>>> Anyone cares to try a first draft or outline? I can do the editorial w= ork if >>>> needed, but someone needs to write something first. >>>> >>>> EHL >>>> >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>> >> >> >> >> -- >> --Breno >> >> +1 (650) 214-1007 desk >> +1 (408) 212-0135 (Grand Central) >> MTV-41-3 : 383-A >> PST (GMT-8) / PDT(GMT-7) >> > --=20 --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) From christianlholm@gmail.com Wed Jun 9 13:58:45 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3606F3A67E3 for ; Wed, 9 Jun 2010 13:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.776 X-Spam-Level: X-Spam-Status: No, score=-0.776 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7aOuFvZmD8Qr for ; Wed, 9 Jun 2010 13:58:44 -0700 (PDT) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id 11DCA3A63C9 for ; Wed, 9 Jun 2010 13:58:43 -0700 (PDT) Received: by ewy24 with SMTP id 24so1715615ewy.14 for ; Wed, 09 Jun 2010 13:58:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=SEuM+Xt8hZnK0fZDVdUMbtjOM8zU65le3fxUmJjLJuE=; b=N0yuNNcL5kWc9rZt6OGEw0ZYXmur47FZbHH1RpErj9B/rI6gYRvLqdLBPmV3Eer1Hv g9bS2FvX7KrBqde+PRsamNurhlm9+uhbcolHVWFbJsNgTY+K/HMk9oV7wETBaR2v1l3y sYVbl2t2mVc5Q0MUL17JbS7vNmyy4P/YQBao8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=J5FhjMbWqc2cFx8q2DQ41+3x1exDWjt4znYf1ARzPAIeki9eGlGykUaamuqf9/W3lu nIueYX2fqHPav7/ZDDMrR3Cn1e8N0OhbK/bH94nX17IKKWQkTEE89o9arTrpyYRmBUgJ hZEOnH7TBxzNmAtZe8PKhvRALXPlD1nnFWeVY= MIME-Version: 1.0 Received: by 10.213.102.3 with SMTP id e3mr1758132ebo.99.1276117122234; Wed, 09 Jun 2010 13:58:42 -0700 (PDT) Sender: christianlholm@gmail.com Received: by 10.213.29.67 with HTTP; Wed, 9 Jun 2010 13:58:42 -0700 (PDT) Date: Wed, 9 Jun 2010 22:58:42 +0200 X-Google-Sender-Auth: q2hKbpVkKJrvyTw90CTHk0qLQGU Message-ID: From: Christian Holm To: oauth@ietf.org Content-Type: multipart/alternative; boundary=0015174bea84c363e804889f2bb3 X-Mailman-Approved-At: Wed, 09 Jun 2010 14:03:18 -0700 Subject: [OAUTH-WG] Recommended token format X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 20:59:45 -0000 --0015174bea84c363e804889f2bb3 Content-Type: text/plain; charset=ISO-8859-1 Hi We are in the process of defining a REST interface for our application, and are looking to use OAuth 2 as the authentication mechanism. I have read through the latest specification, and it seems like a perfect fit for our needs. Our main dilemma is with regard to the format of the access token. As I understand there are basicly two options: * Use the token as an "artifact", ie. just a randomly generated string which is stored centrally. When accessing a resource with the token, the token is verified by looking it up in the central repository and making sure the requested resource can be accessed. * Encrypt the authentication into the token. This way the resource server can verify the access directly from the token without checking with the central repository. This is particularly a good idea if the authentication servers and resource servers are hosted in different data centers. We would like to go with the second option, but since my cryptology knowledge is less than could be wished, I have a had time deciding on the format. I would assume we would have to put the user, the expiry time and the scopes into the token (perhaps with some random letters in between) and then encrypt that using f.ex. AES. Are there any recommendations on the format and encryption method to use? I realize that publicly disclosing the format could weaken it slightly, so the recommendations will have to be fairly generic. Thanks for the help and the excellent work on the OAuth 2.0. Christian Holm --0015174bea84c363e804889f2bb3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi
=A0
We are in the process of defining a REST interface for our application= , and are looking to use OAuth 2 as the authentication mechanism. I have re= ad through the latest specification, and it seems like a perfect fit for ou= r needs. Our main dilemma is with regard to the format of the access token.= As I understand there=A0are basicly two options:
=A0
* Use the token as an "artifact", ie. just a randomly genera= ted string which is stored centrally. When accessing a resource with the to= ken, the token is verified by looking it up in the central repository and m= aking sure the requested resource can be accessed.
* Encrypt the authentication into the token. This way the resource ser= ver can verify the access directly from the token without checking with the= central repository. This is particularly a good idea if the authentication= servers and resource servers are hosted in different data centers.
=A0
We would like to go with the second option, but since my cryptology kn= owledge is less than could be wished, I have a had time deciding on the for= mat. I would assume we would have to put the user, the expiry time and the = scopes=A0into the token (perhaps with some random letters in between) and t= hen encrypt that using f.ex. AES. Are there any recommendations on the form= at and encryption method to use? I realize that publicly disclosing the for= mat could weaken it slightly, so the recommendations will have to be fairly= generic.
=A0
Thanks for the help and the excellent work on the OAuth 2.0.
=A0
Christian Holm
--0015174bea84c363e804889f2bb3-- From eran@hueniverse.com Wed Jun 9 14:54:12 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2191C3A680D for ; Wed, 9 Jun 2010 14:54:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TlMxU2fr+-Lf for ; Wed, 9 Jun 2010 14:54:06 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 17F673A67D9 for ; Wed, 9 Jun 2010 14:54:06 -0700 (PDT) Received: (qmail 31785 invoked from network); 9 Jun 2010 21:54:07 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 9 Jun 2010 21:54:05 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 9 Jun 2010 14:54:05 -0700 From: Eran Hammer-Lahav To: "recordond@gmail.com" , Breno de Medeiros Date: Wed, 9 Jun 2010 14:54:03 -0700 Thread-Topic: [OAUTH-WG] A display parameter for user authorization requests Thread-Index: AcsICdGxO1TLd5w8QIKqDgG9/7yuCQAFHSD7 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C8355B8B355EFeranhueniversecom_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] A display parameter for user authorization requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 21:54:12 -0000 --_000_C8355B8B355EFeranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable -07 will include an initial extensibility model (which I need as well for t= he discovery parameters, signature proposal, etc.) EHL On 6/9/10 12:27 PM, "recordond@gmail.com" wrote: I believe that Eran is separately working on documenting the extension model. Let's leave that discussion for another thread. On Wed, Jun 9, 2010 at 12:23 PM, Breno de Medeiros wrote= : > On Wed, Jun 9, 2010 at 12:06, David Recordon wrote: >> First draft of the UX Extension is at >> http://github.com/daveman692/OAuth-2.0/raw/master/draft-recordon-oauth-v= 2-ux-00.txt. >> >> Eran, I'm more than happy to have you take over as editor. >> >> I included Allen and Breno as authors since I followed Allen's >> suggestion and adopted the language preference parameter from the >> OpenID extension. I also included Luke as an author since he wrote the >> first pass of a display parameter. That said, none of them have seen >> this draft yet. > > Thanks. > > At a higher-level, is the extension model of OAuth2 to add new > parameters at the top-level namespace? Works fine for extensions such > as this one that are probably of interest to a large part of the > community, but I wonder if we should give guidance for a generic > approach to doing this (even if not adhering to it in the 'main' > extensions). > >> >> --David >> >> >> On Tue, Apr 13, 2010 at 12:36 PM, Allen Tom wrote: >>> At least with regards to the language preference, how about if we just = copy >>> the openid.ui.lang parameter from the OpenID UI Extension? >>> >>> http://svn.openid.net/repos/specifications/user_interface/1.0/trunk/ope= nid-user-interface-extension-1_0.html#anchor3 >>> >>> In flows in which the client redirects the user's web browser to author= ize >>> access, the client MAY send the Authorization Server a hint regarding t= he >>> user's preferred language by sending the following parameter: >>> >>> lang >>> The user's preferred languages as a [BCP 47] language priority = list, >>> represented as a comma-separated list of BCP 47 basic language ranges i= n >>> decending priority order. For instance, the value "fr-CA,fr-FR,en-CA" >>> represents the preference for French spoken in Canada, French spoken in >>> France, followed by English spoken in Canada. >>> >>> The language preference hint SHOULD take precedence over the Accept-Lan= guage >>> HTTP header sent by the user's browser, and SHOULD take precedence over= the >>> language preference inferred by the user's IP Address. >>> >>> BCP 47: http://tools.ietf.org/html/bcp47 >>> >>> Allen >>> >>> >>> On 4/12/10 1:32 PM, "Eran Hammer-Lahav" wrote: >>> >>> Between language preferences, display configuration, and immediate chec= k, I >>> think it might be worth to move that work to another draft. Timeline-wi= se, >>> this has the potential of slowing us down. I also fear getting what is = now a >>> pretty simple spec much more complicated. >>> >>> Anyone cares to try a first draft or outline? I can do the editorial wo= rk if >>> needed, but someone needs to write something first. >>> >>> EHL >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> > > > > -- > --Breno > > +1 (650) 214-1007 desk > +1 (408) 212-0135 (Grand Central) > MTV-41-3 : 383-A > PST (GMT-8) / PDT(GMT-7) > --_000_C8355B8B355EFeranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] A display parameter for user authorization requests</= TITLE> </HEAD> <BODY> <FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:= 11pt'>-07 will include an initial extensibility model (which I need as well= for the discovery parameters, signature proposal, etc.)<BR> <BR> EHL<BR> <BR> <BR> On 6/9/10 12:27 PM, "<a href=3D"recordond@gmail.com">recordond@gmail.c= om</a>" <<a href=3D"recordond@gmail.com">recordond@gmail.com</a>>= ; wrote:<BR> <BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"= ><SPAN STYLE=3D'font-size:11pt'>I believe that Eran is separately working o= n documenting the extension<BR> model. Let's leave that discussion for another thread.<BR> <BR> <BR> On Wed, Jun 9, 2010 at 12:23 PM, Breno de Medeiros <<a href=3D"breno@goo= gle.com">breno@google.com</a>> wrote:<BR> > On Wed, Jun 9, 2010 at 12:06, David Recordon <<a href=3D"recordond@= gmail.com">recordond@gmail.com</a>> wrote:<BR> >> First draft of the UX Extension is at<BR> >> <a href=3D"http://github.com/daveman692/OAuth-2.0/raw/master/draft= -recordon-oauth-v2-ux-00.txt">http://github.com/daveman692/OAuth-2.0/raw/ma= ster/draft-recordon-oauth-v2-ux-00.txt</a>.<BR> >><BR> >> Eran, I'm more than happy to have you take over as editor.<BR> >><BR> >> I included Allen and Breno as authors since I followed Allen's<BR> >> suggestion and adopted the language preference parameter from the<= BR> >> OpenID extension. I also included Luke as an author since he wrote= the<BR> >> first pass of a display parameter. That said, none of them have se= en<BR> >> this draft yet.<BR> ><BR> > Thanks.<BR> ><BR> > At a higher-level, is the extension model of OAuth2 to add new<BR> > parameters at the top-level namespace? Works fine for extensions such<= BR> > as this one that are probably of interest to a large part of the<BR> > community, but I wonder if we should give guidance for a generic<BR> > approach to doing this (even if not adhering to it in the 'main'<BR> > extensions).<BR> ><BR> >><BR> >> --David<BR> >><BR> >><BR> >> On Tue, Apr 13, 2010 at 12:36 PM, Allen Tom <<a href=3D"atom@ya= hoo-inc.com">atom@yahoo-inc.com</a>> wrote:<BR> >>> At least with regards to the language preference, how about if= we just copy<BR> >>> the openid.ui.lang parameter from the OpenID UI Extension?<BR> >>><BR> >>> <a href=3D"http://svn.openid.net/repos/specifications/user_int= erface/1.0/trunk/openid-user-interface-extension-1_0.html#anchor3">http://s= vn.openid.net/repos/specifications/user_interface/1.0/trunk/openid-user-int= erface-extension-1_0.html#anchor3</a><BR> >>><BR> >>> In flows in which the client redirects the user’s web br= owser to authorize<BR> >>> access, the client MAY send the Authorization Server a hint re= garding the<BR> >>> user’s preferred language by sending the following param= eter:<BR> >>><BR> >>> =A0=A0=A0=A0lang<BR> >>> =A0=A0=A0=A0=A0=A0=A0=A0The user’s preferred languages a= s a [BCP 47] language priority list,<BR> >>> represented as a comma-separated list of BCP 47 basic language= ranges in<BR> >>> decending priority order. For instance, the value “fr-CA= ,fr-FR,en-CA”<BR> >>> represents the preference for French spoken in Canada, French = spoken in<BR> >>> France, followed by English spoken in Canada.<BR> >>><BR> >>> The language preference hint SHOULD take precedence over the A= ccept-Language<BR> >>> HTTP header sent by the user’s browser, and SHOULD take = precedence over the<BR> >>> language preference inferred by the user’s IP Address.<B= R> >>><BR> >>> BCP 47: =A0<a href=3D"http://tools.ietf.org/html/bcp47">http:/= /tools.ietf.org/html/bcp47</a><BR> >>><BR> >>> Allen<BR> >>><BR> >>><BR> >>> On 4/12/10 1:32 PM, "Eran Hammer-Lahav" <<a href= =3D"eran@hueniverse.com">eran@hueniverse.com</a>> wrote:<BR> >>><BR> >>> Between language preferences, display configuration, and immed= iate check, I<BR> >>> think it might be worth to move that work to another draft. Ti= meline-wise,<BR> >>> this has the potential of slowing us down. I also fear getting= what is now a<BR> >>> pretty simple spec much more complicated.<BR> >>><BR> >>> Anyone cares to try a first draft or outline? I can do the edi= torial work if<BR> >>> needed, but someone needs to write something first.<BR> >>><BR> >>> EHL<BR> >>><BR> >>><BR> >>><BR> >>> _______________________________________________<BR> >>> OAuth mailing list<BR> >>> <a href=3D"OAuth@ietf.org">OAuth@ietf.org</a><BR> >>> <a href=3D"https://www.ietf.org/mailman/listinfo/oauth">https:= //www.ietf.org/mailman/listinfo/oauth</a><BR> >>><BR> >>><BR> >><BR> ><BR> ><BR> ><BR> > --<BR> > --Breno<BR> ><BR> > +1 (650) 214-1007 desk<BR> > +1 (408) 212-0135 (Grand Central)<BR> > MTV-41-3 : 383-A<BR> > PST (GMT-8) / PDT(GMT-7)<BR> ><BR> <BR> </SPAN></FONT></BLOCKQUOTE> </BODY> </HTML> --_000_C8355B8B355EFeranhueniversecom_-- From jpanzer@google.com Wed Jun 9 16:05:39 2010 Return-Path: <jpanzer@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD1B53A6926 for <oauth@core3.amsl.com>; Wed, 9 Jun 2010 16:05:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.117 X-Spam-Level: X-Spam-Status: No, score=-100.117 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jx2IczYGWyct for <oauth@core3.amsl.com>; Wed, 9 Jun 2010 16:05:38 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id C94D73A6893 for <oauth@ietf.org>; Wed, 9 Jun 2010 16:05:37 -0700 (PDT) Received: from hpaq6.eem.corp.google.com (hpaq6.eem.corp.google.com [172.25.149.6]) by smtp-out.google.com with ESMTP id o59N5V8m006102 for <oauth@ietf.org>; Wed, 9 Jun 2010 16:05:31 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1276124732; bh=MhH9iVqyh8e+k4fw3P0TFd+Jyb8=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=iVWOg7PtcxORtdIyf9o9CGwf82e4HTiiWzLKGgvtT78azvL+G+Rj0VLV4FX0dKjCp IIk9Qo6BOo+9an1/uePaw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type; b=TzF0uk/ihYVx/hIe7Edq62kX8jmXz2M5rOWjUWiyea5Seq9x+cidv4Cm2Ssi9luUC dsDfB5FT64euGahg7MbOg== Received: from vws5 (vws5.prod.google.com [10.241.21.133]) by hpaq6.eem.corp.google.com with ESMTP id o59N51gZ001695 for <oauth@ietf.org>; Wed, 9 Jun 2010 16:05:30 -0700 Received: by vws5 with SMTP id 5so3456764vws.11 for <oauth@ietf.org>; Wed, 09 Jun 2010 16:05:30 -0700 (PDT) Received: by 10.224.87.83 with SMTP id v19mr2481258qal.392.1276124730292; Wed, 09 Jun 2010 16:05:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.82.196 with HTTP; Wed, 9 Jun 2010 16:05:10 -0700 (PDT) In-Reply-To: <AANLkTimIXMReEaB3ShbZIjWjiBH-VUjrvHgKHCzgVOu0@mail.gmail.com> References: <255B9BB34FB7D647A506DC292726F6E11262FEE7D8@WSMSG3153V.srv.dir.telstra.com> <AANLkTimIXMReEaB3ShbZIjWjiBH-VUjrvHgKHCzgVOu0@mail.gmail.com> From: John Panzer <jpanzer@google.com> Date: Wed, 9 Jun 2010 16:05:10 -0700 Message-ID: <AANLkTinR-I_CNZNNF8dw30xespwGOWVKcE-ygpUwQMta@mail.gmail.com> To: Nat Sakimura <sakimura@gmail.com> Content-Type: multipart/alternative; boundary=00c09f8fe7a53d01360488a0f179 Cc: oauth <oauth@ietf.org> Subject: Re: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 09 Jun 2010 23:05:39 -0000 --00c09f8fe7a53d01360488a0f179 Content-Type: text/plain; charset=ISO-8859-1 So the thinking is that this is just a generic "include" or "one level of indirection" feature that is orthogonal to other flows? FWIW, I really like that notion. It's also very easy to describe and understand conceptually. -- John Panzer / Google jpanzer@google.com / abstractioneer.org <http://www.abstractioneer.org/> / @jpanzer On Mon, Jun 7, 2010 at 7:53 PM, Nat Sakimura <sakimura@gmail.com> wrote: > I fully agree on it. > > Instead of doing as a flow, defining request_url as one of the core > variable would be better. > The question then is, whether this community accepts the idea. > > > On Mon, Jun 7, 2010 at 10:51 PM, Manger, James H < > James.H.Manger@team.telstra.com> wrote: > >> Nat, >> >> > On the other hand, you are starting to think of it as a generic >> "include" mechanism, are you? >> >> Yes. That feels like the simplest mental model for this functionality, and >> the simplest way to specify it. >> >> -- >> James Manger >> > > > > -- > Nat Sakimura (=nat) > http://www.sakimura.org/en/ > http://twitter.com/_nat_en > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --00c09f8fe7a53d01360488a0f179 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable So the thinking is that this is just a generic "include" or "= ;one level of indirection" feature that is orthogonal to other flows?<= div><br></div><div>FWIW, I really like that notion. =A0It's also very e= asy to describe and understand conceptually.<br clear=3D"all"> <div dir=3D"ltr">--<br>John Panzer / Google<br><a href=3D"mailto:jpanzer@go= ogle.com" target=3D"_blank">jpanzer@google.com</a> / <a href=3D"http://www.= abstractioneer.org/" target=3D"_blank">abstractioneer.org</a> / @jpanzer</d= iv><br> <br><br><div class=3D"gmail_quote">On Mon, Jun 7, 2010 at 7:53 PM, Nat Saki= mura <span dir=3D"ltr"><<a href=3D"mailto:sakimura@gmail.com">sakimura@g= mail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style= =3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> I fully agree on it.=A0<div><br></div><div>Instead of doing as a flow, defi= ning request_url as one of the core variable would be better.=A0</div><div>= The question then is, whether this community accepts the idea.=A0<div class= =3D"im"> <br><br><div class=3D"gmail_quote"> On Mon, Jun 7, 2010 at 10:51 PM, Manger, James H <span dir=3D"ltr"><<a h= ref=3D"mailto:James.H.Manger@team.telstra.com" target=3D"_blank">James.H.Ma= nger@team.telstra.com</a>></span> wrote:<br><blockquote class=3D"gmail_q= uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e= x"> Nat,<br> <div><br> > On the other hand, you are starting to think of it as a generic "= include" mechanism, are you?<br> <br> </div>Yes. That feels like the simplest mental model for this functionality= , and the simplest way to specify it.<br> <br> --<br> <font color=3D"#888888">James Manger<br> </font></blockquote></div><br><br clear=3D"all"><br></div><div class=3D"im"= >-- <br>Nat Sakimura (=3Dnat)<br><a href=3D"http://www.sakimura.org/en/" ta= rget=3D"_blank">http://www.sakimura.org/en/</a><br><a href=3D"http://twitte= r.com/_nat_en" target=3D"_blank">http://twitter.com/_nat_en</a><br> </div></div> <br>_______________________________________________<br> OAuth mailing list<br> <a href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_blank">h= ttps://www.ietf.org/mailman/listinfo/oauth</a><br> <br></blockquote></div><br></div> --00c09f8fe7a53d01360488a0f179-- From wmills@yahoo-inc.com Wed Jun 9 16:11:33 2010 Return-Path: <wmills@yahoo-inc.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80CAC3A688B for <oauth@core3.amsl.com>; Wed, 9 Jun 2010 16:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.851 X-Spam-Level: X-Spam-Status: No, score=-14.851 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, IP_NOT_FRIENDLY=0.334, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QFcB28K6IVtg for <oauth@core3.amsl.com>; Wed, 9 Jun 2010 16:11:31 -0700 (PDT) Received: from mrout1-b.corp.re1.yahoo.com (mrout1-b.corp.re1.yahoo.com [69.147.107.20]) by core3.amsl.com (Postfix) with ESMTP id 729C73A68FA for <oauth@ietf.org>; Wed, 9 Jun 2010 16:11:31 -0700 (PDT) Received: from SNV-EXBH01.ds.corp.yahoo.com (snv-exbh01.ds.corp.yahoo.com [207.126.227.249]) by mrout1-b.corp.re1.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o59NBG7G025705; Wed, 9 Jun 2010 16:11:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:x-mimeole:content-class:mime-version: content-type:content-transfer-encoding:subject:date:message-id: in-reply-to:x-ms-has-attach:x-ms-tnef-correlator:thread-topic: thread-index:references:from:to:cc:return-path:x-originalarrivaltime; b=JNbAm9p3azbCtlWak8ln032hyHcGG1hA6J38Uqb+TSPuaqYXUdOYEGXfUTKDFNT6 Received: from SNV-EXVS08.ds.corp.yahoo.com ([207.126.227.8]) by SNV-EXBH01.ds.corp.yahoo.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Jun 2010 16:11:16 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Jun 2010 16:10:16 -0700 Message-ID: <012AB2B223CB3F4BB846962876F4721705795A00@SNV-EXVS08.ds.corp.yahoo.com> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF6E8E@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] proposal for factoring out request signing in OAuth 2 Thread-Index: AcsAQOuWZ8vnc+/WTui3jk2pAveNrAHWVjGAACOWtaA= References: <AANLkTim-Wc3t9CkTEx2HkhRDB5eGgmqBgqaiDO25TDYB@mail.gmail.com><AANLkTins7-cUV6Ly6mDjRYHJTuWPWWsLe3DvUbLnfPwO@mail.gmail.com><AANLkTikjNTqsk64pC9UyMuKFHBScyNBpsgkkt0OKlU3X@mail.gmail.com><1CD74F85-52F4-4024-9CF7-5FC6A9DBEDB0@lodderstedt.net><AANLkTilJ5l7aOLB4CQlr7R6Br-2oqo-rFs0S5QMJAAMI@mail.gmail.com><4C02B4AE.4000200@lodderstedt.net><AANLkTik2dVLWQHwhlBy2YDeWxFsLxFBfBURVgC5Hv5f0@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3EAF6E8E@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: "William Mills" <wmills@yahoo-inc.com> To: "Eran Hammer-Lahav" <eran@hueniverse.com>, "Brian Eaton" <beaton@google.com> X-OriginalArrivalTime: 09 Jun 2010 23:11:16.0564 (UTC) FILETIME=[10051140:01CB0829] Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] proposal for factoring out request signing in OAuth 2 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 09 Jun 2010 23:11:33 -0000 I thought perhaps the most game changing suggestion on signatures was saying "the client has to know what it's sending to sign". Much of the complexity of the 1.0 signatures was agreeing on what was signed. Was there strong objection to making this simplifying assumption? I think signatures have value. =20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]=20 > On Behalf Of Eran Hammer-Lahav > Sent: Tuesday, June 08, 2010 11:17 PM > To: Brian Eaton > Cc: OAuth WG > Subject: Re: [OAUTH-WG] proposal for factoring out request=20 > signing in OAuth 2 >=20 > We are clearly not making any progress on signatures (for=20 > over a year). >=20 > 1. I agree with Brian (it does happen on occasion) that this=20 > is an impossible list to turn into a single solution. > 2. I'm tired of having this discussion - mostly because we=20 > are unable to agree on the requirements. > 3. We already decided not to mandate TLS for bearer tokens,=20 > just make it a strong suggestion. >=20 > I consider this my decision as editor (but feel free to=20 > disagree with the decision or the powers I granted myself): >=20 > 1. I am going to move all the signature stuff out of the core spec. > 2. I am going to draft a new (individual submission)=20 > signature proposal using the current signature parameters and method. > 3. I expect Brian, Dirk, and others to submit their own=20 > separate signature proposals as individual submissions. > 4. The WG can decide if any of the proposals qualify for=20 > "upgrade" to WG items and the chairs can decide who will edit=20 > these if they become WG items. The WG can also decide if any=20 > of those accepted as WG items should stay in separate specs=20 > or merged into the core spec. >=20 > EHL >=20 > > -----Original Message----- > > From: oauth-bounces@ietf.org=20 > [mailto:oauth-bounces@ietf.org] On Behalf=20 > > Of Brian Eaton > > Sent: Sunday, May 30, 2010 2:42 PM > > To: Torsten Lodderstedt > > Cc: OAuth WG > > Subject: Re: [OAUTH-WG] proposal for factoring out request=20 > signing in=20 > > OAuth > > 2 > >=20 > > On Sun, May 30, 2010 at 11:55 AM, Torsten Lodderstedt=20 > > <torsten@lodderstedt.net> wrote: > > > Regarding client secrets: One of the major obstacles when using=20 > > > OAuth 1.0 in large deployments is the need for sharing client=20 > > > secrets between authz server and resource server. Overcoming that=20 > > > obstacle was an important requirement for OAuth2 from the=20 > beginning,=20 > > > expressed by a > > lot of people. > >=20 > > There are actually a bunch of fundamentally conflicting=20 > requirements=20 > > for signatures from the various folks contributing to this=20 > working group. > >=20 > > - no shared secrets with protected resources at all > >=20 > > - no permanent shared secrets with protected resources > >=20 > > - no shared secrets with clients > >=20 > > - allow access tokens to be used by multiple clients=20 > without sharing=20 > > consumer secrets > >=20 > > - don't allow access tokens to be shared by multiple clients > >=20 > > - don't use public key, because it's slow > >=20 > > - use public key, because it makes key distribution easier > >=20 > > - don't use cryptography at all, because it's too complicated > >=20 > > - don't use bearer tokens at all, because they might leak > >=20 > > - keep access tokens short > >=20 > > - encode lots of information in the access token > >=20 > > I'm sure I'm forgetting some. > >=20 > > For the record, I think *every single one* of those=20 > requirements makes=20 > > sense in certain contexts. > >=20 > > I'm pretty sure we're going to be able to agree on the=20 > cryptographic=20 > > primitives without too much trouble. > >=20 > > But we're going to have to split out profiles to deal with the=20 > > different key distribution challenges. > >=20 > > Cheers, > > Brian > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 From balfanz@google.com Wed Jun 9 16:27:17 2010 Return-Path: <balfanz@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0B9D3A6950 for <oauth@core3.amsl.com>; Wed, 9 Jun 2010 16:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.769 X-Spam-Level: X-Spam-Status: No, score=-100.769 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1bmJ8gvpAF4o for <oauth@core3.amsl.com>; Wed, 9 Jun 2010 16:27:14 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id A169E3A6925 for <oauth@ietf.org>; Wed, 9 Jun 2010 16:27:09 -0700 (PDT) Received: from hpaq13.eem.corp.google.com (hpaq13.eem.corp.google.com [172.25.149.13]) by smtp-out.google.com with ESMTP id o59NR9KV025126 for <oauth@ietf.org>; Wed, 9 Jun 2010 16:27:09 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1276126029; bh=hQTtlxoiMoV8rPjuNwafZPim3Mg=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=QHV6bsS0iZMzRul+6byI1gnTIkoBuhMMyAf9HQu+IxoJDE7ovYktJ1Qtd1zOJeiqg /oUsObPp1B1eF1wqOXWNw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type; b=tKegZ0Uy60QT53Ir+AD4l5xJiTO3Wn7IRVzSqddVBDiv2b3Pn7sfYKBzEvSZ8wZHT iIqXEwkSCLM1poPq/ejiA== Received: from iwn38 (iwn38.prod.google.com [10.241.68.102]) by hpaq13.eem.corp.google.com with ESMTP id o59NR8jI032093 for <oauth@ietf.org>; Wed, 9 Jun 2010 16:27:08 -0700 Received: by iwn38 with SMTP id 38so1226626iwn.11 for <oauth@ietf.org>; Wed, 09 Jun 2010 16:27:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.196.151 with SMTP id eg23mr8419802ibb.179.1276126027845; Wed, 09 Jun 2010 16:27:07 -0700 (PDT) Received: by 10.231.68.144 with HTTP; Wed, 9 Jun 2010 16:27:07 -0700 (PDT) In-Reply-To: <AANLkTinR-I_CNZNNF8dw30xespwGOWVKcE-ygpUwQMta@mail.gmail.com> References: <255B9BB34FB7D647A506DC292726F6E11262FEE7D8@WSMSG3153V.srv.dir.telstra.com> <AANLkTimIXMReEaB3ShbZIjWjiBH-VUjrvHgKHCzgVOu0@mail.gmail.com> <AANLkTinR-I_CNZNNF8dw30xespwGOWVKcE-ygpUwQMta@mail.gmail.com> Date: Wed, 9 Jun 2010 16:27:07 -0700 Message-ID: <AANLkTimceNut-5zVHxnBsHCsMDKUv8YWFcpf6N9wmHta@mail.gmail.com> From: Dirk Balfanz <balfanz@google.com> To: John Panzer <jpanzer@google.com> Content-Type: multipart/alternative; boundary=001636e0b875940fa60488a13e2f Cc: oauth <oauth@ietf.org> Subject: Re: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 09 Jun 2010 23:27:17 -0000 --001636e0b875940fa60488a13e2f Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 9, 2010 at 4:05 PM, John Panzer <jpanzer@google.com> wrote: > So the thinking is that this is just a generic "include" or "one level of > indirection" feature that is orthogonal to other flows? > > FWIW, I really like that notion. It's also very easy to describe and > understand conceptually. > +1 How does the Client decide to use this new level of indirection? When the User Agent looks like it wouldn't like long URLs? Dirk. > -- > John Panzer / Google > jpanzer@google.com / abstractioneer.org <http://www.abstractioneer.org/> / > @jpanzer > > > > On Mon, Jun 7, 2010 at 7:53 PM, Nat Sakimura <sakimura@gmail.com> wrote: > >> I fully agree on it. >> >> Instead of doing as a flow, defining request_url as one of the core >> variable would be better. >> The question then is, whether this community accepts the idea. >> >> >> On Mon, Jun 7, 2010 at 10:51 PM, Manger, James H < >> James.H.Manger@team.telstra.com> wrote: >> >>> Nat, >>> >>> > On the other hand, you are starting to think of it as a generic >>> "include" mechanism, are you? >>> >>> Yes. That feels like the simplest mental model for this functionality, >>> and the simplest way to specify it. >>> >>> -- >>> James Manger >>> >> >> >> >> -- >> Nat Sakimura (=nat) >> http://www.sakimura.org/en/ >> http://twitter.com/_nat_en >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001636e0b875940fa60488a13e2f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <br><br><div class=3D"gmail_quote">On Wed, Jun 9, 2010 at 4:05 PM, John Pan= zer <span dir=3D"ltr"><<a href=3D"mailto:jpanzer@google.com">jpanzer@goo= gle.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D= "border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padd= ing-left: 1ex;"> So the thinking is that this is just a generic "include" or "= ;one level of indirection" feature that is orthogonal to other flows?<= div><br></div><div>FWIW, I really like that notion. =A0It's also very e= asy to describe and understand conceptually.<br clear=3D"all"> </div></blockquote><div><br>+1<br><br>How does the Client decide to use thi= s new level of indirection? When the User Agent looks like it wouldn't = like long URLs? <br><br>Dirk.<br>=A0</div><blockquote class=3D"gmail_quote"= style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.= 8ex; padding-left: 1ex;"> <div><font color=3D"#888888"> <div dir=3D"ltr">--<br>John Panzer / Google<br><a href=3D"mailto:jpanzer@go= ogle.com" target=3D"_blank">jpanzer@google.com</a> / <a href=3D"http://www.= abstractioneer.org/" target=3D"_blank">abstractioneer.org</a> / @jpanzer</d= iv><br> <br><br></font><div class=3D"gmail_quote"><div><div></div><div class=3D"h5"= >On Mon, Jun 7, 2010 at 7:53 PM, Nat Sakimura <span dir=3D"ltr"><<a href= =3D"mailto:sakimura@gmail.com" target=3D"_blank">sakimura@gmail.com</a>>= </span> wrote:<br> </div></div><blockquote class=3D"gmail_quote" style=3D"border-left: 1px sol= id rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div>= <div></div><div class=3D"h5"> I fully agree on it.=A0<div><br></div><div>Instead of doing as a flow, defi= ning request_url as one of the core variable would be better.=A0</div><div>= The question then is, whether this community accepts the idea.=A0<div> <br><br><div class=3D"gmail_quote"> On Mon, Jun 7, 2010 at 10:51 PM, Manger, James H <span dir=3D"ltr"><<a h= ref=3D"mailto:James.H.Manger@team.telstra.com" target=3D"_blank">James.H.Ma= nger@team.telstra.com</a>></span> wrote:<br><blockquote class=3D"gmail_q= uote" style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0= pt 0.8ex; padding-left: 1ex;"> Nat,<br> <div><br> > On the other hand, you are starting to think of it as a generic "= include" mechanism, are you?<br> <br> </div>Yes. That feels like the simplest mental model for this functionality= , and the simplest way to specify it.<br> <br> --<br> <font color=3D"#888888">James Manger<br> </font></blockquote></div><br><br clear=3D"all"><br></div><div>-- <br>Nat S= akimura (=3Dnat)<br><a href=3D"http://www.sakimura.org/en/" target=3D"_blan= k">http://www.sakimura.org/en/</a><br><a href=3D"http://twitter.com/_nat_en= " target=3D"_blank">http://twitter.com/_nat_en</a><br> </div></div> <br></div></div><div class=3D"im">_________________________________________= ______<br> OAuth mailing list<br> <a href=3D"mailto:OAuth@ietf.org" target=3D"_blank">OAuth@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_blank">h= ttps://www.ietf.org/mailman/listinfo/oauth</a><br> <br></div></blockquote></div><br></div> <br>_______________________________________________<br> OAuth mailing list<br> <a href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_blank">h= ttps://www.ietf.org/mailman/listinfo/oauth</a><br> <br></blockquote></div><br> --001636e0b875940fa60488a13e2f-- From balfanz@google.com Wed Jun 9 16:52:02 2010 Return-Path: <balfanz@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B43A83A6880 for <oauth@core3.amsl.com>; Wed, 9 Jun 2010 16:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.373 X-Spam-Level: X-Spam-Status: No, score=-101.373 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h6mh+lwmRpfq for <oauth@core3.amsl.com>; Wed, 9 Jun 2010 16:51:59 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 1BFAB3A69B9 for <oauth@ietf.org>; Wed, 9 Jun 2010 16:51:57 -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 o59Npv66015598 for <oauth@ietf.org>; Wed, 9 Jun 2010 16:51:58 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1276127518; bh=cvUMpRGa4Aj3IIIMAGKk6O/s/og=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=XmurqJzcYbzvEbYgxQghvWeuPedYsuKrEXP0Zpg7wCSa5mQSWxfQF7WrvD9xKREH0 +8icXL6JHEV65dXglcCxw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type; b=lDVcmmG4P2sKrggM5T+ZmpVwfMWfiDU3mss3D/4cOO4EaCh3dhC3QFP/G0rwGf9Te eQS6mmxZ/prj1OL7et2VQ== Received: from iwn35 (iwn35.prod.google.com [10.241.68.99]) by wpaz5.hot.corp.google.com with ESMTP id o59Npuil022326 for <oauth@ietf.org>; Wed, 9 Jun 2010 16:51:57 -0700 Received: by iwn35 with SMTP id 35so6159929iwn.10 for <oauth@ietf.org>; Wed, 09 Jun 2010 16:51:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.141.27 with SMTP id k27mr8541553ibu.152.1276127515897; Wed, 09 Jun 2010 16:51:55 -0700 (PDT) Received: by 10.231.68.144 with HTTP; Wed, 9 Jun 2010 16:51:55 -0700 (PDT) In-Reply-To: <AANLkTim5tJMXK4mcb7SrxK4ZR6FQqRKpZqRmxZ9QOpY9@mail.gmail.com> References: <AANLkTimOXzscoFDtf-PO8965xuchEBJvqALiWM3O9fMl@mail.gmail.com> <4C0F3FFF.2050209@lodderstedt.net> <255B9BB34FB7D647A506DC292726F6E11263F7B9FB@WSMSG3153V.srv.dir.telstra.com> <AANLkTim5tJMXK4mcb7SrxK4ZR6FQqRKpZqRmxZ9QOpY9@mail.gmail.com> Date: Wed, 9 Jun 2010 16:51:55 -0700 Message-ID: <AANLkTimyolfWkyYLCVw50fUkL7R94ifdtN-dGhe_vPHT@mail.gmail.com> From: Dirk Balfanz <balfanz@google.com> To: David Recordon <recordond@gmail.com> Content-Type: multipart/alternative; boundary=0016e646513c45ef300488a19769 Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] polling in the device flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 09 Jun 2010 23:52:02 -0000 --0016e646513c45ef300488a19769 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 9, 2010 at 10:58 AM, David Recordon <recordond@gmail.com> wrote: > Unless I'm misreading the Timeouts spec, it defines a HTTP request > header which the client uses to tell the server how long it will wait. > That's how I read them, too. But that might be an alternative way to pick up the token in the device flow - issue a "hanging" request that returns when the token is rejected/approved. If you do that, then the timeout specs become relevant. Either way, it feels to me like this should be handled at the HTTP layer. Dirk. > That's a different problem from the server telling the client to back > off it's request rate. > > A 503 with a Retry-After header seems reasonable. We should specify > this interaction given that 503 headers will be new to many > developers. > > --David > > > On Wed, Jun 9, 2010 at 12:29 AM, Manger, James H > <James.H.Manger@team.telstra.com> wrote: > > Right on cue a new internet-draft covering the HTTP polling issue has > just > > appeared: > > > > > > > > Hypertext Transfer Protocol (HTTP) Timeouts > > > > draft-loreto-http-timeout [June 2010] > > > > > > > > See also: > > > > Best Practices for the Use of Long Polling and Streaming in > Bidirectional > > HTTP > > > > draft-loreto-http-bidirectional [Feb 2010] > > > > > > > > -- > > > > James Manger > > > > > > > > Am 08.06.2010 22:23, schrieb Dirk Balfanz: > > > > Hi guys, > > > > currently, we specify how polling should work in the device flow as part > of > > the OAuth2 spec. > > > > I would argue that that polling should be handled at a lower layer of the > > stack, and that OAuth2 should be silent on the issue of polling. The > benefit > > will be a simpler spec. > > > > HTTP specifies the 503 response code with the (optional) Retry-After > > response header. ASs could just use that mechanism to throttle clients, > > instead of handling it at the OAuth layer. > > > > The OAuth spec could say something like: "The client requests the access > > token after the user approves or rejects authorization. If the client > cannot > > determine when the user has approved or rejected the authorization, the > > client MAY poll the server. The server MAY use throttling mechanisms such > as > > 503 HTTP response codes and Retry-After response headers which, if used, > the > > client MUST obey." > > > > What do you guys think? > > > > BTW, there is some precedence for this. Google's APIs use 503 response > codes > > to throttle servers, e.g. > > > http://code.google.com/googleapps/domain/gdata_provisioning_api_v2.0_reference.html > > > > Dirk. > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > --0016e646513c45ef300488a19769 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Jun 9, 2010 at 10:58 AM, David Recordon <span dir=3D"ltr"><<a hr= ef=3D"mailto:recordond@gmail.com">recordond@gmail.com</a>></span> wrote:= <br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"b= order-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; paddin= g-left: 1ex;"> Unless I'm misreading the Timeouts spec, it defines a HTTP request<br> header which the client uses to tell the server how long it will wait.<br><= /blockquote><div><br>That's how I read them, too. But that might be an = alternative way to pick up the token in the device flow - issue a "han= ging" request that returns when the token is rejected/approved. If you= do that, then the timeout specs become relevant. Either way, it feels to m= e like this should be handled at the HTTP layer. <br> <br>Dirk.<br>=A0</div><blockquote class=3D"gmail_quote" style=3D"border-lef= t: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1= ex;"> That's a different problem from the server telling the client to back<b= r> off it's request rate.<br> <br> A 503 with a Retry-After header seems reasonable. We should specify<br> this interaction given that 503 headers will be new to many<br> developers.<br> <font color=3D"#888888"><br> --David<br> </font><div><div></div><div class=3D"h5"><br> <br> On Wed, Jun 9, 2010 at 12:29 AM, Manger, James H<br> <<a href=3D"mailto:James.H.Manger@team.telstra.com">James.H.Manger@team.= telstra.com</a>> wrote:<br> > Right on cue a new internet-draft covering the HTTP polling issue has = just<br> > appeared:<br> ><br> ><br> ><br> > =A0 Hypertext Transfer Protocol (HTTP) Timeouts<br> ><br> > =A0 draft-loreto-http-timeout [June 2010]<br> ><br> ><br> ><br> > See also:<br> ><br> > =A0 Best Practices for the Use of Long Polling and Streaming in Bidire= ctional<br> > HTTP<br> ><br> > =A0 draft-loreto-http-bidirectional [Feb 2010]<br> ><br> ><br> ><br> > --<br> ><br> > James Manger<br> ><br> ><br> ><br> > Am 08.06.2010 22:23, schrieb Dirk Balfanz:<br> ><br> > Hi guys,<br> ><br> > currently, we specify how polling should work in the device flow as pa= rt of<br> > the OAuth2 spec.<br> ><br> > I would argue that that polling should be handled at a lower layer of = the<br> > stack, and that OAuth2 should be silent on the issue of polling. The b= enefit<br> > will be a simpler spec.<br> ><br> > HTTP specifies the 503 response code with the (optional) Retry-After<b= r> > response header. ASs could just use that mechanism to throttle clients= ,<br> > instead of handling it at the OAuth layer.<br> ><br> > The OAuth spec could say something like: "The client requests the= access<br> > token after the user approves or rejects authorization. If the client = cannot<br> > determine when the user has approved or rejected the authorization, th= e<br> > client MAY poll the server. The server MAY use throttling mechanisms s= uch as<br> > 503 HTTP response codes and Retry-After response headers which, if use= d, the<br> > client MUST obey."<br> ><br> > What do you guys think?<br> ><br> > BTW, there is some precedence for this. Google's APIs use 503 resp= onse codes<br> > to throttle servers, e.g.<br> > <a href=3D"http://code.google.com/googleapps/domain/gdata_provisioning= _api_v2.0_reference.html" target=3D"_blank">http://code.google.com/googleap= ps/domain/gdata_provisioning_api_v2.0_reference.html</a><br> ><br> > Dirk.<br> ><br> ><br> </div></div><div><div></div><div class=3D"h5">> ________________________= _______________________<br> > OAuth mailing list<br> > <a href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a><br> > <a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_bla= nk">https://www.ietf.org/mailman/listinfo/oauth</a><br> ><br> ><br> </div></div></blockquote></div><br> --0016e646513c45ef300488a19769-- From balfanz@google.com Wed Jun 9 17:02:52 2010 Return-Path: <balfanz@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6325B3A6880 for <oauth@core3.amsl.com>; Wed, 9 Jun 2010 17:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.487 X-Spam-Level: X-Spam-Status: No, score=-104.487 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTpwb-IN1FFN for <oauth@core3.amsl.com>; Wed, 9 Jun 2010 17:02:51 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id D040E3A69B9 for <oauth@ietf.org>; Wed, 9 Jun 2010 17:02:50 -0700 (PDT) Received: from wpaz29.hot.corp.google.com (wpaz29.hot.corp.google.com [172.24.198.93]) by smtp-out.google.com with ESMTP id o5A02mlY013888 for <oauth@ietf.org>; Wed, 9 Jun 2010 17:02:51 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1276128171; bh=0brPsTJi/hpwq0sA+MFX+hWWCJk=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=yFzuQjRqsVfCYrXifdtY6bNVJm6iXLMTYfo5D/F0A5x48kE1jpTxNqAxGRRPhmjn3 dzFqtON8cZOfN/l3pIe8g== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type; b=nzZ4dwHSZuwMvIFvI3tUjB8Uwo3TpMj7qmgQ2fsSqshB6GXlJ7rtVC/Wxvj4x44Aj X/GWQTDNzH46nAmX3Iesw== Received: from iwn3 (iwn3.prod.google.com [10.241.68.67]) by wpaz29.hot.corp.google.com with ESMTP id o5A02lho005068 for <oauth@ietf.org>; Wed, 9 Jun 2010 17:02:47 -0700 Received: by iwn3 with SMTP id 3so3196417iwn.30 for <oauth@ietf.org>; Wed, 09 Jun 2010 17:02:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.59.1 with SMTP id j1mr4135271ibh.55.1276128167303; Wed, 09 Jun 2010 17:02:47 -0700 (PDT) Received: by 10.231.68.144 with HTTP; Wed, 9 Jun 2010 17:02:47 -0700 (PDT) In-Reply-To: <4C0F3FFF.2050209@lodderstedt.net> References: <AANLkTimOXzscoFDtf-PO8965xuchEBJvqALiWM3O9fMl@mail.gmail.com> <4C0F3FFF.2050209@lodderstedt.net> Date: Wed, 9 Jun 2010 17:02:47 -0700 Message-ID: <AANLkTikJ_FMF8PdKJ2ZedJ_3gtY91j745d5ZSkktLW8T@mail.gmail.com> From: Dirk Balfanz <balfanz@google.com> To: Torsten Lodderstedt <torsten@lodderstedt.net> Content-Type: multipart/alternative; boundary=001485ebea30199ccf0488a1be21 Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] polling in the device flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 10 Jun 2010 00:02:52 -0000 --001485ebea30199ccf0488a1be21 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 9, 2010 at 12:17 AM, Torsten Lodderstedt < torsten@lodderstedt.net> wrote: > using mechanisms provided by the HTTP protocol sound reasonable to me. > > I see two questions: > > 1) Is 503 intended for that purpose? > http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html says: "The server > is currently unable to handle the request due to a temporary overloading or > maintenance of the server" > 2) Do HTTP clients supports the Retry-After header? > Both good question. It's probably fair to say that the original intention for 503 did not include telling clients that the resource they're requesting isn't quite ready yet. On the other hand, the original "overloading" language does suggest that it's perfectly within the intentions of the founding fathers to throttle clients if they become too pesky. Which is what we're trying to do here: As far as OAuth is concerned, the client could just sit there and loop and keep asking the server every 2 milliseconds. We thought that wasn't a good idea because (among other things) that might *overload* the server, not because OAuth wouldn't work if the clients did that. So a 503 seems like a reasonable response there, especially since it has that Retry-After header, which indicates that the original intent of a 503 at least included the case where the inability-to-serve was due to the fact that he clients were coming in too fast. As for library support for this - I'm not sure. I briefly looked at the Apache commons client and couldn't find a, say, simple flag that would enable some retry mechanism based on 503s and retry-after headers. Maybe I didn't look hard enough. But it should be fairly easy to add supprot for this to any HTTP client library, right? Dirk. > regards, > Torsten. > > Am 08.06.2010 22:23, schrieb Dirk Balfanz: > > Hi guys, > > currently, we specify how polling should work in the device flow as part of > the OAuth2 spec. > > I would argue that that polling should be handled at a lower layer of the > stack, and that OAuth2 should be silent on the issue of polling. The benefit > will be a simpler spec. > > HTTP specifies the 503 response code with the (optional) Retry-After > response header. ASs could just use that mechanism to throttle clients, > instead of handling it at the OAuth layer. > > The OAuth spec could say something like: "The client requests the access > token after the user approves or rejects authorization. If the client cannot > determine when the user has approved or rejected the authorization, the > client MAY poll the server. The server MAY use throttling mechanisms such as > 503 HTTP response codes and Retry-After response headers which, if used, the > client MUST obey." > > What do you guys think? > > BTW, there is some precedence for this. Google's APIs use 503 response > codes to throttle servers, e.g. > http://code.google.com/googleapps/domain/gdata_provisioning_api_v2.0_reference.html > > Dirk. > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > --001485ebea30199ccf0488a1be21 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <br><br><div class=3D"gmail_quote">On Wed, Jun 9, 2010 at 12:17 AM, Torsten= Lodderstedt <span dir=3D"ltr"><<a href=3D"mailto:torsten@lodderstedt.ne= t">torsten@lodderstedt.net</a>></span> wrote:<br><blockquote class=3D"gm= ail_quote" style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt = 0pt 0pt 0.8ex; padding-left: 1ex;"> =20 =20 <div bgcolor=3D"#ffffff" text=3D"#000000"> using mechanisms provided by the HTTP protocol sound reasonable to me.<br> <br> I see two questions: <br> <br> 1) Is 503 intended for that purpose? <a href=3D"http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html" target= =3D"_blank">http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html</a> says= : "The server is currently unable to handle the request due to a temporary overloading or maintenance of the server"<br> 2) Do HTTP clients supports the Retry-After header?<br></div></blockquote><= div><br>Both good question. It's probably fair to say that the original= intention for 503 did not include telling clients that the resource they&#= 39;re requesting isn't quite ready yet. On the other hand, the original= "overloading" language does suggest that it's perfectly with= in the intentions of the founding fathers to throttle clients if they becom= e too pesky. Which is what we're trying to do here: As far as OAuth is = concerned, the client could just sit there and loop and keep asking the ser= ver every 2 milliseconds. We thought that wasn't a good idea because (a= mong other things) that might *overload* the server, not because OAuth woul= dn't work if the clients did that. So a 503 seems like a reasonable res= ponse there, especially since it has that Retry-After header, which indicat= es that the original intent of a 503 at least included the case where the i= nability-to-serve was due to the fact that he clients were coming in too fa= st. <br> =A0<br>As for library support for this - I'm not sure. I briefly looked= at the Apache commons client and couldn't find a, say, simple flag tha= t would enable some retry mechanism based on 503s and retry-after headers. = Maybe I didn't look hard enough. But it should be fairly easy to add su= pprot for this to any HTTP client library, right?<br> <br>Dirk.<br><br></div><blockquote class=3D"gmail_quote" style=3D"border-le= ft: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: = 1ex;"><div bgcolor=3D"#ffffff" text=3D"#000000"> <br> regards,<br> Torsten.<br> <br> Am 08.06.2010 22:23, schrieb Dirk Balfanz: <blockquote type=3D"cite"><div><div></div><div class=3D"h5">Hi guys, <br> <br> currently, we specify how polling should work in the device flow as part of the OAuth2 spec.<br> <br> I would argue that that polling should be handled at a lower layer of the stack, and that OAuth2 should be silent on the issue of polling. The benefit will be a simpler spec.<br> <br> HTTP specifies the 503 response code with the (optional) Retry-After response header. ASs could just use that mechanism to throttle clients, instead of handling it at the OAuth layer. <br> <br> The OAuth spec could say something like: "The client requests the access token after the user approves or rejects authorization. If the client cannot determine when the user has approved or rejected the authorization, the client MAY poll the server. The server MAY use throttling mechanisms such as 503 HTTP response codes and Retry-After response headers which, if used, the client MUST obey."<br> <br> What do you guys think?<br> <br> BTW, there is some precedence for this. Google's APIs use 503 response codes to throttle servers, e.g. <a href=3D"http://code.google.com/googleapp= s/domain/gdata_provisioning_api_v2.0_reference.html" target=3D"_blank">http= ://code.google.com/googleapps/domain/gdata_provisioning_api_v2.0_reference.= html</a><br> <br> Dirk.<br> <br> </div></div><pre><fieldset></fieldset> _______________________________________________ OAuth mailing list <a href=3D"mailto:OAuth@ietf.org" target=3D"_blank">OAuth@ietf.org</a> <a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_blank">h= ttps://www.ietf.org/mailman/listinfo/oauth</a> </pre> </blockquote> </div> </blockquote></div><br> --001485ebea30199ccf0488a1be21-- From recordond@gmail.com Wed Jun 9 17:03:19 2010 Return-Path: <recordond@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E98B3A69BF for <oauth@core3.amsl.com>; Wed, 9 Jun 2010 17:03:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.639 X-Spam-Level: X-Spam-Status: No, score=-1.639 tagged_above=-999 required=5 tests=[AWL=0.960, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTfKkWcSyZ8Z for <oauth@core3.amsl.com>; Wed, 9 Jun 2010 17:03:18 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 8E6473A6880 for <oauth@ietf.org>; Wed, 9 Jun 2010 17:03:18 -0700 (PDT) Received: by iwn42 with SMTP id 42so6368528iwn.31 for <oauth@ietf.org>; Wed, 09 Jun 2010 17:03:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=fMkAt3dwGxerYqnYdlV2/cEKoKlcuJzxASNo8J9gW1M=; b=FuRT4d4FQ9kuaCrwkKNvkqoAIUbP0NQljGZMuv8fROkoO0TIj3FDfbYJO2In7/yLd/ JBuTmnwYqFW3+0otM36i8dQ37rLnHzzLPmldZf8gDDvXNQQAxuXID+FF+bpP+K1ma7Q9 mjzRAU/3zAIcB9toNcRm8J1mMqw8EoDwGiuzQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=tWw8XNTFNS7z7YocDTkWF+pOslq9gVAsSX2uEye4eiLp3dugASIPF9ngA758V1Ec0r 9Wefs59Mv3GCRP95JEr90DottyAykhy/r1ilaPIBXHSzSerjR3HtS4qlPOVrD6kq7bcF Z20vNHiwfG5i1y70JaSzOM843g0069BUfy8m4= MIME-Version: 1.0 Received: by 10.231.59.1 with SMTP id j1mr4135866ibh.55.1276128197183; Wed, 09 Jun 2010 17:03:17 -0700 (PDT) Received: by 10.231.192.4 with HTTP; Wed, 9 Jun 2010 17:03:17 -0700 (PDT) In-Reply-To: <AANLkTimyolfWkyYLCVw50fUkL7R94ifdtN-dGhe_vPHT@mail.gmail.com> References: <AANLkTimOXzscoFDtf-PO8965xuchEBJvqALiWM3O9fMl@mail.gmail.com> <4C0F3FFF.2050209@lodderstedt.net> <255B9BB34FB7D647A506DC292726F6E11263F7B9FB@WSMSG3153V.srv.dir.telstra.com> <AANLkTim5tJMXK4mcb7SrxK4ZR6FQqRKpZqRmxZ9QOpY9@mail.gmail.com> <AANLkTimyolfWkyYLCVw50fUkL7R94ifdtN-dGhe_vPHT@mail.gmail.com> Date: Wed, 9 Jun 2010 17:03:17 -0700 Message-ID: <AANLkTinNvHyJFwEF6B3G6PVJJEgCpB9dXCNdRxoUpTb_@mail.gmail.com> From: David Recordon <recordond@gmail.com> To: Dirk Balfanz <balfanz@google.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] polling in the device flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 10 Jun 2010 00:03:19 -0000 I think long polling came up at the face to face and we decided to not fundamentally change how the flow works until we have implementation experience. I'm fine with using 503 since it's not really a fundamental change. --David On Wed, Jun 9, 2010 at 4:51 PM, Dirk Balfanz <balfanz@google.com> wrote: > On Wed, Jun 9, 2010 at 10:58 AM, David Recordon <recordond@gmail.com> wro= te: >> >> Unless I'm misreading the Timeouts spec, it defines a HTTP request >> header which the client uses to tell the server how long it will wait. > > That's how I read them, too. But that might be an alternative way to pick= up > the token in the device flow - issue a "hanging" request that returns whe= n > the token is rejected/approved. If you do that, then the timeout specs > become relevant. Either way, it feels to me like this should be handled a= t > the HTTP layer. > > Dirk. > >> >> That's a different problem from the server telling the client to back >> off it's request rate. >> >> A 503 with a Retry-After header seems reasonable. We should specify >> this interaction given that 503 headers will be new to many >> developers. >> >> --David >> >> >> On Wed, Jun 9, 2010 at 12:29 AM, Manger, James H >> <James.H.Manger@team.telstra.com> wrote: >> > Right on cue a new internet-draft covering the HTTP polling issue has >> > just >> > appeared: >> > >> > >> > >> > =A0 Hypertext Transfer Protocol (HTTP) Timeouts >> > >> > =A0 draft-loreto-http-timeout [June 2010] >> > >> > >> > >> > See also: >> > >> > =A0 Best Practices for the Use of Long Polling and Streaming in >> > Bidirectional >> > HTTP >> > >> > =A0 draft-loreto-http-bidirectional [Feb 2010] >> > >> > >> > >> > -- >> > >> > James Manger >> > >> > >> > >> > Am 08.06.2010 22:23, schrieb Dirk Balfanz: >> > >> > Hi guys, >> > >> > currently, we specify how polling should work in the device flow as pa= rt >> > of >> > the OAuth2 spec. >> > >> > I would argue that that polling should be handled at a lower layer of >> > the >> > stack, and that OAuth2 should be silent on the issue of polling. The >> > benefit >> > will be a simpler spec. >> > >> > HTTP specifies the 503 response code with the (optional) Retry-After >> > response header. ASs could just use that mechanism to throttle clients= , >> > instead of handling it at the OAuth layer. >> > >> > The OAuth spec could say something like: "The client requests the acce= ss >> > token after the user approves or rejects authorization. If the client >> > cannot >> > determine when the user has approved or rejected the authorization, th= e >> > client MAY poll the server. The server MAY use throttling mechanisms >> > such as >> > 503 HTTP response codes and Retry-After response headers which, if use= d, >> > the >> > client MUST obey." >> > >> > What do you guys think? >> > >> > BTW, there is some precedence for this. Google's APIs use 503 response >> > codes >> > to throttle servers, e.g. >> > >> > http://code.google.com/googleapps/domain/gdata_provisioning_api_v2.0_r= eference.html >> > >> > Dirk. >> > >> > >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth >> > >> > > > From michael.d.adams@gmail.com Wed Jun 9 17:43:07 2010 Return-Path: <michael.d.adams@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3B1F28C110 for <oauth@core3.amsl.com>; Wed, 9 Jun 2010 17:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.118 X-Spam-Level: X-Spam-Status: No, score=-0.118 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ne7Sqb2n+6Jh for <oauth@core3.amsl.com>; Wed, 9 Jun 2010 17:43:05 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 9D5C83A69AC for <oauth@ietf.org>; Wed, 9 Jun 2010 17:43:05 -0700 (PDT) Received: by iwn42 with SMTP id 42so6399126iwn.31 for <oauth@ietf.org>; Wed, 09 Jun 2010 17:43:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=BE59RCLr+fZXHJVzJ5Rtiv+vFtRjl/i99w+B5WTN4Aw=; b=sv8wLd9bUNthsZqWENrSCWSsJl8N63znlu8Cd+wfRJpIbMoVt4R6j+tEPR324tOj04 kPyl5xAVDRUkriJ+ljqjNoWDn/qAIsM2eXmaFkQWpeBVdP7JLzW48dMttfn5JBXh1tu4 TQ3Ja91UhJvtbSw1eFlO0tJnjKwCPxtgUV+Ew= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=LSFXeg/KfLlL6+dBwva9y+TQ0E0CH1jnK2F5aUhTn9LV15qeFaMlMp35T/UBnsFgvW yYI6dNWeM2i6JvdpGneo2p5K3+Cv3dpcBpY3iQ+7B4/l2+I9T3lyM+uvF6nzMLPN383s bQOx5uBr+CgWgJj+XxR8G5rLoiA8bfCFuLdpo= Received: by 10.231.209.79 with SMTP id gf15mr8703237ibb.138.1276130583343; Wed, 09 Jun 2010 17:43:03 -0700 (PDT) MIME-Version: 1.0 Sender: michael.d.adams@gmail.com Received: by 10.231.19.2 with HTTP; Wed, 9 Jun 2010 17:42:42 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF6E13@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <7C01E631FF4B654FA1E783F1C0265F8C578D67E6@TK5EX14MBXC113.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343B3EAF6E13@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Michael D Adams <mike@automattic.com> Date: Wed, 9 Jun 2010 17:42:42 -0700 X-Google-Sender-Auth: _GZQrfNN6fGrhrWUrIJhw3CJmrI Message-ID: <AANLkTin8rMh7DMGLcCgvVPAAthkKLPDmxMQrK7B4qy9a@mail.gmail.com> To: Eran Hammer-Lahav <eran@hueniverse.com> Content-Type: text/plain; charset=ISO-8859-1 Cc: "oauth@ietf.org" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Questions about sections 3.2/3.3 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 10 Jun 2010 00:43:07 -0000 On Tue, Jun 8, 2010 at 3:10 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote: >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Yaron Goland >> Section 3.3 - Is TLS/SSL mandatory or optional? And if so, what version of >> TLS/SSL? > > Is it ok to require TLS 1.2? > >> To me this text implies that an OAuth server could be conformant and not >> implement TLS/SSL but instead implement some other transport-layer >> security mechanism (say a VPN protocol). From an interoperability >> perspective that seems problematic since it means clients can't know what >> transport-layer solution the token endpoint will support. Wouldn't it be >> reasonable to put in a requirement that all OAuth endpoints MUST support >> RFC 5246 and RFC 5746? > > 5246 makes sense. I don't know enough to say about 5746. > >> In other words the language could read: ".the authorization server MUST >> require the use of a transport-layer mechanism when sending requests to >> the token endpoints. Specifically, authorization servers MUST support >> version 1.2 of TLS as defined in RFC 5246 and extended in RFC 5746 and MAY >> support other equivalent secure channel mechanisms". Does anyone have a list of libraries that support TLS 1.2? OpenSSL, for example, only supports TLS 1.0 in the current stable release. That'd be RFC2246 (presumably plus extensions). I don't know the difference between SSL and TLS let alone TLS 1.0 and TLS 1.2, but a systems friend of mine says: > I dont think it is realistic to require anything higher than TLS 1.0. > > OpenSSL 0.9, which is still supported and is the version in every major Linux > distro's package manager, only supports TLS 1.0. > > OpenSSL 1.0 AFAIK also only supports TLS 1.0. OpenSSL 1.1.0 is going to have > support for TLS 1.1 [1], but is "some years away" as of about a year ago [2]. > > Debian: 0.9.8c http://packages.debian.org/etch/openssl > Ubuntu: 0.9.8k http://packages.ubuntu.com/lucid/openssl > RHEL5 : 0.9.8e http://ftp.redhat.com/pub/redhat/linux/enterprise/5Server/en/os/SRPMS/ > > [1]: http://marc.info/?l=openssl-users&m=127531288020106&w=2 > [2]: http://www.mail-archive.com/openssl-users@openssl.org/msg56601.html --mdawaffe From stpeter@stpeter.im Wed Jun 9 18:38:15 2010 Return-Path: <stpeter@stpeter.im> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D46143A69C3 for <oauth@core3.amsl.com>; Wed, 9 Jun 2010 18:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dZw336bAQbJu for <oauth@core3.amsl.com>; Wed, 9 Jun 2010 18:38:14 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 376F128C11F for <oauth@ietf.org>; Wed, 9 Jun 2010 18:38:14 -0700 (PDT) Received: from squire.local (dsl-228-47.dynamic-dsl.frii.net [216.17.228.47]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 356F240E5D for <oauth@ietf.org>; Wed, 9 Jun 2010 19:38:15 -0600 (MDT) Message-ID: <4C104206.1070603@stpeter.im> Date: Wed, 09 Jun 2010 19:38:14 -0600 From: Peter Saint-Andre <stpeter@stpeter.im> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: oauth@ietf.org References: <7C01E631FF4B654FA1E783F1C0265F8C578D67E6@TK5EX14MBXC113.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343B3EAF6E13@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTin8rMh7DMGLcCgvVPAAthkKLPDmxMQrK7B4qy9a@mail.gmail.com> In-Reply-To: <AANLkTin8rMh7DMGLcCgvVPAAthkKLPDmxMQrK7B4qy9a@mail.gmail.com> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030701040400070906000004" Subject: Re: [OAUTH-WG] Questions about sections 3.2/3.3 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 10 Jun 2010 01:38:16 -0000 This is a cryptographically signed message in MIME format. --------------ms030701040400070906000004 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 6/9/10 6:42 PM, Michael D Adams wrote: > On Tue, Jun 8, 2010 at 3:10 PM, Eran Hammer-Lahav <eran@hueniverse.com>= wrote: >>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behal= f Of Yaron Goland >>> Section 3.3 - Is TLS/SSL mandatory or optional? And if so, what versi= on of >>> TLS/SSL? >> >> Is it ok to require TLS 1.2? >> >>> To me this text implies that an OAuth server could be conformant and = not >>> implement TLS/SSL but instead implement some other transport-layer >>> security mechanism (say a VPN protocol). From an interoperability >>> perspective that seems problematic since it means clients can't know = what >>> transport-layer solution the token endpoint will support. Wouldn't it= be >>> reasonable to put in a requirement that all OAuth endpoints MUST supp= ort >>> RFC 5246 and RFC 5746? >> >> 5246 makes sense. I don't know enough to say about 5746. >> >>> In other words the language could read: ".the authorization server MU= ST >>> require the use of a transport-layer mechanism when sending requests = to >>> the token endpoints. Specifically, authorization servers MUST support= >>> version 1.2 of TLS as defined in RFC 5246 and extended in RFC 5746 an= d MAY >>> support other equivalent secure channel mechanisms". >=20 > Does anyone have a list of libraries that support TLS 1.2? >=20 > OpenSSL, for example, only supports TLS 1.0 in the current stable > release. That'd be RFC2246 (presumably plus extensions). >=20 > I don't know the difference between SSL and TLS let alone TLS 1.0 and > TLS 1.2, but a systems friend of mine says: >=20 >> I dont think it is realistic to require anything higher than TLS 1.0. Typically, specifications do the following: 1. Require support for Transport Layer Security. 2. Point to the latest specification of that technology (RFC 5246). 3. Prohibit or strongly discourage use of some older versions of that technology -- often SSL 2.0 but in some cases also SSL 3.0. I can provide suggested text along those lines (see rfc3920bis for ideas)= =2E Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms030701040400070906000004 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDYxMDAxMzgxNFowIwYJKoZIhvcNAQkEMRYEFKQ3gfteNcQ5b0+Yb+BS Jj7GXQqyMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAh3ER1K0IfpprroFqF5A6cDax5mlH867UVA+LcDai 9X7O0iX+ga7GlkWSu+wNL58pEpjWI9G45Z2avb4K8gWYk3PcT7bs93qp9GRV7dSwnn2tE+0k sVWwBOCAveZAgZltiqbiPduv2iooSbXNKqFBLv6DpjzqE8Q0jY5zBUbo0tWOIN5a184LYQVR pneK9F4KYaqDGueumH9DYigWb4JaeBFBo7BkhcqOvJMdqrDL0I0ENz22iB/yeHy3w/g3g6zN HSYIj7PIg8BPeAB3/rIgbqg+IINOp2S81I35N+PuwbtcCI2gnCFyaL0Zry6HLQSe2MWYFn2x dP05wQzW67hPewAAAAAAAA== --------------ms030701040400070906000004-- From eran@hueniverse.com Wed Jun 9 22:47:50 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 962883A69F1 for <oauth@core3.amsl.com>; Wed, 9 Jun 2010 22:47:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.559 X-Spam-Level: X-Spam-Status: No, score=-1.559 tagged_above=-999 required=5 tests=[AWL=1.040, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WUS5bBfdy8qP for <oauth@core3.amsl.com>; Wed, 9 Jun 2010 22:47:48 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id EA3A13A69E4 for <oauth@ietf.org>; Wed, 9 Jun 2010 22:47:47 -0700 (PDT) Received: (qmail 23511 invoked from network); 10 Jun 2010 05:47:48 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 10 Jun 2010 05:47:47 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 9 Jun 2010 22:47:47 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: Peter Saint-Andre <stpeter@stpeter.im>, "oauth@ietf.org" <oauth@ietf.org> Date: Wed, 9 Jun 2010 22:47:40 -0700 Thread-Topic: [OAUTH-WG] Questions about sections 3.2/3.3 Thread-Index: AcsIPaAX16WjvEf1TqyJdEgjViZOeQAIsxSQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF71C3@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <7C01E631FF4B654FA1E783F1C0265F8C578D67E6@TK5EX14MBXC113.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343B3EAF6E13@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTin8rMh7DMGLcCgvVPAAthkKLPDmxMQrK7B4qy9a@mail.gmail.com> <4C104206.1070603@stpeter.im> In-Reply-To: <4C104206.1070603@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] Questions about sections 3.2/3.3 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 10 Jun 2010 05:47:51 -0000 UGxlYXNlIGRvLg0KDQpFSEwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9t OiBvYXV0aC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmDQo+IE9mIFBldGVyIFNhaW50LUFuZHJlDQo+IFNlbnQ6IFdlZG5lc2RheSwgSnVu ZSAwOSwgMjAxMCA2OjM4IFBNDQo+IFRvOiBvYXV0aEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTog W09BVVRILVdHXSBRdWVzdGlvbnMgYWJvdXQgc2VjdGlvbnMgMy4yLzMuMw0KPiANCj4gT24gNi85 LzEwIDY6NDIgUE0sIE1pY2hhZWwgRCBBZGFtcyB3cm90ZToNCj4gPiBPbiBUdWUsIEp1biA4LCAy MDEwIGF0IDM6MTAgUE0sIEVyYW4gSGFtbWVyLUxhaGF2DQo+IDxlcmFuQGh1ZW5pdmVyc2UuY29t PiB3cm90ZToNCj4gPj4+IEZyb206IG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpvYXV0 aC1ib3VuY2VzQGlldGYub3JnXSBPbg0KPiA+Pj4gQmVoYWxmIE9mIFlhcm9uIEdvbGFuZCBTZWN0 aW9uIDMuMyAtIElzIFRMUy9TU0wgbWFuZGF0b3J5IG9yDQo+ID4+PiBvcHRpb25hbD8gQW5kIGlm IHNvLCB3aGF0IHZlcnNpb24gb2YgVExTL1NTTD8NCj4gPj4NCj4gPj4gSXMgaXQgb2sgdG8gcmVx dWlyZSBUTFMgMS4yPw0KPiA+Pg0KPiA+Pj4gVG8gbWUgdGhpcyB0ZXh0IGltcGxpZXMgdGhhdCBh biBPQXV0aCBzZXJ2ZXIgY291bGQgYmUgY29uZm9ybWFudCBhbmQNCj4gPj4+IG5vdCBpbXBsZW1l bnQgVExTL1NTTCBidXQgaW5zdGVhZCBpbXBsZW1lbnQgc29tZSBvdGhlcg0KPiA+Pj4gdHJhbnNw b3J0LWxheWVyIHNlY3VyaXR5IG1lY2hhbmlzbSAoc2F5IGEgVlBOIHByb3RvY29sKS4gRnJvbSBh bg0KPiA+Pj4gaW50ZXJvcGVyYWJpbGl0eSBwZXJzcGVjdGl2ZSB0aGF0IHNlZW1zIHByb2JsZW1h dGljIHNpbmNlIGl0IG1lYW5zDQo+ID4+PiBjbGllbnRzIGNhbid0IGtub3cgd2hhdCB0cmFuc3Bv cnQtbGF5ZXIgc29sdXRpb24gdGhlIHRva2VuIGVuZHBvaW50DQo+ID4+PiB3aWxsIHN1cHBvcnQu IFdvdWxkbid0IGl0IGJlIHJlYXNvbmFibGUgdG8gcHV0IGluIGEgcmVxdWlyZW1lbnQgdGhhdA0K PiA+Pj4gYWxsIE9BdXRoIGVuZHBvaW50cyBNVVNUIHN1cHBvcnQgUkZDIDUyNDYgYW5kIFJGQyA1 NzQ2Pw0KPiA+Pg0KPiA+PiA1MjQ2IG1ha2VzIHNlbnNlLiBJIGRvbid0IGtub3cgZW5vdWdoIHRv IHNheSBhYm91dCA1NzQ2Lg0KPiA+Pg0KPiA+Pj4gSW4gb3RoZXIgd29yZHMgdGhlIGxhbmd1YWdl IGNvdWxkIHJlYWQ6ICIudGhlIGF1dGhvcml6YXRpb24gc2VydmVyDQo+ID4+PiBNVVNUIHJlcXVp cmUgdGhlIHVzZSBvZiBhIHRyYW5zcG9ydC1sYXllciBtZWNoYW5pc20gd2hlbiBzZW5kaW5nDQo+ ID4+PiByZXF1ZXN0cyB0byB0aGUgdG9rZW4gZW5kcG9pbnRzLiBTcGVjaWZpY2FsbHksIGF1dGhv cml6YXRpb24gc2VydmVycw0KPiA+Pj4gTVVTVCBzdXBwb3J0IHZlcnNpb24gMS4yIG9mIFRMUyBh cyBkZWZpbmVkIGluIFJGQyA1MjQ2IGFuZCBleHRlbmRlZA0KPiA+Pj4gaW4gUkZDIDU3NDYgYW5k IE1BWSBzdXBwb3J0IG90aGVyIGVxdWl2YWxlbnQgc2VjdXJlIGNoYW5uZWwNCj4gbWVjaGFuaXNt cyIuDQo+ID4NCj4gPiBEb2VzIGFueW9uZSBoYXZlIGEgbGlzdCBvZiBsaWJyYXJpZXMgdGhhdCBz dXBwb3J0IFRMUyAxLjI/DQo+ID4NCj4gPiBPcGVuU1NMLCBmb3IgZXhhbXBsZSwgb25seSBzdXBw b3J0cyBUTFMgMS4wIGluIHRoZSBjdXJyZW50IHN0YWJsZQ0KPiA+IHJlbGVhc2UuICBUaGF0J2Qg YmUgUkZDMjI0NiAocHJlc3VtYWJseSBwbHVzIGV4dGVuc2lvbnMpLg0KPiA+DQo+ID4gSSBkb24n dCBrbm93IHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gU1NMIGFuZCBUTFMgbGV0IGFsb25lIFRMUyAx LjAgYW5kDQo+ID4gVExTIDEuMiwgYnV0IGEgc3lzdGVtcyBmcmllbmQgb2YgbWluZSBzYXlzOg0K PiA+DQo+ID4+IEkgZG9udCB0aGluayBpdCBpcyByZWFsaXN0aWMgdG8gcmVxdWlyZSBhbnl0aGlu ZyBoaWdoZXIgdGhhbiBUTFMgMS4wLg0KPiANCj4gVHlwaWNhbGx5LCBzcGVjaWZpY2F0aW9ucyBk byB0aGUgZm9sbG93aW5nOg0KPiANCj4gMS4gUmVxdWlyZSBzdXBwb3J0IGZvciBUcmFuc3BvcnQg TGF5ZXIgU2VjdXJpdHkuDQo+IA0KPiAyLiBQb2ludCB0byB0aGUgbGF0ZXN0IHNwZWNpZmljYXRp b24gb2YgdGhhdCB0ZWNobm9sb2d5IChSRkMgNTI0NikuDQo+IA0KPiAzLiBQcm9oaWJpdCBvciBz dHJvbmdseSBkaXNjb3VyYWdlIHVzZSBvZiBzb21lIG9sZGVyIHZlcnNpb25zIG9mIHRoYXQNCj4g dGVjaG5vbG9neSAtLSBvZnRlbiBTU0wgMi4wIGJ1dCBpbiBzb21lIGNhc2VzIGFsc28gU1NMIDMu MC4NCj4gDQo+IEkgY2FuIHByb3ZpZGUgc3VnZ2VzdGVkIHRleHQgYWxvbmcgdGhvc2UgbGluZXMg KHNlZSByZmMzOTIwYmlzIGZvciBpZGVhcykuDQo+IA0KPiBQZXRlcg0KPiANCj4gLS0NCj4gUGV0 ZXIgU2FpbnQtQW5kcmUNCj4gaHR0cHM6Ly9zdHBldGVyLmltLw0KPiANCj4gDQoNCg== From sakimura@gmail.com Wed Jun 9 23:50:58 2010 Return-Path: <sakimura@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2764F3A68C2 for <oauth@core3.amsl.com>; Wed, 9 Jun 2010 23:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[AWL=0.478, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38YPCiZKYJ5x for <oauth@core3.amsl.com>; Wed, 9 Jun 2010 23:50:53 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 70BBE3A6885 for <oauth@ietf.org>; Wed, 9 Jun 2010 23:50:53 -0700 (PDT) Received: by iwn42 with SMTP id 42so6677544iwn.31 for <oauth@ietf.org>; Wed, 09 Jun 2010 23:50:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=i1CjNk/M34LuJL+hyf6p8t5ZqOPG54Q+Vu5y3YQaJEk=; b=FZC6Orr3knfnR3cCFBGN8k9iJucItmYXA3BmAmnKEHKGAoqOcEyM/AvHRYhmDthHpK nMQvltoEWLklvbHvD1nt94HmX31q42ygkD6qGs62XZr4pKP9z5UqnlJZPUNHZdilWy7E Nyv+PcFkxQWSaBUbSIdVSWX4vyUn0ks/Nji5g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=oN4dOTueH9FGGaQglZ731LxKKldT8NZNFPdX3WmytEveDRrgzDNo8P5NWj1w4v9uTC 5vS1n6yI+jSSPZnsSuYvaTuh7XgEUYQjeAJC0TIYFFJ4vxvYotGk0dvL7O22Gi9H0ahY zDPrlAYu/Qgf8FIoIKZ+y/A1AZ4ffx3NWwits= MIME-Version: 1.0 Received: by 10.231.195.16 with SMTP id ea16mr4038721ibb.64.1276152652614; Wed, 09 Jun 2010 23:50:52 -0700 (PDT) Received: by 10.231.31.131 with HTTP; Wed, 9 Jun 2010 23:50:52 -0700 (PDT) In-Reply-To: <AANLkTinR-I_CNZNNF8dw30xespwGOWVKcE-ygpUwQMta@mail.gmail.com> References: <255B9BB34FB7D647A506DC292726F6E11262FEE7D8@WSMSG3153V.srv.dir.telstra.com> <AANLkTimIXMReEaB3ShbZIjWjiBH-VUjrvHgKHCzgVOu0@mail.gmail.com> <AANLkTinR-I_CNZNNF8dw30xespwGOWVKcE-ygpUwQMta@mail.gmail.com> Date: Thu, 10 Jun 2010 15:50:52 +0900 Message-ID: <AANLkTinFbQSVR82G8W4hF6eJfs9o9J3yH15lqiEiyTtK@mail.gmail.com> From: Nat Sakimura <sakimura@gmail.com> To: John Panzer <jpanzer@google.com> Content-Type: multipart/alternative; boundary=001636b14d0289cc580488a77142 Cc: oauth <oauth@ietf.org> Subject: Re: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 10 Jun 2010 06:50:58 -0000 --001636b14d0289cc580488a77142 Content-Type: text/plain; charset=ISO-8859-1 That's right. It would help various extensions as well. On Thu, Jun 10, 2010 at 8:05 AM, John Panzer <jpanzer@google.com> wrote: > So the thinking is that this is just a generic "include" or "one level of > indirection" feature that is orthogonal to other flows? > > FWIW, I really like that notion. It's also very easy to describe and > understand conceptually. > -- > John Panzer / Google > jpanzer@google.com / abstractioneer.org <http://www.abstractioneer.org/> / > @jpanzer > > > > On Mon, Jun 7, 2010 at 7:53 PM, Nat Sakimura <sakimura@gmail.com> wrote: > >> I fully agree on it. >> >> Instead of doing as a flow, defining request_url as one of the core >> variable would be better. >> The question then is, whether this community accepts the idea. >> >> >> On Mon, Jun 7, 2010 at 10:51 PM, Manger, James H < >> James.H.Manger@team.telstra.com> wrote: >> >>> Nat, >>> >>> > On the other hand, you are starting to think of it as a generic >>> "include" mechanism, are you? >>> >>> Yes. That feels like the simplest mental model for this functionality, >>> and the simplest way to specify it. >>> >>> -- >>> James Manger >>> >> >> >> >> -- >> Nat Sakimura (=nat) >> http://www.sakimura.org/en/ >> http://twitter.com/_nat_en >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > -- Nat Sakimura (=nat) http://www.sakimura.org/en/ http://twitter.com/_nat_en --001636b14d0289cc580488a77142 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable That's right. It would help various extensions as well.=A0<br><br><div = class=3D"gmail_quote">On Thu, Jun 10, 2010 at 8:05 AM, John Panzer <span di= r=3D"ltr"><<a href=3D"mailto:jpanzer@google.com">jpanzer@google.com</a>&= gt;</span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex;">So the thinking is that this is just a gene= ric "include" or "one level of indirection" feature tha= t is orthogonal to other flows?<div> <br></div><div>FWIW, I really like that notion. =A0It's also very easy = to describe and understand conceptually.<br clear=3D"all"><font color=3D"#8= 88888"> <div dir=3D"ltr">--<br>John Panzer / Google<br><a href=3D"mailto:jpanzer@go= ogle.com" target=3D"_blank">jpanzer@google.com</a> / <a href=3D"http://www.= abstractioneer.org/" target=3D"_blank">abstractioneer.org</a> / @jpanzer</d= iv><br> <br><br></font><div class=3D"gmail_quote"><div><div></div><div class=3D"h5"= >On Mon, Jun 7, 2010 at 7:53 PM, Nat Sakimura <span dir=3D"ltr"><<a href= =3D"mailto:sakimura@gmail.com" target=3D"_blank">sakimura@gmail.com</a>>= </span> wrote:<br> </div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo= rder-left:1px #ccc solid;padding-left:1ex"><div><div></div><div class=3D"h5= "> I fully agree on it.=A0<div><br></div><div>Instead of doing as a flow, defi= ning request_url as one of the core variable would be better.=A0</div><div>= The question then is, whether this community accepts the idea.=A0<div> <br><br><div class=3D"gmail_quote"> On Mon, Jun 7, 2010 at 10:51 PM, Manger, James H <span dir=3D"ltr"><<a h= ref=3D"mailto:James.H.Manger@team.telstra.com" target=3D"_blank">James.H.Ma= nger@team.telstra.com</a>></span> wrote:<br><blockquote class=3D"gmail_q= uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e= x"> Nat,<br> <div><br> > On the other hand, you are starting to think of it as a generic "= include" mechanism, are you?<br> <br> </div>Yes. That feels like the simplest mental model for this functionality= , and the simplest way to specify it.<br> <br> --<br> <font color=3D"#888888">James Manger<br> </font></blockquote></div><br><br clear=3D"all"><br></div><div>-- <br>Nat S= akimura (=3Dnat)<br><a href=3D"http://www.sakimura.org/en/" target=3D"_blan= k">http://www.sakimura.org/en/</a><br><a href=3D"http://twitter.com/_nat_en= " target=3D"_blank">http://twitter.com/_nat_en</a><br> </div></div> <br></div></div><div class=3D"im">_________________________________________= ______<br> OAuth mailing list<br> <a href=3D"mailto:OAuth@ietf.org" target=3D"_blank">OAuth@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_blank">h= ttps://www.ietf.org/mailman/listinfo/oauth</a><br> <br></div></blockquote></div><br></div> </blockquote></div><br><br clear=3D"all"><br>-- <br>Nat Sakimura (=3Dnat)<b= r><a href=3D"http://www.sakimura.org/en/">http://www.sakimura.org/en/</a><b= r><a href=3D"http://twitter.com/_nat_en">http://twitter.com/_nat_en</a><br> --001636b14d0289cc580488a77142-- From sakimura@gmail.com Thu Jun 10 00:28:00 2010 Return-Path: <sakimura@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AD7F3A682A for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 00:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.18 X-Spam-Level: X-Spam-Status: No, score=-2.18 tagged_above=-999 required=5 tests=[AWL=0.418, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f9nwSimU8zCa for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 00:27:59 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id D7BEA3A67A7 for <oauth@ietf.org>; Thu, 10 Jun 2010 00:27:58 -0700 (PDT) Received: by iwn42 with SMTP id 42so6703620iwn.31 for <oauth@ietf.org>; Thu, 10 Jun 2010 00:27:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=YY6zeB+iHJF4gE3ANNq3+xfCaXWUFTagNnHCbWbIuCs=; b=oqNzAUiKrKWW9NSy+1oZkbeQd0bboGXNjJR4RjkSWZtkHlCBaKFq0nyMIAko/1F7b1 mjOEvLFe1pb/W0EgiyE9No9G+4zGQAIQdE0a2HOdahoPWWYq36EXoBReshww5HWTHy2B jf4tbxVRe9q8B6zV8LL/j5aCPuyF+rQX0RYbs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=HhZ9E+zaIIO5JM3OclNJwa7Oca1dI8liB7Dft5YGgFfHdZSixxrPth4U3Vts2jln+Q Yz25SJNKnrm+YWmW6eIYpE5PT7CiwHPwciGCGuXIbNt0J/DNRPL1fgwD7h2v9WliH4vU TbHCrHG9iL8bvg0r6nrYYW7/mJKAmkq8DBAfQ= MIME-Version: 1.0 Received: by 10.231.141.27 with SMTP id k27mr8984296ibu.152.1276154877996; Thu, 10 Jun 2010 00:27:57 -0700 (PDT) Received: by 10.231.31.131 with HTTP; Thu, 10 Jun 2010 00:27:57 -0700 (PDT) In-Reply-To: <AANLkTimceNut-5zVHxnBsHCsMDKUv8YWFcpf6N9wmHta@mail.gmail.com> References: <255B9BB34FB7D647A506DC292726F6E11262FEE7D8@WSMSG3153V.srv.dir.telstra.com> <AANLkTimIXMReEaB3ShbZIjWjiBH-VUjrvHgKHCzgVOu0@mail.gmail.com> <AANLkTinR-I_CNZNNF8dw30xespwGOWVKcE-ygpUwQMta@mail.gmail.com> <AANLkTimceNut-5zVHxnBsHCsMDKUv8YWFcpf6N9wmHta@mail.gmail.com> Date: Thu, 10 Jun 2010 16:27:57 +0900 Message-ID: <AANLkTinjIBfPJMjS2Ao3KZ_7lJhJLkJCZpqirCSN2xay@mail.gmail.com> From: Nat Sakimura <sakimura@gmail.com> To: Dirk Balfanz <balfanz@google.com> Content-Type: multipart/alternative; boundary=0016e646513c2e6ffe0488a7f641 Cc: oauth <oauth@ietf.org> Subject: Re: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 10 Jun 2010 07:28:00 -0000 --0016e646513c2e6ffe0488a7f641 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 10, 2010 at 8:27 AM, Dirk Balfanz <balfanz@google.com> wrote: > > > On Wed, Jun 9, 2010 at 4:05 PM, John Panzer <jpanzer@google.com> wrote: > >> So the thinking is that this is just a generic "include" or "one level of >> indirection" feature that is orthogonal to other flows? >> >> FWIW, I really like that notion. It's also very easy to describe and >> understand conceptually. >> > > +1 > > How does the Client decide to use this new level of indirection? When the > User Agent looks like it wouldn't like long URLs? > There are a few cases that I am aware of: 1) When the User Agent looks like it would not like long URLs. It is entirely possible that some extension makes a long URL. For example, the client might want to send a public key with the request. 2) When the server wants the request non-repudiation The server might want the request to be non-repudiable. It is possible to sign the request dynamically, but a simpler way of doing it is to make a signed request file (perhaps in Magic Signature format) and put it on the client. It can just be done by a client utility or something, so that the private key does not even have to reside on the server nor the client needs to program anything. 3) When the server wants the requests to be cacheable As I have proposed, if the request_url comes with sha256 hash of the file, the server knows if the file has changed without fetching it, so it does not have to re-fetch a same file, which is a win as well. 4) When the client wants to simplify the implementation without compromising the security If the request parameters go through the Browser, it may be tampered at the browser even if TLS was used. This implies we need to have signature on the request as well. However, if https request_url was used, it is not going to be tampered, thus we now do not have to sign the request. This simplifies the implementation. > > Dirk. > > >> -- >> John Panzer / Google >> jpanzer@google.com / abstractioneer.org <http://www.abstractioneer.org/>/ @jpanzer >> >> >> >> On Mon, Jun 7, 2010 at 7:53 PM, Nat Sakimura <sakimura@gmail.com> wrote: >> >>> I fully agree on it. >>> >>> Instead of doing as a flow, defining request_url as one of the core >>> variable would be better. >>> The question then is, whether this community accepts the idea. >>> >>> >>> On Mon, Jun 7, 2010 at 10:51 PM, Manger, James H < >>> James.H.Manger@team.telstra.com> wrote: >>> >>>> Nat, >>>> >>>> > On the other hand, you are starting to think of it as a generic >>>> "include" mechanism, are you? >>>> >>>> Yes. That feels like the simplest mental model for this functionality, >>>> and the simplest way to specify it. >>>> >>>> -- >>>> James Manger >>>> >>> >>> >>> >>> -- >>> Nat Sakimura (=nat) >>> http://www.sakimura.org/en/ >>> http://twitter.com/_nat_en >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > -- Nat Sakimura (=nat) http://www.sakimura.org/en/ http://twitter.com/_nat_en --0016e646513c2e6ffe0488a7f641 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <br><br><div class=3D"gmail_quote">On Thu, Jun 10, 2010 at 8:27 AM, Dirk Ba= lfanz <span dir=3D"ltr"><<a href=3D"mailto:balfanz@google.com">balfanz@g= oogle.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style= =3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <br><br><div class=3D"gmail_quote"><div class=3D"im">On Wed, Jun 9, 2010 at= 4:05 PM, John Panzer <span dir=3D"ltr"><<a href=3D"mailto:jpanzer@googl= e.com" target=3D"_blank">jpanzer@google.com</a>></span> wrote:<br><block= quote class=3D"gmail_quote" style=3D"border-left:1px solid rgb(204, 204, 20= 4);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex"> So the thinking is that this is just a generic "include" or "= ;one level of indirection" feature that is orthogonal to other flows?<= div><br></div><div>FWIW, I really like that notion. =A0It's also very e= asy to describe and understand conceptually.<br clear=3D"all"> </div></blockquote></div><div><br>+1<br><br>How does the Client decide to u= se this new level of indirection? When the User Agent looks like it wouldn&= #39;t like long URLs? <br></div></div></blockquote><div><br></div><div> There are a few cases that I am aware of:=A0</div><div><br></div><div>1) Wh= en the User Agent looks like =A0it would not like long URLs.=A0</div><div><= br></div><div>It is entirely possible that some extension makes a long URL.= =A0</div> <div>For example, the client might want to send a public key with=A0</div><= div>the request.=A0</div><div><br></div><div>2) When the server wants the r= equest non-repudiation =A0<br></div><div><br></div><div>The server might wa= nt the request to be non-repudiable.=A0</div> <div>It is possible to sign the request dynamically, but a simpler way of d= oing it is to=A0</div><div>make a signed request file (perhaps in Magic Sig= nature format) and put it on the client. It can just be done by a=A0client = utility or something, so that the private key does not even have to reside = on the server nor the client needs to program anything.=A0</div> <div><br></div><div>3) When the server wants the requests to be cacheable</= div><div><br></div><div>As I have proposed, if the request_url comes with s= ha256 hash of the file,=A0</div><div>the server knows if the file has chang= ed without fetching it, so it does not have to re-fetch a same file, which = is a win as well.=A0</div> <div><br></div><div>4) When the client wants to simplify the implementation= without compromising the security</div><div><br></div><div>If the request = parameters go through the Browser, it may be tampered at the browser even i= f TLS was used. This implies we need to have signature on the request as we= ll. However, if https request_url was used, it is not going to be tampered,= thus we now do not have to sign the request. This simplifies the implement= ation.=A0</div> <div><br></div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"mar= gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class=3D"= gmail_quote"><div><font color=3D"#888888"><br>Dirk.<br>=A0</font></div><div= class=3D"im"> <blockquote class=3D"gmail_quote" style=3D"border-left:1px solid rgb(204, 2= 04, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex"> <div><font color=3D"#888888"> <div dir=3D"ltr">--<br>John Panzer / Google<br><a href=3D"mailto:jpanzer@go= ogle.com" target=3D"_blank">jpanzer@google.com</a> / <a href=3D"http://www.= abstractioneer.org/" target=3D"_blank">abstractioneer.org</a> / @jpanzer</d= iv><br> <br><br></font><div class=3D"gmail_quote"><div><div></div><div>On Mon, Jun = 7, 2010 at 7:53 PM, Nat Sakimura <span dir=3D"ltr"><<a href=3D"mailto:sa= kimura@gmail.com" target=3D"_blank">sakimura@gmail.com</a>></span> wrote= :<br> </div></div><blockquote class=3D"gmail_quote" style=3D"border-left:1px soli= d rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex"><div><div><= /div><div> I fully agree on it.=A0<div><br></div><div>Instead of doing as a flow, defi= ning request_url as one of the core variable would be better.=A0</div><div>= The question then is, whether this community accepts the idea.=A0<div> <br><br><div class=3D"gmail_quote"> On Mon, Jun 7, 2010 at 10:51 PM, Manger, James H <span dir=3D"ltr"><<a h= ref=3D"mailto:James.H.Manger@team.telstra.com" target=3D"_blank">James.H.Ma= nger@team.telstra.com</a>></span> wrote:<br><blockquote class=3D"gmail_q= uote" style=3D"border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt = 0.8ex;padding-left:1ex"> Nat,<br> <div><br> > On the other hand, you are starting to think of it as a generic "= include" mechanism, are you?<br> <br> </div>Yes. That feels like the simplest mental model for this functionality= , and the simplest way to specify it.<br> <br> --<br> <font color=3D"#888888">James Manger<br> </font></blockquote></div><br><br clear=3D"all"><br></div><div>-- <br>Nat S= akimura (=3Dnat)<br><a href=3D"http://www.sakimura.org/en/" target=3D"_blan= k">http://www.sakimura.org/en/</a><br><a href=3D"http://twitter.com/_nat_en= " target=3D"_blank">http://twitter.com/_nat_en</a><br> </div></div> <br></div></div><div>_______________________________________________<br> OAuth mailing list<br> <a href=3D"mailto:OAuth@ietf.org" target=3D"_blank">OAuth@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_blank">h= ttps://www.ietf.org/mailman/listinfo/oauth</a><br> <br></div></blockquote></div><br></div> <br>_______________________________________________<br> OAuth mailing list<br> <a href=3D"mailto:OAuth@ietf.org" target=3D"_blank">OAuth@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_blank">h= ttps://www.ietf.org/mailman/listinfo/oauth</a><br> <br></blockquote></div></div><br> </blockquote></div><br><br clear=3D"all"><br>-- <br>Nat Sakimura (=3Dnat)<b= r><a href=3D"http://www.sakimura.org/en/">http://www.sakimura.org/en/</a><b= r><a href=3D"http://twitter.com/_nat_en">http://twitter.com/_nat_en</a><br> --0016e646513c2e6ffe0488a7f641-- From lindner@inuus.com Thu Jun 10 08:24:02 2010 Return-Path: <lindner@inuus.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04E5F3A69E8 for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 08:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.624 X-Spam-Level: X-Spam-Status: No, score=0.624 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJuW2UK9k7Pn for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 08:24:01 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 35DAE3A6983 for <oauth@ietf.org>; Thu, 10 Jun 2010 08:24:00 -0700 (PDT) Received: by gwj16 with SMTP id 16so14312gwj.31 for <oauth@ietf.org>; Thu, 10 Jun 2010 08:24:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.91.164.1 with SMTP id r1mr691296ago.112.1276183440310; Thu, 10 Jun 2010 08:24:00 -0700 (PDT) Received: by 10.90.30.11 with HTTP; Thu, 10 Jun 2010 08:24:00 -0700 (PDT) Date: Thu, 10 Jun 2010 08:24:00 -0700 Message-ID: <AANLkTilcANtf9WsFh4jJPUBkbCu5x2doTMQEr4_h_Rys@mail.gmail.com> From: Paul Lindner <lindner@inuus.com> To: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org> Content-Type: multipart/alternative; boundary=001485f6d610a0c4320488ae9cca Subject: [OAUTH-WG] Identifying OAuth 2.0 vs 1.0 requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 10 Jun 2010 15:24:02 -0000 --001485f6d610a0c4320488ae9cca Content-Type: text/plain; charset=ISO-8859-1 Hi, As I've been working through our oauth2 implementation I've noticed that it's not easy to disambiguate OAuth 1.0a vs 2.0 API calls based on the request parameters alone. Based on some investigative at the Shindig project it appears that the only standard way to to determine 1.0a vs 2.0 is by checking for the oauth_signature_method parameter. More info here: https://issues.apache.org/jira/browse/SHINDIG-1361 Has anyone else considered this use case? How did you solve it? --001485f6d610a0c4320488ae9cca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,<div><br></div><div>As I've been working through our oauth2 implemen= tation I've noticed that it's not easy to disambiguate OAuth 1.0a v= s 2.0 API calls based on the request parameters alone. =A0 Based on some in= vestigative at the Shindig project it appears that the only standard way to= to determine 1.0a vs 2.0 is by checking for the=A0<span class=3D"Apple-sty= le-span" style=3D"font-family: Arial, sans-serif; font-size: 12px; border-c= ollapse: collapse; ">oauth_signature_method parameter. =A0More info here:</= span></div> <meta charset=3D"utf-8"><div><br></div><div><a href=3D"https://issues.apach= e.org/jira/browse/SHINDIG-1361">https://issues.apache.org/jira/browse/SHIND= IG-1361</a></div><div><br></div><div>Has anyone else considered this use ca= se? =A0How did you solve it?</div> <div><br></div> --001485f6d610a0c4320488ae9cca-- From andrewarnott@gmail.com Thu Jun 10 08:35:39 2010 Return-Path: <andrewarnott@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0548D3A69B6 for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 08:35:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.323 X-Spam-Level: X-Spam-Status: No, score=-0.323 tagged_above=-999 required=5 tests=[AWL=-0.325, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8FuYYdujd2C for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 08:35:37 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 2E0E33A690C for <oauth@ietf.org>; Thu, 10 Jun 2010 08:35:34 -0700 (PDT) Received: by gyh4 with SMTP id 4so22706gyh.31 for <oauth@ietf.org>; Thu, 10 Jun 2010 08:35:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=S35nEzbEROuvvM1QPs/szrlGUR5V3JGKI/oV6gvn5MQ=; b=MW1m/VIeo0CAc0IhshyulBS+0RilkjEAZH4Fa/KeW4AzTyslttuA6EbOtVmDk/1LaS PkMogV7Ef5Y9Ik+fjY8jhwFKDeD4SGcTZ2Uln+JlRqxX6R1CvEmWTumqHIMUwCb2oiVW bYL+plxZjWJEj0GN9X98HYTb79xfhmaoujmoU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Z3x57xwACK8WMQJoOU4X1ksRZqjq/V3A82D/f8kMpVygsVpaVD3esFJta8BizG3XmS C+2Gb+pwubNPnkYghKFmmenxBU1QXAWcfVQW7xkE8SbZLhTtZTiZFDRdVCIeepUI7GiL TkgT4jSt65iExLhucsyEQSATmgE5/JQ+ZJcdM= MIME-Version: 1.0 Received: by 10.151.16.9 with SMTP id t9mr2007302ybi.25.1276184133519; Thu, 10 Jun 2010 08:35:33 -0700 (PDT) Received: by 10.151.26.19 with HTTP; Thu, 10 Jun 2010 08:35:32 -0700 (PDT) In-Reply-To: <AANLkTimCL-O7RIsUlt_zGDfkEEYb9w4_sPh6zxCMBsf0@mail.gmail.com> References: <AANLkTingSGlJNZ5e_stPd1qU5I4gfbh3rQhqYUmqXvdB@mail.gmail.com> <C833CEB4.6B81%cmortimore@salesforce.com> <AANLkTinVQEPBVzmiHEGgHhzaILL0nRSvZpjIlrVEJwTw@mail.gmail.com> <AANLkTil1j7vl8PU2tgCzlWY0U6KiWPmRKiVOxvsctB00@mail.gmail.com> <AANLkTimCL-O7RIsUlt_zGDfkEEYb9w4_sPh6zxCMBsf0@mail.gmail.com> Date: Thu, 10 Jun 2010 08:35:32 -0700 Message-ID: <AANLkTin7B9pPgSu3cNlJGkp_gCed-5aPGRZalzXd2Wg8@mail.gmail.com> From: Andrew Arnott <andrewarnott@gmail.com> To: Marius Scurtescu <mscurtescu@google.com> Content-Type: multipart/alternative; boundary=000e0cd5ca24f28aa10488aec564 Cc: "oauth@ietf.org" <oauth@ietf.org> Subject: Re: [OAUTH-WG] User-agent flow and pre-registered redirect_uri X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 10 Jun 2010 15:35:39 -0000 --000e0cd5ca24f28aa10488aec564 Content-Type: text/plain; charset=ISO-8859-1 Thanks Marius. I've answered your question below. On Wed, Jun 9, 2010 at 9:35 AM, Marius Scurtescu <mscurtescu@google.com>wrote: > > I've always considered an authorization as a tuple of > > client_id,user,scope,issue_date. If an authorization has been approved, > and > > another request for authorization for a subset of the scope previously > > issued comes in, the auth server can skip the interactive user > authorization > > and just approve the request since nothing new is being issued. > > The tuple seems right, except for the issue date, why would you add that? > The issue_date enables to scenarios: expiring tokens and token revocation. Here's how, for each scenario: Obviously to know if a token has expired you need to know when it was issued. Or, you can forget the issue date and just store the expiration date in the token. I choose to go with an issue date (plus an optional expected lifetime) because it gives more ability in the future to say "oops, we had a security weakness in all tokens issued prior to [date], so let's consider all earlier tokens invalid." It's harder to say that when all you have are expiration dates because you don't know how old the token is. This is just the way I chose to do it, but I know there are other ways. Now let's look at how you revoke issued tokens. One of the nice things enabled by OAuth 2.0 is that the authorization server and resource server never have to store tokens if they are appropriate signed by the auth server. This is great because (among other things) clients with little-to-no ability to persistently store tokens may ask for tokens frequently, and that could bog down an auth server with storing all those issued tokens. But how can a user revoke a previously authorized token if no one but the client knows what the tokens are? (thought question) My solution to this is that instead of thinking about revoking *tokens*, the user revokes *authorizations*. The user goes through his account on the authorization server and sees a list of clients and what they are authorized to do. Note that this only requires the auth server to store this authorization tuple -- not the actual issued tokens. If the user clicks "revoke" on one of these authorizations, that row is deleted in the database. Issued tokens (both refresh and access tokens) have this same tuple encoded in them. Now, when a refresh token is used to obtain a new short-lived access token (and you could do this on every access token use as well if you wanted) the token is of course signature-validated, but it is also checked that the authorization tuple has a matching tuple in the auth server's database. If it's missing, then that authorization has been revoked and the token is thereby invalidated. So why the issue date? Because suppose the user has authorized a client and then that client's tokens are compromised (stolen computer perhaps). The user will of course revoke authorization for that client. The user then gets a new copy of that client (perhaps a new computer) and authorizes it. Whoops. Now all those invalidated tokens are valid again because the authorization tuple exists. *Except now the issue date on the authorization on the auth server is newer than in the refresh token on the invalidated client*. That's why issue date is such a critical part of an authorization tuple. Any token issued prior to the earliest authorization on record at the auth server represents a revoked authorization, and without an issue date in the tuple there's no way to recognize that. At least that's the way I'm seeing it. I hope that makes sense. --000e0cd5ca24f28aa10488aec564 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks Marius.<br><br>I've answered your question below.<br clear=3D"al= l"><br><div class=3D"gmail_quote">On Wed, Jun 9, 2010 at 9:35 AM, Marius Sc= urtescu <span dir=3D"ltr"><<a href=3D"mailto:mscurtescu@google.com">mscu= rtescu@google.com</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">> I've alw= ays considered an authorization as a tuple of<br><div class=3D"im"> > client_id,user,scope,issue_date.=A0 If an authorization has been appro= ved, and<br> > another request for authorization for a subset of the scope previously= <br> > issued comes in, the auth server can skip the interactive user authori= zation<br> > and just approve the request since nothing new is being issued.<br> <br> </div>The tuple seems right, except for the issue date, why would you add t= hat?<br></blockquote><br>The issue_date enables to scenarios: expiring toke= ns and token revocation.=A0 Here's how, for each scenario:<br><br>Obvio= usly to know if a token has expired you need to know when it was issued.=A0= Or, you can forget the issue date and just store the expiration date in th= e token. I choose to go with an issue date (plus an optional expected lifet= ime) because it gives more ability in the future to say "oops, we had = a security weakness in all tokens issued prior to [date], so let's cons= ider all earlier tokens invalid."=A0 It's harder to say that when = all you have are expiration dates because you don't know how old the to= ken is.=A0 This is just the way I chose to do it, but I know there are othe= r ways.<br> <br>Now let's look at how you revoke issued tokens.=A0 One of the nice = things enabled by OAuth 2.0 is that the authorization server and resource s= erver never have to store tokens if they are appropriate signed by the auth= server.=A0 This is great because (among other things) clients with little-= to-no ability to persistently store tokens may ask for tokens frequently, a= nd that could bog down an auth server with storing all those issued tokens.= =A0 But how can a user revoke a previously authorized token if no one but t= he client knows what the tokens are? (thought question)=A0 My solution to t= his is that instead of thinking about revoking <i>tokens</i>, the user revo= kes <i>authorizations</i>.=A0 The user goes through his account on the auth= orization server and sees a list of clients and what they are authorized to= do.=A0 Note that this only requires the auth server to store this authoriz= ation tuple -- not the actual issued tokens.=A0 If the user clicks "re= voke" on one of these authorizations, that row is deleted in the datab= ase.=A0 Issued tokens (both refresh and access tokens) have this same tuple= encoded in them.<br> Now, when a refresh token is used to obtain a new short-lived access token = (and you could do this on every access token use as well if you wanted) the= token is of course signature-validated, but it is also checked that the au= thorization tuple has a matching tuple in the auth server's database.= =A0 If it's missing, then that authorization has been revoked and the t= oken is thereby invalidated.<br> So why the issue date?=A0 Because suppose the user has authorized a client = and then that client's tokens are compromised (stolen computer perhaps)= .=A0 The user will of course revoke authorization for that client.=A0 The u= ser then gets a new copy of that client (perhaps a new computer) and author= izes it.=A0 Whoops.=A0 Now all those invalidated tokens are valid again bec= ause the authorization tuple exists.=A0 <i>Except now the issue date on the= authorization on the auth server is newer than in the refresh token on the= invalidated client</i>.=A0 That's why issue date is such a critical pa= rt of an authorization tuple.=A0 Any token issued prior to the earliest aut= horization on record at the auth server represents a revoked authorization,= and without an issue date in the tuple there's no way to recognize tha= t.<br> <br>At least that's the way I'm seeing it.=A0 I hope that makes sen= se.<br></div> --000e0cd5ca24f28aa10488aec564-- From eran@hueniverse.com Thu Jun 10 08:44:27 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2D7528C0E9 for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 08:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.802 X-Spam-Level: X-Spam-Status: No, score=-0.802 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YEG4l8-JGZmA for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 08:44:26 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id B5B253A695F for <oauth@ietf.org>; Thu, 10 Jun 2010 08:44:26 -0700 (PDT) Received: (qmail 8280 invoked from network); 10 Jun 2010 15:44:24 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 10 Jun 2010 15:44:24 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 10 Jun 2010 08:44:23 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: Paul Lindner <lindner@inuus.com>, "OAuth WG (oauth@ietf.org)" <oauth@ietf.org> Date: Thu, 10 Jun 2010 08:44:17 -0700 Thread-Topic: [OAUTH-WG] Identifying OAuth 2.0 vs 1.0 requests Thread-Index: AcsIsPkBzOQ+FzigT2SxkTBZei3iNgAAr1SA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF729E@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <AANLkTilcANtf9WsFh4jJPUBkbCu5x2doTMQEr4_h_Rys@mail.gmail.com> In-Reply-To: <AANLkTilcANtf9WsFh4jJPUBkbCu5x2doTMQEr4_h_Rys@mail.gmail.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_90C41DD21FB7C64BB94121FBBC2E72343B3EAF729EP3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Identifying OAuth 2.0 vs 1.0 requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 10 Jun 2010 15:44:27 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EAF729EP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The request is very different on the resource server. On the authorization = server, why would you use the same endpoint? EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of P= aul Lindner Sent: Thursday, June 10, 2010 8:24 AM To: OAuth WG (oauth@ietf.org) Subject: [OAUTH-WG] Identifying OAuth 2.0 vs 1.0 requests Hi, As I've been working through our oauth2 implementation I've noticed that it= 's not easy to disambiguate OAuth 1.0a vs 2.0 API calls based on the reques= t parameters alone. Based on some investigative at the Shindig project it= appears that the only standard way to to determine 1.0a vs 2.0 is by check= ing for the oauth_signature_method parameter. More info here: https://issues.apache.org/jira/browse/SHINDIG-1361 Has anyone else considered this use case? How did you solve it? --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EAF729EP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV=3D"Content-Type" CONTENT= =3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros= oft Word 14 (filtered medium)"><style><!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} span.apple-style-span {mso-style-name:apple-style-span;} span.EmailStyle18 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-family:"Calibri","sans-serif";} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue vli= nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><span style=3D'f= ont-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>The reque= st is very different on the resource server. On the authorization server, w= hy would you use the same endpoint?<o:p></o:p></span></p><p class=3DMsoNorm= al><span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color= :#1F497D'><o:p> </o:p></span></p><p class=3DMsoNormal><span style=3D'f= ont-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>EHL<o:p><= /o:p></span></p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-f= amily:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><di= v style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0= pt'><div><div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3= .0pt 0in 0in 0in'><p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;f= ont-family:"Tahoma","sans-serif"'>From:</span></b><span style=3D'font-size:= 10.0pt;font-family:"Tahoma","sans-serif"'> oauth-bounces@ietf.org [mailto:o= auth-bounces@ietf.org] <b>On Behalf Of </b>Paul Lindner<br><b>Sent:</b> Thu= rsday, June 10, 2010 8:24 AM<br><b>To:</b> OAuth WG (oauth@ietf.org)<br><b>= Subject:</b> [OAUTH-WG] Identifying OAuth 2.0 vs 1.0 requests<o:p></o:p></s= pan></p></div></div><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMs= oNormal>Hi,<o:p></o:p></p><div><p class=3DMsoNormal><o:p> </o:p></p></= div><div><p class=3DMsoNormal>As I've been working through our oauth2 imple= mentation I've noticed that it's not easy to disambiguate OAuth 1.0a vs 2.0= API calls based on the request parameters alone.   Based on some inve= stigative at the Shindig project it appears that the only standard way to t= o determine 1.0a vs 2.0 is by checking for the <span class=3Dapple-sty= le-span><span style=3D'font-size:9.0pt;font-family:"Arial","sans-serif"'>oa= uth_signature_method parameter.  More info here:</span></span><o:p></o= :p></p></div><div><p class=3DMsoNormal><o:p> </o:p></p></div><div><p c= lass=3DMsoNormal><a href=3D"https://issues.apache.org/jira/browse/SHINDIG-1= 361">https://issues.apache.org/jira/browse/SHINDIG-1361</a><o:p></o:p></p><= /div><div><p class=3DMsoNormal><o:p> </o:p></p></div><div><p class=3DM= soNormal>Has anyone else considered this use case?  How did you solve = it?<o:p></o:p></p></div><div><p class=3DMsoNormal><o:p> </o:p></p></di= v></div></div></body></html>= --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EAF729EP3PW5EX1MB01E_-- From torsten@lodderstedt.net Thu Jun 10 08:46:14 2010 Return-Path: <torsten@lodderstedt.net> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E10AF3A6A01 for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 08:46:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.187 X-Spam-Level: X-Spam-Status: No, score=-0.187 tagged_above=-999 required=5 tests=[AWL=-0.538, BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CX+8bp2ESikj for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 08:46:13 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.18.16]) by core3.amsl.com (Postfix) with ESMTP id 702E53A6A2D for <oauth@ietf.org>; Thu, 10 Jun 2010 08:46:13 -0700 (PDT) Received: from p4fff1ec5.dip.t-dialin.net ([79.255.30.197] helo=[127.0.0.1]) by smtprelay04.ispgateway.de with esmtpa (Exim 4.68) (envelope-from <torsten@lodderstedt.net>) id 1OMjxO-0004rc-8V for oauth@ietf.org; Thu, 10 Jun 2010 17:46:14 +0200 Message-ID: <4C1108C4.9040501@lodderstedt.net> Date: Thu, 10 Jun 2010 17:46:12 +0200 From: Torsten Lodderstedt <torsten@lodderstedt.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org> References: <4BFAA6AB.8040809@lodderstedt.net> <4BFC3142.6010506@lodderstedt.net> <AANLkTilRireowt1v8SidOiMJ-7ilBfvSqAiNfecA7uwR@mail.gmail.com> <4BFC371A.5040109@lodderstedt.net> <AANLkTikF1wk5eqme-N4RHviB5M7HzGYzy0p1mGuaux5g@mail.gmail.com> <4C07F407.4050305@lodderstedt.net> <1275663845.7068.94.camel@localhost.localdomain> <4C09732B.5040800@lodderstedt.net> <4C0F6A9C.2060607@lodderstedt.net> In-Reply-To: <4C0F6A9C.2060607@lodderstedt.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Subject: Re: [OAUTH-WG] proposal: multiple access tokens from a single authorization flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 10 Jun 2010 15:46:15 -0000 no one in the WG having an opinion on this topic? Am 09.06.2010 12:19, schrieb Torsten Lodderstedt: > Hi all, > > I would like to see support in OAuth2 for the authorization of > arbitrary scopes in a single authorization flow for all kinds of > deployments. In some deployments this may require to issue multiple > access tokens at once. > > Therefore, I would like to propose the following addition to section > 2.3.2.1. (Access Token Response): > > Add an optional parameter "additional_access_tokens". > > additional_access_tokens > OPTIONAL. Array of access tokens issued by the authorization > server along with respective expiration and scope. > Used > if the authorization server decides to issue more > than > one access token. The scopes of the different > tokens may > not overlap. > > Example: > HTTP/1.1 200 OK > Content-Type: application/json > Cache-Control: no-store > > { > "access_token":"SlAV32hkKG", > "expires_in":3600, > "refresh_token":"8xLOxBtZp8", > scope:"https://imap.example.com", > additional_access_tokens:[ > { > "access_token":"SlAV32hkKG2", > "expires_in":3600, > scope:"https://sip.example.com" > }, > { > "access_token":"SlAV32hkKG3", > "expires_in":3600, > scope:"https://contacts.example.com/read" > }, > { > "access_token":"SlAV32hkKG4", > "expires_in":3600, > scope:"https://webdav.example.com/read" > } > ] > } > > --- Some motivation --- > > I think we will see more and more clients integrating different > end-user services (like mashups). Based on the current draft, some > OAuth authorization servers may not be able to support such clients > with an acceptable user experiences. > > Suppose a communication client integrating the following services: > - e-Mail via IMAP > - Voice over IP using the SIP protocol > - Contacts via SyncML over HTTP > - Webstorage access (e.g. for e-Mail attachments) using HTTP/WebDAV > > For a particular end-user, the client may discover that all of the > end-user's services rely on the same OAuth2-based authorization server > because they are provided by the same organization (e.g. an isp or a > telco). The services are distinguished at the authorization server by > different scopes (probably including permissions as well), e.g. : > > imap - https://imap.example.com > sip - https://sip.example.com > contacts - https://contacts.example.com/read > webstorage - https://contacts.example.com/read > > Some providers may want to issue different service-specific tokens in > such a setup (Deutsche Telekom does it already), for the following > reasons: > > 1) Security > > a) minimize impact of token abuse - tokens may leak in many ways, > e.g. through log files, proxies or HTTP referer. If a provider just > uses a single token for all services, the impact of token leakage is > much higher. For example, if a token gets exposed by the _contacts_ > service via HTTP referer, an adversary may place long-distance calls > using that token on the _VoIP_ service at the expense of the end-user. > This threat holds for all kinds of tokens (handles and self-contained > tokens). > > b) use a shared secret between authz server and a single service only > - a major critism from the operational security perspective to OAuth > 1.0a was the need to spread client secrets to resource servers. Using > the same shared secret to sign/encrypt tokens for different services > is a comparable problem. This aspect is relevant for self-contained > tokens, only. > > 2) Privacy - the provider wants to restrict access of services to > personal data to the data a particular service is allowed and > authorized to see. This is good style (IMHO), it might also be > required by law (e.g. German Federal Data Protection Act). This aspect > is relevant for self-contained tokens, only. > > 3) Bandwith efficiency - putting only the data required by the > services into the token saves bandwith. This aspect is relevant for > self-contained tokens, only. > > In my opinion, most of these aspects are just a consequence of the > decoupling of authorization server and resource server(s) in OAuth2. > If a single authorization server is responsible for several resource > servers, it has to ensure privacy protection and prevention of token > abuse for all of its services. This should also include some > separation between services, no matter if one uses self-contained > tokens or handles. > > Without the change I proposed, the authorization server in the example > scenario would need to force the client to perform _four_ subsequent > authorization flows in order to obtain all required tokens. Moreover, > the client would need to manage four refresh tokens. > > I would kindly ask you to support my proposal. In my opinion, it > significantly improves the applicability of OAuth2 while the change to > the current draft is minimal. Moreover, deployments w/o the need to > issue multiple tokens are not affected at all. > > Any thoughts? > > regards, > Torsten. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From recordond@gmail.com Thu Jun 10 09:01:15 2010 Return-Path: <recordond@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D4DF28C114 for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 09:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.476 X-Spam-Level: X-Spam-Status: No, score=-0.476 tagged_above=-999 required=5 tests=[AWL=-0.477, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LiJp1ohvQT-3 for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 09:01:14 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 070363A6983 for <oauth@ietf.org>; Thu, 10 Jun 2010 09:01:13 -0700 (PDT) Received: by gyh4 with SMTP id 4so46013gyh.31 for <oauth@ietf.org>; Thu, 10 Jun 2010 09:00:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=fcGG6zYF9os33DZ7SuqJgGVp0ZJjOWry2owkL+gBaOE=; b=IVeBTaMZ9SRhH3uQ4YftrzUousqq1BVT0U0Wo96tL9+zHQLKGWAztExKFHq2qboMZJ fEOed88FKrMTmN+37S8dKyNRTzmObHvWSF6LgXfafWkAFz0kwby5oBWkVBHkWJZ5SGdG x8fcwXjyh5m/XMYqyQaoQuaQAsPx9sFaGyGAo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=G3UpvvnoK2K1uxR3GOYadbfZz5N9FwZ/XPlbrX7j+a6+X+KnPnCszB8AExqxPCwThP I4UnSna8/LHtcpfCZliGSIFYKO0Fhqi5bdnuG/w8cDQxV44HVcV01tE3ZoG3plHVJpq9 M4UC3csxfZVAJl8W06JssNsAumY2rAQwN/Wdo= MIME-Version: 1.0 Received: by 10.150.56.37 with SMTP id e37mr1507979yba.292.1276185253924; Thu, 10 Jun 2010 08:54:13 -0700 (PDT) Received: by 10.231.192.4 with HTTP; Thu, 10 Jun 2010 08:54:13 -0700 (PDT) In-Reply-To: <4C1108C4.9040501@lodderstedt.net> References: <4BFAA6AB.8040809@lodderstedt.net> <4BFC3142.6010506@lodderstedt.net> <AANLkTilRireowt1v8SidOiMJ-7ilBfvSqAiNfecA7uwR@mail.gmail.com> <4BFC371A.5040109@lodderstedt.net> <AANLkTikF1wk5eqme-N4RHviB5M7HzGYzy0p1mGuaux5g@mail.gmail.com> <4C07F407.4050305@lodderstedt.net> <1275663845.7068.94.camel@localhost.localdomain> <4C09732B.5040800@lodderstedt.net> <4C0F6A9C.2060607@lodderstedt.net> <4C1108C4.9040501@lodderstedt.net> Date: Thu, 10 Jun 2010 08:54:13 -0700 Message-ID: <AANLkTils4bwYtv5u9yXJycqTQ_NFt0BUtA7P0kBTITpX@mail.gmail.com> From: David Recordon <recordond@gmail.com> To: Torsten Lodderstedt <torsten@lodderstedt.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] proposal: multiple access tokens from a single authorization flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 10 Jun 2010 16:01:15 -0000 I strongly believe that it should be an extension. Even optional response parameters increase the complexity for client developers and this in particular affects the data model used to store access tokens. --David On Thu, Jun 10, 2010 at 8:46 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote: > no one in the WG having an opinion on this topic? > > Am 09.06.2010 12:19, schrieb Torsten Lodderstedt: >> >> Hi all, >> >> I would like to see support in OAuth2 for the authorization of arbitrary >> scopes in a single authorization flow for all kinds of deployments. In s= ome >> deployments this may require to issue multiple access tokens at once. >> >> Therefore, I would like to propose the following addition to section >> 2.3.2.1. (Access Token Response): >> >> Add an optional parameter "additional_access_tokens". >> >> =A0 additional_access_tokens >> =A0 =A0 =A0 =A0 OPTIONAL. =A0Array of access tokens issued by the author= ization >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0server along with respective expi= ration and scope. Used >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if the authorization server decid= es to issue more than >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0one access token. The scopes of t= he different tokens >> may >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0not overlap. >> >> Example: >> =A0 =A0 HTTP/1.1 200 OK >> =A0 =A0 Content-Type: application/json >> =A0 =A0 Cache-Control: no-store >> >> =A0 =A0 { >> =A0 =A0 =A0 "access_token":"SlAV32hkKG", >> =A0 =A0 =A0 "expires_in":3600, >> =A0 =A0 =A0 "refresh_token":"8xLOxBtZp8", >> =A0 =A0 =A0 scope:"https://imap.example.com", >> =A0 =A0 =A0 additional_access_tokens:[ >> =A0 =A0 =A0 =A0{ >> =A0 =A0 =A0 =A0 =A0"access_token":"SlAV32hkKG2", >> =A0 =A0 =A0 =A0 =A0"expires_in":3600, >> =A0 =A0 =A0 =A0 =A0scope:"https://sip.example.com" >> =A0 =A0 =A0 =A0}, >> =A0 =A0 =A0 =A0{ >> =A0 =A0 =A0 =A0 =A0"access_token":"SlAV32hkKG3", >> =A0 =A0 =A0 =A0 =A0"expires_in":3600, >> =A0 =A0 =A0 =A0 =A0scope:"https://contacts.example.com/read" >> =A0 =A0 =A0 =A0}, >> =A0 =A0 =A0 =A0{ >> =A0 =A0 =A0 =A0 =A0"access_token":"SlAV32hkKG4", >> =A0 =A0 =A0 =A0 =A0"expires_in":3600, >> =A0 =A0 =A0 =A0 =A0scope:"https://webdav.example.com/read" >> =A0 =A0 =A0 =A0} >> =A0 =A0 =A0 ] >> =A0 =A0 } >> >> --- Some motivation --- >> >> I think we will see more and more clients integrating different end-user >> services (like mashups). Based on the current draft, some OAuth >> authorization servers may not be able to support such clients with an >> acceptable user experiences. >> >> Suppose a communication client integrating the following services: >> - e-Mail via IMAP >> - Voice over IP using the SIP protocol >> - Contacts via SyncML over HTTP >> - Webstorage access (e.g. for e-Mail attachments) using HTTP/WebDAV >> >> For a particular end-user, the client may discover that all of the >> end-user's services rely on the same OAuth2-based authorization server >> because they are provided by the same organization (e.g. an isp or a tel= co). >> The services are distinguished at the authorization server by different >> scopes (probably including permissions as well), e.g. : >> >> imap - https://imap.example.com >> sip - =A0https://sip.example.com >> contacts - https://contacts.example.com/read >> webstorage - https://contacts.example.com/read >> >> Some providers may want to issue different service-specific tokens in su= ch >> a setup (Deutsche Telekom does it already), for the following reasons: >> >> 1) Security >> >> =A0a) minimize impact of token abuse - tokens may leak in many ways, e.g= . >> through log files, proxies or HTTP referer. If a provider just uses a si= ngle >> token for all services, the impact of token leakage is much higher. For >> example, if a token gets exposed by the _contacts_ service via HTTP refe= rer, >> an adversary may place long-distance calls using that token on the _VoIP= _ >> service at the expense of the end-user. This threat holds for all kinds = of >> tokens (handles and self-contained tokens). >> >> =A0b) use a shared secret between authz server and a single service only= - a >> major critism from the operational security perspective to OAuth 1.0a wa= s >> the need to spread client secrets to resource servers. Using the same sh= ared >> secret to sign/encrypt tokens for different services is a comparable >> problem. This aspect is relevant for self-contained tokens, only. >> >> 2) Privacy - the provider wants to restrict access of services to person= al >> data to the data a particular service is allowed and authorized to see. = This >> is good style (IMHO), it might also be required by law (e.g. German Fede= ral >> Data Protection Act). This aspect is relevant for self-contained tokens, >> only. >> >> 3) Bandwith efficiency - putting only the data required by the services >> into the token saves bandwith. This aspect is relevant for self-containe= d >> tokens, only. >> >> In my opinion, most of these aspects are just a consequence of the >> decoupling of authorization server and resource server(s) in OAuth2. If = a >> single authorization server is responsible for several resource servers,= it >> has to ensure privacy protection and prevention of token abuse for all o= f >> its services. This should also include some separation between services,= no >> matter if one uses self-contained tokens or handles. >> >> Without the change I proposed, the authorization server in the example >> scenario would need to force the client to perform _four_ subsequent >> authorization flows in order to obtain all required tokens. Moreover, th= e >> client would need to manage four refresh tokens. >> >> I would kindly ask you to support my proposal. In my opinion, it >> significantly improves the applicability of OAuth2 while the change to t= he >> current draft is minimal. Moreover, deployments w/o the need to issue >> multiple tokens are not affected at all. >> >> Any thoughts? >> >> 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 > From lindner@inuus.com Thu Jun 10 09:41:35 2010 Return-Path: <lindner@inuus.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F36073A68FC for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 09:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.676 X-Spam-Level: X-Spam-Status: No, score=-0.676 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7hSJuszlsnV for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 09:41:34 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id E16633A6814 for <oauth@ietf.org>; Thu, 10 Jun 2010 09:41:33 -0700 (PDT) Received: by gwj16 with SMTP id 16so84636gwj.31 for <oauth@ietf.org>; Thu, 10 Jun 2010 09:41:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.42.24 with SMTP id p24mr1375692agp.159.1276188091719; Thu, 10 Jun 2010 09:41:31 -0700 (PDT) Received: by 10.90.30.11 with HTTP; Thu, 10 Jun 2010 09:41:31 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF729E@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <AANLkTilcANtf9WsFh4jJPUBkbCu5x2doTMQEr4_h_Rys@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3EAF729E@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 10 Jun 2010 09:41:31 -0700 Message-ID: <AANLkTimz_V33JnJWsh_jgKoeGgAj1bhYhfge6-C86rJ2@mail.gmail.com> From: Paul Lindner <lindner@inuus.com> To: Eran Hammer-Lahav <eran@hueniverse.com> Content-Type: multipart/alternative; boundary=001636283b1cdfa4550488afb1f6 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Identifying OAuth 2.0 vs 1.0 requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 10 Jun 2010 16:41:35 -0000 --001636283b1cdfa4550488afb1f6 Content-Type: text/plain; charset=ISO-8859-1 I am talking about the resource server. Specifically I want to be able to quickly determine if an incoming request is 1.0a vs 2.0. And since this is a library it can't make a lot of assumptions about the specific environment it's running in. At first I thought I would check the oauth_version parameter. It turns out the 1.0a spec says that it is optional. The only one that is required for 1.0a is oauth_signature_method. Sadly we're long past time to change the spec to optimize for this use-case. (It would have been better to have a parameter for oauth 2.0 that is distinct from 1.0a) At the very least this message will live on in the mailing list archives -- at best we document the proper way to distinguish between the two versions somewhere. On Thu, Jun 10, 2010 at 8:44 AM, Eran Hammer-Lahav <eran@hueniverse.com>wrote: > The request is very different on the resource server. On the authorization > server, why would you use the same endpoint? > > > > EHL > > > > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf > Of *Paul Lindner > *Sent:* Thursday, June 10, 2010 8:24 AM > *To:* OAuth WG (oauth@ietf.org) > *Subject:* [OAUTH-WG] Identifying OAuth 2.0 vs 1.0 requests > > > > Hi, > > > > As I've been working through our oauth2 implementation I've noticed that > it's not easy to disambiguate OAuth 1.0a vs 2.0 API calls based on the > request parameters alone. Based on some investigative at the Shindig > project it appears that the only standard way to to determine 1.0a vs 2.0 is > by checking for the oauth_signature_method parameter. More info here: > > > > https://issues.apache.org/jira/browse/SHINDIG-1361 > > > > Has anyone else considered this use case? How did you solve it? > > > --001636283b1cdfa4550488afb1f6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I am talking about the resource server. Specifically I want to be able to q= uickly determine if an incoming request is 1.0a vs 2.0. =A0And since this i= s a library it can't make a lot of assumptions about the specific envir= onment it's running in.<div> <br></div><div>At first I thought I would check the oauth_version parameter= . =A0It turns out the 1.0a spec says that it is optional. =A0The only one t= hat is required for 1.0a is=A0<span><span style=3D"font-size: 9pt; ">oauth_= signature_method.</span></span></div> <div><span><span style=3D"font-size: 9pt; "><br></span></span></div><div><s= pan><span style=3D"font-size: 9pt; ">Sadly we're long past time to chan= ge the spec to optimize for this use-case. =A0(It would have been better to= have a parameter for oauth 2.0 that is distinct from 1.0a) =A0At the very = least this message will live on in the mailing list archives -- at best we = document the proper way to distinguish between the two versions somewhere.<= /span></span></div> <meta charset=3D"utf-8"><div><br><div class=3D"gmail_quote">On Thu, Jun 10,= 2010 at 8:44 AM, Eran Hammer-Lahav <span dir=3D"ltr"><<a href=3D"mailto= :eran@hueniverse.com">eran@hueniverse.com</a>></span> wrote:<br><blockqu= ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s= olid;padding-left:1ex;"> <div lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div><p class=3D"MsoNorm= al"><span style=3D"font-size:11.0pt;color:#1F497D">The request is very diff= erent on the resource server. On the authorization server, why would you us= e the same endpoint?</span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;color:#1F497D">=A0</= span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;color:#1F49= 7D">EHL</span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;co= lor:#1F497D">=A0</span></p> <div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in = 4.0pt"><div><div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;paddin= g:3.0pt 0in 0in 0in"><p class=3D"MsoNormal"><b><span style=3D"font-size:10.= 0pt">From:</span></b><span style=3D"font-size:10.0pt"> <a href=3D"mailto:oa= uth-bounces@ietf.org" target=3D"_blank">oauth-bounces@ietf.org</a> [mailto:= <a href=3D"mailto:oauth-bounces@ietf.org" target=3D"_blank">oauth-bounces@i= etf.org</a>] <b>On Behalf Of </b>Paul Lindner<br> <b>Sent:</b> Thursday, June 10, 2010 8:24 AM<br><b>To:</b> OAuth WG (<a hre= f=3D"mailto:oauth@ietf.org" target=3D"_blank">oauth@ietf.org</a>)<br><b>Sub= ject:</b> [OAUTH-WG] Identifying OAuth 2.0 vs 1.0 requests</span></p></div> </div><div><div></div><div class=3D"h5"><p class=3D"MsoNormal">=A0</p><p cl= ass=3D"MsoNormal">Hi,</p><div><p class=3D"MsoNormal">=A0</p></div><div><p c= lass=3D"MsoNormal">As I've been working through our oauth2 implementati= on I've noticed that it's not easy to disambiguate OAuth 1.0a vs 2.= 0 API calls based on the request parameters alone. =A0 Based on some invest= igative at the Shindig project it appears that the only standard way to to = determine 1.0a vs 2.0 is by checking for the=A0<span><span style=3D"font-si= ze:9.0pt">oauth_signature_method parameter. =A0More info here:</span></span= ></p> </div><div><p class=3D"MsoNormal">=A0</p></div><div><p class=3D"MsoNormal">= <a href=3D"https://issues.apache.org/jira/browse/SHINDIG-1361" target=3D"_b= lank">https://issues.apache.org/jira/browse/SHINDIG-1361</a></p></div><div>= <p class=3D"MsoNormal"> =A0</p></div><div><p class=3D"MsoNormal">Has anyone else considered this us= e case? =A0How did you solve it?</p></div><div><p class=3D"MsoNormal">=A0</= p></div></div></div></div></div></div></blockquote></div><br></div> --001636283b1cdfa4550488afb1f6-- From igor.faynberg@alcatel-lucent.com Thu Jun 10 10:00:09 2010 Return-Path: <igor.faynberg@alcatel-lucent.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8D3C28C10E for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 10:00:08 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQ9sd8T4I7xR for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 10:00:06 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id E3CCF3A67D6 for <oauth@ietf.org>; Thu, 10 Jun 2010 10:00:05 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id o5AH079C005678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Jun 2010 12:00:07 -0500 (CDT) Received: from [135.222.134.173] (faynberg-c1.mh.lucent.com [135.222.134.173]) by umail.lucent.com (8.13.8/TPES) with ESMTP id o5AH06I3013272; Thu, 10 Jun 2010 12:00:06 -0500 (CDT) Message-ID: <4C111A17.4060703@alcatel-lucent.com> Date: Thu, 10 Jun 2010 13:00:07 -0400 From: Igor Faynberg <igor.faynberg@alcatel-lucent.com> Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Torsten Lodderstedt <torsten@lodderstedt.net> References: <4BFAA6AB.8040809@lodderstedt.net> <4BFC3142.6010506@lodderstedt.net> <AANLkTilRireowt1v8SidOiMJ-7ilBfvSqAiNfecA7uwR@mail.gmail.com> <4BFC371A.5040109@lodderstedt.net> <AANLkTikF1wk5eqme-N4RHviB5M7HzGYzy0p1mGuaux5g@mail.gmail.com> <4C07F407.4050305@lodderstedt.net> <1275663845.7068.94.camel@localhost.localdomain> <4C09732B.5040800@lodderstedt.net> <4C0F6A9C.2060607@lodderstedt.net> <4C1108C4.9040501@lodderstedt.net> In-Reply-To: <4C1108C4.9040501@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.35 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] proposal: multiple access tokens from a single authorization flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 10 Jun 2010 17:00:09 -0000 I thought I had already written this, but I guess the e-mail never went anywhere... I do have a strong opinion on Torsten's proposal, and it is POSITIVE. A nit pick: I would replace "Array" with "List," to read "A list of access tokens issued..." Igor Torsten Lodderstedt wrote: > no one in the WG having an opinion on this topic? > > Am 09.06.2010 12:19, schrieb Torsten Lodderstedt: >> Hi all, >> >> I would like to see support in OAuth2 for the authorization of >> arbitrary scopes in a single authorization flow for all kinds of >> deployments. In some deployments this may require to issue multiple >> access tokens at once. >> >> Therefore, I would like to propose the following addition to section >> 2.3.2.1. (Access Token Response): >> >> Add an optional parameter "additional_access_tokens". >> >> additional_access_tokens >> OPTIONAL. Array of access tokens issued by the authorization >> server along with respective expiration and >> scope. Used >> if the authorization server decides to issue more >> than >> one access token. The scopes of the different >> tokens may >> not overlap. >> >> Example: >> HTTP/1.1 200 OK >> Content-Type: application/json >> Cache-Control: no-store >> >> { >> "access_token":"SlAV32hkKG", >> "expires_in":3600, >> "refresh_token":"8xLOxBtZp8", >> scope:"https://imap.example.com", >> additional_access_tokens:[ >> { >> "access_token":"SlAV32hkKG2", >> "expires_in":3600, >> scope:"https://sip.example.com" >> }, >> { >> "access_token":"SlAV32hkKG3", >> "expires_in":3600, >> scope:"https://contacts.example.com/read" >> }, >> { >> "access_token":"SlAV32hkKG4", >> "expires_in":3600, >> scope:"https://webdav.example.com/read" >> } >> ] >> } >> >> --- Some motivation --- >> >> I think we will see more and more clients integrating different >> end-user services (like mashups). Based on the current draft, some >> OAuth authorization servers may not be able to support such clients >> with an acceptable user experiences. >> >> Suppose a communication client integrating the following services: >> - e-Mail via IMAP >> - Voice over IP using the SIP protocol >> - Contacts via SyncML over HTTP >> - Webstorage access (e.g. for e-Mail attachments) using HTTP/WebDAV >> >> For a particular end-user, the client may discover that all of the >> end-user's services rely on the same OAuth2-based authorization >> server because they are provided by the same organization (e.g. an >> isp or a telco). The services are distinguished at the authorization >> server by different scopes (probably including permissions as well), >> e.g. : >> >> imap - https://imap.example.com >> sip - https://sip.example.com >> contacts - https://contacts.example.com/read >> webstorage - https://contacts.example.com/read >> >> Some providers may want to issue different service-specific tokens in >> such a setup (Deutsche Telekom does it already), for the following >> reasons: >> >> 1) Security >> >> a) minimize impact of token abuse - tokens may leak in many ways, >> e.g. through log files, proxies or HTTP referer. If a provider just >> uses a single token for all services, the impact of token leakage is >> much higher. For example, if a token gets exposed by the _contacts_ >> service via HTTP referer, an adversary may place long-distance calls >> using that token on the _VoIP_ service at the expense of the >> end-user. This threat holds for all kinds of tokens (handles and >> self-contained tokens). >> >> b) use a shared secret between authz server and a single service >> only - a major critism from the operational security perspective to >> OAuth 1.0a was the need to spread client secrets to resource servers. >> Using the same shared secret to sign/encrypt tokens for different >> services is a comparable problem. This aspect is relevant for >> self-contained tokens, only. >> >> 2) Privacy - the provider wants to restrict access of services to >> personal data to the data a particular service is allowed and >> authorized to see. This is good style (IMHO), it might also be >> required by law (e.g. German Federal Data Protection Act). This >> aspect is relevant for self-contained tokens, only. >> >> 3) Bandwith efficiency - putting only the data required by the >> services into the token saves bandwith. This aspect is relevant for >> self-contained tokens, only. >> >> In my opinion, most of these aspects are just a consequence of the >> decoupling of authorization server and resource server(s) in OAuth2. >> If a single authorization server is responsible for several resource >> servers, it has to ensure privacy protection and prevention of token >> abuse for all of its services. This should also include some >> separation between services, no matter if one uses self-contained >> tokens or handles. >> >> Without the change I proposed, the authorization server in the >> example scenario would need to force the client to perform _four_ >> subsequent authorization flows in order to obtain all required >> tokens. Moreover, the client would need to manage four refresh tokens. >> >> I would kindly ask you to support my proposal. In my opinion, it >> significantly improves the applicability of OAuth2 while the change >> to the current draft is minimal. Moreover, deployments w/o the need >> to issue multiple tokens are not affected at all. >> >> Any thoughts? >> >> 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 From yarong@microsoft.com Thu Jun 10 10:20:49 2010 Return-Path: <yarong@microsoft.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BD6C3A6992 for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 10:20:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.999 X-Spam-Level: X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bG4Bd48g9fC8 for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 10:20:48 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id E6BA13A6917 for <oauth@ietf.org>; Thu, 10 Jun 2010 10:20:47 -0700 (PDT) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 10 Jun 2010 10:20:50 -0700 Received: from TK5EX14MBXC115.redmond.corp.microsoft.com ([169.254.4.103]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.01.0160.007; Thu, 10 Jun 2010 10:20:49 -0700 From: Yaron Goland <yarong@microsoft.com> To: Eran Hammer-Lahav <eran@hueniverse.com>, "oauth@ietf.org" <oauth@ietf.org> Thread-Topic: Questions about sections 3.2/3.3 Thread-Index: Acr4TV5Gu7PqT32USNegznSs4LRTdwPBQssAAFuWBlA= Date: Thu, 10 Jun 2010 17:20:50 +0000 Message-ID: <7C01E631FF4B654FA1E783F1C0265F8C57959A42@TK5EX14MBXC115.redmond.corp.microsoft.com> References: <7C01E631FF4B654FA1E783F1C0265F8C578D67E6@TK5EX14MBXC113.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343B3EAF6E13@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF6E13@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Questions about sections 3.2/3.3 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 10 Jun 2010 17:20:49 -0000 The proposed error codes all seem reasonable but it would be good to call t= hem out in the spec so there are common understandings of how to handle the= situation. RFC 5746 matters because the TLS renegotiation attack is particularly poten= t against exactly the kind of web services that would use OAuth. But I leav= e it to the security mavens to figure out if we can reasonably go out witho= ut requiring 5746. Is the threat of the renegotiation attack strong enough = to merit 5746? I'm honestly not sure. For error messages I was proposing URIs only so that 3rd parties can add in= their own error messages without conflicting. It would be equally fine to = say something along the lines of the spec will use plain text strings and a= nyone else who wants to use a plain text string needs to get a RFC approved= . If you want to shove in your own errors then use a URI to prevent collisi= ons. There has to be some benefit to going through the RFC process, let it = be that we get the easy to read strings. :) Your language around basic seems fine but shouldn't we say something about = realm? It is mandatory in basic. Thanks, Yaron > -----Original Message----- > From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] > Sent: Tuesday, June 08, 2010 3:11 PM > To: Yaron Goland; oauth@ietf.org > Subject: RE: Questions about sections 3.2/3.3 >=20 >=20 >=20 > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > Of Yaron Goland > > Sent: Thursday, May 20, 2010 12:20 PM > > To: oauth@ietf.org > > Subject: [OAUTH-WG] Questions about sections 3.2/3.3 > > > > I was reading through the spec and had some questions about 3.2 and > > 3.3 that I list below. > > =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 Yaron > > Section 3.2/3.3 - Handling requests without supported transport layer > > security > > > > Although optional in section 3.2 and mandatory in section 3.3 both > > sections have a similar challenge - what happens if someone makes a > > request without the transport layer security required by the endpoint? > > What HTTP error is to be returned? 401? 403? >=20 > 404 Not found. The server provides the absolute URI of the endpoint. If y= ou > ask for something else that doesn't exist, you get a 404. Note that the > endpoint in 3.2 is really a web-site, not a web service. It is a browser-= specific > endpoint and should support the strongest protection provided by > supported browsers. >=20 > > A further complication is that both sections explicitly allow for > > transport layer security solutions other than TLS/SSL. Doesn't this > > mean that we need to extend section 6.1's definition of the > > www-authenticate response header to also specify what transport layer > security mechanisms are supported? >=20 > Neither section uses the header because these endpoints are not OAuth- > protected. They might use something else but that's outside the scope. >=20 > In general, I think we just need to say what support is required and leav= e the > rest for servers to decide. There is no value in saying that other method= s may > be used (there is no standards police and when you do that, you break > interop anyway). >=20 > > Section 3.3 - Is TLS/SSL mandatory or optional? And if so, what > > version of TLS/SSL? >=20 > Is it ok to require TLS 1.2? >=20 > > The specification currently states: > > > > =A0=A0 .the > > =A0=A0 authorization server MUST require the use of a transport-layer > > =A0=A0 mechanism such as TLS/SSL (or a secure channel with equivalent > > =A0=A0 protections) when sending requests to the token endpoints. > > > > To me this text implies that an OAuth server could be conformant and > > not implement TLS/SSL but instead implement some other transport-layer > > security mechanism (say a VPN protocol). From an interoperability > > perspective that seems problematic since it means clients can't know > > what transport-layer solution the token endpoint will support. > > Wouldn't it be reasonable to put in a requirement that all OAuth > > endpoints MUST support RFC 5246 and RFC 5746? >=20 > 5246 makes sense. I don't know enough to say about 5746. >=20 > > In other words the language could read: ".the authorization server > > MUST require the use of a transport-layer mechanism when sending > > requests to the token endpoints. Specifically, authorization servers > > MUST support version 1.2 of TLS as defined in RFC 5246 and extended in > > RFC 5746 and MAY support other equivalent secure channel mechanisms". > > > > Section 3.3.1 - What error is returned if clients provide credentials > > in both the header and the body? >=20 > 400 Bad Request. >=20 > > Section 3.3.1 explicitly prohibits submitting client credentials using > > multiple schemes but it doesn't define what error to return if this > > requirement is violated. Given the requirement in section 3.3.2.2 to > > include the "error" field wouldn't it be useful to define URIs that > > map to specific errors defined in the specification? For example, "If > > the client does include multiple client credential schemes then, per > > section 3.3.2.2, a 400 Bad Request response MUST be sent with an error > > code of urn:ietf:rfc:X:multiple-client- credentials". >=20 > Why a URI? What's wrong with simple text strings? Are you expecting > collision of error messages? >=20 > > Section 3.3.1 - How exactly are client credentials passed via HTTP > > Basic authentication? >=20 > Client id -> username, client secret -> password. >=20 > > Although section 3.3.1 states that HTTP basic authentication is to be > > supported, it doesn't specify how. I realize the mapping is pretty > > obvious but standards are one area where it pays off to be pedantic. > > Would it be useful to add language such as?: > > > > "The authorization server MUST accept the client credentials using > > both the request parameters and the HTTP Basic authentication scheme > > as defined in [RFC2617]. When using HTTP Basic the client id MUST be > > mapped to the HTTP Basic userid and the client secret MUST be mapped > > to the HTTP Basic password. The realm value can either be discovered > > by sending an unauthenticated request and examining the returned realm > > value in the www-Authenticate header or by reading the authorization > > service's documentation." >=20 > I changed to: >=20 > The client MAY include the client credentials using an HTTP > authentication scheme > which supports authenticating using a username and password, = instead > of using the > 'client_id' and 'client_secret' request parameters. Including= the client > credentials using an HTTP authentication > scheme fulfills the requirements of including the parameters = as > defined by the > various flows. >=20 > Which I think does the trick. >=20 > EHL From mscurtescu@google.com Thu Jun 10 10:21:15 2010 Return-Path: <mscurtescu@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 367A63A69A6 for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 10:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.609 X-Spam-Level: X-Spam-Status: No, score=-103.609 tagged_above=-999 required=5 tests=[AWL=-0.232, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jsqb+d8vIDyd for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 10:21:14 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 34AC83A6917 for <oauth@ietf.org>; Thu, 10 Jun 2010 10:21:14 -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 o5AHLFod018211 for <oauth@ietf.org>; Thu, 10 Jun 2010 10:21:15 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1276190475; bh=sIbpXcv98TsFHkSj/227TmcEGOs=; h=MIME-Version:From:Date:Message-ID:Subject:To:Content-Type; b=M3hhZJScVcnZZzsGYddvQiYZaeutKdtAK2SwP6xKghIJOeg7/85hNsUpNEw7nIpzl n1lerkY47edQnlRHjyNXg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:from:date:message-id:subject:to:content-type; b=QJu8KutxflfVuYQCTk+wWLOZiN1le254zPM575F5inom4ZsPQWt1ndsFCM0Em37y+ 38s+DN6OItjOcQB29609Q== Received: from pwi6 (pwi6.prod.google.com [10.241.219.6]) by hpaq11.eem.corp.google.com with ESMTP id o5AHLDKr027792 for <oauth@ietf.org>; Thu, 10 Jun 2010 10:21:14 -0700 Received: by pwi6 with SMTP id 6so76559pwi.40 for <oauth@ietf.org>; Thu, 10 Jun 2010 10:21:13 -0700 (PDT) Received: by 10.141.3.14 with SMTP id f14mr351122rvi.98.1276190472971; Thu, 10 Jun 2010 10:21:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.124.13 with HTTP; Thu, 10 Jun 2010 10:20:52 -0700 (PDT) From: Marius Scurtescu <mscurtescu@google.com> Date: Thu, 10 Jun 2010 10:20:52 -0700 Message-ID: <AANLkTikqEWohAK31oOtEwlgxX0RvkP4lobxGOCxadPJz@mail.gmail.com> To: OAuth WG <oauth@ietf.org> Content-Type: text/plain; charset=ISO-8859-1 Subject: [OAUTH-WG] type=web_server X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 10 Jun 2010 17:21:15 -0000 There are two requests that have type=web_server (but they are directed to different endpoints): - 2.5.1. Client Requests Authorization - 2.5.2. Client Requests Access Token The is the only case when a type is used for more than one request. While the spec can work perfectly fine like this, if each request message had a unique type that would simplify parsing and validation in a generic library a lot. Can we change in 2.5.2 the type to something else? web_token? Thanks, Marius From igor.faynberg@alcatel-lucent.com Thu Jun 10 10:26:11 2010 Return-Path: <igor.faynberg@alcatel-lucent.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 410DC3A69C7 for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 10:26:11 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FmItf33Jkp-e for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 10:26:10 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 6DFBF3A6990 for <oauth@ietf.org>; Thu, 10 Jun 2010 10:26:10 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id o5AHQ9ej022697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Jun 2010 12:26:09 -0500 (CDT) Received: from [135.222.134.173] (faynberg-c1.mh.lucent.com [135.222.134.173]) by umail.lucent.com (8.13.8/TPES) with ESMTP id o5AHQ9rm011792; Thu, 10 Jun 2010 12:26:09 -0500 (CDT) Message-ID: <4C112031.9070806@alcatel-lucent.com> Date: Thu, 10 Jun 2010 13:26:09 -0400 From: Igor Faynberg <igor.faynberg@alcatel-lucent.com> Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Marius Scurtescu <mscurtescu@google.com> References: <AANLkTikqEWohAK31oOtEwlgxX0RvkP4lobxGOCxadPJz@mail.gmail.com> In-Reply-To: <AANLkTikqEWohAK31oOtEwlgxX0RvkP4lobxGOCxadPJz@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] type=web_server X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 10 Jun 2010 17:26:11 -0000 I agree. Clarity is essential, and if this is not fixed now, it will stay like that forever. In fact, I would define 'type=web_server_auth' for 2.5.1 and 'type=web_server_token' for 2.5.2. Igor Marius Scurtescu wrote: > There are two requests that have type=web_server (but they are > directed to different endpoints): > - 2.5.1. Client Requests Authorization > - 2.5.2. Client Requests Access Token > > The is the only case when a type is used for more than one request. > > While the spec can work perfectly fine like this, if each request > message had a unique type that would simplify parsing and validation > in a generic library a lot. > > Can we change in 2.5.2 the type to something else? web_token? > > Thanks, > Marius > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From mscurtescu@google.com Thu Jun 10 10:35:14 2010 Return-Path: <mscurtescu@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7657428C142 for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 10:35:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.531 X-Spam-Level: X-Spam-Status: No, score=-103.531 tagged_above=-999 required=5 tests=[AWL=-0.155, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dBLOjkgLpi9u for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 10:35:11 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id B32AD28C12A for <oauth@ietf.org>; Thu, 10 Jun 2010 10:35:07 -0700 (PDT) Received: from wpaz29.hot.corp.google.com (wpaz29.hot.corp.google.com [172.24.198.93]) by smtp-out.google.com with ESMTP id o5AHZ9ms018782 for <oauth@ietf.org>; Thu, 10 Jun 2010 10:35:09 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1276191309; bh=uPoAsYa4K3zDVOIcq6IRHR8zeMo=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=low5Bo2IUSYjxmYLZXa0PGUXiTFsQmHBAA5EPlR8ywtOoSSQwQQyAQkiGq6D5px84 NN5mCAk3hVNgTj6GgVOag== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding; b=ku/PqxH27TUnyRXS4kyBNOq4jE5krg67cm0o7oqRQRJkYeo0CUF8jGxw7TGXdgg2o Fyy87HaXDW/I9bycv1HbQ== Received: from pxi3 (pxi3.prod.google.com [10.243.27.3]) by wpaz29.hot.corp.google.com with ESMTP id o5AHZ2E7015427 for <oauth@ietf.org>; Thu, 10 Jun 2010 10:35:03 -0700 Received: by pxi3 with SMTP id 3so92044pxi.24 for <oauth@ietf.org>; Thu, 10 Jun 2010 10:35:02 -0700 (PDT) Received: by 10.141.90.21 with SMTP id s21mr359632rvl.118.1276191300510; Thu, 10 Jun 2010 10:35:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.124.13 with HTTP; Thu, 10 Jun 2010 10:34:40 -0700 (PDT) In-Reply-To: <AANLkTin7B9pPgSu3cNlJGkp_gCed-5aPGRZalzXd2Wg8@mail.gmail.com> References: <AANLkTingSGlJNZ5e_stPd1qU5I4gfbh3rQhqYUmqXvdB@mail.gmail.com> <C833CEB4.6B81%cmortimore@salesforce.com> <AANLkTinVQEPBVzmiHEGgHhzaILL0nRSvZpjIlrVEJwTw@mail.gmail.com> <AANLkTil1j7vl8PU2tgCzlWY0U6KiWPmRKiVOxvsctB00@mail.gmail.com> <AANLkTimCL-O7RIsUlt_zGDfkEEYb9w4_sPh6zxCMBsf0@mail.gmail.com> <AANLkTin7B9pPgSu3cNlJGkp_gCed-5aPGRZalzXd2Wg8@mail.gmail.com> From: Marius Scurtescu <mscurtescu@google.com> Date: Thu, 10 Jun 2010 10:34:40 -0700 Message-ID: <AANLkTilknKnF34td41H0Ycn3rF-mpCT-vDl5wVzQ0Xfb@mail.gmail.com> To: Andrew Arnott <andrewarnott@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "oauth@ietf.org" <oauth@ietf.org> Subject: Re: [OAUTH-WG] User-agent flow and pre-registered redirect_uri X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 10 Jun 2010 17:35:14 -0000 On Thu, Jun 10, 2010 at 8:35 AM, Andrew Arnott <andrewarnott@gmail.com> wro= te: > Thanks Marius. > > I've answered your question below. > > On Wed, Jun 9, 2010 at 9:35 AM, Marius Scurtescu <mscurtescu@google.com> > wrote: >> >> > I've always considered an authorization as a tuple of >> > client_id,user,scope,issue_date.=A0 If an authorization has been appro= ved, >> > and >> > another request for authorization for a subset of the scope previously >> > issued comes in, the auth server can skip the interactive user >> > authorization >> > and just approve the request since nothing new is being issued. >> >> The tuple seems right, except for the issue date, why would you add that= ? > > The issue_date enables to scenarios: expiring tokens and token revocation= . > Here's how, for each scenario: > > Obviously to know if a token has expired you need to know when it was > issued.=A0 Or, you can forget the issue date and just store the expiratio= n > date in the token. I choose to go with an issue date (plus an optional > expected lifetime) because it gives more ability in the future to say "oo= ps, > we had a security weakness in all tokens issued prior to [date], so let's > consider all earlier tokens invalid."=A0 It's harder to say that when all= you > have are expiration dates because you don't know how old the token is.=A0= This > is just the way I chose to do it, but I know there are other ways. > > Now let's look at how you revoke issued tokens.=A0 One of the nice things > enabled by OAuth 2.0 is that the authorization server and resource server > never have to store tokens if they are appropriate signed by the auth > server.=A0 This is great because (among other things) clients with > little-to-no ability to persistently store tokens may ask for tokens > frequently, and that could bog down an auth server with storing all those > issued tokens.=A0 But how can a user revoke a previously authorized token= if > no one but the client knows what the tokens are? (thought question)=A0 My > solution to this is that instead of thinking about revoking tokens, the u= ser > revokes authorizations.=A0 The user goes through his account on the > authorization server and sees a list of clients and what they are authori= zed > to do.=A0 Note that this only requires the auth server to store this > authorization tuple -- not the actual issued tokens.=A0 If the user click= s > "revoke" on one of these authorizations, that row is deleted in the > database.=A0 Issued tokens (both refresh and access tokens) have this sam= e > tuple encoded in them. > Now, when a refresh token is used to obtain a new short-lived access toke= n > (and you could do this on every access token use as well if you wanted) t= he > token is of course signature-validated, but it is also checked that the > authorization tuple has a matching tuple in the auth server's database.= =A0 If > it's missing, then that authorization has been revoked and the token is > thereby invalidated. > So why the issue date?=A0 Because suppose the user has authorized a clien= t and > then that client's tokens are compromised (stolen computer perhaps).=A0 T= he > user will of course revoke authorization for that client.=A0 The user the= n > gets a new copy of that client (perhaps a new computer) and authorizes it= . > Whoops.=A0 Now all those invalidated tokens are valid again because the > authorization tuple exists.=A0 Except now the issue date on the authoriza= tion > on the auth server is newer than in the refresh token on the invalidated > client.=A0 That's why issue date is such a critical part of an authorizat= ion > tuple.=A0 Any token issued prior to the earliest authorization on record = at > the auth server represents a revoked authorization, and without an issue > date in the tuple there's no way to recognize that. > > At least that's the way I'm seeing it.=A0 I hope that makes sense. I see where are you coming from. I assumed that access tokens are saved and issue/expiry times are associated with the tokens, not with the authorization decisions. Marius From mscurtescu@google.com Thu Jun 10 10:39:01 2010 Return-Path: <mscurtescu@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B662D28C15A for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 10:39:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.257 X-Spam-Level: X-Spam-Status: No, score=-101.257 tagged_above=-999 required=5 tests=[AWL=0.720, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RgGzARx8bdWs for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 10:39:01 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 9F3693A6993 for <oauth@ietf.org>; Thu, 10 Jun 2010 10:39:00 -0700 (PDT) Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id o5AHcvHE007617 for <oauth@ietf.org>; Thu, 10 Jun 2010 10:38:57 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1276191539; bh=1XkT+/Yuq1Pi2JiwDuxM+glCxbU=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=v0l81OmfFvesMVf+vBMJJ77aCYy+v+kyjy/vQ9gSfHO0ehK/11lcJtP3pWzEhW/ah +JTEgQkDWOfxY3cgH3MYg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding; b=WAOVq4gv3XCCDdUbZgE/x4sr3awl04XSwnN9Dn6y8AhKHy5OZ1Ps3L1OfrqsJ2K9S uhqVpD9/K2m+A3JM3C60A== Received: from pxi6 (pxi6.prod.google.com [10.243.27.6]) by wpaz17.hot.corp.google.com with ESMTP id o5AHcted030000 for <oauth@ietf.org>; Thu, 10 Jun 2010 10:38:56 -0700 Received: by pxi6 with SMTP id 6so76526pxi.29 for <oauth@ietf.org>; Thu, 10 Jun 2010 10:38:55 -0700 (PDT) Received: by 10.141.4.4 with SMTP id g4mr335090rvi.269.1276191535519; Thu, 10 Jun 2010 10:38:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.124.13 with HTTP; Thu, 10 Jun 2010 10:38:35 -0700 (PDT) In-Reply-To: <AANLkTimz_V33JnJWsh_jgKoeGgAj1bhYhfge6-C86rJ2@mail.gmail.com> References: <AANLkTilcANtf9WsFh4jJPUBkbCu5x2doTMQEr4_h_Rys@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3EAF729E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTimz_V33JnJWsh_jgKoeGgAj1bhYhfge6-C86rJ2@mail.gmail.com> From: Marius Scurtescu <mscurtescu@google.com> Date: Thu, 10 Jun 2010 10:38:35 -0700 Message-ID: <AANLkTin5h1gtVt3CJUjaUB56w2Ku3nJODyfo91dF9J7b@mail.gmail.com> To: Paul Lindner <lindner@inuus.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Identifying OAuth 2.0 vs 1.0 requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 10 Jun 2010 17:39:01 -0000 I run into the same issue. In section "4.2. URI Query Parameter", it would help if the parameter name, oauth_token, was different from OAuth 1. Marius On Thu, Jun 10, 2010 at 9:41 AM, Paul Lindner <lindner@inuus.com> wrote: > I am talking about the resource server. Specifically I want to be able to > quickly determine if an incoming request is 1.0a vs 2.0. =A0And since thi= s is > a library it can't make a lot of assumptions about the specific environme= nt > it's running in. > At first I thought I would check the oauth_version parameter. =A0It turns= out > the 1.0a spec says that it is optional. =A0The only one that is required = for > 1.0a is=A0oauth_signature_method. > Sadly we're long past time to change the spec to optimize for this use-ca= se. > =A0(It would have been better to have a parameter for oauth 2.0 that is > distinct from 1.0a) =A0At the very least this message will live on in the > mailing list archives -- at best we document the proper way to distinguis= h > between the two versions somewhere. > On Thu, Jun 10, 2010 at 8:44 AM, Eran Hammer-Lahav <eran@hueniverse.com> > wrote: >> >> The request is very different on the resource server. On the authorizati= on >> server, why would you use the same endpoint? >> >> >> >> EHL >> >> >> >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf O= f >> Paul Lindner >> Sent: Thursday, June 10, 2010 8:24 AM >> To: OAuth WG (oauth@ietf.org) >> Subject: [OAUTH-WG] Identifying OAuth 2.0 vs 1.0 requests >> >> >> >> Hi, >> >> >> >> As I've been working through our oauth2 implementation I've noticed that >> it's not easy to disambiguate OAuth 1.0a vs 2.0 API calls based on the >> request parameters alone. =A0 Based on some investigative at the Shindig >> project it appears that the only standard way to to determine 1.0a vs 2.= 0 is >> by checking for the=A0oauth_signature_method parameter. =A0More info her= e: >> >> >> >> https://issues.apache.org/jira/browse/SHINDIG-1361 >> >> >> >> Has anyone else considered this use case? =A0How did you solve it? >> >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From eran@hueniverse.com Thu Jun 10 10:42:29 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49DED3A6993 for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 10:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.723 X-Spam-Level: X-Spam-Status: No, score=-1.723 tagged_above=-999 required=5 tests=[AWL=0.876, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJN+gMNlDvBA for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 10:42:28 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 52CB23A698A for <oauth@ietf.org>; Thu, 10 Jun 2010 10:42:28 -0700 (PDT) Received: (qmail 29670 invoked from network); 10 Jun 2010 17:42:30 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 10 Jun 2010 17:42:29 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 10 Jun 2010 10:42:27 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: Marius Scurtescu <mscurtescu@google.com>, Paul Lindner <lindner@inuus.com> Date: Thu, 10 Jun 2010 10:42:21 -0700 Thread-Topic: [OAUTH-WG] Identifying OAuth 2.0 vs 1.0 requests Thread-Index: AcsIw9Gn6Lt+wXM2SeiMNbCttZrHvQAAGSRg Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF7328@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <AANLkTilcANtf9WsFh4jJPUBkbCu5x2doTMQEr4_h_Rys@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3EAF729E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTimz_V33JnJWsh_jgKoeGgAj1bhYhfge6-C86rJ2@mail.gmail.com> <AANLkTin5h1gtVt3CJUjaUB56w2Ku3nJODyfo91dF9J7b@mail.gmail.com> In-Reply-To: <AANLkTin5h1gtVt3CJUjaUB56w2Ku3nJODyfo91dF9J7b@mail.gmail.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Identifying OAuth 2.0 vs 1.0 requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 10 Jun 2010 17:42:29 -0000 But in that case, all the other oauth_* parameters are missing. It's trivia= l. EHL > -----Original Message----- > From: Marius Scurtescu [mailto:mscurtescu@google.com] > Sent: Thursday, June 10, 2010 10:39 AM > To: Paul Lindner > Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Identifying OAuth 2.0 vs 1.0 requests >=20 > I run into the same issue. In section "4.2. URI Query Parameter", it woul= d > help if the parameter name, oauth_token, was different from OAuth 1. >=20 > Marius >=20 >=20 >=20 > On Thu, Jun 10, 2010 at 9:41 AM, Paul Lindner <lindner@inuus.com> wrote: > > I am talking about the resource server. Specifically I want to be able > > to quickly determine if an incoming request is 1.0a vs 2.0. =A0And sinc= e > > this is a library it can't make a lot of assumptions about the > > specific environment it's running in. > > At first I thought I would check the oauth_version parameter. =A0It > > turns out the 1.0a spec says that it is optional. =A0The only one that > > is required for 1.0a is=A0oauth_signature_method. > > Sadly we're long past time to change the spec to optimize for this use-= case. > > =A0(It would have been better to have a parameter for oauth 2.0 that is > > distinct from 1.0a) =A0At the very least this message will live on in > > the mailing list archives -- at best we document the proper way to > > distinguish between the two versions somewhere. > > On Thu, Jun 10, 2010 at 8:44 AM, Eran Hammer-Lahav > > <eran@hueniverse.com> > > wrote: > >> > >> The request is very different on the resource server. On the > >> authorization server, why would you use the same endpoint? > >> > >> > >> > >> EHL > >> > >> > >> > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >> Behalf Of Paul Lindner > >> Sent: Thursday, June 10, 2010 8:24 AM > >> To: OAuth WG (oauth@ietf.org) > >> Subject: [OAUTH-WG] Identifying OAuth 2.0 vs 1.0 requests > >> > >> > >> > >> Hi, > >> > >> > >> > >> As I've been working through our oauth2 implementation I've noticed > >> that it's not easy to disambiguate OAuth 1.0a vs 2.0 API calls based > >> on the request parameters alone. =A0 Based on some investigative at th= e > >> Shindig project it appears that the only standard way to to determine > >> 1.0a vs 2.0 is by checking for the=A0oauth_signature_method > parameter. =A0More info here: > >> > >> > >> > >> https://issues.apache.org/jira/browse/SHINDIG-1361 > >> > >> > >> > >> Has anyone else considered this use case? =A0How did you solve it? > >> > >> > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > From mscurtescu@google.com Thu Jun 10 10:51:38 2010 Return-Path: <mscurtescu@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D60F43A67F6 for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 10:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.863 X-Spam-Level: X-Spam-Status: No, score=-103.863 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3BbinxS3cJIm for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 10:51:38 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 6010B3A6917 for <oauth@ietf.org>; Thu, 10 Jun 2010 10:51:34 -0700 (PDT) Received: from kpbe17.cbf.corp.google.com (kpbe17.cbf.corp.google.com [172.25.105.81]) by smtp-out.google.com with ESMTP id o5AHpZJT015132 for <oauth@ietf.org>; Thu, 10 Jun 2010 10:51:35 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1276192295; bh=+cPcG7g/89eWtZ1hkT/oKPtZW8Q=; h=MIME-Version:From:Date:Message-ID:Subject:To:Content-Type; b=oKgB9qsi9ajBZAQBzRjq/kIdg9eFN6AzmA9gYLpOVWFN8Bdz2eVsUU7d57v74qha2 b/nUY9CcVniN39enc8v6A== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:from:date:message-id:subject:to:content-type; b=qTGtJOufERrCK2ZjJahl/BrI1RquoYxmpp0v1hnZpgyLoLw0rEzqfvEU6sb2Gsebo wxHW0zx6KXVIaVCB1qynQ== Received: from pzk10 (pzk10.prod.google.com [10.243.19.138]) by kpbe17.cbf.corp.google.com with ESMTP id o5AHpY4l020012 for <oauth@ietf.org>; Thu, 10 Jun 2010 10:51:35 -0700 Received: by pzk10 with SMTP id 10so110062pzk.20 for <oauth@ietf.org>; Thu, 10 Jun 2010 10:51:34 -0700 (PDT) Received: by 10.141.124.4 with SMTP id b4mr391770rvn.41.1276192294463; Thu, 10 Jun 2010 10:51:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.124.13 with HTTP; Thu, 10 Jun 2010 10:51:14 -0700 (PDT) From: Marius Scurtescu <mscurtescu@google.com> Date: Thu, 10 Jun 2010 10:51:14 -0700 Message-ID: <AANLkTikl0Wp16bvqF-2MqcLN7OzdrnFIPI5FOV-B2yOf@mail.gmail.com> To: OAuth WG <oauth@ietf.org> Content-Type: text/plain; charset=ISO-8859-1 Subject: [OAUTH-WG] the format parameter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 10 Jun 2010 17:51:39 -0000 I am implementing an OAuth 2 library and the format parameter does not feel right. If a client is using a library then the response format should be totally transparent to the client. The library may have a setting if the client wants to force a format for whatever reason, but individual messages that the client builds and receives should not care about the format. I think initially the Accept header was used. All current "format" uses are in direct requests, so Accept could be used. To give a counter example, the User-Agent flow does not use "format" and it always returns form-encoded in the fragment. There where discussions to use JSON for this flow as well. Should we do that? If yes, do we need "format"? Accept does not work in this case. I don't have a good suggestions, just wondering if anyone else run into this issue. Marius From eran@hueniverse.com Thu Jun 10 10:52:52 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2E0B28C156 for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 10:52:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.088 X-Spam-Level: X-Spam-Status: No, score=-1.088 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gv0d46RjZoEn for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 10:52:51 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 7E28A28C161 for <oauth@ietf.org>; Thu, 10 Jun 2010 10:52:51 -0700 (PDT) Received: (qmail 593 invoked from network); 10 Jun 2010 17:52:53 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 10 Jun 2010 17:52:53 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 10 Jun 2010 10:52:52 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org> Date: Thu, 10 Jun 2010 10:52:45 -0700 Thread-Topic: Names for endpoints Thread-Index: AcsIxbt/1kyybQgwQJKv763yDblFlQ== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF7331@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: ALft AOdo Ah8c Bdrm Bews Bhwx ChR7 DFBP DZv/ Dw+c EKLr Exfx FV1S HAA8 IUBK LpHn; 1; bwBhAHUAdABoAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {86171BD0-23F6-4D37-B458-88A6931E95A6}; ZQByAGEAbgBAAGgAdQBlAG4AaQB2AGUAcgBzAGUALgBjAG8AbQA=; Thu, 10 Jun 2010 17:52:45 GMT; TgBhAG0AZQBzACAAZgBvAHIAIABlAG4AZABwAG8AaQBuAHQAcwA= x-cr-puzzleid: {86171BD0-23F6-4D37-B458-88A6931E95A6} acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OAUTH-WG] Names for endpoints X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 10 Jun 2010 17:52:52 -0000 Pick or suggest new ideas: * Endpoint used to interact with the end-user End-user Endpoint Front Channel Endpoint Authorization Endpoint End-User Authorization Endpoint User-Agent Endpoint * Endpoint used to interact directly with the client Token Endpoint Client Endpoint Back Channel Endpoint EHL From mscurtescu@google.com Thu Jun 10 10:53:33 2010 Return-Path: <mscurtescu@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02DAB28C15E for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 10:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.337 X-Spam-Level: X-Spam-Status: No, score=-101.337 tagged_above=-999 required=5 tests=[AWL=0.640, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6eTMqbeA2Fpj for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 10:53:32 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id D312C28C15D for <oauth@ietf.org>; Thu, 10 Jun 2010 10:53:31 -0700 (PDT) Received: from hpaq2.eem.corp.google.com (hpaq2.eem.corp.google.com [172.25.149.2]) by smtp-out.google.com with ESMTP id o5AHrWZK007666 for <oauth@ietf.org>; Thu, 10 Jun 2010 10:53:32 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1276192412; bh=tfGkPth6SExZzTbjEKLgmJ8VTnc=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=AQCt1Gtu352wySxLzHtSCsa4xLIiryZ7kdqkr9UOiT2aPmV43EMfdwIUexfSh5GsT GrGAgRzQp3PehNOfwiW4w== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding; b=hc93UCK/DXFdrITkUHEu+CwwPH+LpN9cY7jPfctUW9vUV7xwCqpYPTReZX2jMbyt6 oSYDzfgKHCNOPTMp8dodA== Received: from pxi8 (pxi8.prod.google.com [10.243.27.8]) by hpaq2.eem.corp.google.com with ESMTP id o5AHrVHw031575 for <oauth@ietf.org>; Thu, 10 Jun 2010 10:53:31 -0700 Received: by pxi8 with SMTP id 8so94440pxi.33 for <oauth@ietf.org>; Thu, 10 Jun 2010 10:53:30 -0700 (PDT) Received: by 10.141.88.13 with SMTP id q13mr348373rvl.272.1276192410623; Thu, 10 Jun 2010 10:53:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.124.13 with HTTP; Thu, 10 Jun 2010 10:53:10 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF7328@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <AANLkTilcANtf9WsFh4jJPUBkbCu5x2doTMQEr4_h_Rys@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3EAF729E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTimz_V33JnJWsh_jgKoeGgAj1bhYhfge6-C86rJ2@mail.gmail.com> <AANLkTin5h1gtVt3CJUjaUB56w2Ku3nJODyfo91dF9J7b@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3EAF7328@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu <mscurtescu@google.com> Date: Thu, 10 Jun 2010 10:53:10 -0700 Message-ID: <AANLkTimkHm9golV6SbGVj-AJOf1w_At9YWXODcP_Bbym@mail.gmail.com> To: Eran Hammer-Lahav <eran@hueniverse.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Identifying OAuth 2.0 vs 1.0 requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 10 Jun 2010 17:53:33 -0000 On Thu, Jun 10, 2010 at 10:42 AM, Eran Hammer-Lahav <eran@hueniverse.com> w= rote: > But in that case, all the other oauth_* parameters are missing. It's triv= ial. An OAuth 1 filter will interpret this as broken OAuth 1 authentication. Marius > > EHL > >> -----Original Message----- >> From: Marius Scurtescu [mailto:mscurtescu@google.com] >> Sent: Thursday, June 10, 2010 10:39 AM >> To: Paul Lindner >> Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org) >> Subject: Re: [OAUTH-WG] Identifying OAuth 2.0 vs 1.0 requests >> >> I run into the same issue. In section "4.2. URI Query Parameter", it wou= ld >> help if the parameter name, oauth_token, was different from OAuth 1. >> >> Marius >> >> >> >> On Thu, Jun 10, 2010 at 9:41 AM, Paul Lindner <lindner@inuus.com> wrote: >> > I am talking about the resource server. Specifically I want to be able >> > to quickly determine if an incoming request is 1.0a vs 2.0. =A0And sin= ce >> > this is a library it can't make a lot of assumptions about the >> > specific environment it's running in. >> > At first I thought I would check the oauth_version parameter. =A0It >> > turns out the 1.0a spec says that it is optional. =A0The only one that >> > is required for 1.0a is=A0oauth_signature_method. >> > Sadly we're long past time to change the spec to optimize for this use= -case. >> > =A0(It would have been better to have a parameter for oauth 2.0 that i= s >> > distinct from 1.0a) =A0At the very least this message will live on in >> > the mailing list archives -- at best we document the proper way to >> > distinguish between the two versions somewhere. >> > On Thu, Jun 10, 2010 at 8:44 AM, Eran Hammer-Lahav >> > <eran@hueniverse.com> >> > wrote: >> >> >> >> The request is very different on the resource server. On the >> >> authorization server, why would you use the same endpoint? >> >> >> >> >> >> >> >> EHL >> >> >> >> >> >> >> >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >> >> Behalf Of Paul Lindner >> >> Sent: Thursday, June 10, 2010 8:24 AM >> >> To: OAuth WG (oauth@ietf.org) >> >> Subject: [OAUTH-WG] Identifying OAuth 2.0 vs 1.0 requests >> >> >> >> >> >> >> >> Hi, >> >> >> >> >> >> >> >> As I've been working through our oauth2 implementation I've noticed >> >> that it's not easy to disambiguate OAuth 1.0a vs 2.0 API calls based >> >> on the request parameters alone. =A0 Based on some investigative at t= he >> >> Shindig project it appears that the only standard way to to determine >> >> 1.0a vs 2.0 is by checking for the=A0oauth_signature_method >> parameter. =A0More info here: >> >> >> >> >> >> >> >> https://issues.apache.org/jira/browse/SHINDIG-1361 >> >> >> >> >> >> >> >> Has anyone else considered this use case? =A0How did you solve it? >> >> >> >> >> > >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth >> > >> > > From eran@hueniverse.com Thu Jun 10 10:54:16 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 146F828C0FE for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 10:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.835 X-Spam-Level: X-Spam-Status: No, score=-1.835 tagged_above=-999 required=5 tests=[AWL=0.764, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jCbZhxNxaUlu for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 10:54:14 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id D8E9C3A698A for <oauth@ietf.org>; Thu, 10 Jun 2010 10:54:14 -0700 (PDT) Received: (qmail 2461 invoked from network); 10 Jun 2010 17:54:17 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 10 Jun 2010 17:54:16 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 10 Jun 2010 10:54:16 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: Marius Scurtescu <mscurtescu@google.com> Date: Thu, 10 Jun 2010 10:54:10 -0700 Thread-Topic: [OAUTH-WG] Identifying OAuth 2.0 vs 1.0 requests Thread-Index: AcsIxdlg+wxqXkZSRrKZLVAQfmDtswAAA8tw Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF7334@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <AANLkTilcANtf9WsFh4jJPUBkbCu5x2doTMQEr4_h_Rys@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3EAF729E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTimz_V33JnJWsh_jgKoeGgAj1bhYhfge6-C86rJ2@mail.gmail.com> <AANLkTin5h1gtVt3CJUjaUB56w2Ku3nJODyfo91dF9J7b@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3EAF7328@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTimkHm9golV6SbGVj-AJOf1w_At9YWXODcP_Bbym@mail.gmail.com> In-Reply-To: <AANLkTimkHm9golV6SbGVj-AJOf1w_At9YWXODcP_Bbym@mail.gmail.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Identifying OAuth 2.0 vs 1.0 requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 10 Jun 2010 17:54:16 -0000 Which is fine if it doesn't support 2.0. EHL > -----Original Message----- > From: Marius Scurtescu [mailto:mscurtescu@google.com] > Sent: Thursday, June 10, 2010 10:53 AM > To: Eran Hammer-Lahav > Cc: Paul Lindner; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Identifying OAuth 2.0 vs 1.0 requests >=20 > On Thu, Jun 10, 2010 at 10:42 AM, Eran Hammer-Lahav > <eran@hueniverse.com> wrote: > > But in that case, all the other oauth_* parameters are missing. It's tr= ivial. >=20 > An OAuth 1 filter will interpret this as broken OAuth 1 authentication. >=20 > Marius >=20 > > > > EHL > > > >> -----Original Message----- > >> From: Marius Scurtescu [mailto:mscurtescu@google.com] > >> Sent: Thursday, June 10, 2010 10:39 AM > >> To: Paul Lindner > >> Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org) > >> Subject: Re: [OAUTH-WG] Identifying OAuth 2.0 vs 1.0 requests > >> > >> I run into the same issue. In section "4.2. URI Query Parameter", it > >> would help if the parameter name, oauth_token, was different from > OAuth 1. > >> > >> Marius > >> > >> > >> > >> On Thu, Jun 10, 2010 at 9:41 AM, Paul Lindner <lindner@inuus.com> > wrote: > >> > I am talking about the resource server. Specifically I want to be > >> > able to quickly determine if an incoming request is 1.0a vs 2.0. > >> > And since this is a library it can't make a lot of assumptions > >> > about the specific environment it's running in. > >> > At first I thought I would check the oauth_version parameter. =A0It > >> > turns out the 1.0a spec says that it is optional. =A0The only one > >> > that is required for 1.0a is=A0oauth_signature_method. > >> > Sadly we're long past time to change the spec to optimize for this u= se- > case. > >> > =A0(It would have been better to have a parameter for oauth 2.0 that > >> > is distinct from 1.0a) =A0At the very least this message will live o= n > >> > in the mailing list archives -- at best we document the proper way > >> > to distinguish between the two versions somewhere. > >> > On Thu, Jun 10, 2010 at 8:44 AM, Eran Hammer-Lahav > >> > <eran@hueniverse.com> > >> > wrote: > >> >> > >> >> The request is very different on the resource server. On the > >> >> authorization server, why would you use the same endpoint? > >> >> > >> >> > >> >> > >> >> EHL > >> >> > >> >> > >> >> > >> >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >> >> Behalf Of Paul Lindner > >> >> Sent: Thursday, June 10, 2010 8:24 AM > >> >> To: OAuth WG (oauth@ietf.org) > >> >> Subject: [OAUTH-WG] Identifying OAuth 2.0 vs 1.0 requests > >> >> > >> >> > >> >> > >> >> Hi, > >> >> > >> >> > >> >> > >> >> As I've been working through our oauth2 implementation I've > >> >> noticed that it's not easy to disambiguate OAuth 1.0a vs 2.0 API > >> >> calls based on the request parameters alone. =A0 Based on some > >> >> investigative at the Shindig project it appears that the only > >> >> standard way to to determine 1.0a vs 2.0 is by checking for the > >> >> oauth_signature_method > >> parameter. =A0More info here: > >> >> > >> >> > >> >> > >> >> https://issues.apache.org/jira/browse/SHINDIG-1361 > >> >> > >> >> > >> >> > >> >> Has anyone else considered this use case? =A0How did you solve it? > >> >> > >> >> > >> > > >> > _______________________________________________ > >> > OAuth mailing list > >> > OAuth@ietf.org > >> > https://www.ietf.org/mailman/listinfo/oauth > >> > > >> > > > From lindner@inuus.com Thu Jun 10 10:54:39 2010 Return-Path: <lindner@inuus.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD0493A6990 for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 10:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PkMAi2Jg5iyZ for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 10:54:38 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 7455D28C155 for <oauth@ietf.org>; Thu, 10 Jun 2010 10:54:37 -0700 (PDT) Received: by gyh4 with SMTP id 4so146909gyh.31 for <oauth@ietf.org>; Thu, 10 Jun 2010 10:54:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.91.92.5 with SMTP id u5mr1265247agl.74.1276192476992; Thu, 10 Jun 2010 10:54:36 -0700 (PDT) Received: by 10.90.30.11 with HTTP; Thu, 10 Jun 2010 10:54:36 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF7328@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <AANLkTilcANtf9WsFh4jJPUBkbCu5x2doTMQEr4_h_Rys@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3EAF729E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTimz_V33JnJWsh_jgKoeGgAj1bhYhfge6-C86rJ2@mail.gmail.com> <AANLkTin5h1gtVt3CJUjaUB56w2Ku3nJODyfo91dF9J7b@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3EAF7328@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 10 Jun 2010 10:54:36 -0700 Message-ID: <AANLkTikrS4iosFM1Xca3NIPJrVmz_9YP8cCw85zpODJL@mail.gmail.com> From: Paul Lindner <lindner@inuus.com> To: Eran Hammer-Lahav <eran@hueniverse.com> Content-Type: multipart/alternative; boundary=001485f91b2441a1150488b0b72b Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Identifying OAuth 2.0 vs 1.0 requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 10 Jun 2010 17:54:40 -0000 --001485f91b2441a1150488b0b72b Content-Type: text/plain; charset=ISO-8859-1 If you're routing requests with a load balancer it's not so trivial. Instead of a substring match you're talking about a regex with negative lookahead matching -- that's why the presence of the signature param is essential to distinguishing between 2.0/1.0a. On Thu, Jun 10, 2010 at 10:42 AM, Eran Hammer-Lahav <eran@hueniverse.com>wrote: > But in that case, all the other oauth_* parameters are missing. It's > trivial. > > EHL > > > -----Original Message----- > > From: Marius Scurtescu [mailto:mscurtescu@google.com] > > Sent: Thursday, June 10, 2010 10:39 AM > > To: Paul Lindner > > Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org) > > Subject: Re: [OAUTH-WG] Identifying OAuth 2.0 vs 1.0 requests > > > > I run into the same issue. In section "4.2. URI Query Parameter", it > would > > help if the parameter name, oauth_token, was different from OAuth 1. > > > > Marius > > > > > > > > On Thu, Jun 10, 2010 at 9:41 AM, Paul Lindner <lindner@inuus.com> wrote: > > > I am talking about the resource server. Specifically I want to be able > > > to quickly determine if an incoming request is 1.0a vs 2.0. And since > > > this is a library it can't make a lot of assumptions about the > > > specific environment it's running in. > > > At first I thought I would check the oauth_version parameter. It > > > turns out the 1.0a spec says that it is optional. The only one that > > > is required for 1.0a is oauth_signature_method. > > > Sadly we're long past time to change the spec to optimize for this > use-case. > > > (It would have been better to have a parameter for oauth 2.0 that is > > > distinct from 1.0a) At the very least this message will live on in > > > the mailing list archives -- at best we document the proper way to > > > distinguish between the two versions somewhere. > > > On Thu, Jun 10, 2010 at 8:44 AM, Eran Hammer-Lahav > > > <eran@hueniverse.com> > > > wrote: > > >> > > >> The request is very different on the resource server. On the > > >> authorization server, why would you use the same endpoint? > > >> > > >> > > >> > > >> EHL > > >> > > >> > > >> > > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > > >> Behalf Of Paul Lindner > > >> Sent: Thursday, June 10, 2010 8:24 AM > > >> To: OAuth WG (oauth@ietf.org) > > >> Subject: [OAUTH-WG] Identifying OAuth 2.0 vs 1.0 requests > > >> > > >> > > >> > > >> Hi, > > >> > > >> > > >> > > >> As I've been working through our oauth2 implementation I've noticed > > >> that it's not easy to disambiguate OAuth 1.0a vs 2.0 API calls based > > >> on the request parameters alone. Based on some investigative at the > > >> Shindig project it appears that the only standard way to to determine > > >> 1.0a vs 2.0 is by checking for the oauth_signature_method > > parameter. More info here: > > >> > > >> > > >> > > >> https://issues.apache.org/jira/browse/SHINDIG-1361 > > >> > > >> > > >> > > >> Has anyone else considered this use case? How did you solve it? > > >> > > >> > > > > > > _______________________________________________ > > > OAuth mailing list > > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > --001485f91b2441a1150488b0b72b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If you're routing requests with a load balancer it's not so trivial= . =A0 Instead of a substring match you're talking about a regex with ne= gative lookahead matching -- that's why the presence of the signature p= aram is essential to distinguishing between 2.0/1.0a.<div> <div><br><div class=3D"gmail_quote">On Thu, Jun 10, 2010 at 10:42 AM, Eran = Hammer-Lahav <span dir=3D"ltr"><<a href=3D"mailto:eran@hueniverse.com">e= ran@hueniverse.com</a>></span> wrote:<br><blockquote class=3D"gmail_quot= e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"= > But in that case, all the other oauth_* parameters are missing. It's tr= ivial.<br> <font color=3D"#888888"><br> EHL<br> </font><div><div></div><div class=3D"h5"><br> > -----Original Message-----<br> > From: Marius Scurtescu [mailto:<a href=3D"mailto:mscurtescu@google.com= ">mscurtescu@google.com</a>]<br> > Sent: Thursday, June 10, 2010 10:39 AM<br> > To: Paul Lindner<br> > Cc: Eran Hammer-Lahav; OAuth WG (<a href=3D"mailto:oauth@ietf.org">oau= th@ietf.org</a>)<br> > Subject: Re: [OAUTH-WG] Identifying OAuth 2.0 vs 1.0 requests<br> ><br> > I run into the same issue. In section "4.2. URI Query Parameter&q= uot;, it would<br> > help if the parameter name, oauth_token, was different from OAuth 1.<b= r> ><br> > Marius<br> ><br> ><br> ><br> > On Thu, Jun 10, 2010 at 9:41 AM, Paul Lindner <<a href=3D"mailto:li= ndner@inuus.com">lindner@inuus.com</a>> wrote:<br> > > I am talking about the resource server. Specifically I want to be= able<br> > > to quickly determine if an incoming request is 1.0a vs 2.0. =A0An= d since<br> > > this is a library it can't make a lot of assumptions about th= e<br> > > specific environment it's running in.<br> > > At first I thought I would check the oauth_version parameter. =A0= It<br> > > turns out the 1.0a spec says that it is optional. =A0The only one= that<br> > > is required for 1.0a is=A0oauth_signature_method.<br> > > Sadly we're long past time to change the spec to optimize for= this use-case.<br> > > =A0(It would have been better to have a parameter for oauth 2.0 t= hat is<br> > > distinct from 1.0a) =A0At the very least this message will live o= n in<br> > > the mailing list archives -- at best we document the proper way t= o<br> > > distinguish between the two versions somewhere.<br> > > On Thu, Jun 10, 2010 at 8:44 AM, Eran Hammer-Lahav<br> > > <<a href=3D"mailto:eran@hueniverse.com">eran@hueniverse.com</a= >><br> > > wrote:<br> > >><br> > >> The request is very different on the resource server. On the<= br> > >> authorization server, why would you use the same endpoint?<br= > > >><br> > >><br> > >><br> > >> EHL<br> > >><br> > >><br> > >><br> > >> From: <a href=3D"mailto:oauth-bounces@ietf.org">oauth-bounces= @ietf.org</a> [mailto:<a href=3D"mailto:oauth-bounces@ietf.org">oauth-bounc= es@ietf.org</a>] On<br> > >> Behalf Of Paul Lindner<br> > >> Sent: Thursday, June 10, 2010 8:24 AM<br> > >> To: OAuth WG (<a href=3D"mailto:oauth@ietf.org">oauth@ietf.or= g</a>)<br> > >> Subject: [OAUTH-WG] Identifying OAuth 2.0 vs 1.0 requests<br> > >><br> > >><br> > >><br> > >> Hi,<br> > >><br> > >><br> > >><br> > >> As I've been working through our oauth2 implementation I&= #39;ve noticed<br> > >> that it's not easy to disambiguate OAuth 1.0a vs 2.0 API = calls based<br> > >> on the request parameters alone. =A0 Based on some investigat= ive at the<br> > >> Shindig project it appears that the only standard way to to d= etermine<br> > >> 1.0a vs 2.0 is by checking for the=A0oauth_signature_method<b= r> > parameter. =A0More info here:<br> > >><br> > >><br> > >><br> > >> <a href=3D"https://issues.apache.org/jira/browse/SHINDIG-1361= " target=3D"_blank">https://issues.apache.org/jira/browse/SHINDIG-1361</a><= br> > >><br> > >><br> > >><br> > >> Has anyone else considered this use case? =A0How did you solv= e it?<br> > >><br> > >><br> > ><br> > > _______________________________________________<br> > > OAuth mailing list<br> > > <a href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a><br> > > <a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D= "_blank">https://www.ietf.org/mailman/listinfo/oauth</a><br> > ><br> > ><br> </div></div></blockquote></div><br></div></div> --001485f91b2441a1150488b0b72b-- From jricher@mitre.org Thu Jun 10 10:59:25 2010 Return-Path: <jricher@mitre.org> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE04C28C15A for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 10:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sqZcIIvgs65M for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 10:59:25 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id D05CD3A67F6 for <oauth@ietf.org>; Thu, 10 Jun 2010 10:59:24 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o5AHxQRP007782 for <oauth@ietf.org>; Thu, 10 Jun 2010 13:59:26 -0400 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o5AHxQoL007779; Thu, 10 Jun 2010 13:59:26 -0400 Received: from [129.83.50.65] (129.83.50.65) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server id 8.2.254.0; Thu, 10 Jun 2010 13:59:26 -0400 From: Justin Richer <jricher@mitre.org> To: Marius Scurtescu <mscurtescu@google.com> In-Reply-To: <AANLkTikl0Wp16bvqF-2MqcLN7OzdrnFIPI5FOV-B2yOf@mail.gmail.com> References: <AANLkTikl0Wp16bvqF-2MqcLN7OzdrnFIPI5FOV-B2yOf@mail.gmail.com> Content-Type: text/plain; charset="UTF-8" Date: Thu, 10 Jun 2010 13:59:25 -0400 Message-ID: <1276192765.31840.12.camel@localhost.localdomain> MIME-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] the format parameter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 10 Jun 2010 17:59:26 -0000 One of the things that I found particularly useful with working with OAuth1 was the ability to perform an entire transaction through URL parameter manipulation. This is why I wholly support keeping the client id and secret fields in the client auth flow and the username and password fields in the username flow. I'm fine with supporting alternative ways to pass information around, with various headers or basic auth or what have you, but I don't want to lose the ability to GET and/or POST a bunch of form parameters to use OAuth. I don't want to have to dive any deeper into the HTTP stack than that. With that in mind, I support keeping the format parameter, with an alternative expression of the same information being made available via the Accepts header for clients that want to do that instead. -- Justin On Thu, 2010-06-10 at 13:51 -0400, Marius Scurtescu wrote: > I am implementing an OAuth 2 library and the format parameter does not > feel right. > > If a client is using a library then the response format should be > totally transparent to the client. The library may have a setting if > the client wants to force a format for whatever reason, but individual > messages that the client builds and receives should not care about the > format. > > I think initially the Accept header was used. All current "format" > uses are in direct requests, so Accept could be used. > > To give a counter example, the User-Agent flow does not use "format" > and it always returns form-encoded in the fragment. There where > discussions to use JSON for this flow as well. Should we do that? If > yes, do we need "format"? Accept does not work in this case. > > I don't have a good suggestions, just wondering if anyone else run > into this issue. > > Marius > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From jricher@mitre.org Thu Jun 10 11:05:40 2010 Return-Path: <jricher@mitre.org> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47FEC28C113 for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 11:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4fXibsNYGOrH for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 11:05:39 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 61E3328C13D for <oauth@ietf.org>; Thu, 10 Jun 2010 11:05:39 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o5AI5emx014153 for <oauth@ietf.org>; Thu, 10 Jun 2010 14:05:41 -0400 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o5AI5cDL014107; Thu, 10 Jun 2010 14:05:38 -0400 Received: from [129.83.50.65] (129.83.50.65) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server id 8.2.254.0; Thu, 10 Jun 2010 14:05:38 -0400 From: Justin Richer <jricher@mitre.org> To: Eran Hammer-Lahav <eran@hueniverse.com> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF7331@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF7331@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset="UTF-8" Date: Thu, 10 Jun 2010 14:05:37 -0400 Message-ID: <1276193137.31840.14.camel@localhost.localdomain> MIME-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Names for endpoints X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 10 Jun 2010 18:05:40 -0000 My vote: > * Endpoint used to interact with the end-user > Authorization Endpoint or > End-User Authorization Endpoint > * Endpoint used to interact directly with the client > Token Endpoint -- Justin From mscurtescu@google.com Thu Jun 10 11:09:36 2010 Return-Path: <mscurtescu@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A71328C153 for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 11:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.844 X-Spam-Level: X-Spam-Status: No, score=-104.844 tagged_above=-999 required=5 tests=[AWL=1.133, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JSso0yFHka+s for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 11:09:35 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id ABEE828C12A for <oauth@ietf.org>; Thu, 10 Jun 2010 11:09:35 -0700 (PDT) Received: from hpaq7.eem.corp.google.com (hpaq7.eem.corp.google.com [172.25.149.7]) by smtp-out.google.com with ESMTP id o5AI9aN9013157 for <oauth@ietf.org>; Thu, 10 Jun 2010 11:09:37 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1276193377; bh=pEq/tND/5NrTYuw8FY7kISaUbsA=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=yXzI9dKeSkXcLMMChB1ASQziLpmESV23O5GIq6rJVuXGbFqxuA7aSIJBD3RuIKlNq I1lG6MV5gjvN4RY/vVT3g== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type; b=nT8986jOpRYJhjZYTo0K5AjhQQ7TGbE7Noc4iTGCWuKoOzMUR63PhsIkRh+jbfd5l FRUn4gUqX3HJtiSoqb5Gg== Received: from pzk38 (pzk38.prod.google.com [10.243.19.166]) by hpaq7.eem.corp.google.com with ESMTP id o5AI9Zei032335 for <oauth@ietf.org>; Thu, 10 Jun 2010 11:09:35 -0700 Received: by pzk38 with SMTP id 38so120693pzk.28 for <oauth@ietf.org>; Thu, 10 Jun 2010 11:09:34 -0700 (PDT) Received: by 10.141.14.12 with SMTP id r12mr397538rvi.94.1276193374649; Thu, 10 Jun 2010 11:09:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.124.13 with HTTP; Thu, 10 Jun 2010 11:09:14 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF7331@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF7331@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu <mscurtescu@google.com> Date: Thu, 10 Jun 2010 11:09:14 -0700 Message-ID: <AANLkTimE7vGIX07xnW48JfeI7NS9Hagj2XI0_l6hCN8U@mail.gmail.com> To: Eran Hammer-Lahav <eran@hueniverse.com> Content-Type: text/plain; charset=ISO-8859-1 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Names for endpoints X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 10 Jun 2010 18:09:36 -0000 On Thu, Jun 10, 2010 at 10:52 AM, Eran Hammer-Lahav <eran@hueniverse.com> wrote: > Pick or suggest new ideas: > > * Endpoint used to interact with the end-user > > End-user Endpoint -1 > Front Channel Endpoint > Authorization Endpoint +1 > End-User Authorization Endpoint > User-Agent Endpoint not bad, but it conflicts with a flow name Suggestion: - Approval Endpoint - Frontend URI > > > * Endpoint used to interact directly with the client > > Token Endpoint +1 > Client Endpoint > Back Channel Endpoint Suggestion: - Backend URI Marius From lindner@inuus.com Thu Jun 10 11:18:40 2010 Return-Path: <lindner@inuus.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 860D63A6993 for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 11:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.624 X-Spam-Level: X-Spam-Status: No, score=0.624 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-MaZh-lF6EX for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 11:18:39 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 301963A6917 for <oauth@ietf.org>; Thu, 10 Jun 2010 11:18:39 -0700 (PDT) Received: by yxt33 with SMTP id 33so66426yxt.31 for <oauth@ietf.org>; Thu, 10 Jun 2010 11:18:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.91.63.40 with SMTP id q40mr1465510agk.92.1276193917055; Thu, 10 Jun 2010 11:18:37 -0700 (PDT) Sender: lindner@inuus.com Received: by 10.90.30.11 with HTTP; Thu, 10 Jun 2010 11:18:37 -0700 (PDT) In-Reply-To: <1276192765.31840.12.camel@localhost.localdomain> References: <AANLkTikl0Wp16bvqF-2MqcLN7OzdrnFIPI5FOV-B2yOf@mail.gmail.com> <1276192765.31840.12.camel@localhost.localdomain> Date: Thu, 10 Jun 2010 11:18:37 -0700 X-Google-Sender-Auth: q1kpJv8QBLtFA1rCCZry9genK3k Message-ID: <AANLkTink_XxSzR38laCjqOaNtdL_AjBIU5QQNzalQBL-@mail.gmail.com> From: Paul Lindner <plindner@linkedin.com> To: Justin Richer <jricher@mitre.org> Content-Type: multipart/alternative; boundary=0016e6408cae1735c10488b10da2 Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] the format parameter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 10 Jun 2010 18:18:40 -0000 --0016e6408cae1735c10488b10da2 Content-Type: text/plain; charset=ISO-8859-1 Another alternative idea -- designate the 'format' param as an accept-header override. This technique has been successful for the X-Method-Override header and cements the Accept header syntax as the proper mechanism for selecting output format. On Thu, Jun 10, 2010 at 10:59 AM, Justin Richer <jricher@mitre.org> wrote: > One of the things that I found particularly useful with working with > OAuth1 was the ability to perform an entire transaction through URL > parameter manipulation. This is why I wholly support keeping the client > id and secret fields in the client auth flow and the username and > password fields in the username flow. I'm fine with supporting > alternative ways to pass information around, with various headers or > basic auth or what have you, but I don't want to lose the ability to GET > and/or POST a bunch of form parameters to use OAuth. I don't want to > have to dive any deeper into the HTTP stack than that. > > With that in mind, I support keeping the format parameter, with an > alternative expression of the same information being made available via > the Accepts header for clients that want to do that instead. > > -- Justin > > On Thu, 2010-06-10 at 13:51 -0400, Marius Scurtescu wrote: > > I am implementing an OAuth 2 library and the format parameter does not > > feel right. > > > > If a client is using a library then the response format should be > > totally transparent to the client. The library may have a setting if > > the client wants to force a format for whatever reason, but individual > > messages that the client builds and receives should not care about the > > format. > > > > I think initially the Accept header was used. All current "format" > > uses are in direct requests, so Accept could be used. > > > > To give a counter example, the User-Agent flow does not use "format" > > and it always returns form-encoded in the fragment. There where > > discussions to use JSON for this flow as well. Should we do that? If > > yes, do we need "format"? Accept does not work in this case. > > > > I don't have a good suggestions, just wondering if anyone else run > > into this issue. > > > > Marius > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0016e6408cae1735c10488b10da2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Another alternative idea -- designate the 'format' param as an acce= pt-header override. =A0This technique has been successful for the X-Method-= Override header and cements the Accept header syntax as the proper mechanis= m for selecting output format.<br> <br><div class=3D"gmail_quote">On Thu, Jun 10, 2010 at 10:59 AM, Justin Ric= her <span dir=3D"ltr"><<a href=3D"mailto:jricher@mitre.org">jricher@mitr= e.org</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"m= argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> One of the things that I found particularly useful with working with<br> OAuth1 was the ability to perform an entire transaction through URL<br> parameter manipulation. This is why I wholly support keeping the client<br> id and secret fields in the client auth flow and the username and<br> password fields in the username flow. I'm fine with supporting<br> alternative ways to pass information around, with various headers or<br> basic auth or what have you, but I don't want to lose the ability to GE= T<br> and/or POST a bunch of form parameters to use OAuth. I don't want to<br= > have to dive any deeper into the HTTP stack than that.<br> <br> With that in mind, I support keeping the format parameter, with an<br> alternative expression of the same information being made available via<br> the Accepts header for clients that want to do that instead.<br> <br> =A0-- Justin<br> <br> On Thu, 2010-06-10 at 13:51 -0400, Marius Scurtescu wrote:<br> > I am implementing an OAuth 2 library and the format parameter does not= <br> > feel right.<br> ><br> > If a client is using a library then the response format should be<br> > totally transparent to the client. The library may have a setting if<b= r> > the client wants to force a format for whatever reason, but individual= <br> > messages that the client builds and receives should not care about the= <br> > format.<br> ><br> > I think initially the Accept header was used. All current "format= "<br> > uses are in direct requests, so Accept could be used.<br> ><br> > To give a counter example, the User-Agent flow does not use "form= at"<br> > and it always returns form-encoded in the fragment. There where<br> > discussions to use JSON for this flow as well. Should we do that? If<b= r> > yes, do we need "format"? Accept does not work in this case.= <br> ><br> > I don't have a good suggestions, just wondering if anyone else run= <br> > into this issue.<br> ><br> > Marius<br> > _______________________________________________<br> > OAuth mailing list<br> > <a href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a><br> > <a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_bla= nk">https://www.ietf.org/mailman/listinfo/oauth</a><br> <br> <br> _______________________________________________<br> OAuth mailing list<br> <a href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_blank">h= ttps://www.ietf.org/mailman/listinfo/oauth</a><br> </blockquote></div><br> --0016e6408cae1735c10488b10da2-- From eran@hueniverse.com Thu Jun 10 11:29:48 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B29C3A67DA for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 11:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.611 X-Spam-Level: X-Spam-Status: No, score=-0.611 tagged_above=-999 required=5 tests=[AWL=-0.613, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SyFOPzLidKfG for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 11:29:34 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 32C0C3A6995 for <oauth@ietf.org>; Thu, 10 Jun 2010 11:29:25 -0700 (PDT) Received: (qmail 29670 invoked from network); 10 Jun 2010 18:29:26 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 10 Jun 2010 18:29:26 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 10 Jun 2010 11:29:24 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: Paul Lindner <plindner@linkedin.com>, Justin Richer <jricher@mitre.org> Date: Thu, 10 Jun 2010 11:29:19 -0700 Thread-Topic: [OAUTH-WG] the format parameter Thread-Index: AcsIyV1VmEneB/o/Rbu5XwM66DbD/gAAWtMw Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF736C@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <AANLkTikl0Wp16bvqF-2MqcLN7OzdrnFIPI5FOV-B2yOf@mail.gmail.com> <1276192765.31840.12.camel@localhost.localdomain> <AANLkTink_XxSzR38laCjqOaNtdL_AjBIU5QQNzalQBL-@mail.gmail.com> In-Reply-To: <AANLkTink_XxSzR38laCjqOaNtdL_AjBIU5QQNzalQBL-@mail.gmail.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_90C41DD21FB7C64BB94121FBBC2E72343B3EAF736CP3PW5EX1MB01E_" MIME-Version: 1.0 Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] the format parameter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 10 Jun 2010 18:29:48 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EAF736CP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There is a bigger issue with even having multiple formats. If only we can d= ecide between form-encoded and JSON... EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of P= aul Lindner Sent: Thursday, June 10, 2010 11:19 AM To: Justin Richer Cc: OAuth WG Subject: Re: [OAUTH-WG] the format parameter Another alternative idea -- designate the 'format' param as an accept-heade= r override. This technique has been successful for the X-Method-Override h= eader and cements the Accept header syntax as the proper mechanism for sele= cting output format. On Thu, Jun 10, 2010 at 10:59 AM, Justin Richer <jricher@mitre.org<mailto:j= richer@mitre.org>> wrote: One of the things that I found particularly useful with working with OAuth1 was the ability to perform an entire transaction through URL parameter manipulation. This is why I wholly support keeping the client id and secret fields in the client auth flow and the username and password fields in the username flow. I'm fine with supporting alternative ways to pass information around, with various headers or basic auth or what have you, but I don't want to lose the ability to GET and/or POST a bunch of form parameters to use OAuth. I don't want to have to dive any deeper into the HTTP stack than that. With that in mind, I support keeping the format parameter, with an alternative expression of the same information being made available via the Accepts header for clients that want to do that instead. -- Justin On Thu, 2010-06-10 at 13:51 -0400, Marius Scurtescu wrote: > I am implementing an OAuth 2 library and the format parameter does not > feel right. > > If a client is using a library then the response format should be > totally transparent to the client. The library may have a setting if > the client wants to force a format for whatever reason, but individual > messages that the client builds and receives should not care about the > format. > > I think initially the Accept header was used. All current "format" > uses are in direct requests, so Accept could be used. > > To give a counter example, the User-Agent flow does not use "format" > and it always returns form-encoded in the fragment. There where > discussions to use JSON for this flow as well. Should we do that? If > yes, do we need "format"? Accept does not work in this case. > > I don't have a good suggestions, just wondering if anyone else run > into this issue. > > Marius > _______________________________________________ > OAuth mailing list > OAuth@ietf.org<mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EAF736CP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV=3D"Content-Type" CONTENT= =3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros= oft Word 14 (filtered medium)"><style><!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} span.EmailStyle17 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-family:"Calibri","sans-serif";} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue vli= nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><span style=3D'f= ont-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>There is = a bigger issue with even having multiple formats. If only we can decide bet= ween form-encoded and JSON…<o:p></o:p></span></p><p class=3DMsoNormal= ><span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#= 1F497D'><o:p> </o:p></span></p><p class=3DMsoNormal><span style=3D'fon= t-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>EHL<o:p></o= :p></span></p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-fam= ily:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div = style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt= '><div><div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0= pt 0in 0in 0in'><p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;fon= t-family:"Tahoma","sans-serif"'>From:</span></b><span style=3D'font-size:10= .0pt;font-family:"Tahoma","sans-serif"'> oauth-bounces@ietf.org [mailto:oau= th-bounces@ietf.org] <b>On Behalf Of </b>Paul Lindner<br><b>Sent:</b> Thurs= day, June 10, 2010 11:19 AM<br><b>To:</b> Justin Richer<br><b>Cc:</b> OAuth= WG<br><b>Subject:</b> Re: [OAUTH-WG] the format parameter<o:p></o:p></span= ></p></div></div><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNo= rmal style=3D'margin-bottom:12.0pt'>Another alternative idea -- designate t= he 'format' param as an accept-header override.  This technique has be= en successful for the X-Method-Override header and cements the Accept heade= r syntax as the proper mechanism for selecting output format.<o:p></o:p></p= ><div><p class=3DMsoNormal>On Thu, Jun 10, 2010 at 10:59 AM, Justin Richer = <<a href=3D"mailto:jricher@mitre.org">jricher@mitre.org</a>> wrote:<o= :p></o:p></p><p class=3DMsoNormal>One of the things that I found particular= ly useful with working with<br>OAuth1 was the ability to perform an entire = transaction through URL<br>parameter manipulation. This is why I wholly sup= port keeping the client<br>id and secret fields in the client auth flow and= the username and<br>password fields in the username flow. I'm fine with su= pporting<br>alternative ways to pass information around, with various heade= rs or<br>basic auth or what have you, but I don't want to lose the ability = to GET<br>and/or POST a bunch of form parameters to use OAuth. I don't want= to<br>have to dive any deeper into the HTTP stack than that.<br><br>With t= hat in mind, I support keeping the format parameter, with an<br>alternative= expression of the same information being made available via<br>the Accepts= header for clients that want to do that instead.<br><br> -- Justin<br= ><br>On Thu, 2010-06-10 at 13:51 -0400, Marius Scurtescu wrote:<br>> I a= m implementing an OAuth 2 library and the format parameter does not<br>>= feel right.<br>><br>> If a client is using a library then the respon= se format should be<br>> totally transparent to the client. The library = may have a setting if<br>> the client wants to force a format for whatev= er reason, but individual<br>> messages that the client builds and recei= ves should not care about the<br>> format.<br>><br>> I think initi= ally the Accept header was used. All current "format"<br>> use= s are in direct requests, so Accept could be used.<br>><br>> To give = a counter example, the User-Agent flow does not use "format"<br>&= gt; and it always returns form-encoded in the fragment. There where<br>>= discussions to use JSON for this flow as well. Should we do that? If<br>&g= t; yes, do we need "format"? Accept does not work in this case.<b= r>><br>> I don't have a good suggestions, just wondering if anyone el= se run<br>> into this issue.<br>><br>> Marius<br>> ____________= ___________________________________<br>> OAuth mailing list<br>> <a h= ref=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a><br>> <a href=3D"https:/= /www.ietf.org/mailman/listinfo/oauth" target=3D"_blank">https://www.ietf.or= g/mailman/listinfo/oauth</a><br><br><br>___________________________________= ____________<br>OAuth mailing list<br><a href=3D"mailto:OAuth@ietf.org">OAu= th@ietf.org</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/oauth" = target=3D"_blank">https://www.ietf.org/mailman/listinfo/oauth</a><o:p></o:p= ></p></div><p class=3DMsoNormal><o:p> </o:p></p></div></div></body></h= tml>= --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EAF736CP3PW5EX1MB01E_-- From eran@hueniverse.com Thu Jun 10 12:43:00 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDE5428C115 for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 12:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.856 X-Spam-Level: X-Spam-Status: No, score=-1.856 tagged_above=-999 required=5 tests=[AWL=0.743, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0VO309xLlZ7z for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 12:43:00 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 0113C3A68AB for <oauth@ietf.org>; Thu, 10 Jun 2010 12:42:59 -0700 (PDT) Received: (qmail 32663 invoked from network); 10 Jun 2010 19:43:01 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 10 Jun 2010 19:43:01 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 10 Jun 2010 12:43:00 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org> Date: Thu, 10 Jun 2010 12:42:54 -0700 Thread-Topic: Client credentials w/ or w/o secret Thread-Index: AcsI1R6QGWMlKRAeTrWaKw1wWehjhQ== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF73BB@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: A1Xb CLpT C4fr C9HJ DDJ2 D6PP EG7x EITs FxqP F7z+ G7xg HZAR IYRu I1Gq I5SG JizT; 1; bwBhAHUAdABoAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {B4F8DDCD-83E1-4ED3-BD50-D12F5A391D62}; ZQByAGEAbgBAAGgAdQBlAG4AaQB2AGUAcgBzAGUALgBjAG8AbQA=; Thu, 10 Jun 2010 19:42:54 GMT; QwBsAGkAZQBuAHQAIABjAHIAZQBkAGUAbgB0AGkAYQBsAHMAIAB3AC8AIABvAHIAIAB3AC8AbwAgAHMAZQBjAHIAZQB0AA== x-cr-puzzleid: {B4F8DDCD-83E1-4ED3-BD50-D12F5A391D62} acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OAUTH-WG] Client credentials w/ or w/o secret X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 10 Jun 2010 19:43:01 -0000 Some of the flows require/allow a client secret while others disallow it (w= hen the client has no secure means to keep it secret). My question is, do y= ou plan to issue different credentials for different flows (with or without= secret) or allow the same set to be used, sometimes with and sometimes wit= hout a secret based on the flow? EHL From hardjono@mit.edu Thu Jun 10 13:27:28 2010 Return-Path: <hardjono@mit.edu> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10EC43A659A for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 13:27:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.667 X-Spam-Level: X-Spam-Status: No, score=-0.667 tagged_above=-999 required=5 tests=[AWL=-0.668, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m9GEn5MbPZ2Y for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 13:27:26 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (DMZ-MAILSEC-SCANNER-6.MIT.EDU [18.7.68.35]) by core3.amsl.com (Postfix) with ESMTP id 80C4B3A6359 for <oauth@ietf.org>; Thu, 10 Jun 2010 13:27:26 -0700 (PDT) X-AuditID: 12074423-b7b4cae000000a2b-17-4c114ab0d196 Received: from mailhub-auth-2.mit.edu (MAILHUB-AUTH-2.MIT.EDU [18.7.62.36]) by dmz-mailsec-scanner-6.mit.edu (Symantec Brightmail Gateway) with SMTP id B2.1E.02603.0BA411C4; Thu, 10 Jun 2010 16:27:28 -0400 (EDT) Received: from outgoing.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 o5AKRSvo003287; Thu, 10 Jun 2010 16:27:28 -0400 Received: from w92exedge4.exchange.mit.edu (W92EXEDGE4.EXCHANGE.MIT.EDU [18.7.73.16]) ) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id o5AKRQHm029479; Thu, 10 Jun 2010 16:27:27 -0400 Received: from oc11exhub1.exchange.mit.edu (18.9.3.11) by w92exedge4.exchange.mit.edu (18.7.73.16) with Microsoft SMTP Server (TLS) id 8.1.393.1; Thu, 10 Jun 2010 16:27:25 -0400 Received: from EXPO10.exchange.mit.edu ([18.9.4.15]) by oc11exhub1.exchange.mit.edu ([18.9.3.11]) with mapi; Thu, 10 Jun 2010 16:27:26 -0400 From: Thomas Hardjono <hardjono@MIT.EDU> To: Marius Scurtescu <mscurtescu@google.com>, Andrew Arnott <andrewarnott@gmail.com> Date: Thu, 10 Jun 2010 16:27:10 -0400 Thread-Topic: [OAUTH-WG] User-agent flow and pre-registered redirect_uri Thread-Index: AcsIw018mzuX+BmdQxeT5uA90S2LdQAFhrUA Message-ID: <DADD7EAD88AB484D8CCC328D40214CCD017A07B2D4@EXPO10.exchange.mit.edu> References: <AANLkTingSGlJNZ5e_stPd1qU5I4gfbh3rQhqYUmqXvdB@mail.gmail.com> <C833CEB4.6B81%cmortimore@salesforce.com> <AANLkTinVQEPBVzmiHEGgHhzaILL0nRSvZpjIlrVEJwTw@mail.gmail.com> <AANLkTil1j7vl8PU2tgCzlWY0U6KiWPmRKiVOxvsctB00@mail.gmail.com> <AANLkTimCL-O7RIsUlt_zGDfkEEYb9w4_sPh6zxCMBsf0@mail.gmail.com> <AANLkTin7B9pPgSu3cNlJGkp_gCed-5aPGRZalzXd2Wg8@mail.gmail.com> <AANLkTilknKnF34td41H0Ycn3rF-mpCT-vDl5wVzQ0Xfb@mail.gmail.com> In-Reply-To: <AANLkTilknKnF34td41H0Ycn3rF-mpCT-vDl5wVzQ0Xfb@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0000_01CB08B9.C470CD50" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "oauth@ietf.org" <oauth@ietf.org> Subject: Re: [OAUTH-WG] User-agent flow and pre-registered redirect_uri X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 10 Jun 2010 20:27:28 -0000 ------=_NextPart_000_0000_01CB08B9.C470CD50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Andrew, Marius, Comments in-line. > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf = Of > Marius Scurtescu > Sent: Thursday, June 10, 2010 1:35 PM > To: Andrew Arnott > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] User-agent flow and pre-registered = redirect_uri >=20 > On Thu, Jun 10, 2010 at 8:35 AM, Andrew Arnott = <andrewarnott@gmail.com> > wrote: > > Thanks Marius. > > > > I've answered your question below. > > > > On Wed, Jun 9, 2010 at 9:35 AM, Marius Scurtescu = <mscurtescu@google.com> > > wrote: > >> > >> > I've always considered an authorization as a tuple of > >> > client_id,user,scope,issue_date.=A0 If an authorization has been approved, > >> > and > >> > another request for authorization for a subset of the scope previously > >> > issued comes in, the auth server can skip the interactive user > >> > authorization > >> > and just approve the request since nothing new is being issued. > >> > >> The tuple seems right, except for the issue date, why would you add that? > > > > The issue_date enables to scenarios: expiring tokens and token revocation. > > Here's how, for each scenario: > > > > Obviously to know if a token has expired you need to know when it = was > > issued.=A0 Or, you can forget the issue date and just store the = expiration > > date in the token. I choose to go with an issue date (plus an = optional > > expected lifetime) because it gives more ability in the future to = say > "oops, > > we had a security weakness in all tokens issued prior to [date], so let's > > consider all earlier tokens invalid."=A0 It's harder to say that = when all you > > have are expiration dates because you don't know how old the token = is. > This > > is just the way I chose to do it, but I know there are other ways. > > I noticed that there is no nonce used in the token request portion and the response from authorization server. Did I miss it (ie. is it embedded somewhere?) > > Now let's look at how you revoke issued tokens.=A0 One of the nice = things > > enabled by OAuth 2.0 is that the authorization server and resource server > > never have to store tokens if they are appropriate signed by the = auth > > server.=A0=20 Yes and no. It depends on (a) what is meant by "signing" the tokens and (b) whether the Autz Server needs to log all actions for legal purposes (eg. non-repudiation) Some service providers might want to archive all tokens it accepted/validated together with the info on resources/objects accessed by the clients. > > This is great because (among other things) clients with > > little-to-no ability to persistently store tokens may ask for tokens > > frequently, and that could bog down an auth server with storing all those > > issued tokens.=A0 But how can a user revoke a previously authorized = token if > > no one but the client knows what the tokens are? (thought = question)=A0 My > > solution to this is that instead of thinking about revoking tokens, = the > user > > revokes authorizations.=A0 The user goes through his account on the > > authorization server and sees a list of clients and what they are > authorized > > to do.=A0 Note that this only requires the auth server to store this > > authorization tuple -- not the actual issued tokens.=A0 If the user = clicks > > "revoke" on one of these authorizations, that row is deleted in the > > database.=A0 Issued tokens (both refresh and access tokens) have = this same > > tuple encoded in them. > > Now, when a refresh token is used to obtain a new short-lived access token > > (and you could do this on every access token use as well if you = wanted) the > > token is of course signature-validated, but it is also checked that = the > > authorization tuple has a matching tuple in the auth server's = database.=A0 If > > it's missing, then that authorization has been revoked and the token = is > > thereby invalidated. OK, so this is not live "revocation" with an immediate effect. Like Kerberos, there is a gap of time between the client revoking the token (service ticket) to the time when the refresh token (TGT) is exercised = next. During this gap of time the token is still live and valid. The only way to get around this is to have the resource server contact = the authorization server every time (but that would defeat the purpose of tokens/tickets). Even in X509, cert validation means the service = provider or RP performs a live check against the OCSP servers. > > So why the issue date?=A0 Because suppose the user has authorized a = client > and > > then that client's tokens are compromised (stolen computer = perhaps).=A0 The > > user will of course revoke authorization for that client.=A0 The = user then > > gets a new copy of that client (perhaps a new computer) and = authorizes it. > > Whoops.=A0 Now all those invalidated tokens are valid again because = the > > authorization tuple exists.=A0=20 If the tokens (tickets) were issued to the client entity (principal) = versus to the human-user principal, then this will not be a problem. If the = user loses her client/laptop, then she need only revoke the tokens associated = to the client/laptop. I think this is where there is room for OAuth 2.0 to innovate, such as = to introduce a special kind of token (human-token) that is independent from client/laptop tokens. The human-token could even be stored in a secure cloud service and be used for client-initiation or emergency purposes = only. Thus, whenever the human-user wants to move to a new laptop/client, the human-token is pulled down from the cloud, used to authenticate to the = auth server, and then deleted (from the client) once the new client/laptop becomes a known entity/principal in the ecosystem and has its own = tokens. Just a thought. > > > > Except now the issue date on the authorization > > on the auth server is newer than in the refresh token on the = invalidated > > client.=A0 That's why issue date is such a critical part of an authorization > > tuple.=A0 Any token issued prior to the earliest authorization on = record at > > the auth server represents a revoked authorization, and without an = issue > > date in the tuple there's no way to recognize that. > > > > At least that's the way I'm seeing it.=A0 I hope that makes sense. >=20 > I see where are you coming from. I assumed that access tokens are > saved and issue/expiry times are associated with the tokens, not with > the authorization decisions. >=20 > Marius > _______________________________________________ /thomas/ ------=_NextPart_000_0000_01CB08B9.C470CD50 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILazCCAj0w ggGmAhEAzbp/VvDf5LxU/iKss3KqVTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMjgwODAxMjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBAOUZv22jVmEtmUhx9mfeuY3rt56GgAqRDvo4Ja9GiILlc6igmyRdDR/MZW4MsNBWhBiH mgabEKFz37RYOWtuwfYV1aioP6oSBo0xrH+wNNePNGeICc0UEeJORVZpH3gCgNrcR5EpuzbJY1zF 4Ncth3uhtzKwezC6Ki8xqu6jZ9rbAgMBAAEwDQYJKoZIhvcNAQECBQADgYEATD+4i8Zo3+5DMw5d 6abLB4RNejP/khv0Nq3YlSI2aBFsfELM85wuxAc/FLAPT/+Qknb54rxK6Y/NoIAK98Up8YIiXbix 3YEjo3slFUYweRb46gVLlH8dwhzI47f0EEA8E8NfH1PoSOSGtHuhNbB7Jbq4046rPzidADQAmPPR cZQwggRGMIIDr6ADAgECAhBm/Ufjwhnk6JrNmd31OsskMA0GCSqGSIb3DQEBBQUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNTEwMjgwMDAwMDBaFw0xNTEwMjcy MzU5NTlaMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g RzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDJ36zn6vj4AxTEAJLVwX42wjzvfHIV y8CrjD0clc5vHhAsPwDtlybmtsfmrUMdP6SHR0dMPlT4bPjH/LGevTBwvJexAwXqlfGtQMVEeksF ovJg/Nc6ZWLv/xB7ola7xU5wLdaiHzztsELoXo1XIaymmdkR6dIaB8B0R0IL/MU06v3muiTRHQgV N6LXc88BQS9jsjo/vqUabvTJSls9laYVuzUCGfnU77yPDnF2WbtLtj7W/FoW9NYOifJJ/mwM7RXp 2Yh1nHnOYCfdua11zi9zlXpAOoV1SbC432i8q80TgoURUKPgPAuuwApTzdcwb4UyRhvkSRDCbOKv H3n/27S1AgMBAAGjgf8wgfwwEgYDVR0TAQH/BAgwBgEB/wIBADBEBgNVHSAEPTA7MDkGC2CGSAGG +EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0P BAQDAgEGMBEGCWCGSAGG+EIBAQQEAwIBBjAuBgNVHREEJzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0 ZUxhYmVsMy0yMDQ4LTE1NTAdBgNVHQ4EFgQUEX1eGX08BN9qbNaiiho/Mdg7lFIwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwDQYJKoZIhvcNAQEFBQAD gYEAPKPaAmM6xJOqq3LT3K1QOB4MnhZKiLfu69n/D42VoNa7+moLrmGE2GhHie9PrLIfSUGbSTN2 k4uebrlDHGC9wtyKLYfBRcARcgQaayQqbG/n/AcTKdB3OiPn9cGFaBm/xgFUIBmuNYLMYjxhCcb0 1euwD6afM4Wa03GOUI+Z3WIwggTcMIIDxKADAgECAhAdbJ7qJ1t3pQoJyWI9GoXNMA0GCSqGSIb3 DQEBBQUAMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g RzIwHhcNMTAwMjE3MDAwMDAwWhcNMTEwMzA2MjM1OTU5WjCCARMxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4w HAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQgQ2xhc3Mg MSAtIE1pY3Jvc29mdCBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD1Rob21hcyBIYXJkam9ubzEfMB0G CSqGSIb3DQEJARYQaGFyZGpvbm9AbWl0LmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 5IPN5gsvYs8ugsfq1ndIZqRJXlbGSKsX+IH45pbnLeWPFWzfG7mxch4QhqOD0RUs2GCI1YNHPS8C sFyj1V05XnT0p/1eHa8eHOV2V3RVljq3P5R2+vhskoGE2Nwm1wi8YP9ce0Cs2Qf4wiPm9oL2ls5M yvOCR0aWfBkXD231vBUCAwEAAaOB4jCB3zAJBgNVHRMEAjAAMEQGA1UdIAQ9MDswOQYLYIZIAYb4 RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBQGCmCGSAGG+EUBBgcEBhYETm9u ZTBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlzaWduLmNv bS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAJrdkpPOIr2sXpSrE9hlj36x FOukzUivx4QwmsyLSFvMrkSQ/7NCGQ73O6DMlmJZbtQPMdIpqc9ZwPYhOkyQ9AaKz10yHVO8TkW2 CAN0Atk1ZfAF78C1h/jch429nYmjADnDZyDuyRUi2yW4ouJkX84Suj1SYaC5ptZVmmMUyRwcNV6/ iHewW8wsIf0mOqtP79RMAJ6oGh0XlUmzlahqtMbi3JX02D9gAVW9j8zXqtI0pHSpMNkNzkFp8GRd 5bxaCdQzszNIPfQGNIM0x7w97ZbF8z+F2yCRSL0+4G9kQxGRpxkd1OWjov5OJfmPvOyTZkkX9cmd Sivi3+fEDBgv0kIxggTEMIIEwAIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1 YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAdbJ7qJ1t3pQoJyWI9GoXNMAkGBSsOAwIaBQCgggMnMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDYxMDIwMjcwNlowIwYJ KoZIhvcNAQkEMRYEFACNGLdiN8lXlvdVEsNDbT7i3K+HMIG3BgkqhkiG9w0BCQ8xgakwgaYwCwYJ YIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcN AwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAsG CWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMAoGCCqGSIb3DQIFMIIBAwYJKwYB BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzICEB1snuonW3elCgnJYj0ahc0wggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAdbJ7qJ1t3pQoJ yWI9GoXNMA0GCSqGSIb3DQEBAQUABIGAL/LF47lxhdWD+SV7KcEonSH23wLMObaawY6cAFt99Tlv ZbZwYqrp1+TK4OgdzBr8704pNbkuOCASNubqXzIOGP7t1cZYYO/lLkYql+IllYxHGfMSYgl8rI53 fIfeUAS81sGsNdMalsxp/jgdLICBhRzSiiBvbTBCTXD0avsW8pMAAAAAAAA= ------=_NextPart_000_0000_01CB08B9.C470CD50-- From eran@hueniverse.com Thu Jun 10 13:29:13 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98E763A6783 for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 13:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.618 X-Spam-Level: X-Spam-Status: No, score=-0.618 tagged_above=-999 required=5 tests=[AWL=-0.619, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3eY9a+4V-bKk for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 13:29:12 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 9E5613A67AC for <oauth@ietf.org>; Thu, 10 Jun 2010 13:29:12 -0700 (PDT) Received: (qmail 946 invoked from network); 10 Jun 2010 20:29:14 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 10 Jun 2010 20:29:14 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 10 Jun 2010 13:29:12 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org> Date: Thu, 10 Jun 2010 13:29:06 -0700 Thread-Topic: Proposal for single JSON response format Thread-Index: AcsI25LiV8WWr/WxSnmFMcXJetYFeg== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF73EF@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] Proposal for single JSON response format X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 10 Jun 2010 20:29:13 -0000 After taking a break from our previous debate(s) on the issue of which resp= onse format to support, I would like to suggest the following: - Support a single response format (including in the user-agent fragment) u= sing JSON. My reason for this is very simple, while right now we have a very limited n= eed (key/value pairs), we already have a few proposals which require a rich= er syntax. As OAuth matures, I expect more and more extensions to make use = of the server response to include additional parameters (flat or structured= ). By using JSON, we can very easily support "namespaces" (i.e. { "access_t= oken":"xyz","ext":{...} }), multiple token in a single response, etc. I appreciate the simplicity in using form-encoded (both code and library de= pendency wise), but long term, it will create a real limitation and will re= quire extensions to also specify a different response format. Those worried about the need to include a JSON library in cases where it wi= ll be hard to do (embedded devices, etc.), can always extend the protocol t= o provide a way to receive key/value form-encoded pairs. However, they will= need to figure out how to accommodate structured responses if they wish su= pport it. I am certain that the vast majority of implementations will have = no problem including a JSON library. Please respond only with yes or no (+/- 1). If you have a different proposa= l, please post it in a new thread. If you are going to vote against this, p= lease indicate if your objection is blocking (i.e. you are opposed to it an= d will block a consensus call with this approach). EHL From bouiaw@gmail.com Thu Jun 10 13:30:47 2010 Return-Path: <bouiaw@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A48A63A68AB for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 13:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.93 X-Spam-Level: X-Spam-Status: No, score=-1.93 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_NO=0.669] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dVgmUAlh++QE for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 13:30:46 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id B9B373A6783 for <oauth@ietf.org>; Thu, 10 Jun 2010 13:30:44 -0700 (PDT) Received: by wya21 with SMTP id 21so245792wya.31 for <oauth@ietf.org>; Thu, 10 Jun 2010 13:30:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=Vy3LkA63UV4+EQPA768v+ojZHO9nRf//UdXbuO+2OHs=; b=f5ozevIR2LY5PWiYT++ylIRUBm2VzbVeF0nAAFXg4Qs6bUFYKfWemKNXJmtYQNNAml RORAd1eSpzIpxjeannKJ8VC4loJbpDH8CtTCzEjNoa23DzaTA8FmyL6wTTuKNGvlvLQ1 GRZf6rcD6IwxOAfE33ocjhQSlUPP+0FnQiwbQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=jOp0BwJzAYFvfXveGrUzNwhoiEgrAQUxBc52PsYH+bw51kW11mAAZfYBvT+EVbB+it 3UYgJFEdSmDwCoxdvxgPY7VeFB4arECeem/eJpquIHYfwgU+IFP/5dECTF0y2gcd+clv 9JrK1ydC+adB3salC1kMhgCbaDNv8yXgzHGso= MIME-Version: 1.0 Received: by 10.227.69.208 with SMTP id a16mr771825wbj.193.1276201843555; Thu, 10 Jun 2010 13:30:43 -0700 (PDT) Received: by 10.216.63.21 with HTTP; Thu, 10 Jun 2010 13:30:43 -0700 (PDT) Date: Thu, 10 Jun 2010 22:30:43 +0200 Message-ID: <AANLkTinJ6Psj9JZ6E_L-BMyKCSosQKCIVpgDOG0QIC3V@mail.gmail.com> From: Bouiaw <bouiaw@gmail.com> To: oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [OAUTH-WG] No more encrypted token specification in OAuth 2.0 draft 06 ! X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 10 Jun 2010 20:32:05 -0000 It seems that token encryption spec has been removed between OAuth 2.0 draft 05 and draft 06 The related diff : http://tools.ietf.org/rfcdiff?url2=draft-ietf-oauth-v2-06.txt Is it intended ? Can we expect to have these encrypted token stuff back in security paragraph (currently in TODO status) for draft 07 ? Do you plan major changes compared to OAuth 2.0 draft 05 ? Thanks in advance for your answers. From jhart@photobucket.com Thu Jun 10 13:32:15 2010 Return-Path: <jhart@photobucket.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D0C83A6783 for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 13:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eYsAsBADZMAr for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 13:32:14 -0700 (PDT) Received: from exhub003-1.exch003intermedia.net (exhub003-1.exch003intermedia.net [207.5.74.28]) by core3.amsl.com (Postfix) with ESMTP id 60CAC3A6994 for <oauth@ietf.org>; Thu, 10 Jun 2010 13:32:14 -0700 (PDT) Received: from EXVMBX003-4.exch003intermedia.net ([207.5.74.44]) by exhub003-1.exch003intermedia.net ([207.5.74.28]) with mapi; Thu, 10 Jun 2010 13:32:16 -0700 From: Justin Hart <jhart@photobucket.com> To: Eran Hammer-Lahav <eran@hueniverse.com> Date: Thu, 10 Jun 2010 13:32:15 -0700 Thread-Topic: [OAUTH-WG] Proposal for single JSON response format Thread-Index: AcsI3APo4e3qZ4sfTEm7y77nD5MoAA== Message-ID: <C10D643A-9A1D-4BCE-B115-003E7051E188@photobucket.com> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF73EF@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF73EF@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 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Proposal for single JSON response format X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 10 Jun 2010 20:32:15 -0000 +1 for MUST JSON response, MAY form-encoded (and xml, etc etc) response via= extension (response_format parameter?) ---- -- Justin Hart -- jhart@photobucket.com On Jun 10, 2010, at 2:29 PM, Eran Hammer-Lahav wrote: > After taking a break from our previous debate(s) on the issue of which re= sponse format to support, I would like to suggest the following: >=20 > - Support a single response format (including in the user-agent fragment)= using JSON. >=20 > My reason for this is very simple, while right now we have a very limited= need (key/value pairs), we already have a few proposals which require a ri= cher syntax. As OAuth matures, I expect more and more extensions to make us= e of the server response to include additional parameters (flat or structur= ed). By using JSON, we can very easily support "namespaces" (i.e. { "access= _token":"xyz","ext":{...} }), multiple token in a single response, etc. >=20 > I appreciate the simplicity in using form-encoded (both code and library = dependency wise), but long term, it will create a real limitation and will = require extensions to also specify a different response format. >=20 > Those worried about the need to include a JSON library in cases where it = will be hard to do (embedded devices, etc.), can always extend the protocol= to provide a way to receive key/value form-encoded pairs. However, they wi= ll need to figure out how to accommodate structured responses if they wish = support it. I am certain that the vast majority of implementations will hav= e no problem including a JSON library. >=20 > Please respond only with yes or no (+/- 1). If you have a different propo= sal, please post it in a new thread. If you are going to vote against this,= please indicate if your objection is blocking (i.e. you are opposed to it = and will block a consensus call with this approach). >=20 > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From hardjono@mit.edu Thu Jun 10 13:33:56 2010 Return-Path: <hardjono@mit.edu> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93F3E3A659A for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 13:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.856 X-Spam-Level: X-Spam-Status: No, score=-1.856 tagged_above=-999 required=5 tests=[AWL=0.743, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tfzwzJHO-Sq7 for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 13:33:55 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (DMZ-MAILSEC-SCANNER-1.MIT.EDU [18.9.25.12]) by core3.amsl.com (Postfix) with ESMTP id 6F1863A6783 for <oauth@ietf.org>; Thu, 10 Jun 2010 13:33:55 -0700 (PDT) X-AuditID: 1209190c-b7bd2ae000005d05-5b-4c114c3572f6 Received: from mailhub-auth-1.mit.edu (MAILHUB-AUTH-1.MIT.EDU [18.9.21.35]) by dmz-mailsec-scanner-1.mit.edu (Symantec Brightmail Gateway) with SMTP id AE.35.23813.53C411C4; Thu, 10 Jun 2010 16:33:57 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-EXCHANGE-1.MIT.EDU [18.9.28.15]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id o5AKXv5B024354; Thu, 10 Jun 2010 16:33:57 -0400 Received: from oc11exedge1.exchange.mit.edu (OC11EXEDGE1.EXCHANGE.MIT.EDU [18.9.3.17]) ) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id o5AKXuod030416; Thu, 10 Jun 2010 16:33:56 -0400 Received: from w92exhub5.exchange.mit.edu (18.7.73.11) by oc11exedge1.exchange.mit.edu (18.9.3.17) with Microsoft SMTP Server (TLS) id 8.1.393.1; Thu, 10 Jun 2010 16:33:53 -0400 Received: from EXPO10.exchange.mit.edu ([18.9.4.15]) by w92exhub5.exchange.mit.edu ([18.7.73.11]) with mapi; Thu, 10 Jun 2010 16:33:55 -0400 From: Thomas Hardjono <hardjono@MIT.EDU> To: Eran Hammer-Lahav <eran@hueniverse.com>, "OAuth WG (oauth@ietf.org)" <oauth@ietf.org> Date: Thu, 10 Jun 2010 16:33:49 -0400 Thread-Topic: Client credentials w/ or w/o secret Thread-Index: AcsI1R6QGWMlKRAeTrWaKw1wWehjhQABkt9Q Message-ID: <DADD7EAD88AB484D8CCC328D40214CCD017A07B2D6@EXPO10.exchange.mit.edu> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF73BB@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF73BB@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0004_01CB08BA.B4BB8AC0" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [OAUTH-WG] Client credentials w/ or w/o secret X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 10 Jun 2010 20:33:56 -0000 ------=_NextPart_000_0004_01CB08BA.B4BB8AC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit If you want to introduce the notion of non-repudiation (meaning that the client cannot deny issuing an access request to the resource server), then you need to get the client to exercise its secret (eg. by using it in some crypto computation). When a flow does not include the exercise/usage of the client secret, then you do not get non-repudiation. I think this aspects needs to be made clear in the spec. Which may bring-up the question as to some flows being safer than others. /thomas/ __________________________________________ > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of > Eran Hammer-Lahav > Sent: Thursday, June 10, 2010 3:43 PM > To: OAuth WG (oauth@ietf.org) > Subject: [OAUTH-WG] Client credentials w/ or w/o secret > > Some of the flows require/allow a client secret while others disallow it > (when the client has no secure means to keep it secret). My question is, do > you plan to issue different credentials for different flows (with or without > secret) or allow the same set to be used, sometimes with and sometimes > without a secret based on the flow? > > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth ------=_NextPart_000_0004_01CB08BA.B4BB8AC0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILazCCAj0w ggGmAhEAzbp/VvDf5LxU/iKss3KqVTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMjgwODAxMjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBAOUZv22jVmEtmUhx9mfeuY3rt56GgAqRDvo4Ja9GiILlc6igmyRdDR/MZW4MsNBWhBiH mgabEKFz37RYOWtuwfYV1aioP6oSBo0xrH+wNNePNGeICc0UEeJORVZpH3gCgNrcR5EpuzbJY1zF 4Ncth3uhtzKwezC6Ki8xqu6jZ9rbAgMBAAEwDQYJKoZIhvcNAQECBQADgYEATD+4i8Zo3+5DMw5d 6abLB4RNejP/khv0Nq3YlSI2aBFsfELM85wuxAc/FLAPT/+Qknb54rxK6Y/NoIAK98Up8YIiXbix 3YEjo3slFUYweRb46gVLlH8dwhzI47f0EEA8E8NfH1PoSOSGtHuhNbB7Jbq4046rPzidADQAmPPR cZQwggRGMIIDr6ADAgECAhBm/Ufjwhnk6JrNmd31OsskMA0GCSqGSIb3DQEBBQUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNTEwMjgwMDAwMDBaFw0xNTEwMjcy MzU5NTlaMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g RzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDJ36zn6vj4AxTEAJLVwX42wjzvfHIV y8CrjD0clc5vHhAsPwDtlybmtsfmrUMdP6SHR0dMPlT4bPjH/LGevTBwvJexAwXqlfGtQMVEeksF ovJg/Nc6ZWLv/xB7ola7xU5wLdaiHzztsELoXo1XIaymmdkR6dIaB8B0R0IL/MU06v3muiTRHQgV N6LXc88BQS9jsjo/vqUabvTJSls9laYVuzUCGfnU77yPDnF2WbtLtj7W/FoW9NYOifJJ/mwM7RXp 2Yh1nHnOYCfdua11zi9zlXpAOoV1SbC432i8q80TgoURUKPgPAuuwApTzdcwb4UyRhvkSRDCbOKv H3n/27S1AgMBAAGjgf8wgfwwEgYDVR0TAQH/BAgwBgEB/wIBADBEBgNVHSAEPTA7MDkGC2CGSAGG +EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0P BAQDAgEGMBEGCWCGSAGG+EIBAQQEAwIBBjAuBgNVHREEJzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0 ZUxhYmVsMy0yMDQ4LTE1NTAdBgNVHQ4EFgQUEX1eGX08BN9qbNaiiho/Mdg7lFIwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwDQYJKoZIhvcNAQEFBQAD gYEAPKPaAmM6xJOqq3LT3K1QOB4MnhZKiLfu69n/D42VoNa7+moLrmGE2GhHie9PrLIfSUGbSTN2 k4uebrlDHGC9wtyKLYfBRcARcgQaayQqbG/n/AcTKdB3OiPn9cGFaBm/xgFUIBmuNYLMYjxhCcb0 1euwD6afM4Wa03GOUI+Z3WIwggTcMIIDxKADAgECAhAdbJ7qJ1t3pQoJyWI9GoXNMA0GCSqGSIb3 DQEBBQUAMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g RzIwHhcNMTAwMjE3MDAwMDAwWhcNMTEwMzA2MjM1OTU5WjCCARMxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4w HAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQgQ2xhc3Mg MSAtIE1pY3Jvc29mdCBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD1Rob21hcyBIYXJkam9ubzEfMB0G CSqGSIb3DQEJARYQaGFyZGpvbm9AbWl0LmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 5IPN5gsvYs8ugsfq1ndIZqRJXlbGSKsX+IH45pbnLeWPFWzfG7mxch4QhqOD0RUs2GCI1YNHPS8C sFyj1V05XnT0p/1eHa8eHOV2V3RVljq3P5R2+vhskoGE2Nwm1wi8YP9ce0Cs2Qf4wiPm9oL2ls5M yvOCR0aWfBkXD231vBUCAwEAAaOB4jCB3zAJBgNVHRMEAjAAMEQGA1UdIAQ9MDswOQYLYIZIAYb4 RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBQGCmCGSAGG+EUBBgcEBhYETm9u ZTBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlzaWduLmNv bS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAJrdkpPOIr2sXpSrE9hlj36x FOukzUivx4QwmsyLSFvMrkSQ/7NCGQ73O6DMlmJZbtQPMdIpqc9ZwPYhOkyQ9AaKz10yHVO8TkW2 CAN0Atk1ZfAF78C1h/jch429nYmjADnDZyDuyRUi2yW4ouJkX84Suj1SYaC5ptZVmmMUyRwcNV6/ iHewW8wsIf0mOqtP79RMAJ6oGh0XlUmzlahqtMbi3JX02D9gAVW9j8zXqtI0pHSpMNkNzkFp8GRd 5bxaCdQzszNIPfQGNIM0x7w97ZbF8z+F2yCRSL0+4G9kQxGRpxkd1OWjov5OJfmPvOyTZkkX9cmd Sivi3+fEDBgv0kIxggTEMIIEwAIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1 YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAdbJ7qJ1t3pQoJyWI9GoXNMAkGBSsOAwIaBQCgggMnMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDYxMDIwMzM0OVowIwYJ KoZIhvcNAQkEMRYEFCFebBfekOtJDoWzAMrcG+ap6RczMIG3BgkqhkiG9w0BCQ8xgakwgaYwCwYJ YIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcN AwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAsG CWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMAoGCCqGSIb3DQIFMIIBAwYJKwYB BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzICEB1snuonW3elCgnJYj0ahc0wggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAdbJ7qJ1t3pQoJ yWI9GoXNMA0GCSqGSIb3DQEBAQUABIGAPtpdp9DYQqVyGFLw5c02IS/NVCG2YH6Ji/X8GjSsJ+kB J5uCldXR/7rhCXnrnHLurXaCoW7LvWkCg+fzxkMPfNubHKxlXmIWa+F59m1BXsuf6KvqKiqfvC+p 59nXrBV2bufH0Fb+AAKZYOfoHc0GRvdNaoReznHd1ytIhv05Gd8AAAAAAAA= ------=_NextPart_000_0004_01CB08BA.B4BB8AC0-- From dick.hardt@gmail.com Thu Jun 10 13:34:39 2010 Return-Path: <dick.hardt@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CA8C3A6784 for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 13:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.19 X-Spam-Level: X-Spam-Status: No, score=-2.19 tagged_above=-999 required=5 tests=[AWL=0.409, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3NdICgnXZTtp for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 13:34:38 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 2D4813A6783 for <oauth@ietf.org>; Thu, 10 Jun 2010 13:34:38 -0700 (PDT) Received: by pwi8 with SMTP id 8so150739pwi.31 for <oauth@ietf.org>; Thu, 10 Jun 2010 13:34:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=agpvgcTTPksoQE5SymUDlgjPoZz3sWRR630dFtFb09U=; b=WoaFOfT74DimHVMIvgZ8tHhmJ5NnywQGS7TP5VJ2Eceq1aovIrl/lB86oNfSeYW58v 5rMqNsJ7nEH7WV0gCUETR1s5HHyASzJ/DcoY4K5D7BiMnA9W4E10bEjdkLdIlg9TCg34 JVyMnvWq3b15hDf0hEslU1KVy++pCr/ma4m4g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=Lt00tqYjZzMIewmxVvjh/KLuRkjTWgYxeKVfqhXn0l/j4feTbtDFmZgmnVQteJQjLT ZP6fUwf8RfEUU6ylM59Ws66GGUgw7WcijsEKKIjYqRm6RciSDXIfqEAaAjrIMEeJAc46 O+vhlYK0RP0ooEmeQCsJG1WuxPmqXxK/FC8U0= Received: by 10.141.88.14 with SMTP id q14mr517799rvl.183.1276202078047; Thu, 10 Jun 2010 13:34:38 -0700 (PDT) Received: from [10.0.1.15] (c-24-130-32-55.hsd1.ca.comcast.net [24.130.32.55]) by mx.google.com with ESMTPS id k17sm381329rvh.5.2010.06.10.13.34.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 10 Jun 2010 13:34:37 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Dick Hardt <dick.hardt@gmail.com> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF73EF@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 10 Jun 2010 13:34:36 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <09258F6B-9AB7-4318-A2C1-AB29C495842C@gmail.com> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF73EF@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav <eran@hueniverse.com> X-Mailer: Apple Mail (2.1078) Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Proposal for single JSON response format X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 10 Jun 2010 20:34:39 -0000 +1 On 2010-06-10, at 1:29 PM, Eran Hammer-Lahav wrote: > After taking a break from our previous debate(s) on the issue of which = response format to support, I would like to suggest the following: >=20 > - Support a single response format (including in the user-agent = fragment) using JSON. >=20 > My reason for this is very simple, while right now we have a very = limited need (key/value pairs), we already have a few proposals which = require a richer syntax. As OAuth matures, I expect more and more = extensions to make use of the server response to include additional = parameters (flat or structured). By using JSON, we can very easily = support "namespaces" (i.e. { "access_token":"xyz","ext":{...} }), = multiple token in a single response, etc. >=20 > I appreciate the simplicity in using form-encoded (both code and = library dependency wise), but long term, it will create a real = limitation and will require extensions to also specify a different = response format. >=20 > Those worried about the need to include a JSON library in cases where = it will be hard to do (embedded devices, etc.), can always extend the = protocol to provide a way to receive key/value form-encoded pairs. = However, they will need to figure out how to accommodate structured = responses if they wish support it. I am certain that the vast majority = of implementations will have no problem including a JSON library. >=20 > Please respond only with yes or no (+/- 1). If you have a different = proposal, please post it in a new thread. If you are going to vote = against this, please indicate if your objection is blocking (i.e. you = are opposed to it and will block a consensus call with this approach). >=20 > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From michael.d.adams@gmail.com Thu Jun 10 13:36:58 2010 Return-Path: <michael.d.adams@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56BD93A6783 for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 13:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6km4gB18YIBZ for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 13:36:57 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 686C23A659A for <oauth@ietf.org>; Thu, 10 Jun 2010 13:36:57 -0700 (PDT) Received: by gwj16 with SMTP id 16so285222gwj.31 for <oauth@ietf.org>; Thu, 10 Jun 2010 13:36:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=zFQv1+N1k85eTbWAjiihvo5tYm65dNq7gir62WknXkg=; b=If43+cd3tFKYoE8lXKcJl68cMjtReofgMqNotartdMcaijf6+hs9T+sQqWxhcPdHmL IVNkcKH/nUW7ybbnYmN+BOAjRfxSs/aQYinZKfwpA/2qWQZZlhrbzst/fksJHfXFVy82 oYld1VDOTZa/B+plBFS4sJXW38BS8LYr130s4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=mDAvvY5wl8788jAU5NsBQpyiTbucIpbIcJV7NBMgSMVpIz7/+8dOzU1Df7FkCplnsL B6MavRMPX/zYaMQv7noazjrKeK8fTxEZ7xW8IB9/tcb0RDCKN/3NiJBBMDUd+IzxUuLQ tKP2/cxwf3HqNn9kBfNtXrvZ0GEFW/0c660xQ= Received: by 10.150.160.17 with SMTP id i17mr1975026ybe.399.1276202218882; Thu, 10 Jun 2010 13:36:58 -0700 (PDT) MIME-Version: 1.0 Sender: michael.d.adams@gmail.com Received: by 10.231.19.2 with HTTP; Thu, 10 Jun 2010 13:36:38 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF73EF@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF73EF@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Michael D Adams <mike@automattic.com> Date: Thu, 10 Jun 2010 13:36:38 -0700 X-Google-Sender-Auth: XNi97gsH3PqhR4N3aMwDujZMSu8 Message-ID: <AANLkTikhW1DLCpiERQFFJECDGtrG7UFZdrjYY4-ytd7K@mail.gmail.com> To: Eran Hammer-Lahav <eran@hueniverse.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Proposal for single JSON response format X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 10 Jun 2010 20:36:58 -0000 +1 On Thu, Jun 10, 2010 at 1:29 PM, Eran Hammer-Lahav <eran@hueniverse.com> wr= ote: > After taking a break from our previous debate(s) on the issue of which re= sponse format to support, I would like to suggest the following: > > - Support a single response format (including in the user-agent fragment)= using JSON. > > My reason for this is very simple, while right now we have a very limited= need (key/value pairs), we already have a few proposals which require a ri= cher syntax. As OAuth matures, I expect more and more extensions to make us= e of the server response to include additional parameters (flat or structur= ed). By using JSON, we can very easily support "namespaces" (i.e. { "access= _token":"xyz","ext":{...} }), multiple token in a single response, etc. > > I appreciate the simplicity in using form-encoded (both code and library = dependency wise), but long term, it will create a real limitation and will = require extensions to also specify a different response format. > > Those worried about the need to include a JSON library in cases where it = will be hard to do (embedded devices, etc.), can always extend the protocol= to provide a way to receive key/value form-encoded pairs. However, they wi= ll need to figure out how to accommodate structured responses if they wish = support it. I am certain that the vast majority of implementations will hav= e no problem including a JSON library. > > Please respond only with yes or no (+/- 1). If you have a different propo= sal, please post it in a new thread. If you are going to vote against this,= please indicate if your objection is blocking (i.e. you are opposed to it = and will block a consensus call with this approach). > > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From recordond@gmail.com Thu Jun 10 13:48:29 2010 Return-Path: <recordond@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A5163A68CD for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 13:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.717 X-Spam-Level: X-Spam-Status: No, score=-1.717 tagged_above=-999 required=5 tests=[AWL=0.882, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LnokhwdoC-kV for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 13:48:27 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 8B6FB3A659A for <oauth@ietf.org>; Thu, 10 Jun 2010 13:48:27 -0700 (PDT) Received: by iwn42 with SMTP id 42so334892iwn.31 for <oauth@ietf.org>; Thu, 10 Jun 2010 13:48:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=zFQv1+N1k85eTbWAjiihvo5tYm65dNq7gir62WknXkg=; b=jxAwC9im//MJD5TJv0TuF0bLO6nEZcy+9sv+zMU5IGDMh+z8UbUodSisUVyj28bHB8 ZmH/WoqJRlZDLSLokJziQtASXGQ9iltZlj/agvdxOkgz0v6JRwsHc65lLsdPmzf0wGZE OkZmx0oiLT1r4srew3N3exVcehrKbsnZVtRFQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=XN+4ihWzX/+xINdhgxhBSc3r1AQFigKr3i49R9JLcgPtQEEnk4h8B+s5uSvnxauY06 h0aHSLXEpvSZB5bm+LS+wPILIQ1CJWUaBFjPieW+IofCW+FtCMPbhf8vezZtPStk6UQ3 jQabejmpb9LXdPrZmjhsvP8Cmzn+ux/6IqmWk= MIME-Version: 1.0 Received: by 10.231.168.129 with SMTP id u1mr704354iby.49.1276202906487; Thu, 10 Jun 2010 13:48:26 -0700 (PDT) Received: by 10.231.192.4 with HTTP; Thu, 10 Jun 2010 13:48:26 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF73EF@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF73EF@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 10 Jun 2010 13:48:26 -0700 Message-ID: <AANLkTinmme06vMRYKr1Chm1JvhgeuKgoQ7hh_YYhPoqR@mail.gmail.com> From: David Recordon <recordond@gmail.com> To: Eran Hammer-Lahav <eran@hueniverse.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Proposal for single JSON response format X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 10 Jun 2010 20:48:29 -0000 +1 On Thu, Jun 10, 2010 at 1:29 PM, Eran Hammer-Lahav <eran@hueniverse.com> wr= ote: > After taking a break from our previous debate(s) on the issue of which re= sponse format to support, I would like to suggest the following: > > - Support a single response format (including in the user-agent fragment)= using JSON. > > My reason for this is very simple, while right now we have a very limited= need (key/value pairs), we already have a few proposals which require a ri= cher syntax. As OAuth matures, I expect more and more extensions to make us= e of the server response to include additional parameters (flat or structur= ed). By using JSON, we can very easily support "namespaces" (i.e. { "access= _token":"xyz","ext":{...} }), multiple token in a single response, etc. > > I appreciate the simplicity in using form-encoded (both code and library = dependency wise), but long term, it will create a real limitation and will = require extensions to also specify a different response format. > > Those worried about the need to include a JSON library in cases where it = will be hard to do (embedded devices, etc.), can always extend the protocol= to provide a way to receive key/value form-encoded pairs. However, they wi= ll need to figure out how to accommodate structured responses if they wish = support it. I am certain that the vast majority of implementations will hav= e no problem including a JSON library. > > Please respond only with yes or no (+/- 1). If you have a different propo= sal, please post it in a new thread. If you are going to vote against this,= please indicate if your objection is blocking (i.e. you are opposed to it = and will block a consensus call with this approach). > > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From recordond@gmail.com Thu Jun 10 13:51:05 2010 Return-Path: <recordond@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C70E63A659A for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 13:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.815 X-Spam-Level: X-Spam-Status: No, score=-1.815 tagged_above=-999 required=5 tests=[AWL=0.784, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QWNv5sObQpZW for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 13:51:04 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id CF3403A6359 for <oauth@ietf.org>; Thu, 10 Jun 2010 13:51:04 -0700 (PDT) Received: by iwn42 with SMTP id 42so337125iwn.31 for <oauth@ietf.org>; Thu, 10 Jun 2010 13:51:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=H+/fPP5CmUH4gd5eNp46vzw2Xn8/TDcuqxS1td/SfdM=; b=Cjs86ZXdSjEb7+p6AGHIwbhSqBqZufEyQQPsjB+0aA0nzztQ7zdcJP06VGu3TUCrUl r0Lo1wlmjt6CjGoSwlqMRZEoYrJpT4wHI8vYMPf4Hh1PCQCxiHrLcvkJthTeYf9BPqwa KqYmpv+1C79pnaA8vE9Amq26YB0KWhGAVuVaU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=eyMZQ1/qTjr6BkvYnOdC4dcsK0oGyawrbEgmhaPvD/R5ZemC3BJ+xQSmoU0IcWX0gR ToHOgMzvwqHhJPM6L9dOWYww7zeRwz5HxwYjBZ+Pi+XOh2TosmiazTqizp4X80zLX1Ir XMxDEvSwnWc3uuqYVsEkYlr4+/cZuQgiN1xp8= MIME-Version: 1.0 Received: by 10.42.1.75 with SMTP id 11mr270385icf.37.1276203064498; Thu, 10 Jun 2010 13:51:04 -0700 (PDT) Received: by 10.231.192.4 with HTTP; Thu, 10 Jun 2010 13:51:04 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF73BB@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF73BB@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 10 Jun 2010 13:51:04 -0700 Message-ID: <AANLkTik9whDRZ4O3z_uaSOqg-pKGgtK6bfjMPdIHy01b@mail.gmail.com> From: David Recordon <recordond@gmail.com> To: Eran Hammer-Lahav <eran@hueniverse.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Client credentials w/ or w/o secret X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 10 Jun 2010 20:51:05 -0000 We've talked about issuing different client secrets for use with different flows. We haven't actually implemented it yet and prefer using something like TPM on devices which support it. A different secret is at least better than nothing for apps which can't reliably keep secrets and don't have something like a TPM. --David On Thu, Jun 10, 2010 at 12:42 PM, Eran Hammer-Lahav <eran@hueniverse.com> w= rote: > Some of the flows require/allow a client secret while others disallow it = (when the client has no secure means to keep it secret). My question is, do= you plan to issue different credentials for different flows (with or witho= ut secret) or allow the same set to be used, sometimes with and sometimes w= ithout a secret based on the flow? > > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From jricher@mitre.org Thu Jun 10 13:51:47 2010 Return-Path: <jricher@mitre.org> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CDB83A67AC for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 13:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z9iS48WFrRwp for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 13:51:46 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 488733A659A for <oauth@ietf.org>; Thu, 10 Jun 2010 13:51:46 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o5AKpmgZ020090 for <oauth@ietf.org>; Thu, 10 Jun 2010 16:51:48 -0400 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o5AKpl8p020085; Thu, 10 Jun 2010 16:51:47 -0400 Received: from [129.83.50.65] (129.83.50.65) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server id 8.2.254.0; Thu, 10 Jun 2010 16:51:47 -0400 From: Justin Richer <jricher@mitre.org> To: Eran Hammer-Lahav <eran@hueniverse.com> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF73EF@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF73EF@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset="UTF-8" Date: Thu, 10 Jun 2010 16:51:47 -0400 Message-ID: <1276203107.31840.16.camel@localhost.localdomain> MIME-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Proposal for single JSON response format X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 10 Jun 2010 20:51:47 -0000 +1 Propose we have other encodings as extensions, then. -- justin On Thu, 2010-06-10 at 16:29 -0400, Eran Hammer-Lahav wrote: > After taking a break from our previous debate(s) on the issue of which response format to support, I would like to suggest the following: > > - Support a single response format (including in the user-agent fragment) using JSON. > > My reason for this is very simple, while right now we have a very limited need (key/value pairs), we already have a few proposals which require a richer syntax. As OAuth matures, I expect more and more extensions to make use of the server response to include additional parameters (flat or structured). By using JSON, we can very easily support "namespaces" (i.e. { "access_token":"xyz","ext":{...} }), multiple token in a single response, etc. > > I appreciate the simplicity in using form-encoded (both code and library dependency wise), but long term, it will create a real limitation and will require extensions to also specify a different response format. > > Those worried about the need to include a JSON library in cases where it will be hard to do (embedded devices, etc.), can always extend the protocol to provide a way to receive key/value form-encoded pairs. However, they will need to figure out how to accommodate structured responses if they wish support it. I am certain that the vast majority of implementations will have no problem including a JSON library. > > Please respond only with yes or no (+/- 1). If you have a different proposal, please post it in a new thread. If you are going to vote against this, please indicate if your objection is blocking (i.e. you are opposed to it and will block a consensus call with this approach). > > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From torsten@lodderstedt.net Thu Jun 10 14:19:15 2010 Return-Path: <torsten@lodderstedt.net> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4416A3A69A3 for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 14:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.468 X-Spam-Level: X-Spam-Status: No, score=-0.468 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_20=-0.74, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KuNaC4shAtN4 for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 14:19:14 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.36]) by core3.amsl.com (Postfix) with ESMTP id CA8EA3A67AE for <oauth@ietf.org>; Thu, 10 Jun 2010 14:19:13 -0700 (PDT) Received: from p4fff38af.dip.t-dialin.net ([79.255.56.175] helo=[127.0.0.1]) by smtprelay02.ispgateway.de with esmtpa (Exim 4.68) (envelope-from <torsten@lodderstedt.net>) id 1OMp9e-0003hI-E5; Thu, 10 Jun 2010 23:19:14 +0200 Message-ID: <4C1156D1.20504@lodderstedt.net> Date: Thu, 10 Jun 2010 23:19:13 +0200 From: Torsten Lodderstedt <torsten@lodderstedt.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Eran Hammer-Lahav <eran@hueniverse.com> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF73EF@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF73EF@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Proposal for single JSON response format X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 10 Jun 2010 21:19:15 -0000 +1 Am 10.06.2010 22:29, schrieb Eran Hammer-Lahav: > After taking a break from our previous debate(s) on the issue of which response format to support, I would like to suggest the following: > > - Support a single response format (including in the user-agent fragment) using JSON. > > My reason for this is very simple, while right now we have a very limited need (key/value pairs), we already have a few proposals which require a richer syntax. As OAuth matures, I expect more and more extensions to make use of the server response to include additional parameters (flat or structured). By using JSON, we can very easily support "namespaces" (i.e. { "access_token":"xyz","ext":{...} }), multiple token in a single response, etc. > > I appreciate the simplicity in using form-encoded (both code and library dependency wise), but long term, it will create a real limitation and will require extensions to also specify a different response format. > > Those worried about the need to include a JSON library in cases where it will be hard to do (embedded devices, etc.), can always extend the protocol to provide a way to receive key/value form-encoded pairs. However, they will need to figure out how to accommodate structured responses if they wish support it. I am certain that the vast majority of implementations will have no problem including a JSON library. > > Please respond only with yes or no (+/- 1). If you have a different proposal, please post it in a new thread. If you are going to vote against this, please indicate if your objection is blocking (i.e. you are opposed to it and will block a consensus call with this approach). > > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From torsten@lodderstedt.net Thu Jun 10 14:23:32 2010 Return-Path: <torsten@lodderstedt.net> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1312A3A69C7 for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 14:23:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.387 X-Spam-Level: X-Spam-Status: No, score=-1.387 tagged_above=-999 required=5 tests=[AWL=0.863, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cmBIQ1Tj+AnP for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 14:23:28 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.29.24]) by core3.amsl.com (Postfix) with ESMTP id 7F5FA3A67AE for <oauth@ietf.org>; Thu, 10 Jun 2010 14:23:25 -0700 (PDT) Received: from p4fff38af.dip.t-dialin.net ([79.255.56.175] helo=[127.0.0.1]) by smtprelay02.ispgateway.de with esmtpa (Exim 4.68) (envelope-from <torsten@lodderstedt.net>) id 1OMpDi-0002NE-PG; Thu, 10 Jun 2010 23:23:26 +0200 Message-ID: <4C1157CD.1010101@lodderstedt.net> Date: Thu, 10 Jun 2010 23:23:25 +0200 From: Torsten Lodderstedt <torsten@lodderstedt.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Eran Hammer-Lahav <eran@hueniverse.com> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF7331@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF7331@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Names for endpoints X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 10 Jun 2010 21:23:32 -0000 Am 10.06.2010 19:52, schrieb Eran Hammer-Lahav: > Pick or suggest new ideas: > > * Endpoint used to interact with the end-user > > End-user Endpoint > Front Channel Endpoint > Authorization Endpoint > > End-User Authorization Endpoint > +1 > User-Agent Endpoint > > > * Endpoint used to interact directly with the client > > Token Endpoint > > Client Endpoint > +1 > Back Channel Endpoint > > > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From cmortimore@salesforce.com Thu Jun 10 15:11:13 2010 Return-Path: <cmortimore@salesforce.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD8013A67FD for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 15:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.831 X-Spam-Level: X-Spam-Status: No, score=-3.831 tagged_above=-999 required=5 tests=[AWL=1.278, BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VYKmHq7wLutv for <oauth@core3.amsl.com>; Thu, 10 Jun 2010 15:11:11 -0700 (PDT) Received: from exprod8og113.obsmtp.com (exprod8og113.obsmtp.com [64.18.3.26]) by core3.amsl.com (Postfix) with SMTP id 034603A67E9 for <oauth@ietf.org>; Thu, 10 Jun 2010 15:11:10 -0700 (PDT) Received: from source ([204.14.239.239]) by exprod8ob113.postini.com ([64.18.7.12]) with SMTP ID DSNKTBFjAbnmCXeNfUYmpxuxhIFQkbOKAKNU@postini.com; Thu, 10 Jun 2010 15:11:13 PDT Received: from EXSFM-MB01.internal.salesforce.com ([10.1.127.45]) by exsfm-hub4.internal.salesforce.com ([10.1.127.8]) with mapi; Thu, 10 Jun 2010 15:11:12 -0700 From: Chuck Mortimore <cmortimore@salesforce.com> To: Eran Hammer-Lahav <eran@hueniverse.com>, "oauth@ietf.org" <oauth@ietf.org> Date: Thu, 10 Jun 2010 15:11:11 -0700 Thread-Topic: [OAUTH-WG] Proposal for single JSON response format Thread-Index: AcsI25LiV8WWr/WxSnmFMcXJetYFegADkJ12 Message-ID: <C836B10F.6E21%cmortimore@salesforce.com> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF73EF@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C836B10F6E21cmortimoresalesforcecom_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Proposal for single JSON response format X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 10 Jun 2010 22:11:14 -0000 --_000_C836B10F6E21cmortimoresalesforcecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable +1 with optional extension for XML encoded -cmort On 6/10/10 1:29 PM, "Eran Hammer-Lahav" <eran@hueniverse.com> wrote: After taking a break from our previous debate(s) on the issue of which resp= onse format to support, I would like to suggest the following: - Support a single response format (including in the user-agent fragment) u= sing JSON. My reason for this is very simple, while right now we have a very limited n= eed (key/value pairs), we already have a few proposals which require a rich= er syntax. As OAuth matures, I expect more and more extensions to make use = of the server response to include additional parameters (flat or structured= ). By using JSON, we can very easily support "namespaces" (i.e. { "access_t= oken":"xyz","ext":{...} }), multiple token in a single response, etc. I appreciate the simplicity in using form-encoded (both code and library de= pendency wise), but long term, it will create a real limitation and will re= quire extensions to also specify a different response format. Those worried about the need to include a JSON library in cases where it wi= ll be hard to do (embedded devices, etc.), can always extend the protocol t= o provide a way to receive key/value form-encoded pairs. However, they will= need to figure out how to accommodate structured responses if they wish su= pport it. I am certain that the vast majority of implementations will have = no problem including a JSON library. Please respond only with yes or no (+/- 1). If you have a different proposa= l, please post it in a new thread. If you are going to vote against this, p= lease indicate if your objection is blocking (i.e. you are opposed to it an= d will block a consensus call with this approach). EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_C836B10F6E21cmortimoresalesforcecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <HTML> <HEAD> <TITLE>Re: [OAUTH-WG] Proposal for single JSON response format +1 with optiona= l extension for XML encoded

-cmort


On 6/10/10 1:29 PM, "Eran Hammer-Lahav" <eran@hueniverse.com> wrote:

After taking a break from our previous debate(s) on the issue of= which response format to support, I would like to suggest the following:
- Support a single response format (including in the user-agent fragment) u= sing JSON.

My reason for this is very simple, while right now we have a very limited n= eed (key/value pairs), we already have a few proposals which require a rich= er syntax. As OAuth matures, I expect more and more extensions to make use = of the server response to include additional parameters (flat or structured= ). By using JSON, we can very easily support "namespaces" (i.e. {= "access_token":"xyz","ext":{...} }), multipl= e token in a single response, etc.

I appreciate the simplicity in using form-encoded (both code and library de= pendency wise), but long term, it will create a real limitation and will re= quire extensions to also specify a different response format.

Those worried about the need to include a JSON library in cases where it wi= ll be hard to do (embedded devices, etc.), can always extend the protocol t= o provide a way to receive key/value form-encoded pairs. However, they will= need to figure out how to accommodate structured responses if they wish su= pport it. I am certain that the vast majority of implementations will have = no problem including a JSON library.

Please respond only with yes or no (+/- 1). If you have a different proposa= l, please post it in a new thread. If you are going to vote against this, p= lease indicate if your objection is blocking (i.e. you are opposed to it an= d will block a consensus call with this approach).

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

--_000_C836B10F6E21cmortimoresalesforcecom_-- From beaton@google.com Thu Jun 10 15:19:11 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AFEC3A680D for ; Thu, 10 Jun 2010 15:19:11 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wRcPfbyp8-db for ; Thu, 10 Jun 2010 15:18:58 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id CBBC83A67E7 for ; Thu, 10 Jun 2010 15:18:57 -0700 (PDT) Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id o5AMIwdF023009 for ; Thu, 10 Jun 2010 15:18:59 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1276208339; bh=NPvwsXjJU5SJ2+qR8VoHTU6LVS0=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=Bpx7VAS0k2Y+7piKcdUfgqfUsTDREJvd2lVmwhENnyA/UItY2fnMh58+r3pK22k8v /rAGi77gl2TaatjRlb6rA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding; b=kOHnrsQ76VdLKFNRy4ipi5YozTos0+1tVRBY8y4mT4qLlPXU0FxECqFX3gWb7UeCI h1fJFEPHozufN9mN1gjeQ== Received: from pxi10 (pxi10.prod.google.com [10.243.27.10]) by wpaz17.hot.corp.google.com with ESMTP id o5AMIv5Q021954 for ; Thu, 10 Jun 2010 15:18:57 -0700 Received: by pxi10 with SMTP id 10so293849pxi.35 for ; Thu, 10 Jun 2010 15:18:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.117.16 with SMTP id p16mr568827wfc.290.1276208336768; Thu, 10 Jun 2010 15:18:56 -0700 (PDT) Received: by 10.142.207.21 with HTTP; Thu, 10 Jun 2010 15:18:56 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF73EF@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF73EF@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 10 Jun 2010 15:18:56 -0700 Message-ID: From: Brian Eaton To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Proposal for single JSON response format X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 22:19:11 -0000 +1. On Thu, Jun 10, 2010 at 1:29 PM, Eran Hammer-Lahav wr= ote: > After taking a break from our previous debate(s) on the issue of which re= sponse format to support, I would like to suggest the following: > > - Support a single response format (including in the user-agent fragment)= using JSON. > > My reason for this is very simple, while right now we have a very limited= need (key/value pairs), we already have a few proposals which require a ri= cher syntax. As OAuth matures, I expect more and more extensions to make us= e of the server response to include additional parameters (flat or structur= ed). By using JSON, we can very easily support "namespaces" (i.e. { "access= _token":"xyz","ext":{...} }), multiple token in a single response, etc. > > I appreciate the simplicity in using form-encoded (both code and library = dependency wise), but long term, it will create a real limitation and will = require extensions to also specify a different response format. > > Those worried about the need to include a JSON library in cases where it = will be hard to do (embedded devices, etc.), can always extend the protocol= to provide a way to receive key/value form-encoded pairs. However, they wi= ll need to figure out how to accommodate structured responses if they wish = support it. I am certain that the vast majority of implementations will hav= e no problem including a JSON library. > > Please respond only with yes or no (+/- 1). If you have a different propo= sal, please post it in a new thread. If you are going to vote against this,= please indicate if your objection is blocking (i.e. you are opposed to it = and will block a consensus call with this approach). > > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From sakimura@gmail.com Thu Jun 10 15:20:52 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D1323A67D1 for ; Thu, 10 Jun 2010 15:20:52 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tAZ2mtirmNzt for ; Thu, 10 Jun 2010 15:20:45 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id 5D32A3A6807 for ; Thu, 10 Jun 2010 15:20:44 -0700 (PDT) Received: by pxi15 with SMTP id 15so173378pxi.31 for ; Thu, 10 Jun 2010 15:20:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:x-mailer :mime-version:subject:date:cc; bh=zMLogbkTmbyAsWu2E6yGmvPaE6Bzi626XJwmWwC5Mrw=; b=AcoLUTLIZNJKqXlEotgZHIY+lGGsn5B4U1F35LBOmI0bxhC1wyOlnAPKnjz/XhWtS+ /JjNOtFz128RIqJOefQ9AGxjMCgzHoKgJiuwZ4My6zHo1fIy5yslFYJSB7aKkdlivdQi ITY8GL3+ueeQYhB6PGapkY+pfMZdcB+feGktE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:x-mailer:mime-version:subject:date:cc; b=YVq4kygt2IcKuJynhPZ1GCBO/k8NhxBLgv3b5YGeVMH52NsBOpXfe+rJcWhSqLBBQB Cr/YaDsCH2IoYk5vzPfLGEzJ4DHclfAfYU477wbtKQifP9pxs++SUaXzuV3ANftmpc0E vt4WF6l19GSTRvOgzyde0HJzzBUXM3S22OtuY= Received: by 10.141.23.18 with SMTP id a18mr597277rvj.239.1276208443276; Thu, 10 Jun 2010 15:20:43 -0700 (PDT) Received: from [192.168.2.6] (pd84713.tokynt01.ap.so-net.ne.jp [111.216.71.19]) by mx.google.com with ESMTPS id b12sm471710rvn.10.2010.06.10.15.20.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 10 Jun 2010 15:20:42 -0700 (PDT) References: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF73EF@P3PW5EX1MB01.EX1.SECURESERVER.NET> Message-Id: <7795D591-B281-4BFE-A287-55379F0C374A@gmail.com> From: Nat To: Brian Eaton In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7E18) Mime-Version: 1.0 (iPhone Mail 7E18) Date: Fri, 11 Jun 2010 07:21:01 +0900 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Proposal for single JSON response format X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 22:20:52 -0000 +1 =nat @ Tokyo via iPhone On 2010/06/11, at 7:18, Brian Eaton wrote: > +1. > > On Thu, Jun 10, 2010 at 1:29 PM, Eran Hammer-Lahav > wrote: >> After taking a break from our previous debate(s) on the issue of >> which response format to support, I would like to suggest the >> following: >> >> - Support a single response format (including in the user-agent >> fragment) using JSON. >> >> My reason for this is very simple, while right now we have a very >> limited need (key/value pairs), we already have a few proposals >> which require a richer syntax. As OAuth matures, I expect more and >> more extensions to make use of the server response to include >> additional parameters (flat or structured). By using JSON, we can >> very easily support "namespaces" (i.e. { "access_token":"xyz","ext": >> {...} }), multiple token in a single response, etc. >> >> I appreciate the simplicity in using form-encoded (both code and >> library dependency wise), but long term, it will create a real >> limitation and will require extensions to also specify a different >> response format. >> >> Those worried about the need to include a JSON library in cases >> where it will be hard to do (embedded devices, etc.), can always >> extend the protocol to provide a way to receive key/value form- >> encoded pairs. However, they will need to figure out how to >> accommodate structured responses if they wish support it. I am >> certain that the vast majority of implementations will have no >> problem including a JSON library. >> >> Please respond only with yes or no (+/- 1). If you have a different >> proposal, please post it in a new thread. If you are going to vote >> against this, please indicate if your objection is blocking (i.e. >> you are opposed to it and will block a consensus call with this >> approach). >> >> 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 cmortimore@salesforce.com Thu Jun 10 16:00:50 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DC263A67CC for ; Thu, 10 Jun 2010 16:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.702 X-Spam-Level: X-Spam-Status: No, score=-3.702 tagged_above=-999 required=5 tests=[AWL=0.296, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TWgNGG1qlpKr for ; Thu, 10 Jun 2010 16:00:42 -0700 (PDT) Received: from exprod8og119.obsmtp.com (exprod8og119.obsmtp.com [64.18.3.38]) by core3.amsl.com (Postfix) with SMTP id 201283A67AC for ; Thu, 10 Jun 2010 16:00:42 -0700 (PDT) Received: from source ([204.14.239.238]) by exprod8ob119.postini.com ([64.18.7.12]) with SMTP ID DSNKTBFunDTiIw0KDfuIJyssImA1vcMClrrd@postini.com; Thu, 10 Jun 2010 16:00:44 PDT Received: from EXSFM-MB01.internal.salesforce.com ([10.1.127.45]) by exsfm-hub3.internal.salesforce.com ([10.1.127.7]) with mapi; Thu, 10 Jun 2010 16:00:43 -0700 From: Chuck Mortimore To: Eran Hammer-Lahav , Luke Shepard , Marius Scurtescu , Brian Ellin Date: Thu, 10 Jun 2010 16:00:42 -0700 Thread-Topic: [OAUTH-WG] Proposal: make it possible to get a verification code in the user-agent flow Thread-Index: Acr65tymULu0V0HLRQejycK1Jz3TrAAoGTAsA1pfs1I= Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C836BCAA6E30cmortimoresalesforcecom_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Proposal: make it possible to get a verification code in the user-agent flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 23:00:50 -0000 --_000_C836BCAA6E30cmortimoresalesforcecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Did anyone ever write up the specifics of this? I've seen general support= , and would like to see it added. -cmort On 5/24/10 2:22 PM, "Eran Hammer-Lahav" wrote: Anyone wants to turn this into an actual proposal with list of changes to t= he current flow? EHL On 5/23/10 7:13 PM, "Luke Shepard" wrote: Brian - I like your proposal. It solves the refresh token problem and the s= erver-side auth in one go. Marius - your proposal would work great in a circumstance where you have st= rong integration between JavaScript and the server, and they are both contr= olled by the same developer. In that case, sure, the developer could pass t= he access token back to the front-end (although you would have a perf hit). However, the case that I'd like to solve (and what I read, Brian wants to a= s well) is like this: - Client includes some Javascript from the relevant service (either Faceboo= k or Twitter @anywhere) - The JS handles the auth flow and does some client-side API calls - for ex= ample, Twitter displays hovercards on each username on the site, or Faceboo= k renders some profile pics - The JS also passes a token down to the server - either in the cookies, or= perhaps directly via an Ajax call - The server can now independently make its own API calls if it wants, and = gets a refresh token or whatever else it wants This allows for a single, general purpose JS library that handles auth for = both client and server applications - which is something that the web serve= r flow by itself does not allow. On May 21, 2010, at 5:50 PM, Marius Scurtescu wrote: > On Fri, May 21, 2010 at 1:46 PM, Brian Ellin wrote: >> Marius, >> I don't understand. Will you elaborate on how specifically that would w= ork? > > Maybe I am missing something, but I was suggesting that the JavaScript > code starts a web server flow at the end of which it has a > verification code. It passes this verification code down to the client > server, the client server swaps it for an access token and a refresh > token and passes the access token to the JavaScript client. When the > access token expires the client JavaScript has two options, ask the > client server for a refresh or do an immediate request to that authz > server. > > If you want that the client server and client JavaScript have tokens > with totally different scopes, then you probably want to send the user > for approval twice. If you just want the client JavaScript to have a > token with a lesser scope (and avoid a second approval), then we > should probably look into down-scoping, which currently is not > supported. > > Would that work? > > Marius > > >> Brian >> >> On Fri, May 21, 2010 at 12:35 PM, Marius Scurtescu >> wrote: >>> >>> Why not use the web server flow in this case? >>> >>> I think it should work with un-registered clients as well (no client >>> secret). >>> >>> Marius >>> >>> >>> >>> On Fri, May 21, 2010 at 10:39 AM, Brian Ellin wrot= e: >>>> We're using the OAuth 2.0 User-Agent flow in @anywhere at Twitter. >>>> @anywhere is a pure javascript layer that developers can drop in to a= dd >>>> Twitter features to their website. With the User-Agent flow, we issue >>>> short >>>> lived access tokens that refresh as they expire. It works great for >>>> in-page >>>> stuff, but many developers are also building server-side integrations >>>> and >>>> would love to have different longer lived access tokens on their serve= r. >>>> This is a common pattern that other connect-like services built on to= p >>>> of >>>> OAuth 2.0 will also find necessary. >>>> So, why not just use the access token issued by the User-Agent flow on >>>> the >>>> client server? Overloading the use of that token is not desirable for= a >>>> couple of reasons: >>>> 1) The client server may not be using ssl, and as such the browser >>>> cannot >>>> securely transfer the access token to the server. >>>> 2) The access token lifetime policy for the User-Agent flow may not >>>> be desirable on the server. Specifically, the server may need a token >>>> that >>>> lasts for, say, two weeks instead of 15 minutes. Additionally, the >>>> token on >>>> the server may have access to different resources that are >>>> not desirable to >>>> transmit to or through the browser. >>>> In short, it is desirable to get two different access tokens from a >>>> single >>>> user authorization triggered by the User-Agent flow. >>>> Proposal: >>>> Make it possible to get a Web Server flow verification code from the >>>> User-Agent client authorization request [1]. Specifically, add a new >>>> optional parameter named "web_server_code" which when set to "true" >>>> returns >>>> a Web Server flow verification "code" field in the User-Agent >>>> authorization >>>> response. The verification code can then be sent by the javascript >>>> layer to >>>> the client server, where it is then used to request an access token [2= ]. >>>> Love to hear your feedback. >>>> 1: http://tools.ietf.org/html/draft-ietf-oauth-v2-05#section-3.5.1 >>>> 2: http://tools.ietf.org/html/draft-ietf-oauth-v2-05#section-3.6.2 >>>> -- >>>> Brian Ellin >>>> Product Manager, Twitter Platform >>>> http://twitter.com/brianellin >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >> >> >> >> -- >> Brian Ellin >> Twitter Platform Team >> http://twitter.com/brianellin >> > _______________________________________________ > OAuth mailing 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_C836BCAA6E30cmortimoresalesforcecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] Proposal: make it possible to get a verification code= in the user-agent flow Did anyone ever= write up the specifics of this?   I’ve seen general suppor= t, and would like to see it added.

-cmort


On 5/24/10 2:22 PM, "Eran Hammer-Lahav" <eran@hueniverse.com> wrote:

Anyone wants to turn this into an actual proposal wi= th list of changes to the current flow?

EHL


On 5/23/10 7:13 PM, "Luke Shepard" <lshepard@facebook.com> wrote:

Brian - I like your proposal. It solves the refresh = token problem and the server-side auth in one go.

Marius - your proposal would work great in a circumstance where you have st= rong integration between JavaScript and the server, and they are both contr= olled by the same developer. In that case, sure, the developer could pass t= he access token back to the front-end (although you would have a perf hit).=

However, the case that I'd like to solve (and what I read, Brian wants to a= s well) is like this:

- Client includes some Javascript from the relevant service (either Faceboo= k or Twitter @anywhere)
- The JS handles the auth flow and does some client-side API calls - for ex= ample, Twitter displays hovercards on each username on the site, or Faceboo= k renders some profile pics
- The JS also passes a token down to the server - either in the cookies, or= perhaps directly via an Ajax call
- The server can now independently make its own API calls if it wants, and = gets a refresh token or whatever else it wants

This allows for a single, general purpose JS library that handles auth for = both client and server applications - which is something that the web serve= r flow by itself does not allow.

On May 21, 2010, at 5:50 PM, Marius Scurtescu wrote:

> On Fri, May 21, 2010 at 1:46 PM, Brian Ellin <bellin@twitter.com> wrote:
>> Marius,
>> I don't understand.  Will you elaborate on how specifically t= hat would work?
>
> Maybe I am missing something, but I was suggesting that the JavaScript=
> code starts a web server flow at the end of which it has a
> verification code. It passes this verification code down to the client=
> server, the client server swaps it for an access token and a refresh > token and passes the access token to the JavaScript client. When the > access token expires the client JavaScript has two options, ask the > client server for a refresh or do an immediate request to that authz > server.
>
> If you want that the client server and client JavaScript have tokens > with totally different scopes, then you probably want to send the user=
> for approval twice. If you just want the client JavaScript to have a > token with a lesser scope (and avoid a second approval), then we
> should probably look into down-scoping, which currently is not
> supported.
>
> Would that work?
>
> Marius
>
>
>> Brian
>>
>> On Fri, May 21, 2010 at 12:35 PM, Marius Scurtescu <mscurtescu@google.com>
>> wrote:
>>>
>>> Why not use the web server flow in this case?
>>>
>>> I think it should work with un-registered clients as well (no = client
>>> secret).
>>>
>>> Marius
>>>
>>>
>>>
>>> On Fri, May 21, 2010 at 10:39 AM, Brian Ellin <bellin@twitter.com> wrote:
>>>> We're using the OAuth 2.0 User-Agent flow in @anywhere at = Twitter.
>>>>  @anywhere is a pure javascript layer that developers= can drop in to add
>>>> Twitter features to their website.  With the User-Age= nt flow, we issue
>>>> short
>>>> lived access tokens that refresh as they expire.  It = works great for
>>>> in-page
>>>> stuff, but many developers are also building server-side i= ntegrations
>>>> and
>>>> would love to have different longer lived access tokens on= their server.
>>>>  This is a common pattern that other connect-like ser= vices built on top
>>>> of
>>>> OAuth 2.0 will also find necessary.
>>>> So, why not just use the access token issued by the User-A= gent flow on
>>>> the
>>>> client server?  Overloading the use of that token is = not desirable for a
>>>> couple of reasons:
>>>> 1) The client server may not be using ssl, and as such the= browser
>>>> cannot
>>>> securely transfer the access token to the server.
>>>> 2) The access token lifetime policy for the User-Agent flo= w may not
>>>> be desirable on the server.  Specifically, the server= may need a token
>>>> that
>>>> lasts for, say, two weeks instead of 15 minutes.  Add= itionally, the
>>>> token on
>>>> the server may have access to different resources that are=
>>>> not desirable to
>>>> transmit to or through the browser.
>>>> In short, it is desirable to get two different access toke= ns from a
>>>> single
>>>> user authorization triggered by the User-Agent flow.
>>>> Proposal:
>>>> Make it possible to get a Web Server flow verification cod= e from the
>>>> User-Agent client authorization request [1]. Specifically,= add a new
>>>> optional parameter named "web_server_code" which= when set to "true"
>>>> returns
>>>> a Web Server flow verification "code" field in t= he User-Agent
>>>> authorization
>>>> response.  The verification code can then be sent by = the javascript
>>>> layer to
>>>> the client server, where it is then used to request an acc= ess token [2].
>>>> Love to hear your feedback.
>>>> 1: http://tools.ietf.org/html/draft-ietf-oauth-v2-05#sect= ion-3.5.1
>>>> 2: http://tools.ietf.org/html/draft-ietf-oauth-v2-05#sect= ion-3.6.2
>>>> --
>>>> Brian Ellin
>>>> Product Manager, Twitter Platform
>>>> http://twitter.c= om/brianellin
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> ht= tps://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>
>>
>>
>> --
>> Brian Ellin
>> Twitter Platform Team
>> http://twitter.com/brian= ellin
>>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ie= tf.org/mailman/listinfo/oauth

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


--_000_C836BCAA6E30cmortimoresalesforcecom_-- From eran@hueniverse.com Thu Jun 10 16:02:55 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 597883A67E3 for ; Thu, 10 Jun 2010 16:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.87 X-Spam-Level: X-Spam-Status: No, score=-1.87 tagged_above=-999 required=5 tests=[AWL=0.729, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2GxPhaOsvqGx for ; Thu, 10 Jun 2010 16:02:54 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 18E9B3A67AF for ; Thu, 10 Jun 2010 16:02:53 -0700 (PDT) Received: (qmail 4997 invoked from network); 10 Jun 2010 23:02:55 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 10 Jun 2010 23:02:55 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 10 Jun 2010 16:02:55 -0700 From: Eran Hammer-Lahav To: David Recordon , Torsten Lodderstedt Date: Thu, 10 Jun 2010 16:02:50 -0700 Thread-Topic: [OAUTH-WG] proposal: multiple access tokens from a single authorization flow Thread-Index: AcsItiyeaHg+nMUNRo2sqKvwEZbRPAAOpMlQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF7473@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4BFAA6AB.8040809@lodderstedt.net> <4BFC3142.6010506@lodderstedt.net> <4BFC371A.5040109@lodderstedt.net> <4C07F407.4050305@lodderstedt.net> <1275663845.7068.94.camel@localhost.localdomain> <4C09732B.5040800@lodderstedt.net> <4C0F6A9C.2060607@lodderstedt.net> <4C1108C4.9040501@lodderstedt.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 \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] proposal: multiple access tokens from a single authorization flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 23:02:55 -0000 I strongly believe that it should be first presented as an I-D. This is tru= e in general for most proposed changes of this size. It is hard to tell how= big of an impact a change like this will have without some actual text. On= ce proposed, the WG can decide if this is of interest as a WG item. If it i= s, we discuss the technical details. Then, we can have a chat about editori= al work and how to best fit it within the OAuth specifications framework. Hope this helps. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of David Recordon > Sent: Thursday, June 10, 2010 8:54 AM > To: Torsten Lodderstedt > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] proposal: multiple access tokens from a single > authorization flow >=20 > I strongly believe that it should be an extension. Even optional response > parameters increase the complexity for client developers and this in > particular affects the data model used to store access tokens. >=20 > --David >=20 >=20 > On Thu, Jun 10, 2010 at 8:46 AM, Torsten Lodderstedt > wrote: > > no one in the WG having an opinion on this topic? > > > > Am 09.06.2010 12:19, schrieb Torsten Lodderstedt: > >> > >> Hi all, > >> > >> I would like to see support in OAuth2 for the authorization of > >> arbitrary scopes in a single authorization flow for all kinds of > >> deployments. In some deployments this may require to issue multiple > access tokens at once. > >> > >> Therefore, I would like to propose the following addition to section > >> 2.3.2.1. (Access Token Response): > >> > >> Add an optional parameter "additional_access_tokens". > >> > >> =A0 additional_access_tokens > >> =A0 =A0 =A0 =A0 OPTIONAL. =A0Array of access tokens issued by the auth= orization > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0server along with respective ex= piration and scope. > >> Used > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if the authorization server dec= ides to issue more > >> than > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0one access token. The scopes of= the different > >> tokens may > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0not overlap. > >> > >> Example: > >> =A0 =A0 HTTP/1.1 200 OK > >> =A0 =A0 Content-Type: application/json > >> =A0 =A0 Cache-Control: no-store > >> > >> =A0 =A0 { > >> =A0 =A0 =A0 "access_token":"SlAV32hkKG", > >> =A0 =A0 =A0 "expires_in":3600, > >> =A0 =A0 =A0 "refresh_token":"8xLOxBtZp8", > >> =A0 =A0 =A0 scope:"https://imap.example.com", > >> =A0 =A0 =A0 additional_access_tokens:[ > >> =A0 =A0 =A0 =A0{ > >> =A0 =A0 =A0 =A0 =A0"access_token":"SlAV32hkKG2", > >> =A0 =A0 =A0 =A0 =A0"expires_in":3600, > >> =A0 =A0 =A0 =A0 =A0scope:"https://sip.example.com" > >> =A0 =A0 =A0 =A0}, > >> =A0 =A0 =A0 =A0{ > >> =A0 =A0 =A0 =A0 =A0"access_token":"SlAV32hkKG3", > >> =A0 =A0 =A0 =A0 =A0"expires_in":3600, > >> =A0 =A0 =A0 =A0 =A0scope:"https://contacts.example.com/read" > >> =A0 =A0 =A0 =A0}, > >> =A0 =A0 =A0 =A0{ > >> =A0 =A0 =A0 =A0 =A0"access_token":"SlAV32hkKG4", > >> =A0 =A0 =A0 =A0 =A0"expires_in":3600, > >> =A0 =A0 =A0 =A0 =A0scope:"https://webdav.example.com/read" > >> =A0 =A0 =A0 =A0} > >> =A0 =A0 =A0 ] > >> =A0 =A0 } > >> > >> --- Some motivation --- > >> > >> I think we will see more and more clients integrating different > >> end-user services (like mashups). Based on the current draft, some > >> OAuth authorization servers may not be able to support such clients > >> with an acceptable user experiences. > >> > >> Suppose a communication client integrating the following services: > >> - e-Mail via IMAP > >> - Voice over IP using the SIP protocol > >> - Contacts via SyncML over HTTP > >> - Webstorage access (e.g. for e-Mail attachments) using HTTP/WebDAV > >> > >> For a particular end-user, the client may discover that all of the > >> end-user's services rely on the same OAuth2-based authorization > >> server because they are provided by the same organization (e.g. an isp= or > a telco). > >> The services are distinguished at the authorization server by > >> different scopes (probably including permissions as well), e.g. : > >> > >> imap - https://imap.example.com > >> sip - =A0https://sip.example.com > >> contacts - https://contacts.example.com/read webstorage - > >> https://contacts.example.com/read > >> > >> Some providers may want to issue different service-specific tokens in > >> such a setup (Deutsche Telekom does it already), for the following > reasons: > >> > >> 1) Security > >> > >> =A0a) minimize impact of token abuse - tokens may leak in many ways, e= .g. > >> through log files, proxies or HTTP referer. If a provider just uses a > >> single token for all services, the impact of token leakage is much > >> higher. For example, if a token gets exposed by the _contacts_ > >> service via HTTP referer, an adversary may place long-distance calls > >> using that token on the _VoIP_ service at the expense of the > >> end-user. This threat holds for all kinds of tokens (handles and self- > contained tokens). > >> > >> =A0b) use a shared secret between authz server and a single service > >> only - a major critism from the operational security perspective to > >> OAuth 1.0a was the need to spread client secrets to resource servers. > >> Using the same shared secret to sign/encrypt tokens for different > >> services is a comparable problem. This aspect is relevant for self- > contained tokens, only. > >> > >> 2) Privacy - the provider wants to restrict access of services to > >> personal data to the data a particular service is allowed and > >> authorized to see. This is good style (IMHO), it might also be > >> required by law (e.g. German Federal Data Protection Act). This > >> aspect is relevant for self-contained tokens, only. > >> > >> 3) Bandwith efficiency - putting only the data required by the > >> services into the token saves bandwith. This aspect is relevant for > >> self-contained tokens, only. > >> > >> In my opinion, most of these aspects are just a consequence of the > >> decoupling of authorization server and resource server(s) in OAuth2. > >> If a single authorization server is responsible for several resource > >> servers, it has to ensure privacy protection and prevention of token > >> abuse for all of its services. This should also include some > >> separation between services, no matter if one uses self-contained toke= ns > or handles. > >> > >> Without the change I proposed, the authorization server in the > >> example scenario would need to force the client to perform _four_ > >> subsequent authorization flows in order to obtain all required > >> tokens. Moreover, the client would need to manage four refresh tokens. > >> > >> I would kindly ask you to support my proposal. In my opinion, it > >> significantly improves the applicability of OAuth2 while the change > >> to the current draft is minimal. Moreover, deployments w/o the need > >> to issue multiple tokens are not affected at all. > >> > >> Any thoughts? > >> > >> 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 > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Thu Jun 10 16:18:13 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D80073A67E5 for ; Thu, 10 Jun 2010 16:18:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.178 X-Spam-Level: X-Spam-Status: No, score=-1.178 tagged_above=-999 required=5 tests=[AWL=-0.068, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3d8fylWx1ew for ; Thu, 10 Jun 2010 16:18:12 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 83ED33A67BD for ; Thu, 10 Jun 2010 16:18:12 -0700 (PDT) Received: (qmail 8896 invoked from network); 10 Jun 2010 23:18:14 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 10 Jun 2010 23:18:12 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 10 Jun 2010 16:18:12 -0700 From: Eran Hammer-Lahav To: David Recordon Date: Thu, 10 Jun 2010 16:18:06 -0700 Thread-Topic: [OAUTH-WG] A display parameter for user authorization requests Thread-Index: AcsIBtu+PgvGgweHROG2XyL3qYa6RQA7DxpA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF7476@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 WG Subject: Re: [OAUTH-WG] A display parameter for user authorization requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 23:18:13 -0000 Since these are all extensions to the end-user endpoint, I'd suggest we mov= e the 'immediate' parameter here as well. OPTIONAL. The parameter value must be set to true or false. If set to true, the authorization serve= r MUST NOT prompt the end-user to authenticate or approve access. Instead, the au= thorization server attempts to establish the end-user's identity via other mea= ns (e.g. browser cookies) and checks if the end-user has previously approved= an identical access request by the same client and if that access grant is stil= l active. If the authorization server does not support an immediate check or= if it is unable to establish the end-user's identity or approval status, it MU= ST deny the request without prompting the end-user. Defaults to false if omitted. EHL > -----Original Message----- > From: David Recordon [mailto:recordond@gmail.com] > Sent: Wednesday, June 09, 2010 12:06 PM > To: Eran Hammer-Lahav; Allen Tom; Breno de Medeiros; Luke Shepard > Cc: OAuth WG > Subject: Re: [OAUTH-WG] A display parameter for user authorization > requests >=20 > First draft of the UX Extension is at > http://github.com/daveman692/OAuth-2.0/raw/master/draft-recordon- > oauth-v2-ux-00.txt. >=20 > Eran, I'm more than happy to have you take over as editor. >=20 > I included Allen and Breno as authors since I followed Allen's suggestion= and > adopted the language preference parameter from the OpenID extension. I > also included Luke as an author since he wrote the first pass of a displa= y > parameter. That said, none of them have seen this draft yet. >=20 > --David >=20 >=20 > On Tue, Apr 13, 2010 at 12:36 PM, Allen Tom wrote: > > At least with regards to the language preference, how about if we just > > copy the openid.ui.lang parameter from the OpenID UI Extension? > > > > http://svn.openid.net/repos/specifications/user_interface/1.0/trunk/op > > enid-user-interface-extension-1_0.html#anchor3 > > > > In flows in which the client redirects the user's web browser to > > authorize access, the client MAY send the Authorization Server a hint > > regarding the user's preferred language by sending the following > parameter: > > > > =A0=A0=A0=A0lang > > =A0=A0=A0=A0=A0=A0=A0=A0The user's preferred languages as a [BCP 47] la= nguage priority > > list, represented as a comma-separated list of BCP 47 basic language > > ranges in decending priority order. For instance, the value "fr-CA,fr-F= R,en- > CA" > > represents the preference for French spoken in Canada, French spoken > > in France, followed by English spoken in Canada. > > > > The language preference hint SHOULD take precedence over the > > Accept-Language HTTP header sent by the user's browser, and SHOULD > > take precedence over the language preference inferred by the user's IP > Address. > > > > BCP 47: =A0http://tools.ietf.org/html/bcp47 > > > > Allen > > > > > > On 4/12/10 1:32 PM, "Eran Hammer-Lahav" > wrote: > > > > Between language preferences, display configuration, and immediate > > check, I think it might be worth to move that work to another draft. > > Timeline-wise, this has the potential of slowing us down. I also fear > > getting what is now a pretty simple spec much more complicated. > > > > Anyone cares to try a first draft or outline? I can do the editorial > > work if needed, but someone needs to write something first. > > > > EHL > > > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > From recordond@gmail.com Thu Jun 10 17:32:37 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6AC53A684E for ; Thu, 10 Jun 2010 17:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.893 X-Spam-Level: X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[AWL=0.706, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5iAiIRcCLt+r for ; Thu, 10 Jun 2010 17:32:36 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 382FF3A681E for ; Thu, 10 Jun 2010 17:32:36 -0700 (PDT) Received: by iwn42 with SMTP id 42so536248iwn.31 for ; Thu, 10 Jun 2010 17:32:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=XYVmoK+LeTZpvXE7pVbP7zapdhjTk9GvedxNKD5i1o8=; b=k8QD8O+y7xE1qC/IxfuPg4TJMuO30YEcIi100FHA+WbjTC/1Zz2k9EOWvf1V/ozlGA OF+Ond/xvkNJSgEhUWGga7jbDm+II6QC/T1AjHpvAfaU5TlRrTHHFR8AoYMchySdAw6F Pb0nBtTkJ9d8oWKTPE3CtcT1KfGghZqsd3kQo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=TVVMSrVV3I6KHioTTMfY2QtJH4h3WSPi1b8PQ9f2X3gPJd3jP4zwiB4OAa0IL7IQtL QlJp6rxWlAtbB62b5fZ0JwQ4IdPfrQtWxZC2I1LB2xbnw/9T4LcrzAyl3hjWmXFl+YKu mtcYytEQnhjTEn4DCDWHCMsYpm4GjDlAu2rag= MIME-Version: 1.0 Received: by 10.231.148.200 with SMTP id q8mr983659ibv.10.1276216355852; Thu, 10 Jun 2010 17:32:35 -0700 (PDT) Received: by 10.231.192.4 with HTTP; Thu, 10 Jun 2010 17:32:35 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF7476@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF7476@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 10 Jun 2010 17:32:35 -0700 Message-ID: From: David Recordon To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: OAuth WG Subject: Re: [OAUTH-WG] A display parameter for user authorization requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 00:32:38 -0000 +1 for moving immediate here as well. On Thu, Jun 10, 2010 at 4:18 PM, Eran Hammer-Lahav wr= ote: > Since these are all extensions to the end-user endpoint, I'd suggest we m= ove the 'immediate' parameter here as well. > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0OPTIONAL. The parameter value must be set = to true or > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0false. If se= t to > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0true, the au= thorization server MUST NOT prompt the > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0end-user to authenticate or approve access= . Instead, the authorization server > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0attempts to establish the end-user's ident= ity via other means (e.g. browser > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0cookies) and checks if the end-user has pr= eviously approved an identical access > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0request by the same client and if that acc= ess grant is still active. If the > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0authorization server does not support an i= mmediate check or if it is unable to > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0establish the end-user's identity or appro= val status, it MUST deny the request > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0without prompting the end-user. Defaults t= o false if > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0omitted. > =A0 =A0 =A0 =A0 =A0 =A0 =A0 > EHL > >> -----Original Message----- >> From: David Recordon [mailto:recordond@gmail.com] >> Sent: Wednesday, June 09, 2010 12:06 PM >> To: Eran Hammer-Lahav; Allen Tom; Breno de Medeiros; Luke Shepard >> Cc: OAuth WG >> Subject: Re: [OAUTH-WG] A display parameter for user authorization >> requests >> >> First draft of the UX Extension is at >> http://github.com/daveman692/OAuth-2.0/raw/master/draft-recordon- >> oauth-v2-ux-00.txt. >> >> Eran, I'm more than happy to have you take over as editor. >> >> I included Allen and Breno as authors since I followed Allen's suggestio= n and >> adopted the language preference parameter from the OpenID extension. I >> also included Luke as an author since he wrote the first pass of a displ= ay >> parameter. That said, none of them have seen this draft yet. >> >> --David >> >> >> On Tue, Apr 13, 2010 at 12:36 PM, Allen Tom wrote: >> > At least with regards to the language preference, how about if we just >> > copy the openid.ui.lang parameter from the OpenID UI Extension? >> > >> > http://svn.openid.net/repos/specifications/user_interface/1.0/trunk/op >> > enid-user-interface-extension-1_0.html#anchor3 >> > >> > In flows in which the client redirects the user's web browser to >> > authorize access, the client MAY send the Authorization Server a hint >> > regarding the user's preferred language by sending the following >> parameter: >> > >> > =A0=A0=A0=A0lang >> > =A0=A0=A0=A0=A0=A0=A0=A0The user's preferred languages as a [BCP 47] l= anguage priority >> > list, represented as a comma-separated list of BCP 47 basic language >> > ranges in decending priority order. For instance, the value "fr-CA,fr-= FR,en- >> CA" >> > represents the preference for French spoken in Canada, French spoken >> > in France, followed by English spoken in Canada. >> > >> > The language preference hint SHOULD take precedence over the >> > Accept-Language HTTP header sent by the user's browser, and SHOULD >> > take precedence over the language preference inferred by the user's IP >> Address. >> > >> > BCP 47: =A0http://tools.ietf.org/html/bcp47 >> > >> > Allen >> > >> > >> > On 4/12/10 1:32 PM, "Eran Hammer-Lahav" >> wrote: >> > >> > Between language preferences, display configuration, and immediate >> > check, I think it might be worth to move that work to another draft. >> > Timeline-wise, this has the potential of slowing us down. I also fear >> > getting what is now a pretty simple spec much more complicated. >> > >> > Anyone cares to try a first draft or outline? I can do the editorial >> > work if needed, but someone needs to write something first. >> > >> > EHL >> > >> > >> > >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth >> > >> > > From James.H.Manger@team.telstra.com Thu Jun 10 17:46:22 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39BAA3A6893 for ; Thu, 10 Jun 2010 17:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.521 X-Spam-Level: X-Spam-Status: No, score=0.521 tagged_above=-999 required=5 tests=[AWL=1.422, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LZddYeO+Mc75 for ; Thu, 10 Jun 2010 17:46:21 -0700 (PDT) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by core3.amsl.com (Postfix) with ESMTP id 8BFF73A6890 for ; Thu, 10 Jun 2010 17:46:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,400,1272808800"; d="scan'208";a="4747821" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipocvi.tcif.telstra.com.au with ESMTP; 11 Jun 2010 10:46:19 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6009"; a="3090652" Received: from wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) by ipcdvi.tcif.telstra.com.au with ESMTP; 11 Jun 2010 10:46:21 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) with mapi; Fri, 11 Jun 2010 10:46:20 +1000 From: "Manger, James H" To: "OAuth WG (oauth@ietf.org)" Date: Fri, 11 Jun 2010 10:46:20 +1000 Thread-Topic: Proposal for single JSON response format Thread-Index: AcsI25LiV8WWr/WxSnmFMcXJetYFegAI9j9g Message-ID: <255B9BB34FB7D647A506DC292726F6E11263FEC9FC@WSMSG3153V.srv.dir.telstra.com> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF73EF@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF73EF@P3PW5EX1MB01.EX1.SECURESERVER.NET> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Proposal for single JSON response format X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 00:46:22 -0000 KzENCg0KLS0NCkphbWVzIE1hbmdlcg0KDQotLS0tLS0tLS0tDQpGcm9tOiBvYXV0aC1ib3VuY2Vz QGlldGYub3JnIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEVy YW4gSGFtbWVyLUxhaGF2DQpTZW50OiBGcmlkYXksIDExIEp1bmUgMjAxMCA2OjI5IEFNDQpUbzog T0F1dGggV0cgKG9hdXRoQGlldGYub3JnKQ0KU3ViamVjdDogW09BVVRILVdHXSBQcm9wb3NhbCBm b3Igc2luZ2xlIEpTT04gcmVzcG9uc2UgZm9ybWF0DQoNCi0gU3VwcG9ydCBhIHNpbmdsZSByZXNw b25zZSBmb3JtYXQgKGluY2x1ZGluZyBpbiB0aGUgdXNlci1hZ2VudCBmcmFnbWVudCkgdXNpbmcg SlNPTi4NCg== From lshepard@facebook.com Thu Jun 10 17:52:31 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E96EA3A684E for ; Thu, 10 Jun 2010 17:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.196 X-Spam-Level: X-Spam-Status: No, score=-2.196 tagged_above=-999 required=5 tests=[AWL=1.069, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lu5kSUTdLcPn for ; Thu, 10 Jun 2010 17:52:31 -0700 (PDT) Received: from mailout-sf2p.facebook.com (mailout-snc1.facebook.com [69.63.179.25]) by core3.amsl.com (Postfix) with ESMTP id 2D4923A680D for ; Thu, 10 Jun 2010 17:52:31 -0700 (PDT) Received: from mail.thefacebook.com ([192.168.18.198]) by pp02.snc1.tfbnw.net (8.14.3/8.14.3) with ESMTP id o5B0pnhY004549 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 10 Jun 2010 17:51:49 -0700 Received: from sc-hub01.TheFacebook.com (192.168.18.104) by sc-hub03.TheFacebook.com (192.168.18.198) with Microsoft SMTP Server (TLS) id 14.0.694.1; Thu, 10 Jun 2010 17:52:29 -0700 Received: from SC-MBXC1.TheFacebook.com ([192.168.18.100]) by sc-hub01.TheFacebook.com ([192.168.18.104]) with mapi; Thu, 10 Jun 2010 17:50:37 -0700 From: Luke Shepard To: "Manger, James H" Date: Thu, 10 Jun 2010 17:50:35 -0700 Thread-Topic: [OAUTH-WG] Proposal for single JSON response format Thread-Index: AcsJABuNJQQjvdy8Sz69O8Tp96N/bA== Message-ID: <4A5E1C55-D589-4F25-9D45-E640BA7C833F@facebook.com> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF73EF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E11263FEC9FC@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11263FEC9FC@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-06-10_04:2010-02-06, 2010-06-10, 2010-06-10 signatures=0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Proposal for single JSON response format X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 00:52:32 -0000 +1 On Jun 10, 2010, at 5:46 PM, Manger, James H wrote: > +1 >=20 > -- > James Manger >=20 > ---------- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of= Eran Hammer-Lahav > Sent: Friday, 11 June 2010 6:29 AM > To: OAuth WG (oauth@ietf.org) > Subject: [OAUTH-WG] Proposal for single JSON response format >=20 > - Support a single response format (including in the user-agent fragment)= using JSON. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From sakimura@gmail.com Thu Jun 10 18:25:52 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE35F3A687D for ; Thu, 10 Jun 2010 18:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nhwB-3OrtdXH for ; Thu, 10 Jun 2010 18:25:49 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 9878C3A6893 for ; Thu, 10 Jun 2010 18:25:49 -0700 (PDT) Received: by pvg2 with SMTP id 2so196376pvg.31 for ; Thu, 10 Jun 2010 18:25:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:x-mailer :mime-version:subject:date:cc; bh=UDDPRuFjKyakeElr3GC3ZBjCwfINWf7YFihyGlx6LJc=; b=DB0KRDOgMuaa9o6/wCGC6f+pxA1qUCKWnHsT8PKN3iJlZDoPf8almx/MSw+f2mJ6Oa eJLS4Zw/Hf8jbLU9QrK6tV8bxxilAQHBJ7y1LHL42TvMcJ+NH9ygQ5qj3sDpEFJWFIWs tSthaYjngi57gb9jPpHT8D4xt2rvoJfM+VlgA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:x-mailer:mime-version:subject:date:cc; b=dOpJwVBJJbVlVG1nN2fpNGAsWeFKK4B5g/kjCY2pnYcKEZGkH5PZB3PFmStEnPGwmq OOX6m3ckgLvUKTTkgQZvv9i1Lslyg2U+fo9uO0nWTDAgWt40K4VH/qMxjPSSHC6V4sM2 nwot3d14cswMIvYEuyT9IHt71UnCGRbmCfuVc= Received: by 10.114.187.37 with SMTP id k37mr855902waf.37.1276219549064; Thu, 10 Jun 2010 18:25:49 -0700 (PDT) Received: from [61.127.102.115] (u-61127102115.hotspot.ne.jp [61.127.102.115]) by mx.google.com with ESMTPS id c22sm6678092wam.18.2010.06.10.18.25.44 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 10 Jun 2010 18:25:47 -0700 (PDT) References: <255B9BB34FB7D647A506DC292726F6E11262FEE7D8@WSMSG3153V.srv.dir.telstra.com> Message-Id: <10AFC0D1-847A-4725-BB8B-D2452B0CB170@gmail.com> From: Nat To: Nat Sakimura In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-5--587862747 Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7E18) Mime-Version: 1.0 (iPhone Mail 7E18) Date: Fri, 11 Jun 2010 10:26:03 +0900 Cc: oauth Subject: Re: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 01:25:52 -0000 --Apple-Mail-5--587862747 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit One more good thing: 5) We can move almost all the params into JSON. =nat @ Tokyo via iPhone On 2010/06/10, at 16:27, Nat Sakimura wrote: > > > On Thu, Jun 10, 2010 at 8:27 AM, Dirk Balfanz > wrote: > > > On Wed, Jun 9, 2010 at 4:05 PM, John Panzer > wrote: > So the thinking is that this is just a generic "include" or "one > level of indirection" feature that is orthogonal to other flows? > > FWIW, I really like that notion. It's also very easy to describe > and understand conceptually. > > +1 > > How does the Client decide to use this new level of indirection? > When the User Agent looks like it wouldn't like long URLs? > > There are a few cases that I am aware of: > > 1) When the User Agent looks like it would not like long URLs. > > It is entirely possible that some extension makes a long URL. > For example, the client might want to send a public key with > the request. > > 2) When the server wants the request non-repudiation > > The server might want the request to be non-repudiable. > It is possible to sign the request dynamically, but a simpler way of > doing it is to > make a signed request file (perhaps in Magic Signature format) and > put it on the client. It can just be done by a client utility or > something, so that the private key does not even have to reside on > the server nor the client needs to program anything. > > 3) When the server wants the requests to be cacheable > > As I have proposed, if the request_url comes with sha256 hash of the > file, > the server knows if the file has changed without fetching it, so it > does not have to re-fetch a same file, which is a win as well. > > 4) When the client wants to simplify the implementation without > compromising the security > > If the request parameters go through the Browser, it may be tampered > at the browser even if TLS was used. This implies we need to have > signature on the request as well. However, if https request_url was > used, it is not going to be tampered, thus we now do not have to > sign the request. This simplifies the implementation. > > > > Dirk. > > -- > John Panzer / Google > jpanzer@google.com / abstractioneer.org / @jpanzer > > > > On Mon, Jun 7, 2010 at 7:53 PM, Nat Sakimura > wrote: > I fully agree on it. > > Instead of doing as a flow, defining request_url as one of the core > variable would be better. > The question then is, whether this community accepts the idea. > > > On Mon, Jun 7, 2010 at 10:51 PM, Manger, James H > wrote: > Nat, > > > On the other hand, you are starting to think of it as a generic > "include" mechanism, are you? > > Yes. That feels like the simplest mental model for this > functionality, and the simplest way to specify it. > > -- > James Manger > > > > -- > Nat Sakimura (=nat) > http://www.sakimura.org/en/ > http://twitter.com/_nat_en > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > > -- > Nat Sakimura (=nat) > http://www.sakimura.org/en/ > http://twitter.com/_nat_en --Apple-Mail-5--587862747 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
One more good thing: 

5) We can move almost all the params into JSON. 

=nat @ Tokyo via iPhone

On 2010/06/10, at 16:27, Nat Sakimura <sakimura@gmail.com> wrote:



On Thu, Jun 10, 2010 at 8:27 AM, Dirk Balfanz <balfanz@google.com> wrote:


On Wed, Jun 9, 2010 at 4:05 PM, John Panzer <jpanzer@google.com> wrote:
So the thinking is that this is just a generic "include" or "one level of indirection" feature that is orthogonal to other flows?

FWIW, I really like that notion.  It's also very easy to describe and understand conceptually.

+1

How does the Client decide to use this new level of indirection? When the User Agent looks like it wouldn't like long URLs?

There are a few cases that I am aware of: 

1) When the User Agent looks like  it would not like long URLs. 

It is entirely possible that some extension makes a long URL. 
For example, the client might want to send a public key with 
the request. 

2) When the server wants the request non-repudiation  

The server might want the request to be non-repudiable. 
It is possible to sign the request dynamically, but a simpler way of doing it is to 
make a signed request file (perhaps in Magic Signature format) and put it on the client. It can just be done by a client utility or something, so that the private key does not even have to reside on the server nor the client needs to program anything. 

3) When the server wants the requests to be cacheable

As I have proposed, if the request_url comes with sha256 hash of the file, 
the server knows if the file has changed without fetching it, so it does not have to re-fetch a same file, which is a win as well. 

4) When the client wants to simplify the implementation without compromising the security

If the request parameters go through the Browser, it may be tampered at the browser even if TLS was used. This implies we need to have signature on the request as well. However, if https request_url was used, it is not going to be tampered, thus we now do not have to sign the request. This simplifies the implementation. 

 

Dirk.
 
--
John Panzer / Google
jpanzer@google.com / abstractioneer.org / @jpanzer



On Mon, Jun 7, 2010 at 7:53 PM, Nat Sakimura <sakimura@gmail.com> wrote:
I fully agree on it. 

Instead of doing as a flow, defining request_url as one of the core variable would be better. 
The question then is, whether this community accepts the idea. 


On Mon, Jun 7, 2010 at 10:51 PM, Manger, James H <James.H.Manger@team.telstra.com> wrote:
Nat,

> On the other hand, you are starting to think of it as a generic "include" mechanism, are you?

Yes. That feels like the simplest mental model for this functionality, and the simplest way to specify it.

--
James Manger




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



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





--
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
--Apple-Mail-5--587862747-- From lshepard@facebook.com Thu Jun 10 20:12:16 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79F1F3A685B for ; Thu, 10 Jun 2010 20:12:16 -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.712, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZKjgoc7zVd3 for ; Thu, 10 Jun 2010 20:12:10 -0700 (PDT) Received: from mailout-sf2p.facebook.com (mailout-snc1.facebook.com [69.63.179.25]) by core3.amsl.com (Postfix) with ESMTP id C8BE53A681F for ; Thu, 10 Jun 2010 20:12:09 -0700 (PDT) Received: from mail.thefacebook.com ([192.168.18.212]) by pp02.snc1.tfbnw.net (8.14.3/8.14.3) with ESMTP id o5B3BTmN018600 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 10 Jun 2010 20:11:29 -0700 Received: from sc-hub02.TheFacebook.com (192.168.18.105) by sc-hub04.TheFacebook.com (192.168.18.212) with Microsoft SMTP Server (TLS) id 14.0.694.1; Thu, 10 Jun 2010 20:10:25 -0700 Received: from SC-MBXC1.TheFacebook.com ([192.168.18.100]) by sc-hub02.TheFacebook.com ([192.168.18.105]) with mapi; Thu, 10 Jun 2010 20:06:08 -0700 From: Luke Shepard To: Nat Date: Thu, 10 Jun 2010 20:06:06 -0700 Thread-Topic: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow Thread-Index: AcsJEwmZLRKrN1TvS9u2zSF3E96v+Q== Message-ID: <314B8197-4B36-4FAF-B0C8-8CDC49FC8BAC@facebook.com> References: <255B9BB34FB7D647A506DC292726F6E11262FEE7D8@WSMSG3153V.srv.dir.telstra.com> <10AFC0D1-847A-4725-BB8B-D2452B0CB170@gmail.com> In-Reply-To: <10AFC0D1-847A-4725-BB8B-D2452B0CB170@gmail.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_314B81974B364FAFB0C88CDC49FC8BACfacebookcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-06-10_04:2010-02-06, 2010-06-10, 2010-06-10 signatures=0 Cc: oauth Subject: Re: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 03:12:16 -0000 --_000_314B81974B364FAFB0C88CDC49FC8BACfacebookcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I like this idea. Hadn't thought about the security benefits, thanks for en= umerating Nat. On Jun 10, 2010, at 6:26 PM, Nat wrote: One more good thing: 5) We can move almost all the params into JSON. =3Dnat @ Tokyo via iPhone On 2010/06/10, at 16:27, Nat Sakimura > wrote: On Thu, Jun 10, 2010 at 8:27 AM, Dirk Balfanz <b= alfanz@google.com> wrote: On Wed, Jun 9, 2010 at 4:05 PM, John Panzer <jpa= nzer@google.com> wrote: So the thinking is that this is just a generic "include" or "one level of i= ndirection" feature that is orthogonal to other flows? FWIW, I really like that notion. It's also very easy to describe and under= stand conceptually. +1 How does the Client decide to use this new level of indirection? When the U= ser Agent looks like it wouldn't like long URLs? There are a few cases that I am aware of: 1) When the User Agent looks like it would not like long URLs. It is entirely possible that some extension makes a long URL. For example, the client might want to send a public key with the request. 2) When the server wants the request non-repudiation The server might want the request to be non-repudiable. It is possible to sign the request dynamically, but a simpler way of doing = it is to make a signed request file (perhaps in Magic Signature format) and put it o= n the client. It can just be done by a client utility or something, so that= the private key does not even have to reside on the server nor the client = needs to program anything. 3) When the server wants the requests to be cacheable As I have proposed, if the request_url comes with sha256 hash of the file, the server knows if the file has changed without fetching it, so it does no= t have to re-fetch a same file, which is a win as well. 4) When the client wants to simplify the implementation without compromisin= g the security If the request parameters go through the Browser, it may be tampered at the= browser even if TLS was used. This implies we need to have signature on th= e request as well. However, if https request_url was used, it is not going = to be tampered, thus we now do not have to sign the request. This simplifie= s the implementation. Dirk. -- John Panzer / Google jpanzer@google.com / = abstractioneer.org / @jpanzer On Mon, Jun 7, 2010 at 7:53 PM, Nat Sakimura <sa= kimura@gmail.com> wrote: I fully agree on it. Instead of doing as a flow, defining request_url as one of the core variabl= e would be better. The question then is, whether this community accepts the idea. On Mon, Jun 7, 2010 at 10:51 PM, Manger, James H <James.H.Manger@team.telstra.com> wrote: Nat, > On the other hand, you are starting to think of it as a generic "include"= mechanism, are you? Yes. That feels like the simplest mental model for this functionality, and = the simplest way to specify it. -- James Manger -- Nat Sakimura (=3Dnat) http://www.sakimura.org/en/ http://twitter.com/_nat_en _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/l= istinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/l= istinfo/oauth -- Nat Sakimura (=3Dnat) http://www.sakimura.org/en/ http://twitter.com/_nat_en --_000_314B81974B364FAFB0C88CDC49FC8BACfacebookcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I like this idea. Hadn't t= hought about the security benefits, thanks for enumerating Nat.

On Jun 10, 2010, at 6:26 PM, Nat wrote:

On= e more good thing: 

5) We can move almost all= the params into JSON. 

=3Dnat @ Tokyo via iPhone
On 2010/06/10, at 16:27, Nat Sakimura <sakimura@gmail.com> wrote:



On Thu, Jun 10, 2010= at 8:27 AM, Dirk Balfanz <balfanz@google.com= > wrote:


On Wed, Jun 9, 2010 at= 4:05 PM, John Panzer <jpanzer@= google.com> wrote:
So the thinking is that this is just a generic "include" or "one level of i= ndirection" feature that is orthogonal to other flows?

F= WIW, I really like that notion.  It's also very easy to describe and u= nderstand conceptually.

+1

How does the Client decide to u= se this new level of indirection? When the User Agent looks like it wouldn'= t like long URLs?

There are a few cases that I am aware of: 

1)= When the User Agent looks like  it would not like long URLs. 

It is entirely possible that some extension makes a = long URL. 
For example, the client might want to send a public key with 
the request. 

2) When the server wants= the request non-repudiation  

The server= might want the request to be non-repudiable. 
It is possible to sign the request dynamically, but a simpler way of d= oing it is to 
make a signed request file (perhaps in Magic = Signature format) and put it on the client. It can just be done by a c= lient utility or something, so that the private key does not even have to r= eside on the server nor the client needs to program anything. 

3) When the server wants the requests to be cacheable

As I have proposed, if the request_url comes with s= ha256 hash of the file, 
the server knows if the file has ch= anged without fetching it, so it does not have to re-fetch a same file, whi= ch is a win as well. 

4) When the client wants to simplify the implementation= without compromising the security

If the request = parameters go through the Browser, it may be tampered at the browser even i= f TLS was used. This implies we need to have signature on the request as we= ll. However, if https request_url was used, it is not going to be tampered,= thus we now do not have to sign the request. This simplifies the implement= ation. 

 

Dirk.
 
--
John Panzer / Google
jpanz= er@google.com / abstractioneer.org / @= jpanzer



On Mon, Jun = 7, 2010 at 7:53 PM, Nat Sakimura <sakimura@gmail.com> wrote:
<= /div>
I fully agree on it. 

Instead of doing as a flow, d= efining request_url as one of the core variable would be better. 
The question then is, whether this community accepts the idea. <= div>

On Mon, Jun 7, 2010 at 10:51 PM, Manger, James H <James.H.Manger@team.telstra.co= m> wrote:
Nat,

> On the other hand, you are starting to think of it as a generic "inclu= de" mechanism, are you?

Yes. That feels like the simplest mental model for this functionality= , and the simplest way to specify it.

--
James Manger




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



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





--
Nat Sakimura (=3Dnat)http://www.sakimura.org/en/
http://twitter.com/_na= t_en
<ATT00001..txt>
= --_000_314B81974B364FAFB0C88CDC49FC8BACfacebookcom_-- From andrewarnott@gmail.com Thu Jun 10 20:20:00 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C13CF28C0EA for ; Thu, 10 Jun 2010 20:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.258 X-Spam-Level: X-Spam-Status: No, score=-0.258 tagged_above=-999 required=5 tests=[AWL=-0.260, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-5NOmpKsKbf for ; Thu, 10 Jun 2010 20:19:59 -0700 (PDT) Received: from mail-yw0-f179.google.com (mail-yw0-f179.google.com [209.85.211.179]) by core3.amsl.com (Postfix) with ESMTP id C0C513A681F for ; Thu, 10 Jun 2010 20:19:58 -0700 (PDT) Received: by ywh9 with SMTP id 9so813037ywh.17 for ; Thu, 10 Jun 2010 20:19:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=Yy+29gQz6v80ABn6MH1EUIqDoTkRiZC+lGqG1zWxVoQ=; b=HtFwAULCEiv59L3Ksojq5YLtL6xZYPa3hL8IKaEjpGwjFq+4DljoBc5S9R2vp46JqN GH4hNcD0UHFWyxj82w5Fm34WBcnYtnCowr+AOvLKOtyrxooFLFHZhPcuR5P8ovEeXVCx og0E6mrfNI5Cr1GrpWAG9dG7H2uIaRhdBD5C0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=vRP/Zp8Qr5qu+G8eTm4GinEFX3XJqrWPHdcRAFaDGugEl7yYFTO7yG2v51G5zBLDzC ex/b7tFEvxlrMiinyLpwMn9DgtRpirztwXtkeMEmqGc+2LHTpPgDHZeJJPgrivIMQREy /gskcKSSEoXGo9pN3VC7upfe8XFIuXLfogj24= MIME-Version: 1.0 Received: by 10.150.168.18 with SMTP id q18mr2357793ybe.326.1276226397175; Thu, 10 Jun 2010 20:19:57 -0700 (PDT) Received: by 10.151.26.19 with HTTP; Thu, 10 Jun 2010 20:19:56 -0700 (PDT) In-Reply-To: References: Date: Thu, 10 Jun 2010 20:19:56 -0700 Message-ID: From: Andrew Arnott To: Thomas Hardjono Content-Type: multipart/alternative; boundary=000e0cd5cf580e81d50488b89d66 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] User-agent flow and pre-registered redirect_uri X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 03:20:00 -0000 --000e0cd5cf580e81d50488b89d66 Content-Type: text/plain; charset=ISO-8859-1 Hi Thomas, Some responses inline... On Thu, Jun 10, 2010 at 1:27 PM, Thomas Hardjono wrote: > > > The issue_date enables to scenarios: expiring tokens and token > revocation. > > > Here's how, for each scenario: > > > > > > Obviously to know if a token has expired you need to know when it was > > > issued. Or, you can forget the issue date and just store the > expiration > > > date in the token. I choose to go with an issue date (plus an optional > > > expected lifetime) because it gives more ability in the future to say > > "oops, > > > we had a security weakness in all tokens issued prior to [date], so > let's > > > consider all earlier tokens invalid." It's harder to say that when all > you > > > have are expiration dates because you don't know how old the token is. > > This > > > is just the way I chose to do it, but I know there are other ways. > > > > > I noticed that there is no nonce used in the token request portion > and the response from authorization server. > Did I miss it (ie. is it embedded somewhere?) > > I actually asked a similar question on another thread. The spec doesn't mention nonces at all. The only place they seem to make sense to me would be as an embedded part of the verification code, and that's only if the authz server wants to make sure they can only be exchanged for a refresh token once. In my implementation that's exactly what I did: there's a nonce embedded in the verification code. > > > > Now let's look at how you revoke issued tokens. One of the nice things > > > enabled by OAuth 2.0 is that the authorization server and resource > server > > > never have to store tokens if they are appropriate signed by the auth > > > server. > > Yes and no. It depends on (a) what is meant by "signing" the tokens and > (b) whether the Autz Server needs to log all actions for legal purposes > (eg. non-repudiation) Some service providers might want to archive all > tokens it accepted/validated together with the info on resources/objects > accessed by the clients. > Of course there are different requirements for different companies and governments, absolutely. I'm just speaking of technological requirements here. However, I suggest we choose our terms a bit more carefully here because what you're saying doesn't seem to strictly fit. An authorization server doesn't need non-repudiation because it never receives signed messages from anyone other than itself. An authz server may want to log that authorizations took place, and perhaps even what tokens were issued, but they can be in a log file perhaps without being in the database for programmatic lookup later as a normal course of business. I suspect when you said "service provider" you meant what the spec refers to as a "resource server", and certainly they can log whatever they want as well. But technologically speaking, the only member that has to actually store tokens for the flow to work is the client, and even that can be a very short-lived persistence depending on the user scenario. > > > > This is great because (among other things) clients with > > > little-to-no ability to persistently store tokens may ask for tokens > > > frequently, and that could bog down an auth server with storing all > those > > > issued tokens. But how can a user revoke a previously authorized token > if > > > no one but the client knows what the tokens are? (thought question) My > > > solution to this is that instead of thinking about revoking tokens, the > > user > > > revokes authorizations. The user goes through his account on the > > > authorization server and sees a list of clients and what they are > > authorized > > > to do. Note that this only requires the auth server to store this > > > authorization tuple -- not the actual issued tokens. If the user > clicks > > > "revoke" on one of these authorizations, that row is deleted in the > > > database. Issued tokens (both refresh and access tokens) have this > same > > > tuple encoded in them. > > > Now, when a refresh token is used to obtain a new short-lived access > token > > > (and you could do this on every access token use as well if you wanted) > the > > > token is of course signature-validated, but it is also checked that the > > > authorization tuple has a matching tuple in the auth server's > database. > If > > > it's missing, then that authorization has been revoked and the token is > > > thereby invalidated. > > > OK, so this is not live "revocation" with an immediate effect. Like > Kerberos, there is a gap of time between the client revoking the token > (service ticket) to the time when the refresh token (TGT) is exercised > next. > During this gap of time the token is still live and valid. > > The only way to get around this is to have the resource server contact the > authorization server every time (but that would defeat the purpose of > tokens/tickets). Even in X509, cert validation means the service provider > or > RP performs a live check against the OCSP servers. > I agree. And where that time window between a token's revocation and its actual loss of usefulness is something that has to be weighed by each application and it might mean checking each token as it comes in on each request. Although the spec separates the authz server and resource server roles, they commonly will be the same server, so this token check will simply be a database lookup. If the two roles are indeed on different servers a token validity check on every single request to the resource server *may* be too costly in bandwidth and performance, in which case there is actually a variety of ways to mitigate the problems, but that's beyond the scope of this thread by quite a bit (start a new one if you'd like). > > > > > So why the issue date? Because suppose the user has authorized a > client > > and > > > then that client's tokens are compromised (stolen computer perhaps). > The > > > user will of course revoke authorization for that client. The user > then > > > gets a new copy of that client (perhaps a new computer) and authorizes > it. > > > Whoops. Now all those invalidated tokens are valid again because the > > > authorization tuple exists. > > If the tokens (tickets) were issued to the client entity (principal) versus > to the human-user principal, then this will not be a problem. If the user > loses her client/laptop, then she need only revoke the tokens associated to > the client/laptop. > Sure, but that requires either that you store all issued tokens so you can revoke individual ones, or that you revoke all tokens issued to a client_id. But client apps can't keep secrets, so an installed app on a laptop will likely just have a client_id that is preset for the app (it doesn't have to be this way, but it may). That means that all installations of that app on all laptops will have the same client_id (and no secret), and therefore you can't revoke all tokens issued to an individual laptop because there's no distinction for it. Yes, I know this isn't the way all applications will be, but again it MAY be this way, so I'm planning for it. > > I think this is where there is room for OAuth 2.0 to innovate, such as to > introduce a special kind of token (human-token) that is independent from > client/laptop tokens. The human-token could even be stored in a secure > cloud service and be used for client-initiation or emergency purposes only. > Thus, whenever the human-user wants to move to a new laptop/client, the > human-token is pulled down from the cloud, used to authenticate to the auth > server, and then deleted (from the client) once the new client/laptop > becomes a known entity/principal in the ecosystem and has its own tokens. > Just a thought. > Bring on the innovation. :) --000e0cd5cf580e81d50488b89d66 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Thomas,

Some responses inline...

On Thu, Jun 10, 2010 at 1:27 PM, Thomas Hardjono <hardjono@mit.edu> wrote:
> > The issue_date enables to scenarios: expiring tokens and token
revocation.
> > Here's how, for each scenario:
> >
> > Obviously to know if a token has expired you need to know when it= was
> > issued.=A0 Or, you can forget the issue date and just store the e= xpiration
> > date in the token. I choose to go with an issue date (plus an opt= ional
> > expected lifetime) because it gives more ability in the future to= say
> "oops,
> > we had a security weakness in all tokens issued prior to [date], = so
let's
> > consider all earlier tokens invalid."=A0 It's harder to = say that when all
you
> > have are expiration dates because you don't know how old the = token is.
> This
> > is just the way I chose to do it, but I know there are other ways= .
> >

I noticed that there is no nonce used in the token request port= ion
and the response from authorization server.
Did I miss it (ie. is it embedded somewhere?)

I actually asked a similar qu= estion on another thread.=A0 The spec doesn't mention nonces at all.=A0= The only place they seem to make sense to me would be as an embedded part = of the verification code, and that's only if the authz server wants to = make sure they can only be exchanged for a refresh token once.=A0 In my imp= lementation that's exactly what I did: there's a nonce embedded in = the verification code.
=A0

> > Now let's look at how you revoke issued tokens.=A0 One of the= nice things
> > enabled by OAuth 2.0 is that the authorization server and resourc= e
server
> > never have to store tokens if they are appropriate signed by the = auth
> > server.=A0

Yes and no. =A0It depends on (a) what is meant by "signing"= the tokens and
(b) whether the Autz Server needs to log all actions for legal purposes
(eg. non-repudiation) Some service providers might want to archive all
tokens it accepted/validated together with the info on resources/objects accessed by the clients.

Of course there are diffe= rent requirements for different companies and governments, absolutely.=A0 I= 'm just speaking of technological requirements here.=A0 However, I sugg= est we choose our terms a bit more carefully here because what you're s= aying doesn't seem to strictly fit.=A0 An authorization server doesn= 9;t need non-repudiation because it never receives signed messages from any= one other than itself.=A0 An authz server may want to log that authorizatio= ns took place, and perhaps even what tokens were issued, but they can be in= a log file perhaps without being in the database for programmatic lookup l= ater as a normal course of business.=A0 I suspect when you said "servi= ce provider" you meant what the spec refers to as a "resource ser= ver", and certainly they can log whatever they want as well.=A0 But te= chnologically speaking, the only member that has to actually store tokens f= or the flow to work is the client, and even that can be a very short-lived = persistence depending on the user scenario.

> > This is great because (among other things) clients with
> > little-to-no ability to persistently store tokens may ask for tok= ens
> > frequently, and that could bog down an auth server with storing a= ll
those
> > issued tokens.=A0 But how can a user revoke a previously authoriz= ed token
if
> > no one but the client knows what the tokens are? (thought questio= n)=A0 My
> > solution to this is that instead of thinking about revoking token= s, the
> user
> > revokes authorizations.=A0 The user goes through his account on t= he
> > authorization server and sees a list of clients and what they are=
> authorized
> > to do.=A0 Note that this only requires the auth server to store t= his
> > authorization tuple -- not the actual issued tokens.=A0 If the us= er clicks
> > "revoke" on one of these authorizations, that row is de= leted in the
> > database.=A0 Issued tokens (both refresh and access tokens) have = this same
> > tuple encoded in them.
> > Now, when a refresh token is used to obtain a new short-lived acc= ess
token
> > (and you could do this on every access token use as well if you w= anted)
the
> > token is of course signature-validated, but it is also checked th= at the
> > authorization tuple has a matching tuple in the auth server's= database.=A0
If
> > it's missing, then that authorization has been revoked and th= e token is
> > thereby invalidated.


OK, so this is not live "revocation" with an immediat= e effect. Like
Kerberos, there is a gap of time between the client revoking the token
(service ticket) to the time when the refresh token (TGT) is exercised next= .
During this gap of time the token is still live and valid.

The only way to get around this is to have the resource server contact the<= br> authorization server every time (but that would defeat the purpose of
tokens/tickets). Even in X509, cert validation means the service provider o= r
RP performs a live check against the OCSP servers.
I agree.=A0 And where that time window between a token's revocation an= d its actual loss of usefulness is something that has to be weighed by each= application and it might mean checking each token as it comes in on each r= equest.=A0 Although the spec separates the authz server and resource server= roles, they commonly will be the same server, so this token check will sim= ply be a database lookup. If the two roles are indeed on different servers = a token validity check on every single request to the resource server ma= y be too costly in bandwidth and performance, in which case there is ac= tually a variety of ways to mitigate the problems, but that's beyond th= e scope of this thread by quite a bit (start a new one if you'd like).<= br>


> > So why the issue date?=A0 Because suppose the user has authorized= a client
> and
> > then that client's tokens are compromised (stolen computer pe= rhaps).=A0
The
> > user will of course revoke authorization for that client.=A0 The = user then
> > gets a new copy of that client (perhaps a new computer) and autho= rizes
it.
> > Whoops.=A0 Now all those invalidated tokens are valid again becau= se the
> > authorization tuple exists.=A0

If the tokens (tickets) were issued to the client entity (principal) = versus
to the human-user principal, then this will not be a problem. If the user loses her client/laptop, then she need only revoke the tokens associated to=
the client/laptop.

Sure, but that requires either = that you store all issued tokens so you can revoke individual ones, or that= you revoke all tokens issued to a client_id.=A0 But client apps can't = keep secrets, so an installed app on a laptop will likely just have a clien= t_id that is preset for the app (it doesn't have to be this way, but it= may).=A0 That means that all installations of that app on all laptops will= have the same client_id (and no secret), and therefore you can't revok= e all tokens issued to an individual laptop because there's no distinct= ion for it.

Yes, I know this isn't the way all applications will be, but again = it MAY be this way, so I'm planning for it.
=A0

I think this is where there is room for OAuth 2.0 to innovate, such as to introduce a special kind of token (human-token) that is independent from client/laptop tokens. =A0The human-token could even be stored in a secure cloud service and be used for client-initiation or emergency purposes only.=
Thus, whenever the human-user wants to move to a new laptop/client, the
human-token is pulled down from the cloud, used to authenticate to the auth=
server, and then deleted (from the client) once the new client/laptop
becomes a known entity/principal in the ecosystem and has its own tokens. Just a thought.

Bring on the innovation. :)
--000e0cd5cf580e81d50488b89d66-- From recordond@gmail.com Thu Jun 10 21:13:48 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76DFA3A69B0 for ; Thu, 10 Jun 2010 21:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.957 X-Spam-Level: X-Spam-Status: No, score=-1.957 tagged_above=-999 required=5 tests=[AWL=0.642, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vRFQQAR5gcBx for ; Thu, 10 Jun 2010 21:13:46 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 8F0083A6899 for ; Thu, 10 Jun 2010 21:13:46 -0700 (PDT) Received: by iwn42 with SMTP id 42so728311iwn.31 for ; Thu, 10 Jun 2010 21:13:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=rcNbI5CJMU1NYJTUYANb3J9+yobevLhAGHxAZd+ATT4=; b=jERaHPNVP1BWjpHcTEUpl+0ccX+tQIFVoopKWnMTve6LUflGYLilWZnbdfePgkFsmf 4+QpFNEUcrJdZLyzhgqjKazpc4vZhjEAblQDtjq2IZCbjZmtqE0rupu4nuYzMTC+9TwP nlZu/hi3x06vzno1I0ZE0Bvs0LDeKrYTHZSsQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=IPeIilnYUf/2rbL1FQ6CIh1hnHx51Qf4DwENs2FCR0uqxFQ+0PWLWjiBB2nHC0q0QA L3E00nWGshQYRqWeJCrMAe6AdS0gSmcCjSzIOUZiT809mI5oIgVteiQ+1qk4MKCf+6AM dCQ8WUydr4cQzf4Zj0yLp8+JTEYYkoYFqs/tY= MIME-Version: 1.0 Received: by 10.231.59.199 with SMTP id m7mr1220001ibh.30.1276229625014; Thu, 10 Jun 2010 21:13:45 -0700 (PDT) Received: by 10.231.192.4 with HTTP; Thu, 10 Jun 2010 21:13:44 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF7476@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 10 Jun 2010 21:13:44 -0700 Message-ID: From: David Recordon To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: OAuth WG Subject: Re: [OAUTH-WG] A display parameter for user authorization requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 04:13:48 -0000 http://github.com/daveman692/OAuth-2.0/raw/master/draft-recordon-oauth-v2-u= x-01.txt On Thu, Jun 10, 2010 at 5:32 PM, David Recordon wrote= : > +1 for moving immediate here as well. > > > On Thu, Jun 10, 2010 at 4:18 PM, Eran Hammer-Lahav = wrote: >> Since these are all extensions to the end-user endpoint, I'd suggest we = move the 'immediate' parameter here as well. >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0OPTIONAL. The parameter value must be set= to true or >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0false. If s= et to >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0true, the a= uthorization server MUST NOT prompt the >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0end-user to authenticate or approve acces= s. Instead, the authorization server >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0attempts to establish the end-user's iden= tity via other means (e.g. browser >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0cookies) and checks if the end-user has p= reviously approved an identical access >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0request by the same client and if that ac= cess grant is still active. If the >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0authorization server does not support an = immediate check or if it is unable to >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0establish the end-user's identity or appr= oval status, it MUST deny the request >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0without prompting the end-user. Defaults = to false if >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0omitted. >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 >> EHL >> >>> -----Original Message----- >>> From: David Recordon [mailto:recordond@gmail.com] >>> Sent: Wednesday, June 09, 2010 12:06 PM >>> To: Eran Hammer-Lahav; Allen Tom; Breno de Medeiros; Luke Shepard >>> Cc: OAuth WG >>> Subject: Re: [OAUTH-WG] A display parameter for user authorization >>> requests >>> >>> First draft of the UX Extension is at >>> http://github.com/daveman692/OAuth-2.0/raw/master/draft-recordon- >>> oauth-v2-ux-00.txt. >>> >>> Eran, I'm more than happy to have you take over as editor. >>> >>> I included Allen and Breno as authors since I followed Allen's suggesti= on and >>> adopted the language preference parameter from the OpenID extension. I >>> also included Luke as an author since he wrote the first pass of a disp= lay >>> parameter. That said, none of them have seen this draft yet. >>> >>> --David >>> >>> >>> On Tue, Apr 13, 2010 at 12:36 PM, Allen Tom wrote: >>> > At least with regards to the language preference, how about if we jus= t >>> > copy the openid.ui.lang parameter from the OpenID UI Extension? >>> > >>> > http://svn.openid.net/repos/specifications/user_interface/1.0/trunk/o= p >>> > enid-user-interface-extension-1_0.html#anchor3 >>> > >>> > In flows in which the client redirects the user's web browser to >>> > authorize access, the client MAY send the Authorization Server a hint >>> > regarding the user's preferred language by sending the following >>> parameter: >>> > >>> > =A0=A0=A0=A0lang >>> > =A0=A0=A0=A0=A0=A0=A0=A0The user's preferred languages as a [BCP 47] = language priority >>> > list, represented as a comma-separated list of BCP 47 basic language >>> > ranges in decending priority order. For instance, the value "fr-CA,fr= -FR,en- >>> CA" >>> > represents the preference for French spoken in Canada, French spoken >>> > in France, followed by English spoken in Canada. >>> > >>> > The language preference hint SHOULD take precedence over the >>> > Accept-Language HTTP header sent by the user's browser, and SHOULD >>> > take precedence over the language preference inferred by the user's I= P >>> Address. >>> > >>> > BCP 47: =A0http://tools.ietf.org/html/bcp47 >>> > >>> > Allen >>> > >>> > >>> > On 4/12/10 1:32 PM, "Eran Hammer-Lahav" >>> wrote: >>> > >>> > Between language preferences, display configuration, and immediate >>> > check, I think it might be worth to move that work to another draft. >>> > Timeline-wise, this has the potential of slowing us down. I also fear >>> > getting what is now a pretty simple spec much more complicated. >>> > >>> > Anyone cares to try a first draft or outline? I can do the editorial >>> > work if needed, but someone needs to write something first. >>> > >>> > EHL >>> > >>> > >>> > >>> > _______________________________________________ >>> > OAuth mailing list >>> > OAuth@ietf.org >>> > https://www.ietf.org/mailman/listinfo/oauth >>> > >>> > >> > From naitiks@gmail.com Thu Jun 10 22:17:57 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9D213A69C6 for ; Thu, 10 Jun 2010 22:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2BAxHtlpwIAC for ; Thu, 10 Jun 2010 22:17:51 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 65AD83A69C2 for ; Thu, 10 Jun 2010 22:17:51 -0700 (PDT) Received: by iwn42 with SMTP id 42so778038iwn.31 for ; Thu, 10 Jun 2010 22:17:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=nIU5kSwTd8dadkjyKPTszUFA4iHVNLc0ghauKoBlu20=; b=qdTdcbacj53W2wxrWFJZ0nflXPQTzkPgOu6QBhZrGBQTAz50S8eIpB+Rk25OMkYI5I 5zWlqgBya93lmdyNmmszSHnXsTYcNVKBUUVcYrheCrpRYOSvsG0xwiAlEOVkhmLqCrhN B4H1JriQzfx3L6m2NxOZoj8NHX8sAQrZeMcgU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=N4WJBrW38+VenHqYtNbqVlZHpz9YH9y7F5P1E0DDkdEJTEKM29+fYQoolwW2fYCou8 BAt/zMy2BZHDOvhrPENfuJ2YT6kgq6ojug/dYs+ul37/twef/Hg2rMbxAZ41UYG/bGqv YMDoqqbMQs4L12jLGCGkq8r3OJ7C7/kOlA/Is= Received: by 10.231.119.102 with SMTP id y38mr1202453ibq.135.1276233471151; Thu, 10 Jun 2010 22:17:51 -0700 (PDT) MIME-Version: 1.0 Sender: naitiks@gmail.com Received: by 10.231.170.138 with HTTP; Thu, 10 Jun 2010 22:17:30 -0700 (PDT) In-Reply-To: <4A5E1C55-D589-4F25-9D45-E640BA7C833F@facebook.com> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF73EF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E11263FEC9FC@WSMSG3153V.srv.dir.telstra.com> <4A5E1C55-D589-4F25-9D45-E640BA7C833F@facebook.com> From: Naitik Shah Date: Thu, 10 Jun 2010 22:17:30 -0700 X-Google-Sender-Auth: SMyrSPYNUA_r9eFVH_-v-PEjiHw Message-ID: To: Luke Shepard Content-Type: multipart/alternative; boundary=00163692034db2d3a30488ba4267 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Proposal for single JSON response format X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 05:17:58 -0000 --00163692034db2d3a30488ba4267 Content-Type: text/plain; charset=UTF-8 +1 On Thu, Jun 10, 2010 at 5:50 PM, Luke Shepard wrote: > +1 > > On Jun 10, 2010, at 5:46 PM, Manger, James H wrote: > > > +1 > > > > -- > > James Manger > > > > ---------- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Eran Hammer-Lahav > > Sent: Friday, 11 June 2010 6:29 AM > > To: OAuth WG (oauth@ietf.org) > > Subject: [OAUTH-WG] Proposal for single JSON response format > > > > - Support a single response format (including in the user-agent fragment) > using JSON. > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --00163692034db2d3a30488ba4267 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1

On Thu, Jun 10, 2010 at 5:50 PM, Luke = Shepard <lshe= pard@facebook.com> wrote:
+1

On Jun 10, 2010, at 5:46 PM, Manger, James H wrote:

> +1
>
> --
> James Manger
>
> ----------
> From: oauth-bounces@ietf.org= [mailto:oauth-bounces@ietf.o= rg] On Behalf Of Eran Hammer-Lahav
> Sent: Friday, 11 June 2010 6:29 AM
> To: OAuth WG (oauth@ietf.org) > Subject: [OAUTH-WG] Proposal for single JSON response format
>
> - Support a single response format (including in the user-agent fragme= nt) using JSON.
> _______________________________________________
> 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

--00163692034db2d3a30488ba4267-- From eran@hueniverse.com Fri Jun 11 00:41:26 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C962C3A6A2F for ; Fri, 11 Jun 2010 00:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[AWL=-0.526, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rjeqZ05Kwa6x for ; Fri, 11 Jun 2010 00:41:26 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 17F083A69FF for ; Fri, 11 Jun 2010 00:41:25 -0700 (PDT) Received: (qmail 24454 invoked from network); 11 Jun 2010 07:41:26 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 11 Jun 2010 07:41:26 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Fri, 11 Jun 2010 00:41:26 -0700 From: Eran Hammer-Lahav To: "OAuth WG (oauth@ietf.org)" Date: Fri, 11 Jun 2010 00:41:23 -0700 Thread-Topic: Device flow to move to an extension Thread-Index: AcsJOX1e+S8/2cmcQnaAz3XlGMB0bw== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF74BC@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] Device flow to move to an extension X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 07:41:26 -0000 Unlike the rest of the flows, the device flow lacks deployment experience a= nd is still likely to change. It also uses a very different architecture th= an the rest of the flows (which becomes more obvious in my -07 rewrite). Un= less there is strong objection, I am going to remove it from the core spec = and republish it as a new draft. In general, I am going to iterate through the spec in the next couple weeks= and move unstable (and non-essential) features out to extension specs. EHL From mscurtescu@google.com Fri Jun 11 06:57:49 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E885B28C0EE for ; Fri, 11 Jun 2010 06:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.401 X-Spam-Level: X-Spam-Status: No, score=-101.401 tagged_above=-999 required=5 tests=[AWL=0.576, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KFqQpu0EcgHA for ; Fri, 11 Jun 2010 06:57:48 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 4D9B23A69F2 for ; Fri, 11 Jun 2010 06:57:48 -0700 (PDT) Received: from hpaq2.eem.corp.google.com (hpaq2.eem.corp.google.com [172.25.149.2]) by smtp-out.google.com with ESMTP id o5BDvibc004824 for ; Fri, 11 Jun 2010 06:57:45 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1276264665; bh=cRV9CWS4/Z9hLz8dcsUnKCNkVUQ=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=c0NCjk5Fp5TOwDOwYNsrVRHCRI5JEM3fDmkq6GZrvMUC3ECp9DFfbA6e/ZEgUmdBI 3uz+A7LXECxjMvZgOPRXA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding; b=nNuufua4jHaHmmsiqMCDENeahAMir4+pbnE6NtG+raU5fbmraWP+RSjorV/zSvQlz GDSHRKrso1/4XIr6WkzmQ== Received: from pvg12 (pvg12.prod.google.com [10.241.210.140]) by hpaq2.eem.corp.google.com with ESMTP id o5BDvgJ1023168 for ; Fri, 11 Jun 2010 06:57:43 -0700 Received: by pvg12 with SMTP id 12so531772pvg.8 for ; Fri, 11 Jun 2010 06:57:41 -0700 (PDT) Received: by 10.141.214.41 with SMTP id r41mr1433575rvq.77.1276264661352; Fri, 11 Jun 2010 06:57:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.124.13 with HTTP; Fri, 11 Jun 2010 06:57:21 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF7476@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu Date: Fri, 11 Jun 2010 06:57:21 -0700 Message-ID: To: David Recordon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: OAuth WG Subject: Re: [OAUTH-WG] A display parameter for user authorization requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 13:57:50 -0000 There was discussion about a username hint parameter, in general this is needed when immediate is used. Should username go to this UX Extension, or rather immediate and username should go to a separate one together? Marius On Thu, Jun 10, 2010 at 5:32 PM, David Recordon wrote= : > +1 for moving immediate here as well. > > > On Thu, Jun 10, 2010 at 4:18 PM, Eran Hammer-Lahav = wrote: >> Since these are all extensions to the end-user endpoint, I'd suggest we = move the 'immediate' parameter here as well. >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0OPTIONAL. The parameter value must be set= to true or >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0false. If s= et to >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0true, the a= uthorization server MUST NOT prompt the >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0end-user to authenticate or approve acces= s. Instead, the authorization server >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0attempts to establish the end-user's iden= tity via other means (e.g. browser >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0cookies) and checks if the end-user has p= reviously approved an identical access >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0request by the same client and if that ac= cess grant is still active. If the >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0authorization server does not support an = immediate check or if it is unable to >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0establish the end-user's identity or appr= oval status, it MUST deny the request >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0without prompting the end-user. Defaults = to false if >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0omitted. >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 >> EHL >> >>> -----Original Message----- >>> From: David Recordon [mailto:recordond@gmail.com] >>> Sent: Wednesday, June 09, 2010 12:06 PM >>> To: Eran Hammer-Lahav; Allen Tom; Breno de Medeiros; Luke Shepard >>> Cc: OAuth WG >>> Subject: Re: [OAUTH-WG] A display parameter for user authorization >>> requests >>> >>> First draft of the UX Extension is at >>> http://github.com/daveman692/OAuth-2.0/raw/master/draft-recordon- >>> oauth-v2-ux-00.txt. >>> >>> Eran, I'm more than happy to have you take over as editor. >>> >>> I included Allen and Breno as authors since I followed Allen's suggesti= on and >>> adopted the language preference parameter from the OpenID extension. I >>> also included Luke as an author since he wrote the first pass of a disp= lay >>> parameter. That said, none of them have seen this draft yet. >>> >>> --David >>> >>> >>> On Tue, Apr 13, 2010 at 12:36 PM, Allen Tom wrote: >>> > At least with regards to the language preference, how about if we jus= t >>> > copy the openid.ui.lang parameter from the OpenID UI Extension? >>> > >>> > http://svn.openid.net/repos/specifications/user_interface/1.0/trunk/o= p >>> > enid-user-interface-extension-1_0.html#anchor3 >>> > >>> > In flows in which the client redirects the user's web browser to >>> > authorize access, the client MAY send the Authorization Server a hint >>> > regarding the user's preferred language by sending the following >>> parameter: >>> > >>> > =A0=A0=A0=A0lang >>> > =A0=A0=A0=A0=A0=A0=A0=A0The user's preferred languages as a [BCP 47] = language priority >>> > list, represented as a comma-separated list of BCP 47 basic language >>> > ranges in decending priority order. For instance, the value "fr-CA,fr= -FR,en- >>> CA" >>> > represents the preference for French spoken in Canada, French spoken >>> > in France, followed by English spoken in Canada. >>> > >>> > The language preference hint SHOULD take precedence over the >>> > Accept-Language HTTP header sent by the user's browser, and SHOULD >>> > take precedence over the language preference inferred by the user's I= P >>> Address. >>> > >>> > BCP 47: =A0http://tools.ietf.org/html/bcp47 >>> > >>> > Allen >>> > >>> > >>> > On 4/12/10 1:32 PM, "Eran Hammer-Lahav" >>> wrote: >>> > >>> > Between language preferences, display configuration, and immediate >>> > check, I think it might be worth to move that work to another draft. >>> > Timeline-wise, this has the potential of slowing us down. I also fear >>> > getting what is now a pretty simple spec much more complicated. >>> > >>> > Anyone cares to try a first draft or outline? I can do the editorial >>> > work if needed, but someone needs to write something first. >>> > >>> > 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 gffletch@aol.com Fri Jun 11 07:39:22 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D55E63A69A5 for ; Fri, 11 Jun 2010 07:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.183 X-Spam-Level: X-Spam-Status: No, score=-0.183 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K4a1ZrmfW58K for ; Fri, 11 Jun 2010 07:39:20 -0700 (PDT) Received: from imr-da01.mx.aol.com (imr-da01.mx.aol.com [205.188.105.143]) by core3.amsl.com (Postfix) with ESMTP id C70843A69A0 for ; Fri, 11 Jun 2010 07:39:19 -0700 (PDT) Received: from mtaout-mb04.r1000.mx.aol.com (mtaout-mb04.r1000.mx.aol.com [172.29.41.68]) by imr-da01.mx.aol.com (8.14.1/8.14.1) with ESMTP id o5BEcfGG020982; Fri, 11 Jun 2010 10:38:41 -0400 Received: from palantir.local (unknown [10.172.1.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-mb04.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 401FFE000090; Fri, 11 Jun 2010 10:38:41 -0400 (EDT) Message-ID: <4C124A70.2000002@aol.com> Date: Fri, 11 Jun 2010 10:38:40 -0400 From: George Fletcher Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Andrew Arnott References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------040803020404050107050404" x-aol-global-disposition: G X-AOL-SCOLL-SCORE: 0:2:476520000:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d29444c124a7148ed X-AOL-IP: 10.172.1.149 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] User-agent flow and pre-registered redirect_uri X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 14:39:23 -0000 This is a multi-part message in MIME format. --------------040803020404050107050404 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Makes perfect sense as we have the same model for our clients & tokens:) The one use case we've encountered is that this model revokes the tokens for all clients with the same client_id. So if I've got three of the same client installed (on three computers) and they likely all have the same client_id, then revoking that client_id affects all three clients. I think this is a reasonable trade-off. Especially since revoking authorizations will be an infrequent event. Thanks, George On 6/10/10 11:35 AM, Andrew Arnott wrote: > Thanks Marius. > > I've answered your question below. > > On Wed, Jun 9, 2010 at 9:35 AM, Marius Scurtescu > > wrote: > > > I've always considered an authorization as a tuple of > > client_id,user,scope,issue_date. If an authorization has been > approved, and > > another request for authorization for a subset of the scope > previously > > issued comes in, the auth server can skip the interactive user > authorization > > and just approve the request since nothing new is being issued. > > The tuple seems right, except for the issue date, why would you > add that? > > > The issue_date enables to scenarios: expiring tokens and token > revocation. Here's how, for each scenario: > > Obviously to know if a token has expired you need to know when it was > issued. Or, you can forget the issue date and just store the > expiration date in the token. I choose to go with an issue date (plus > an optional expected lifetime) because it gives more ability in the > future to say "oops, we had a security weakness in all tokens issued > prior to [date], so let's consider all earlier tokens invalid." It's > harder to say that when all you have are expiration dates because you > don't know how old the token is. This is just the way I chose to do > it, but I know there are other ways. > > Now let's look at how you revoke issued tokens. One of the nice > things enabled by OAuth 2.0 is that the authorization server and > resource server never have to store tokens if they are appropriate > signed by the auth server. This is great because (among other things) > clients with little-to-no ability to persistently store tokens may ask > for tokens frequently, and that could bog down an auth server with > storing all those issued tokens. But how can a user revoke a > previously authorized token if no one but the client knows what the > tokens are? (thought question) My solution to this is that instead of > thinking about revoking /tokens/, the user revokes /authorizations/. > The user goes through his account on the authorization server and sees > a list of clients and what they are authorized to do. Note that this > only requires the auth server to store this authorization tuple -- not > the actual issued tokens. If the user clicks "revoke" on one of these > authorizations, that row is deleted in the database. Issued tokens > (both refresh and access tokens) have this same tuple encoded in them. > Now, when a refresh token is used to obtain a new short-lived access > token (and you could do this on every access token use as well if you > wanted) the token is of course signature-validated, but it is also > checked that the authorization tuple has a matching tuple in the auth > server's database. If it's missing, then that authorization has been > revoked and the token is thereby invalidated. > So why the issue date? Because suppose the user has authorized a > client and then that client's tokens are compromised (stolen computer > perhaps). The user will of course revoke authorization for that > client. The user then gets a new copy of that client (perhaps a new > computer) and authorizes it. Whoops. Now all those invalidated > tokens are valid again because the authorization tuple exists. /Except > now the issue date on the authorization on the auth server is newer > than in the refresh token on the invalidated client/. That's why > issue date is such a critical part of an authorization tuple. Any > token issued prior to the earliest authorization on record at the auth > server represents a revoked authorization, and without an issue date > in the tuple there's no way to recognize that. > > At least that's the way I'm seeing it. I hope that makes sense. > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --------------040803020404050107050404 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Makes perfect sense as we have the same model for our clients & tokens:)

The one use case we've encountered is that this model revokes the tokens for all clients with the same client_id. So if I've got three of the same client installed (on three computers) and they likely all have the same client_id, then revoking that client_id affects all three clients. I think this is a reasonable trade-off. Especially since revoking authorizations will be an infrequent event.

Thanks,
George

On 6/10/10 11:35 AM, Andrew Arnott wrote:
Thanks Marius.

I've answered your question below.

On Wed, Jun 9, 2010 at 9:35 AM, Marius Scurtescu <mscurtescu@google.com> wrote:
> I've always considered an authorization as a tuple of
> client_id,user,scope,issue_date.  If an authorization has been approved, and
> another request for authorization for a subset of the scope previously
> issued comes in, the auth server can skip the interactive user authorization
> and just approve the request since nothing new is being issued.

The tuple seems right, except for the issue date, why would you add that?

The issue_date enables to scenarios: expiring tokens and token revocation.  Here's how, for each scenario:

Obviously to know if a token has expired you need to know when it was issued.  Or, you can forget the issue date and just store the expiration date in the token. I choose to go with an issue date (plus an optional expected lifetime) because it gives more ability in the future to say "oops, we had a security weakness in all tokens issued prior to [date], so let's consider all earlier tokens invalid."  It's harder to say that when all you have are expiration dates because you don't know how old the token is.  This is just the way I chose to do it, but I know there are other ways.

Now let's look at how you revoke issued tokens.  One of the nice things enabled by OAuth 2.0 is that the authorization server and resource server never have to store tokens if they are appropriate signed by the auth server.  This is great because (among other things) clients with little-to-no ability to persistently store tokens may ask for tokens frequently, and that could bog down an auth server with storing all those issued tokens.  But how can a user revoke a previously authorized token if no one but the client knows what the tokens are? (thought question)  My solution to this is that instead of thinking about revoking tokens, the user revokes authorizations.  The user goes through his account on the authorization server and sees a list of clients and what they are authorized to do.  Note that this only requires the auth server to store this authorization tuple -- not the actual issued tokens.  If the user clicks "revoke" on one of these authorizations, that row is deleted in the database.  Issued tokens (both refresh and access tokens) have this same tuple encoded in them.
Now, when a refresh token is used to obtain a new short-lived access token (and you could do this on every access token use as well if you wanted) the token is of course signature-validated, but it is also checked that the authorization tuple has a matching tuple in the auth server's database.  If it's missing, then that authorization has been revoked and the token is thereby invalidated.
So why the issue date?  Because suppose the user has authorized a client and then that client's tokens are compromised (stolen computer perhaps).  The user will of course revoke authorization for that client.  The user then gets a new copy of that client (perhaps a new computer) and authorizes it.  Whoops.  Now all those invalidated tokens are valid again because the authorization tuple exists.  Except now the issue date on the authorization on the auth server is newer than in the refresh token on the invalidated client.  That's why issue date is such a critical part of an authorization tuple.  Any token issued prior to the earliest authorization on record at the auth server represents a revoked authorization, and without an issue date in the tuple there's no way to recognize that.

At least that's the way I'm seeing it.  I hope that makes sense.

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--------------040803020404050107050404-- From torsten@lodderstedt.net Fri Jun 11 07:50:24 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82B303A68DA for ; Fri, 11 Jun 2010 07:50:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.564 X-Spam-Level: X-Spam-Status: No, score=-0.564 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_20=-0.74, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S5FLJl8MRdUJ for ; Fri, 11 Jun 2010 07:50:22 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.29]) by core3.amsl.com (Postfix) with ESMTP id 334DE3A6879 for ; Fri, 11 Jun 2010 07:50:19 -0700 (PDT) Received: from p4fff06ec.dip.t-dialin.net ([79.255.6.236] helo=[127.0.0.1]) by smtprelay02.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1ON5Yd-0004HZ-Tx; Fri, 11 Jun 2010 16:50:08 +0200 Message-ID: <4C124D1D.5040602@lodderstedt.net> Date: Fri, 11 Jun 2010 16:50:05 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: George Fletcher References: <4C124A70.2000002@aol.com> In-Reply-To: <4C124A70.2000002@aol.com> Content-Type: multipart/alternative; boundary="------------040705080402090105040904" X-Df-Sender: 141509 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] User-agent flow and pre-registered redirect_uri X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 14:50:24 -0000 This is a multi-part message in MIME format. --------------040705080402090105040904 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Am 11.06.2010 16:38, schrieb George Fletcher: > Makes perfect sense as we have the same model for our clients & tokens:) > > The one use case we've encountered is that this model revokes the > tokens for all clients with the same client_id. So if I've got three > of the same client installed (on three computers) and they likely all > have the same client_id, then revoking that client_id affects all > three clients. I think this is a reasonable trade-off. Especially > since revoking authorizations will be an infrequent event. Alternatively, a device_id (hostname, IMEI, ...) could be incorporated into the authorization tuple. This would allow to a) visualize to the end-user the devices were clients w/ tokens reside and b) revoke tokens by device_id. regards, Torsten. > > Thanks, > George > > On 6/10/10 11:35 AM, Andrew Arnott wrote: >> Thanks Marius. >> >> I've answered your question below. >> >> On Wed, Jun 9, 2010 at 9:35 AM, Marius Scurtescu >> > wrote: >> >> > I've always considered an authorization as a tuple of >> > client_id,user,scope,issue_date. If an authorization has been >> approved, and >> > another request for authorization for a subset of the scope >> previously >> > issued comes in, the auth server can skip the interactive user >> authorization >> > and just approve the request since nothing new is being issued. >> >> The tuple seems right, except for the issue date, why would you >> add that? >> >> >> The issue_date enables to scenarios: expiring tokens and token >> revocation. Here's how, for each scenario: >> >> Obviously to know if a token has expired you need to know when it was >> issued. Or, you can forget the issue date and just store the >> expiration date in the token. I choose to go with an issue date (plus >> an optional expected lifetime) because it gives more ability in the >> future to say "oops, we had a security weakness in all tokens issued >> prior to [date], so let's consider all earlier tokens invalid." It's >> harder to say that when all you have are expiration dates because you >> don't know how old the token is. This is just the way I chose to do >> it, but I know there are other ways. >> >> Now let's look at how you revoke issued tokens. One of the nice >> things enabled by OAuth 2.0 is that the authorization server and >> resource server never have to store tokens if they are appropriate >> signed by the auth server. This is great because (among other >> things) clients with little-to-no ability to persistently store >> tokens may ask for tokens frequently, and that could bog down an auth >> server with storing all those issued tokens. But how can a user >> revoke a previously authorized token if no one but the client knows >> what the tokens are? (thought question) My solution to this is that >> instead of thinking about revoking /tokens/, the user revokes >> /authorizations/. The user goes through his account on the >> authorization server and sees a list of clients and what they are >> authorized to do. Note that this only requires the auth server to >> store this authorization tuple -- not the actual issued tokens. If >> the user clicks "revoke" on one of these authorizations, that row is >> deleted in the database. Issued tokens (both refresh and access >> tokens) have this same tuple encoded in them. >> Now, when a refresh token is used to obtain a new short-lived access >> token (and you could do this on every access token use as well if you >> wanted) the token is of course signature-validated, but it is also >> checked that the authorization tuple has a matching tuple in the auth >> server's database. If it's missing, then that authorization has been >> revoked and the token is thereby invalidated. >> So why the issue date? Because suppose the user has authorized a >> client and then that client's tokens are compromised (stolen computer >> perhaps). The user will of course revoke authorization for that >> client. The user then gets a new copy of that client (perhaps a new >> computer) and authorizes it. Whoops. Now all those invalidated >> tokens are valid again because the authorization tuple exists. >> /Except now the issue date on the authorization on the auth server is >> newer than in the refresh token on the invalidated client/. That's >> why issue date is such a critical part of an authorization tuple. >> Any token issued prior to the earliest authorization on record at the >> auth server represents a revoked authorization, and without an issue >> date in the tuple there's no way to recognize that. >> >> At least that's the way I'm seeing it. I hope that makes sense. >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --------------040705080402090105040904 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Am 11.06.2010 16:38, schrieb George Fletcher:
Makes perfect sense as we have the same model for our clients & tokens:)

The one use case we've encountered is that this model revokes the tokens for all clients with the same client_id. So if I've got three of the same client installed (on three computers) and they likely all have the same client_id, then revoking that client_id affects all three clients. I think this is a reasonable trade-off. Especially since revoking authorizations will be an infrequent event.

Alternatively, a device_id (hostname, IMEI, ...) could be incorporated into the authorization tuple. This would allow to a) visualize to the end-user the devices were clients w/ tokens reside and b) revoke tokens by device_id.

regards,
Torsten.

Thanks,
George

On 6/10/10 11:35 AM, Andrew Arnott wrote:
Thanks Marius.

I've answered your question below.

On Wed, Jun 9, 2010 at 9:35 AM, Marius Scurtescu <mscurtescu@google.com> wrote:
> I've always considered an authorization as a tuple of
> client_id,user,scope,issue_date.  If an authorization has been approved, and
> another request for authorization for a subset of the scope previously
> issued comes in, the auth server can skip the interactive user authorization
> and just approve the request since nothing new is being issued.

The tuple seems right, except for the issue date, why would you add that?

The issue_date enables to scenarios: expiring tokens and token revocation.  Here's how, for each scenario:

Obviously to know if a token has expired you need to know when it was issued.  Or, you can forget the issue date and just store the expiration date in the token. I choose to go with an issue date (plus an optional expected lifetime) because it gives more ability in the future to say "oops, we had a security weakness in all tokens issued prior to [date], so let's consider all earlier tokens invalid."  It's harder to say that when all you have are expiration dates because you don't know how old the token is.  This is just the way I chose to do it, but I know there are other ways.

Now let's look at how you revoke issued tokens.  One of the nice things enabled by OAuth 2.0 is that the authorization server and resource server never have to store tokens if they are appropriate signed by the auth server.  This is great because (among other things) clients with little-to-no ability to persistently store tokens may ask for tokens frequently, and that could bog down an auth server with storing all those issued tokens.  But how can a user revoke a previously authorized token if no one but the client knows what the tokens are? (thought question)  My solution to this is that instead of thinking about revoking tokens, the user revokes authorizations.  The user goes through his account on the authorization server and sees a list of clients and what they are authorized to do.  Note that this only requires the auth server to store this authorization tuple -- not the actual issued tokens.  If the user clicks "revoke" on one of these authorizations, that row is deleted in the database.  Issued tokens (both refresh and access tokens) have this same tuple encoded in them.
Now, when a refresh token is used to obtain a new short-lived access token (and you could do this on every access token use as well if you wanted) the token is of course signature-validated, but it is also checked that the authorization tuple has a matching tuple in the auth server's database.  If it's missing, then that authorization has been revoked and the token is thereby invalidated.
So why the issue date?  Because suppose the user has authorized a client and then that client's tokens are compromised (stolen computer perhaps).  The user will of course revoke authorization for that client.  The user then gets a new copy of that client (perhaps a new computer) and authorizes it.  Whoops.  Now all those invalidated tokens are valid again because the authorization tuple exists.  Except now the issue date on the authorization on the auth server is newer than in the refresh token on the invalidated client.  That's why issue date is such a critical part of an authorization tuple.  Any token issued prior to the earliest authorization on record at the auth server represents a revoked authorization, and without an issue date in the tuple there's no way to recognize that.

At least that's the way I'm seeing it.  I hope that makes sense.

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

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--------------040705080402090105040904-- From jricher@mitre.org Fri Jun 11 08:05:54 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C2C13A68A3 for ; Fri, 11 Jun 2010 08:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.236 X-Spam-Level: X-Spam-Status: No, score=-5.236 tagged_above=-999 required=5 tests=[AWL=-0.496, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HBShveNAFBjH for ; Fri, 11 Jun 2010 08:05:53 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 109493A6837 for ; Fri, 11 Jun 2010 08:05:52 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o5BF5sKm030007 for ; Fri, 11 Jun 2010 11:05:55 -0400 Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o5BF5sf2030004; Fri, 11 Jun 2010 11:05:54 -0400 Received: from [129.83.50.65] (129.83.50.65) by imchub2.MITRE.ORG (129.83.29.74) with Microsoft SMTP Server id 8.2.254.0; Fri, 11 Jun 2010 11:05:54 -0400 From: Justin Richer To: George Fletcher In-Reply-To: <4C124A70.2000002@aol.com> References: <4C124A70.2000002@aol.com> Content-Type: text/plain; charset="UTF-8" Date: Fri, 11 Jun 2010 11:05:53 -0400 Message-ID: <1276268753.31840.50.camel@localhost.localdomain> MIME-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] User-agent flow and pre-registered redirect_uri X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 15:05:54 -0000 Along these lines, I'd like to propose an extension for per-client instance information to be passed from a client to the server. Things like a human-readable client name/description, instance name/description (could be tied to host name, ip, label like "home" or "Work"), and even something like a display icon. This is especially useful for things like device clients (where I might have a bunch of devices with the same client ID) or unregistered clients, where the client id string ends up being closer to a user-agent string from a browser than a trusted identifier, especially since it can't have a reliable secret. Speaking of which, the spec is relatively quiet on registered vs. unregistered clients. I'd like to see the WG maybe pull together some guidance on this topic? I'm not sure what form that would take though, an information note that sits along with the RFC? A page on the oauth wiki? Basically, I think we can get away from the anonymous/anonymous hack that Google used with OAuth1 since we're not requiring the client secret for signing anymore. Thoughts? -- Justin On Fri, 2010-06-11 at 10:38 -0400, George Fletcher wrote: > Makes perfect sense as we have the same model for our clients & > tokens:) > > The one use case we've encountered is that this model revokes the > tokens for all clients with the same client_id. So if I've got three > of the same client installed (on three computers) and they likely all > have the same client_id, then revoking that client_id affects all > three clients. I think this is a reasonable trade-off. Especially > since revoking authorizations will be an infrequent event. > > Thanks, > George > > On 6/10/10 11:35 AM, Andrew Arnott wrote: > > Thanks Marius. > > > > I've answered your question below. > > > > On Wed, Jun 9, 2010 at 9:35 AM, Marius Scurtescu > > wrote: > > > I've always considered an authorization as a tuple of > > > client_id,user,scope,issue_date. If an authorization has > > been approved, and > > > another request for authorization for a subset of the > > scope previously > > > issued comes in, the auth server can skip the interactive > > user authorization > > > and just approve the request since nothing new is being > > issued. > > > > > > The tuple seems right, except for the issue date, why would > > you add that? > > > > The issue_date enables to scenarios: expiring tokens and token > > revocation. Here's how, for each scenario: > > > > Obviously to know if a token has expired you need to know when it > > was issued. Or, you can forget the issue date and just store the > > expiration date in the token. I choose to go with an issue date > > (plus an optional expected lifetime) because it gives more ability > > in the future to say "oops, we had a security weakness in all tokens > > issued prior to [date], so let's consider all earlier tokens > > invalid." It's harder to say that when all you have are expiration > > dates because you don't know how old the token is. This is just the > > way I chose to do it, but I know there are other ways. > > > > Now let's look at how you revoke issued tokens. One of the nice > > things enabled by OAuth 2.0 is that the authorization server and > > resource server never have to store tokens if they are appropriate > > signed by the auth server. This is great because (among other > > things) clients with little-to-no ability to persistently store > > tokens may ask for tokens frequently, and that could bog down an > > auth server with storing all those issued tokens. But how can a > > user revoke a previously authorized token if no one but the client > > knows what the tokens are? (thought question) My solution to this > > is that instead of thinking about revoking tokens, the user revokes > > authorizations. The user goes through his account on the > > authorization server and sees a list of clients and what they are > > authorized to do. Note that this only requires the auth server to > > store this authorization tuple -- not the actual issued tokens. If > > the user clicks "revoke" on one of these authorizations, that row is > > deleted in the database. Issued tokens (both refresh and access > > tokens) have this same tuple encoded in them. > > Now, when a refresh token is used to obtain a new short-lived access > > token (and you could do this on every access token use as well if > > you wanted) the token is of course signature-validated, but it is > > also checked that the authorization tuple has a matching tuple in > > the auth server's database. If it's missing, then that > > authorization has been revoked and the token is thereby invalidated. > > So why the issue date? Because suppose the user has authorized a > > client and then that client's tokens are compromised (stolen > > computer perhaps). The user will of course revoke authorization for > > that client. The user then gets a new copy of that client (perhaps > > a new computer) and authorizes it. Whoops. Now all those > > invalidated tokens are valid again because the authorization tuple > > exists. Except now the issue date on the authorization on the auth > > server is newer than in the refresh token on the invalidated client. > > That's why issue date is such a critical part of an authorization > > tuple. Any token issued prior to the earliest authorization on > > record at the auth server represents a revoked authorization, and > > without an issue date in the tuple there's no way to recognize that. > > > > At least that's the way I'm seeing it. I hope that makes sense. > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > From eran@hueniverse.com Fri Jun 11 08:10:11 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B94E03A6837 for ; Fri, 11 Jun 2010 08:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[AWL=0.672, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtGBVp9tiRtD for ; Fri, 11 Jun 2010 08:10:03 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 08E963A68A3 for ; Fri, 11 Jun 2010 08:10:03 -0700 (PDT) Received: (qmail 6392 invoked from network); 11 Jun 2010 15:10:05 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 11 Jun 2010 15:10:04 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Fri, 11 Jun 2010 08:09:51 -0700 From: Eran Hammer-Lahav To: Marius Scurtescu , "recordond@gmail.com" Date: Fri, 11 Jun 2010 08:09:44 -0700 Thread-Topic: [OAUTH-WG] A display parameter for user authorization requests Thread-Index: AcsJbhI12rADHHouQeWdwfprt1JHHQACg1Xm Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C8379FC835885eranhueniversecom_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] A display parameter for user authorization requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 15:10:11 -0000 --_000_C8379FC835885eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think username needs to be covered in the OpenID Connect spec (i.e. Ident= ity layer on top of OAuth). Just a hint isn't enough. The client needs to b= e able to verify that the server response is what was asked, and also the s= erver needs to inform the client of who logged in. EHL On 6/11/10 6:57 AM, "Marius Scurtescu" wrote: There was discussion about a username hint parameter, in general this is needed when immediate is used. Should username go to this UX Extension, or rather immediate and username should go to a separate one together? Marius On Thu, Jun 10, 2010 at 5:32 PM, David Recordon wrote= : > +1 for moving immediate here as well. > > > On Thu, Jun 10, 2010 at 4:18 PM, Eran Hammer-Lahav = wrote: >> Since these are all extensions to the end-user endpoint, I'd suggest we = move the 'immediate' parameter here as well. >> >> >> >> OPTIONAL. The parameter value must be set to true or >> false. If set to >> true, the authorization ser= ver MUST NOT prompt the >> end-user to authenticate or approve access. Instead, the = authorization server >> attempts to establish the end-user's identity via other m= eans (e.g. browser >> cookies) and checks if the end-user has previously approv= ed an identical access >> request by the same client and if that access grant is st= ill active. If the >> authorization server does not support an immediate check = or if it is unable to >> establish the end-user's identity or approval status, it = MUST deny the request >> without prompting the end-user. Defaults to false if >> omitted. >> >> EHL >> >>> -----Original Message----- >>> From: David Recordon [mailto:recordond@gmail.com] >>> Sent: Wednesday, June 09, 2010 12:06 PM >>> To: Eran Hammer-Lahav; Allen Tom; Breno de Medeiros; Luke Shepard >>> Cc: OAuth WG >>> Subject: Re: [OAUTH-WG] A display parameter for user authorization >>> requests >>> >>> First draft of the UX Extension is at >>> http://github.com/daveman692/OAuth-2.0/raw/master/draft-recordon- >>> oauth-v2-ux-00.txt. >>> >>> Eran, I'm more than happy to have you take over as editor. >>> >>> I included Allen and Breno as authors since I followed Allen's suggesti= on and >>> adopted the language preference parameter from the OpenID extension. I >>> also included Luke as an author since he wrote the first pass of a disp= lay >>> parameter. That said, none of them have seen this draft yet. >>> >>> --David >>> >>> >>> On Tue, Apr 13, 2010 at 12:36 PM, Allen Tom wrote: >>> > At least with regards to the language preference, how about if we jus= t >>> > copy the openid.ui.lang parameter from the OpenID UI Extension? >>> > >>> > http://svn.openid.net/repos/specifications/user_interface/1.0/trunk/o= p >>> > enid-user-interface-extension-1_0.html#anchor3 >>> > >>> > In flows in which the client redirects the user's web browser to >>> > authorize access, the client MAY send the Authorization Server a hint >>> > regarding the user's preferred language by sending the following >>> parameter: >>> > >>> > lang >>> > The user's preferred languages as a [BCP 47] language priorit= y >>> > list, represented as a comma-separated list of BCP 47 basic language >>> > ranges in decending priority order. For instance, the value "fr-CA,fr= -FR,en- >>> CA" >>> > represents the preference for French spoken in Canada, French spoken >>> > in France, followed by English spoken in Canada. >>> > >>> > The language preference hint SHOULD take precedence over the >>> > Accept-Language HTTP header sent by the user's browser, and SHOULD >>> > take precedence over the language preference inferred by the user's I= P >>> Address. >>> > >>> > BCP 47: http://tools.ietf.org/html/bcp47 >>> > >>> > Allen >>> > >>> > >>> > On 4/12/10 1:32 PM, "Eran Hammer-Lahav" >>> wrote: >>> > >>> > Between language preferences, display configuration, and immediate >>> > check, I think it might be worth to move that work to another draft. >>> > Timeline-wise, this has the potential of slowing us down. I also fear >>> > getting what is now a pretty simple spec much more complicated. >>> > >>> > Anyone cares to try a first draft or outline? I can do the editorial >>> > work if needed, but someone needs to write something first. >>> > >>> > 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 > --_000_C8379FC835885eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] A display parameter for user authorization requests</= TITLE> </HEAD> <BODY> <FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:= 11pt'>I think username needs to be covered in the OpenID Connect spec (i.e.= Identity layer on top of OAuth). Just a hint isn’t enough. The clien= t needs to be able to verify that the server response is what was asked, an= d also the server needs to inform the client of who logged in.<BR> <BR> EHL<BR> <BR> <BR> On 6/11/10 6:57 AM, "Marius Scurtescu" <<a href=3D"mscurtescu@= google.com">mscurtescu@google.com</a>> wrote:<BR> <BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"= ><SPAN STYLE=3D'font-size:11pt'>There was discussion about a username hint = parameter, in general this<BR> is needed when immediate is used. Should username go to this UX<BR> Extension, or rather immediate and username should go to a separate<BR> one together?<BR> <BR> Marius<BR> <BR> <BR> <BR> On Thu, Jun 10, 2010 at 5:32 PM, David Recordon <<a href=3D"recordond@gm= ail.com">recordond@gmail.com</a>> wrote:<BR> > +1 for moving immediate here as well.<BR> ><BR> ><BR> > On Thu, Jun 10, 2010 at 4:18 PM, Eran Hammer-Lahav <<a href=3D"eran= @hueniverse.com">eran@hueniverse.com</a>> wrote:<BR> >> Since these are all extensions to the end-user endpoint, I'd sugge= st we move the 'immediate' parameter here as well.<BR> >><BR> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0<t hangText=3D'immediate'><BR> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<vspace /><BR> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0OPTIONAL. The parameter value must = be set to <spanx style=3D'verb'>true</spanx> or<BR> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<spanx style=3D'verb'>false&l= t;/spanx>. If set to<BR> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<spanx style=3D'verb'>true<= ;/spanx>, the authorization server MUST NOT prompt the<BR> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0end-user to authenticate or approve= access. Instead, the authorization server<BR> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0attempts to establish the end-user'= s identity via other means (e.g. browser<BR> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0cookies) and checks if the end-user= has previously approved an identical access<BR> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0request by the same client and if t= hat access grant is still active. If the<BR> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0authorization server does not suppo= rt an immediate check or if it is unable to<BR> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0establish the end-user's identity o= r approval status, it MUST deny the request<BR> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0without prompting the end-user. Def= aults to <spanx style=3D'verb'>false</spanx> if<BR> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0omitted.<BR> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0</t><BR> >> EHL<BR> >><BR> >>> -----Original Message-----<BR> >>> From: David Recordon [<a href=3D"mailto:recordond@gmail.com">m= ailto:recordond@gmail.com</a>]<BR> >>> Sent: Wednesday, June 09, 2010 12:06 PM<BR> >>> To: Eran Hammer-Lahav; Allen Tom; Breno de Medeiros; Luke Shep= ard<BR> >>> Cc: OAuth WG<BR> >>> Subject: Re: [OAUTH-WG] A display parameter for user authoriza= tion<BR> >>> requests<BR> >>><BR> >>> First draft of the UX Extension is at<BR> >>> <a href=3D"http://github.com/daveman692/OAuth-2.0/raw/master/d= raft-recordon-">http://github.com/daveman692/OAuth-2.0/raw/master/draft-rec= ordon-</a><BR> >>> oauth-v2-ux-00.txt.<BR> >>><BR> >>> Eran, I'm more than happy to have you take over as editor.<BR> >>><BR> >>> I included Allen and Breno as authors since I followed Allen's= suggestion and<BR> >>> adopted the language preference parameter from the OpenID exte= nsion. I<BR> >>> also included Luke as an author since he wrote the first pass = of a display<BR> >>> parameter. That said, none of them have seen this draft yet.<B= R> >>><BR> >>> --David<BR> >>><BR> >>><BR> >>> On Tue, Apr 13, 2010 at 12:36 PM, Allen Tom <<a href=3D"ato= m@yahoo-inc.com">atom@yahoo-inc.com</a>> wrote:<BR> >>> > At least with regards to the language preference, how abo= ut if we just<BR> >>> > copy the openid.ui.lang parameter from the OpenID UI Exte= nsion?<BR> >>> ><BR> >>> > <a href=3D"http://svn.openid.net/repos/specifications/use= r_interface/1.0/trunk/op">http://svn.openid.net/repos/specifications/user_i= nterface/1.0/trunk/op</a><BR> >>> > enid-user-interface-extension-1_0.html#anchor3<BR> >>> ><BR> >>> > In flows in which the client redirects the user's web bro= wser to<BR> >>> > authorize access, the client MAY send the Authorization S= erver a hint<BR> >>> > regarding the user's preferred language by sending the fo= llowing<BR> >>> parameter:<BR> >>> ><BR> >>> > =A0=A0=A0=A0lang<BR> >>> > =A0=A0=A0=A0=A0=A0=A0=A0The user's preferred languages as= a [BCP 47] language priority<BR> >>> > list, represented as a comma-separated list of BCP 47 bas= ic language<BR> >>> > ranges in decending priority order. For instance, the val= ue "fr-CA,fr-FR,en-<BR> >>> CA"<BR> >>> > represents the preference for French spoken in Canada, Fr= ench spoken<BR> >>> > in France, followed by English spoken in Canada.<BR> >>> ><BR> >>> > The language preference hint SHOULD take precedence over = the<BR> >>> > Accept-Language HTTP header sent by the user's browser, a= nd SHOULD<BR> >>> > take precedence over the language preference inferred by = the user's IP<BR> >>> Address.<BR> >>> ><BR> >>> > BCP 47: =A0<a href=3D"http://tools.ietf.org/html/bcp47">h= ttp://tools.ietf.org/html/bcp47</a><BR> >>> ><BR> >>> > Allen<BR> >>> ><BR> >>> ><BR> >>> > On 4/12/10 1:32 PM, "Eran Hammer-Lahav" <<a = href=3D"eran@hueniverse.com">eran@hueniverse.com</a>><BR> >>> wrote:<BR> >>> ><BR> >>> > Between language preferences, display configuration, and = immediate<BR> >>> > check, I think it might be worth to move that work to ano= ther draft.<BR> >>> > Timeline-wise, this has the potential of slowing us down.= I also fear<BR> >>> > getting what is now a pretty simple spec much more compli= cated.<BR> >>> ><BR> >>> > Anyone cares to try a first draft or outline? I can do th= e editorial<BR> >>> > work if needed, but someone needs to write something firs= t.<BR> >>> ><BR> >>> > EHL<BR> >>> ><BR> >>> ><BR> >>> ><BR> >>> > _______________________________________________<BR> >>> > OAuth mailing list<BR> >>> > <a href=3D"OAuth@ietf.org">OAuth@ietf.org</a><BR> >>> > <a href=3D"https://www.ietf.org/mailman/listinfo/oauth">h= ttps://www.ietf.org/mailman/listinfo/oauth</a><BR> >>> ><BR> >>> ><BR> >><BR> > _______________________________________________<BR> > OAuth mailing list<BR> > <a href=3D"OAuth@ietf.org">OAuth@ietf.org</a><BR> > <a href=3D"https://www.ietf.org/mailman/listinfo/oauth">https://www.ie= tf.org/mailman/listinfo/oauth</a><BR> ><BR> <BR> </SPAN></FONT></BLOCKQUOTE> </BODY> </HTML> --_000_C8379FC835885eranhueniversecom_-- From mscurtescu@google.com Fri Jun 11 08:20:37 2010 Return-Path: <mscurtescu@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76CA43A6921 for <oauth@core3.amsl.com>; Fri, 11 Jun 2010 08:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.826 X-Spam-Level: X-Spam-Status: No, score=-103.826 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OXCiwY+f86ao for <oauth@core3.amsl.com>; Fri, 11 Jun 2010 08:20:32 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 5B9D13A6970 for <oauth@ietf.org>; Fri, 11 Jun 2010 08:20:30 -0700 (PDT) Received: from kpbe19.cbf.corp.google.com (kpbe19.cbf.corp.google.com [172.25.105.83]) by smtp-out.google.com with ESMTP id o5BFKSgq011171 for <oauth@ietf.org>; Fri, 11 Jun 2010 08:20:28 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1276269628; bh=B7lmA+EckYsoF36x+Gic/IMdx7c=; h=MIME-Version:From:Date:Message-ID:Subject:To:Cc:Content-Type: Content-Transfer-Encoding; b=ta+xcRI/AwNOwzCfdbjsmkzrC8HgCf80uPRYx0a4rRHkNw+LmJ4TyGE1OeRWrf98u qRtH5KUqIqK4eedQQzG0A== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:from:date:message-id:subject:to:cc: content-type:content-transfer-encoding; b=T/faUQhJAODN72ZbaAPARIkOQWX6zGkdQ1Gj1g3857+B3p7WILdqM4kWGDoUuEImN rt8fo6vx7ulurbv5NsJrg== Received: from pxi7 (pxi7.prod.google.com [10.243.27.7]) by kpbe19.cbf.corp.google.com with ESMTP id o5BFKRnN006248 for <oauth@ietf.org>; Fri, 11 Jun 2010 08:20:27 -0700 Received: by pxi7 with SMTP id 7so777421pxi.41 for <oauth@ietf.org>; Fri, 11 Jun 2010 08:20:27 -0700 (PDT) Received: by 10.141.105.7 with SMTP id h7mr1487190rvm.267.1276269627160; Fri, 11 Jun 2010 08:20:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.124.13 with HTTP; Fri, 11 Jun 2010 08:20:07 -0700 (PDT) From: Marius Scurtescu <mscurtescu@google.com> Date: Fri, 11 Jun 2010 08:20:07 -0700 Message-ID: <AANLkTinfFTOumqCp0bIDRr4lOJKtJ3rKuqOBdys5fG1-@mail.gmail.com> To: Justin Richer <jricher@mitre.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "oauth@ietf.org" <oauth@ietf.org> Subject: [OAUTH-WG] unregistered clients (was: User-agent flow and pre-registered redirect_uri) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 11 Jun 2010 15:20:38 -0000 On Fri, Jun 11, 2010 at 8:05 AM, Justin Richer <jricher@mitre.org> wrote: > Along these lines, I'd like to propose an extension for per-client > instance information to be passed from a client to the server. Things > like a human-readable client name/description, instance name/description > (could be tied to host name, ip, label like "home" or "Work"), and even > something like a display icon. This is especially useful for things like > device clients (where I might have a bunch of devices with the same > client ID) or unregistered clients, where the client id string ends up > being closer to a user-agent string from a browser than a trusted > identifier, especially since it can't have a reliable secret. Yes, I think something like this is definitely needed. I suggested an optional client_name parameter exactly for this purpose. For OAuth 1 Google is using a custom parameter. > Speaking of which, the spec is relatively quiet on registered vs. > unregistered clients. I'd like to see the WG maybe pull together some > guidance on this topic? I'm not sure what form that would take though, > an information note that sits along with the RFC? A page on the oauth > wiki? Basically, I think we can get away from the anonymous/anonymous > hack that Google used with OAuth1 since we're not requiring the client > secret for signing anymore. Thoughts? Yes, the secret does not need to be set to "anonymous" anymore, but the client_id still needs a special value in order to signal unregistered mode. Either that, or yet one more parameter, but that could be going too far. Not sure if we can standardize on a value, like "anonymous". It depends what current implementations are using. I think it is perfectly fine for the authz server to define this special client_id. If we want to move all this to an extension, I still think it should be rather in core, then I can write it up. Marius > > =A0-- Justin > > > On Fri, 2010-06-11 at 10:38 -0400, George Fletcher wrote: >> Makes perfect sense as we have the same model for our clients & >> tokens:) >> >> The one use case we've encountered is that this model revokes the >> tokens for all clients with the same client_id. So if I've got three >> of the same client installed (on three computers) and they likely all >> have the same client_id, then revoking that client_id affects all >> three clients. I think this is a reasonable trade-off. Especially >> since revoking authorizations will be an infrequent event. >> >> Thanks, >> George >> >> On 6/10/10 11:35 AM, Andrew Arnott wrote: >> > Thanks Marius. >> > >> > I've answered your question below. >> > >> > On Wed, Jun 9, 2010 at 9:35 AM, Marius Scurtescu >> > <mscurtescu@google.com> wrote: >> > =A0 =A0 =A0 =A0 > I've always considered an authorization as a tuple o= f >> > =A0 =A0 =A0 =A0 > client_id,user,scope,issue_date. =A0If an authorizat= ion has >> > =A0 =A0 =A0 =A0 been approved, and >> > =A0 =A0 =A0 =A0 > another request for authorization for a subset of th= e >> > =A0 =A0 =A0 =A0 scope previously >> > =A0 =A0 =A0 =A0 > issued comes in, the auth server can skip the intera= ctive >> > =A0 =A0 =A0 =A0 user authorization >> > =A0 =A0 =A0 =A0 > and just approve the request since nothing new is be= ing >> > =A0 =A0 =A0 =A0 issued. >> > >> > >> > =A0 =A0 =A0 =A0 The tuple seems right, except for the issue date, why = would >> > =A0 =A0 =A0 =A0 you add that? >> > >> > The issue_date enables to scenarios: expiring tokens and token >> > revocation. =A0Here's how, for each scenario: >> > >> > Obviously to know if a token has expired you need to know when it >> > was issued. =A0Or, you can forget the issue date and just store the >> > expiration date in the token. I choose to go with an issue date >> > (plus an optional expected lifetime) because it gives more ability >> > in the future to say "oops, we had a security weakness in all tokens >> > issued prior to [date], so let's consider all earlier tokens >> > invalid." =A0It's harder to say that when all you have are expiration >> > dates because you don't know how old the token is. =A0This is just the >> > way I chose to do it, but I know there are other ways. >> > >> > Now let's look at how you revoke issued tokens. =A0One of the nice >> > things enabled by OAuth 2.0 is that the authorization server and >> > resource server never have to store tokens if they are appropriate >> > signed by the auth server. =A0This is great because (among other >> > things) clients with little-to-no ability to persistently store >> > tokens may ask for tokens frequently, and that could bog down an >> > auth server with storing all those issued tokens. =A0But how can a >> > user revoke a previously authorized token if no one but the client >> > knows what the tokens are? (thought question) =A0My solution to this >> > is that instead of thinking about revoking tokens, the user revokes >> > authorizations. =A0The user goes through his account on the >> > authorization server and sees a list of clients and what they are >> > authorized to do. =A0Note that this only requires the auth server to >> > store this authorization tuple -- not the actual issued tokens. =A0If >> > the user clicks "revoke" on one of these authorizations, that row is >> > deleted in the database. =A0Issued tokens (both refresh and access >> > tokens) have this same tuple encoded in them. >> > Now, when a refresh token is used to obtain a new short-lived access >> > token (and you could do this on every access token use as well if >> > you wanted) the token is of course signature-validated, but it is >> > also checked that the authorization tuple has a matching tuple in >> > the auth server's database. =A0If it's missing, then that >> > authorization has been revoked and the token is thereby invalidated. >> > So why the issue date? =A0Because suppose the user has authorized a >> > client and then that client's tokens are compromised (stolen >> > computer perhaps). =A0The user will of course revoke authorization for >> > that client. =A0The user then gets a new copy of that client (perhaps >> > a new computer) and authorizes it. =A0Whoops. =A0Now all those >> > invalidated tokens are valid again because the authorization tuple >> > exists. =A0Except now the issue date on the authorization on the auth >> > server is newer than in the refresh token on the invalidated client. >> > That's why issue date is such a critical part of an authorization >> > tuple. =A0Any token issued prior to the earliest authorization on >> > record at the auth server represents a revoked authorization, and >> > without an issue date in the tuple there's no way to recognize that. >> > >> > At least that's the way I'm seeing it. =A0I hope that makes sense. >> > >> > >> > _______________________________________________ >> > OAuth mailing 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 Fri Jun 11 08:34:20 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BBD03A6A0F for <oauth@core3.amsl.com>; Fri, 11 Jun 2010 08:34:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AWL=0.601, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FY1peH-OsFtQ for <oauth@core3.amsl.com>; Fri, 11 Jun 2010 08:34:03 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id C3B423A687C for <oauth@ietf.org>; Fri, 11 Jun 2010 08:33:53 -0700 (PDT) Received: (qmail 5312 invoked from network); 11 Jun 2010 15:33:36 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 11 Jun 2010 15:33:36 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Fri, 11 Jun 2010 08:33:30 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org> Date: Fri, 11 Jun 2010 08:33:27 -0700 Thread-Topic: Device flow to move to an extension Thread-Index: AcsJe3AqrvudyeI9TT2d+2r/CoZzYA== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF757B@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] Device flow to move to an extension X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 11 Jun 2010 15:34:21 -0000 Unlike the rest of the flows, the device flow lacks deployment experience a= nd is still likely to change. It also uses a very different architecture th= an the rest of the flows (which becomes more obvious in my -07 rewrite). Un= less there is strong objection, I am going to remove it from the core spec = and republish it as a new draft. In general, I am going to iterate through the spec in the next couple weeks= and move unstable (and non-essential) features out to extension specs. EHL From cs@comlounge.net Fri Jun 11 08:35:50 2010 Return-Path: <cs@comlounge.net> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E931D28C122 for <oauth@core3.amsl.com>; Fri, 11 Jun 2010 08:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.601 X-Spam-Level: X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_36=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ylau1ZzEoINi for <oauth@core3.amsl.com>; Fri, 11 Jun 2010 08:35:46 -0700 (PDT) Received: from post.comlounge.net (post.comlounge.net [85.214.59.142]) by core3.amsl.com (Postfix) with ESMTP id 9839F28C129 for <oauth@ietf.org>; Fri, 11 Jun 2010 08:35:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by post.comlounge.net (Postfix) with ESMTP id 339E06F409C for <oauth@ietf.org>; Fri, 11 Jun 2010 17:35:20 +0200 (CEST) Received: from post.comlounge.net ([127.0.0.1]) by localhost (h1346004.stratoserver.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WLYMr0Amxf82 for <oauth@ietf.org>; Fri, 11 Jun 2010 17:35:19 +0200 (CEST) Received: from [192.168.2.113] (p5B393361.dip.t-dialin.net [91.57.51.97]) by post.comlounge.net (Postfix) with ESMTPSA id C9C001CE02D8 for <oauth@ietf.org>; Fri, 11 Jun 2010 17:35:18 +0200 (CEST) Message-ID: <4C1257B5.9080706@comlounge.net> Date: Fri, 11 Jun 2010 17:35:17 +0200 From: Christian Scholz <cs@comlounge.net> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; de; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: oauth@ietf.org References: <AANLkTingSGlJNZ5e_stPd1qU5I4gfbh3rQhqYUmqXvdB@mail.gmail.com> <C833CEB4.6B81%cmortimore@salesforce.com> <AANLkTinVQEPBVzmiHEGgHhzaILL0nRSvZpjIlrVEJwTw@mail.gmail.com> <AANLkTil1j7vl8PU2tgCzlWY0U6KiWPmRKiVOxvsctB00@mail.gmail.com> <AANLkTimCL-O7RIsUlt_zGDfkEEYb9w4_sPh6zxCMBsf0@mail.gmail.com> <AANLkTin7B9pPgSu3cNlJGkp_gCed-5aPGRZalzXd2Wg8@mail.gmail.com> <4C124A70.2000002@aol.com> <1276268753.31840.50.camel@localhost.localdomain> In-Reply-To: <1276268753.31840.50.camel@localhost.localdomain> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [OAUTH-WG] User-agent flow and pre-registered redirect_uri X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 11 Jun 2010 15:35:50 -0000 Hi! Am 11.06.10 17:05, schrieb Justin Richer: > Along these lines, I'd like to propose an extension for per-client > instance information to be passed from a client to the server. Things > like a human-readable client name/description, instance name/description > (could be tied to host name, ip, label like "home" or "Work"), and even > something like a display icon. This is especially useful for things like > device clients (where I might have a bunch of devices with the same > client ID) or unregistered clients, where the client id string ends up > being closer to a user-agent string from a browser than a trusted > identifier, especially since it can't have a reliable secret. We have the need for dynamic binding of clients in the User Managed Access group (UMA) as well. I did look into OpenID Connect but felt that reusing an OAuth flow based on a different type is maybe mixing things a bit too much. To me using a flow means that in the end usually you end up with an access token which here is not the case. Especially I don't like the reuse of the token URI as IMHO it's better to use separate endpoints for different APIs. I thus went along and crafted some simple handshake in the UMA specification which I also wanted to move out into a single specification over the next days. You can find it here: http://kantarainitiative.org/confluence/display/~christianscholz/Step+1+experimental+version+v1 under "Dynamic binding of OAuth clients". It is a simple handshake where you provide a JSON formatted client descriptor containing the information you describe above and the results is a set of client credentials plus optionally additional information (in UMA we eventually need to pass back more information like additional endpoints). We also discussed it yesterday on the UMA conference call and the consensus was that it's better to let the server assign a client id so you have a more unique identifier. Moreover it is probably easier to send the client id as intended and not all the relevant client information on every request. Other options would be to use some URL as client id and providing an XRD document describing the client via hostmeta. Any feedback on what people's requirements and thoughts on the issue are welcome! -- Cristian > Speaking of which, the spec is relatively quiet on registered vs. > unregistered clients. I'd like to see the WG maybe pull together some > guidance on this topic? I'm not sure what form that would take though, > an information note that sits along with the RFC? A page on the oauth > wiki? Basically, I think we can get away from the anonymous/anonymous > hack that Google used with OAuth1 since we're not requiring the client > secret for signing anymore. Thoughts? > > -- Justin > > > On Fri, 2010-06-11 at 10:38 -0400, George Fletcher wrote: >> Makes perfect sense as we have the same model for our clients & >> tokens:) >> >> The one use case we've encountered is that this model revokes the >> tokens for all clients with the same client_id. So if I've got three >> of the same client installed (on three computers) and they likely all >> have the same client_id, then revoking that client_id affects all >> three clients. I think this is a reasonable trade-off. Especially >> since revoking authorizations will be an infrequent event. >> >> Thanks, >> George >> >> On 6/10/10 11:35 AM, Andrew Arnott wrote: >>> Thanks Marius. >>> >>> I've answered your question below. >>> >>> On Wed, Jun 9, 2010 at 9:35 AM, Marius Scurtescu >>> <mscurtescu@google.com> wrote: >>> > I've always considered an authorization as a tuple of >>> > client_id,user,scope,issue_date. If an authorization has >>> been approved, and >>> > another request for authorization for a subset of the >>> scope previously >>> > issued comes in, the auth server can skip the interactive >>> user authorization >>> > and just approve the request since nothing new is being >>> issued. >>> >>> >>> The tuple seems right, except for the issue date, why would >>> you add that? >>> >>> The issue_date enables to scenarios: expiring tokens and token >>> revocation. Here's how, for each scenario: >>> >>> Obviously to know if a token has expired you need to know when it >>> was issued. Or, you can forget the issue date and just store the >>> expiration date in the token. I choose to go with an issue date >>> (plus an optional expected lifetime) because it gives more ability >>> in the future to say "oops, we had a security weakness in all tokens >>> issued prior to [date], so let's consider all earlier tokens >>> invalid." It's harder to say that when all you have are expiration >>> dates because you don't know how old the token is. This is just the >>> way I chose to do it, but I know there are other ways. >>> >>> Now let's look at how you revoke issued tokens. One of the nice >>> things enabled by OAuth 2.0 is that the authorization server and >>> resource server never have to store tokens if they are appropriate >>> signed by the auth server. This is great because (among other >>> things) clients with little-to-no ability to persistently store >>> tokens may ask for tokens frequently, and that could bog down an >>> auth server with storing all those issued tokens. But how can a >>> user revoke a previously authorized token if no one but the client >>> knows what the tokens are? (thought question) My solution to this >>> is that instead of thinking about revoking tokens, the user revokes >>> authorizations. The user goes through his account on the >>> authorization server and sees a list of clients and what they are >>> authorized to do. Note that this only requires the auth server to >>> store this authorization tuple -- not the actual issued tokens. If >>> the user clicks "revoke" on one of these authorizations, that row is >>> deleted in the database. Issued tokens (both refresh and access >>> tokens) have this same tuple encoded in them. >>> Now, when a refresh token is used to obtain a new short-lived access >>> token (and you could do this on every access token use as well if >>> you wanted) the token is of course signature-validated, but it is >>> also checked that the authorization tuple has a matching tuple in >>> the auth server's database. If it's missing, then that >>> authorization has been revoked and the token is thereby invalidated. >>> So why the issue date? Because suppose the user has authorized a >>> client and then that client's tokens are compromised (stolen >>> computer perhaps). The user will of course revoke authorization for >>> that client. The user then gets a new copy of that client (perhaps >>> a new computer) and authorizes it. Whoops. Now all those >>> invalidated tokens are valid again because the authorization tuple >>> exists. Except now the issue date on the authorization on the auth >>> server is newer than in the refresh token on the invalidated client. >>> That's why issue date is such a critical part of an authorization >>> tuple. Any token issued prior to the earliest authorization on >>> record at the auth server represents a revoked authorization, and >>> without an issue date in the tuple there's no way to recognize that. >>> >>> At least that's the way I'm seeing it. I hope that makes sense. >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth -- Christian Scholz Homepage: http://comlounge.net COM.lounge GmbH blog: http://mrtopf.de/blog Hanbrucher Str. 33 Skype: HerrTopf 52064 Aachen Video Blog: http://comlounge.tv Tel: +49 241 400 730 0 E-Mail cs@comlounge.net Fax: +49 241 979 00 850 IRC: MrTopf, Tao_T Podcasts: Der OpenWeb-Podcast (http://openwebpodcast.de) Data Without Borders (http://datawithoutborders.net) Politisches: http://politfunk.de/ Technical: http://comlounge.tv/ From wmills@yahoo-inc.com Fri Jun 11 08:44:54 2010 Return-Path: <wmills@yahoo-inc.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26C1E28C10B for <oauth@core3.amsl.com>; Fri, 11 Jun 2010 08:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.313 X-Spam-Level: X-Spam-Status: No, score=-15.313 tagged_above=-999 required=5 tests=[AWL=0.463, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3HS+mfTn99Yo for <oauth@core3.amsl.com>; Fri, 11 Jun 2010 08:44:52 -0700 (PDT) Received: from mrout1-b.corp.re1.yahoo.com (mrout1-b.corp.re1.yahoo.com [69.147.107.20]) by core3.amsl.com (Postfix) with ESMTP id 5F0953A6966 for <oauth@ietf.org>; Fri, 11 Jun 2010 08:44:52 -0700 (PDT) Received: from SNV-EXBH01.ds.corp.yahoo.com (snv-exbh01.ds.corp.yahoo.com [207.126.227.249]) by mrout1-b.corp.re1.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o5BFiUKe033486; Fri, 11 Jun 2010 08:44:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:x-mimeole:content-class:mime-version: content-type:content-transfer-encoding:subject:date:message-id: in-reply-to:x-ms-has-attach:x-ms-tnef-correlator:thread-topic: thread-index:references:from:to:cc:return-path:x-originalarrivaltime; b=JkRwaKBWMCq1YuwaYtAQ1PvMXYgscPlGuohE1hvo5xS4BJy3QSaYbtdQC4/3lB42 Received: from SNV-EXVS08.ds.corp.yahoo.com ([207.126.227.8]) by SNV-EXBH01.ds.corp.yahoo.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 11 Jun 2010 08:44:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 11 Jun 2010 08:44:29 -0700 Message-ID: <012AB2B223CB3F4BB846962876F4721705795B42@SNV-EXVS08.ds.corp.yahoo.com> In-Reply-To: <AANLkTinfFTOumqCp0bIDRr4lOJKtJ3rKuqOBdys5fG1-@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] unregistered clients (was: User-agent flow andpre-registered redirect_uri) Thread-Index: AcsJenQM0AldrTs/SWiE5rcH7E8NlAAAeTsg References: <AANLkTinfFTOumqCp0bIDRr4lOJKtJ3rKuqOBdys5fG1-@mail.gmail.com> From: "William Mills" <wmills@yahoo-inc.com> To: "Marius Scurtescu" <mscurtescu@google.com>, "Justin Richer" <jricher@mitre.org> X-OriginalArrivalTime: 11 Jun 2010 15:44:30.0271 (UTC) FILETIME=[FB0CDCF0:01CB097C] Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] unregistered clients (was: User-agent flow andpre-registered redirect_uri) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 11 Jun 2010 15:44:54 -0000 I am in favor of an optional client_name parameter. I think a client_id = parameter of the form of an HTTP URL, effecttively reserving the prefix = http:// would be sufficient to indicate an unregistered client ID. The = URL could then point to either a favicon type image or an XML doc more = fully describing the client. > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]=20 > On Behalf Of Marius Scurtescu > Sent: Friday, June 11, 2010 8:20 AM > To: Justin Richer > Cc: oauth@ietf.org > Subject: [OAUTH-WG] unregistered clients (was: User-agent=20 > flow andpre-registered redirect_uri) >=20 > On Fri, Jun 11, 2010 at 8:05 AM, Justin Richer=20 > <jricher@mitre.org> wrote: > > Along these lines, I'd like to propose an extension for per-client=20 > > instance information to be passed from a client to the=20 > server. Things=20 > > like a human-readable client name/description, instance=20 > > name/description (could be tied to host name, ip, label=20 > like "home" or=20 > > "Work"), and even something like a display icon. This is especially=20 > > useful for things like device clients (where I might have a=20 > bunch of=20 > > devices with the same client ID) or unregistered clients, where the=20 > > client id string ends up being closer to a user-agent string from a=20 > > browser than a trusted identifier, especially since it=20 > can't have a reliable secret. >=20 > Yes, I think something like this is definitely needed. I=20 > suggested an optional client_name parameter exactly for this=20 > purpose. For OAuth 1 Google is using a custom parameter. >=20 >=20 > > Speaking of which, the spec is relatively quiet on registered vs. > > unregistered clients. I'd like to see the WG maybe pull=20 > together some=20 > > guidance on this topic? I'm not sure what form that would=20 > take though,=20 > > an information note that sits along with the RFC? A page on=20 > the oauth=20 > > wiki? Basically, I think we can get away from the=20 > anonymous/anonymous=20 > > hack that Google used with OAuth1 since we're not requiring=20 > the client=20 > > secret for signing anymore. Thoughts? >=20 > Yes, the secret does not need to be set to "anonymous"=20 > anymore, but the client_id still needs a special value in=20 > order to signal unregistered mode. Either that, or yet one=20 > more parameter, but that could be going too far. >=20 > Not sure if we can standardize on a value, like "anonymous".=20 > It depends what current implementations are using. I think it=20 > is perfectly fine for the authz server to define this special=20 > client_id. >=20 > If we want to move all this to an extension, I still think it=20 > should be rather in core, then I can write it up. >=20 > Marius >=20 > > > > =A0-- Justin > > > > > > On Fri, 2010-06-11 at 10:38 -0400, George Fletcher wrote: > >> Makes perfect sense as we have the same model for our clients & > >> tokens:) > >> > >> The one use case we've encountered is that this model revokes the=20 > >> tokens for all clients with the same client_id. So if I've=20 > got three=20 > >> of the same client installed (on three computers) and they=20 > likely all=20 > >> have the same client_id, then revoking that client_id affects all=20 > >> three clients. I think this is a reasonable trade-off. Especially=20 > >> since revoking authorizations will be an infrequent event. > >> > >> Thanks, > >> George > >> > >> On 6/10/10 11:35 AM, Andrew Arnott wrote: > >> > Thanks Marius. > >> > > >> > I've answered your question below. > >> > > >> > On Wed, Jun 9, 2010 at 9:35 AM, Marius Scurtescu=20 > >> > <mscurtescu@google.com> wrote: > >> > =A0 =A0 =A0 =A0 > I've always considered an authorization as a = tuple of > >> > =A0 =A0 =A0 =A0 > client_id,user,scope,issue_date. =A0If an=20 > authorization has > >> > =A0 =A0 =A0 =A0 been approved, and > >> > =A0 =A0 =A0 =A0 > another request for authorization for a subset = of the > >> > =A0 =A0 =A0 =A0 scope previously > >> > =A0 =A0 =A0 =A0 > issued comes in, the auth server can skip the=20 > interactive > >> > =A0 =A0 =A0 =A0 user authorization > >> > =A0 =A0 =A0 =A0 > and just approve the request since nothing new = is being > >> > =A0 =A0 =A0 =A0 issued. > >> > > >> > > >> > =A0 =A0 =A0 =A0 The tuple seems right, except for the issue=20 > date, why would > >> > =A0 =A0 =A0 =A0 you add that? > >> > > >> > The issue_date enables to scenarios: expiring tokens and token=20 > >> > revocation. =A0Here's how, for each scenario: > >> > > >> > Obviously to know if a token has expired you need to=20 > know when it=20 > >> > was issued. =A0Or, you can forget the issue date and just=20 > store the=20 > >> > expiration date in the token. I choose to go with an issue date=20 > >> > (plus an optional expected lifetime) because it gives=20 > more ability=20 > >> > in the future to say "oops, we had a security weakness in all=20 > >> > tokens issued prior to [date], so let's consider all=20 > earlier tokens=20 > >> > invalid." =A0It's harder to say that when all you have are=20 > expiration=20 > >> > dates because you don't know how old the token is. =A0This is = just=20 > >> > the way I chose to do it, but I know there are other ways. > >> > > >> > Now let's look at how you revoke issued tokens. =A0One of the = nice=20 > >> > things enabled by OAuth 2.0 is that the authorization server and=20 > >> > resource server never have to store tokens if they are=20 > appropriate=20 > >> > signed by the auth server. =A0This is great because (among other > >> > things) clients with little-to-no ability to persistently store=20 > >> > tokens may ask for tokens frequently, and that could bog down an=20 > >> > auth server with storing all those issued tokens. =A0But how can = a=20 > >> > user revoke a previously authorized token if no one but=20 > the client=20 > >> > knows what the tokens are? (thought question) =A0My=20 > solution to this=20 > >> > is that instead of thinking about revoking tokens, the=20 > user revokes=20 > >> > authorizations. =A0The user goes through his account on the=20 > >> > authorization server and sees a list of clients and what=20 > they are=20 > >> > authorized to do. =A0Note that this only requires the auth=20 > server to=20 > >> > store this authorization tuple -- not the actual issued=20 > tokens. =A0If=20 > >> > the user clicks "revoke" on one of these authorizations,=20 > that row=20 > >> > is deleted in the database. =A0Issued tokens (both refresh=20 > and access > >> > tokens) have this same tuple encoded in them. > >> > Now, when a refresh token is used to obtain a new short-lived=20 > >> > access token (and you could do this on every access token use as=20 > >> > well if you wanted) the token is of course=20 > signature-validated, but=20 > >> > it is also checked that the authorization tuple has a matching=20 > >> > tuple in the auth server's database. =A0If it's missing, then = that=20 > >> > authorization has been revoked and the token is thereby=20 > invalidated. > >> > So why the issue date? =A0Because suppose the user has=20 > authorized a=20 > >> > client and then that client's tokens are compromised (stolen=20 > >> > computer perhaps). =A0The user will of course revoke = authorization=20 > >> > for that client. =A0The user then gets a new copy of that client=20 > >> > (perhaps a new computer) and authorizes it. =A0Whoops. =A0 > Now all those=20 > >> > invalidated tokens are valid again because the=20 > authorization tuple=20 > >> > exists. =A0Except now the issue date on the authorization=20 > on the auth=20 > >> > server is newer than in the refresh token on the=20 > invalidated client. > >> > That's why issue date is such a critical part of an=20 > authorization=20 > >> > tuple. =A0Any token issued prior to the earliest authorization on = > >> > record at the auth server represents a revoked=20 > authorization, and=20 > >> > without an issue date in the tuple there's no way to=20 > recognize that. > >> > > >> > At least that's the way I'm seeing it. =A0I hope that makes = sense. > >> > > >> > > >> > _______________________________________________ > >> > OAuth mailing list > >> > OAuth@ietf.org > >> > https://www.ietf.org/mailman/listinfo/oauth > >> > > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 From gffletch@aol.com Fri Jun 11 08:52:32 2010 Return-Path: <gffletch@aol.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 781093A6966 for <oauth@core3.amsl.com>; Fri, 11 Jun 2010 08:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.122 X-Spam-Level: X-Spam-Status: No, score=-0.122 tagged_above=-999 required=5 tests=[AWL=-0.123, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OLU7QoI5OJWl for <oauth@core3.amsl.com>; Fri, 11 Jun 2010 08:52:29 -0700 (PDT) Received: from imr-db02.mx.aol.com (imr-db02.mx.aol.com [205.188.91.96]) by core3.amsl.com (Postfix) with ESMTP id 82BFF3A68DA for <oauth@ietf.org>; Fri, 11 Jun 2010 08:52:29 -0700 (PDT) Received: from mtaout-da05.r1000.mx.aol.com (mtaout-da05.r1000.mx.aol.com [172.29.51.133]) by imr-db02.mx.aol.com (8.14.1/8.14.1) with ESMTP id o5BFq34h018682 for <oauth@ietf.org>; Fri, 11 Jun 2010 11:52:06 -0400 Received: from palantir.local (unknown [10.172.1.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-da05.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 918A1E000100 for <oauth@ietf.org>; Fri, 11 Jun 2010 11:52:06 -0400 (EDT) Message-ID: <4C125BA5.6090907@aol.com> Date: Fri, 11 Jun 2010 11:52:05 -0400 From: George Fletcher <gffletch@aol.com> Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: oauth@ietf.org References: <AANLkTingSGlJNZ5e_stPd1qU5I4gfbh3rQhqYUmqXvdB@mail.gmail.com> <C833CEB4.6B81%cmortimore@salesforce.com> <AANLkTinVQEPBVzmiHEGgHhzaILL0nRSvZpjIlrVEJwTw@mail.gmail.com> <AANLkTil1j7vl8PU2tgCzlWY0U6KiWPmRKiVOxvsctB00@mail.gmail.com> <AANLkTimCL-O7RIsUlt_zGDfkEEYb9w4_sPh6zxCMBsf0@mail.gmail.com> <AANLkTin7B9pPgSu3cNlJGkp_gCed-5aPGRZalzXd2Wg8@mail.gmail.com> <4C124A70.2000002@aol.com> <1276268753.31840.50.camel@localhost.localdomain> <4C1257B5.9080706@comlounge.net> In-Reply-To: <4C1257B5.9080706@comlounge.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit x-aol-global-disposition: G X-AOL-SCOLL-SCORE: 0:2:492715680:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d33854c125ba63c53 X-AOL-IP: 10.172.1.149 Subject: Re: [OAUTH-WG] User-agent flow and pre-registered redirect_uri X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 11 Jun 2010 15:52:32 -0000 +1 for "dynamic registration" On 6/11/10 11:35 AM, Christian Scholz wrote: > Hi! > > Am 11.06.10 17:05, schrieb Justin Richer: > >> Along these lines, I'd like to propose an extension for per-client >> instance information to be passed from a client to the server. Things >> like a human-readable client name/description, instance name/description >> (could be tied to host name, ip, label like "home" or "Work"), and even >> something like a display icon. This is especially useful for things like >> device clients (where I might have a bunch of devices with the same >> client ID) or unregistered clients, where the client id string ends up >> being closer to a user-agent string from a browser than a trusted >> identifier, especially since it can't have a reliable secret. >> > We have the need for dynamic binding of clients in the User Managed > Access group (UMA) as well. I did look into OpenID Connect but felt that > reusing an OAuth flow based on a different type is maybe mixing things a > bit too much. To me using a flow means that in the end usually > you end up with an access token which here is not the case. Especially I > don't like the reuse of the token URI as IMHO it's better to use > separate endpoints for different APIs. > > I thus went along and crafted some simple handshake in the UMA > specification which I also wanted to move out into a single > specification over the next days. > > You can find it here: > > http://kantarainitiative.org/confluence/display/~christianscholz/Step+1+experimental+version+v1 > > under "Dynamic binding of OAuth clients". > > It is a simple handshake where you provide a JSON formatted client > descriptor containing the information you describe above and the results > is a set of client credentials plus optionally additional information > (in UMA we eventually need to pass back more information like additional > endpoints). > > We also discussed it yesterday on the UMA conference call and the > consensus was that it's better to let the server assign a client id so > you have a more unique identifier. > > Moreover it is probably easier to send the client id as intended and not > all the relevant client information on every request. > > Other options would be to use some URL as client id and providing an XRD > document describing the client via hostmeta. > > Any feedback on what people's requirements and thoughts on the issue are > welcome! > > -- Cristian > > > >> Speaking of which, the spec is relatively quiet on registered vs. >> unregistered clients. I'd like to see the WG maybe pull together some >> guidance on this topic? I'm not sure what form that would take though, >> an information note that sits along with the RFC? A page on the oauth >> wiki? Basically, I think we can get away from the anonymous/anonymous >> hack that Google used with OAuth1 since we're not requiring the client >> secret for signing anymore. Thoughts? >> >> -- Justin >> >> >> On Fri, 2010-06-11 at 10:38 -0400, George Fletcher wrote: >> >>> Makes perfect sense as we have the same model for our clients& >>> tokens:) >>> >>> The one use case we've encountered is that this model revokes the >>> tokens for all clients with the same client_id. So if I've got three >>> of the same client installed (on three computers) and they likely all >>> have the same client_id, then revoking that client_id affects all >>> three clients. I think this is a reasonable trade-off. Especially >>> since revoking authorizations will be an infrequent event. >>> >>> Thanks, >>> George >>> >>> On 6/10/10 11:35 AM, Andrew Arnott wrote: >>> >>>> Thanks Marius. >>>> >>>> I've answered your question below. >>>> >>>> On Wed, Jun 9, 2010 at 9:35 AM, Marius Scurtescu >>>> <mscurtescu@google.com> wrote: >>>> > I've always considered an authorization as a tuple of >>>> > client_id,user,scope,issue_date. If an authorization has >>>> been approved, and >>>> > another request for authorization for a subset of the >>>> scope previously >>>> > issued comes in, the auth server can skip the interactive >>>> user authorization >>>> > and just approve the request since nothing new is being >>>> issued. >>>> >>>> >>>> The tuple seems right, except for the issue date, why would >>>> you add that? >>>> >>>> The issue_date enables to scenarios: expiring tokens and token >>>> revocation. Here's how, for each scenario: >>>> >>>> Obviously to know if a token has expired you need to know when it >>>> was issued. Or, you can forget the issue date and just store the >>>> expiration date in the token. I choose to go with an issue date >>>> (plus an optional expected lifetime) because it gives more ability >>>> in the future to say "oops, we had a security weakness in all tokens >>>> issued prior to [date], so let's consider all earlier tokens >>>> invalid." It's harder to say that when all you have are expiration >>>> dates because you don't know how old the token is. This is just the >>>> way I chose to do it, but I know there are other ways. >>>> >>>> Now let's look at how you revoke issued tokens. One of the nice >>>> things enabled by OAuth 2.0 is that the authorization server and >>>> resource server never have to store tokens if they are appropriate >>>> signed by the auth server. This is great because (among other >>>> things) clients with little-to-no ability to persistently store >>>> tokens may ask for tokens frequently, and that could bog down an >>>> auth server with storing all those issued tokens. But how can a >>>> user revoke a previously authorized token if no one but the client >>>> knows what the tokens are? (thought question) My solution to this >>>> is that instead of thinking about revoking tokens, the user revokes >>>> authorizations. The user goes through his account on the >>>> authorization server and sees a list of clients and what they are >>>> authorized to do. Note that this only requires the auth server to >>>> store this authorization tuple -- not the actual issued tokens. If >>>> the user clicks "revoke" on one of these authorizations, that row is >>>> deleted in the database. Issued tokens (both refresh and access >>>> tokens) have this same tuple encoded in them. >>>> Now, when a refresh token is used to obtain a new short-lived access >>>> token (and you could do this on every access token use as well if >>>> you wanted) the token is of course signature-validated, but it is >>>> also checked that the authorization tuple has a matching tuple in >>>> the auth server's database. If it's missing, then that >>>> authorization has been revoked and the token is thereby invalidated. >>>> So why the issue date? Because suppose the user has authorized a >>>> client and then that client's tokens are compromised (stolen >>>> computer perhaps). The user will of course revoke authorization for >>>> that client. The user then gets a new copy of that client (perhaps >>>> a new computer) and authorizes it. Whoops. Now all those >>>> invalidated tokens are valid again because the authorization tuple >>>> exists. Except now the issue date on the authorization on the auth >>>> server is newer than in the refresh token on the invalidated client. >>>> That's why issue date is such a critical part of an authorization >>>> tuple. Any token issued prior to the earliest authorization on >>>> record at the auth server represents a revoked authorization, and >>>> without an issue date in the tuple there's no way to recognize that. >>>> >>>> At least that's the way I'm seeing it. I hope that makes sense. >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing 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 jricher@mitre.org Fri Jun 11 08:52:36 2010 Return-Path: <jricher@mitre.org> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C61428C0EE for <oauth@core3.amsl.com>; Fri, 11 Jun 2010 08:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.442 X-Spam-Level: X-Spam-Status: No, score=-4.442 tagged_above=-999 required=5 tests=[AWL=-1.043, BAYES_50=0.001, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id euWYSOFzFwcw for <oauth@core3.amsl.com>; Fri, 11 Jun 2010 08:52:34 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 056233A6966 for <oauth@ietf.org>; Fri, 11 Jun 2010 08:52:33 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o5BFqaJ1014393 for <oauth@ietf.org>; Fri, 11 Jun 2010 11:52:36 -0400 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o5BFqaJD014385; Fri, 11 Jun 2010 11:52:36 -0400 Received: from [129.83.50.65] (129.83.50.65) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server id 8.2.254.0; Fri, 11 Jun 2010 11:52:35 -0400 From: Justin Richer <jricher@mitre.org> To: Christian Scholz <cs@comlounge.net> In-Reply-To: <4C1257B5.9080706@comlounge.net> References: <AANLkTingSGlJNZ5e_stPd1qU5I4gfbh3rQhqYUmqXvdB@mail.gmail.com> <C833CEB4.6B81%cmortimore@salesforce.com> <AANLkTinVQEPBVzmiHEGgHhzaILL0nRSvZpjIlrVEJwTw@mail.gmail.com> <AANLkTil1j7vl8PU2tgCzlWY0U6KiWPmRKiVOxvsctB00@mail.gmail.com> <AANLkTimCL-O7RIsUlt_zGDfkEEYb9w4_sPh6zxCMBsf0@mail.gmail.com> <AANLkTin7B9pPgSu3cNlJGkp_gCed-5aPGRZalzXd2Wg8@mail.gmail.com> <4C124A70.2000002@aol.com> <1276268753.31840.50.camel@localhost.localdomain> <4C1257B5.9080706@comlounge.net> Content-Type: text/plain; charset="UTF-8" Date: Fri, 11 Jun 2010 11:52:35 -0400 Message-ID: <1276271555.31840.61.camel@localhost.localdomain> MIME-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org" <oauth@ietf.org> Subject: Re: [OAUTH-WG] User-agent flow and pre-registered redirect_uri X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 11 Jun 2010 15:52:36 -0000 One missing point from this is that the same client ID could be used for different instances for the same user. That's how google's xoauth_display_name was used, and that's what I'm proposing as an extension to the capability below. Unregistered clients are a separate, but slightly related, issue, and the handshake proposal outlined here might help that (or the dynamic binding proposed as part of OpenID Connect). But I think that we might be better served to have a means that doesn't require registration at all. I think we can get the functionality of just using "anonymous" as the client id without requiring all clients to do so, again like a browser user agent string can do today. It can't be trusted as authoritative, but can be used as a hint. And of course, any particular AS may choose to require registration still. Maybe we need to drill in to the pros/cons of requiring registration, allowing ad-hoc registration, and allowing unknown client ids before we can answer this question. -- Justin On Fri, 2010-06-11 at 11:35 -0400, Christian Scholz wrote: > Hi! > > Am 11.06.10 17:05, schrieb Justin Richer: > > Along these lines, I'd like to propose an extension for per-client > > instance information to be passed from a client to the server. Things > > like a human-readable client name/description, instance name/description > > (could be tied to host name, ip, label like "home" or "Work"), and even > > something like a display icon. This is especially useful for things like > > device clients (where I might have a bunch of devices with the same > > client ID) or unregistered clients, where the client id string ends up > > being closer to a user-agent string from a browser than a trusted > > identifier, especially since it can't have a reliable secret. > > We have the need for dynamic binding of clients in the User Managed > Access group (UMA) as well. I did look into OpenID Connect but felt that > reusing an OAuth flow based on a different type is maybe mixing things a > bit too much. To me using a flow means that in the end usually > you end up with an access token which here is not the case. Especially I > don't like the reuse of the token URI as IMHO it's better to use > separate endpoints for different APIs. > > I thus went along and crafted some simple handshake in the UMA > specification which I also wanted to move out into a single > specification over the next days. > > You can find it here: > > http://kantarainitiative.org/confluence/display/~christianscholz/Step+1+experimental+version+v1 > > under "Dynamic binding of OAuth clients". > > It is a simple handshake where you provide a JSON formatted client > descriptor containing the information you describe above and the results > is a set of client credentials plus optionally additional information > (in UMA we eventually need to pass back more information like additional > endpoints). > > We also discussed it yesterday on the UMA conference call and the > consensus was that it's better to let the server assign a client id so > you have a more unique identifier. > > Moreover it is probably easier to send the client id as intended and not > all the relevant client information on every request. > > Other options would be to use some URL as client id and providing an XRD > document describing the client via hostmeta. > > Any feedback on what people's requirements and thoughts on the issue are > welcome! > > -- Cristian > > > > Speaking of which, the spec is relatively quiet on registered vs. > > unregistered clients. I'd like to see the WG maybe pull together some > > guidance on this topic? I'm not sure what form that would take though, > > an information note that sits along with the RFC? A page on the oauth > > wiki? Basically, I think we can get away from the anonymous/anonymous > > hack that Google used with OAuth1 since we're not requiring the client > > secret for signing anymore. Thoughts? > > > > -- Justin > > > > > > On Fri, 2010-06-11 at 10:38 -0400, George Fletcher wrote: > >> Makes perfect sense as we have the same model for our clients & > >> tokens:) > >> > >> The one use case we've encountered is that this model revokes the > >> tokens for all clients with the same client_id. So if I've got three > >> of the same client installed (on three computers) and they likely all > >> have the same client_id, then revoking that client_id affects all > >> three clients. I think this is a reasonable trade-off. Especially > >> since revoking authorizations will be an infrequent event. > >> > >> Thanks, > >> George > >> > >> On 6/10/10 11:35 AM, Andrew Arnott wrote: > >>> Thanks Marius. > >>> > >>> I've answered your question below. > >>> > >>> On Wed, Jun 9, 2010 at 9:35 AM, Marius Scurtescu > >>> <mscurtescu@google.com> wrote: > >>> > I've always considered an authorization as a tuple of > >>> > client_id,user,scope,issue_date. If an authorization has > >>> been approved, and > >>> > another request for authorization for a subset of the > >>> scope previously > >>> > issued comes in, the auth server can skip the interactive > >>> user authorization > >>> > and just approve the request since nothing new is being > >>> issued. > >>> > >>> > >>> The tuple seems right, except for the issue date, why would > >>> you add that? > >>> > >>> The issue_date enables to scenarios: expiring tokens and token > >>> revocation. Here's how, for each scenario: > >>> > >>> Obviously to know if a token has expired you need to know when it > >>> was issued. Or, you can forget the issue date and just store the > >>> expiration date in the token. I choose to go with an issue date > >>> (plus an optional expected lifetime) because it gives more ability > >>> in the future to say "oops, we had a security weakness in all tokens > >>> issued prior to [date], so let's consider all earlier tokens > >>> invalid." It's harder to say that when all you have are expiration > >>> dates because you don't know how old the token is. This is just the > >>> way I chose to do it, but I know there are other ways. > >>> > >>> Now let's look at how you revoke issued tokens. One of the nice > >>> things enabled by OAuth 2.0 is that the authorization server and > >>> resource server never have to store tokens if they are appropriate > >>> signed by the auth server. This is great because (among other > >>> things) clients with little-to-no ability to persistently store > >>> tokens may ask for tokens frequently, and that could bog down an > >>> auth server with storing all those issued tokens. But how can a > >>> user revoke a previously authorized token if no one but the client > >>> knows what the tokens are? (thought question) My solution to this > >>> is that instead of thinking about revoking tokens, the user revokes > >>> authorizations. The user goes through his account on the > >>> authorization server and sees a list of clients and what they are > >>> authorized to do. Note that this only requires the auth server to > >>> store this authorization tuple -- not the actual issued tokens. If > >>> the user clicks "revoke" on one of these authorizations, that row is > >>> deleted in the database. Issued tokens (both refresh and access > >>> tokens) have this same tuple encoded in them. > >>> Now, when a refresh token is used to obtain a new short-lived access > >>> token (and you could do this on every access token use as well if > >>> you wanted) the token is of course signature-validated, but it is > >>> also checked that the authorization tuple has a matching tuple in > >>> the auth server's database. If it's missing, then that > >>> authorization has been revoked and the token is thereby invalidated. > >>> So why the issue date? Because suppose the user has authorized a > >>> client and then that client's tokens are compromised (stolen > >>> computer perhaps). The user will of course revoke authorization for > >>> that client. The user then gets a new copy of that client (perhaps > >>> a new computer) and authorizes it. Whoops. Now all those > >>> invalidated tokens are valid again because the authorization tuple > >>> exists. Except now the issue date on the authorization on the auth > >>> server is newer than in the refresh token on the invalidated client. > >>> That's why issue date is such a critical part of an authorization > >>> tuple. Any token issued prior to the earliest authorization on > >>> record at the auth server represents a revoked authorization, and > >>> without an issue date in the tuple there's no way to recognize that. > >>> > >>> At least that's the way I'm seeing it. I hope that makes sense. > >>> > >>> > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth > >>> > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > -- > Christian Scholz Homepage: http://comlounge.net > COM.lounge GmbH blog: http://mrtopf.de/blog > Hanbrucher Str. 33 Skype: HerrTopf > 52064 Aachen Video Blog: http://comlounge.tv > Tel: +49 241 400 730 0 E-Mail cs@comlounge.net > Fax: +49 241 979 00 850 IRC: MrTopf, Tao_T > > Podcasts: > Der OpenWeb-Podcast (http://openwebpodcast.de) > Data Without Borders (http://datawithoutborders.net) > Politisches: http://politfunk.de/ > Technical: http://comlounge.tv/ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From mscurtescu@google.com Fri Jun 11 08:54:36 2010 Return-Path: <mscurtescu@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9FE53A6987 for <oauth@core3.amsl.com>; Fri, 11 Jun 2010 08:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.251 X-Spam-Level: X-Spam-Status: No, score=-104.251 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ppKCHX-CUdhB for <oauth@core3.amsl.com>; Fri, 11 Jun 2010 08:54:30 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id B91DB3A6983 for <oauth@ietf.org>; Fri, 11 Jun 2010 08:54:30 -0700 (PDT) Received: from hpaq1.eem.corp.google.com (hpaq1.eem.corp.google.com [172.25.149.1]) by smtp-out.google.com with ESMTP id o5BFsWoF025934 for <oauth@ietf.org>; Fri, 11 Jun 2010 08:54:32 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1276271672; bh=KKrublRzeIfqmsona1vs+LYWk28=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=n2i6+evggjRRjwNtitFcvrXxerP2Zr+hCWJUsQ66iUKpu5TfRSYdywjMAQ8KZfJ7E YAf2Gs4nVjsyRSBl6JnYA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type; b=QSu/ptUGAMETpAdLLFuXSx5/N/IOyDVSgeF1blo0/6b4zA3ilzdbw/Fn/bbrMH/GX dO5KRkaZOHDNKtDN68LCw== Received: from pwi2 (pwi2.prod.google.com [10.241.219.2]) by hpaq1.eem.corp.google.com with ESMTP id o5BFsUWa010899 for <oauth@ietf.org>; Fri, 11 Jun 2010 08:54:31 -0700 Received: by pwi2 with SMTP id 2so662246pwi.6 for <oauth@ietf.org>; Fri, 11 Jun 2010 08:54:30 -0700 (PDT) Received: by 10.141.105.7 with SMTP id h7mr1522468rvm.267.1276271670091; Fri, 11 Jun 2010 08:54:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.124.13 with HTTP; Fri, 11 Jun 2010 08:54:10 -0700 (PDT) In-Reply-To: <4C1257B5.9080706@comlounge.net> References: <AANLkTingSGlJNZ5e_stPd1qU5I4gfbh3rQhqYUmqXvdB@mail.gmail.com> <C833CEB4.6B81%cmortimore@salesforce.com> <AANLkTinVQEPBVzmiHEGgHhzaILL0nRSvZpjIlrVEJwTw@mail.gmail.com> <AANLkTil1j7vl8PU2tgCzlWY0U6KiWPmRKiVOxvsctB00@mail.gmail.com> <AANLkTimCL-O7RIsUlt_zGDfkEEYb9w4_sPh6zxCMBsf0@mail.gmail.com> <AANLkTin7B9pPgSu3cNlJGkp_gCed-5aPGRZalzXd2Wg8@mail.gmail.com> <4C124A70.2000002@aol.com> <1276268753.31840.50.camel@localhost.localdomain> <4C1257B5.9080706@comlounge.net> From: Marius Scurtescu <mscurtescu@google.com> Date: Fri, 11 Jun 2010 08:54:10 -0700 Message-ID: <AANLkTilcpAw7hZuQK43_ybS-wy3bQnPqMfRXOdqY4iYa@mail.gmail.com> To: Christian Scholz <cs@comlounge.net> Content-Type: text/plain; charset=ISO-8859-1 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] User-agent flow and pre-registered redirect_uri X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 11 Jun 2010 15:54:36 -0000 On Fri, Jun 11, 2010 at 8:35 AM, Christian Scholz <cs@comlounge.net> wrote: > Hi! > > Am 11.06.10 17:05, schrieb Justin Richer: >> Along these lines, I'd like to propose an extension for per-client >> instance information to be passed from a client to the server. Things >> like a human-readable client name/description, instance name/description >> (could be tied to host name, ip, label like "home" or "Work"), and even >> something like a display icon. This is especially useful for things like >> device clients (where I might have a bunch of devices with the same >> client ID) or unregistered clients, where the client id string ends up >> being closer to a user-agent string from a browser than a trusted >> identifier, especially since it can't have a reliable secret. > > We have the need for dynamic binding of clients in the User Managed > Access group (UMA) as well. I did look into OpenID Connect but felt that > reusing an OAuth flow based on a different type is maybe mixing things a > bit too much. To me using a flow means that in the end usually > you end up with an access token which here is not the case. Especially I > don't like the reuse of the token URI as IMHO it's better to use > separate endpoints for different APIs. > > I thus went along and crafted some simple handshake in the UMA > specification which I also wanted to move out into a single > specification over the next days. > > You can find it here: > > http://kantarainitiative.org/confluence/display/~christianscholz/Step+1+experimental+version+v1 > > under "Dynamic binding of OAuth clients". > > It is a simple handshake where you provide a JSON formatted client > descriptor containing the information you describe above and the results > is a set of client credentials plus optionally additional information > (in UMA we eventually need to pass back more information like additional > endpoints). In general during registration an authz server will verify that the client really owns the domain it claims it does. Does any validation like that happen in the suggested "Dynamic binding of OAuth clients"? Marius From recordond@gmail.com Fri Jun 11 08:59:09 2010 Return-Path: <recordond@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 538553A695F for <oauth@core3.amsl.com>; Fri, 11 Jun 2010 08:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[AWL=0.588, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9fCHTgiZ8pUi for <oauth@core3.amsl.com>; Fri, 11 Jun 2010 08:59:08 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id E77B13A68A3 for <oauth@ietf.org>; Fri, 11 Jun 2010 08:59:07 -0700 (PDT) Received: by iwn42 with SMTP id 42so1309976iwn.31 for <oauth@ietf.org>; Fri, 11 Jun 2010 08:59:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=SVa5ut9TzLP2e9T89MxcjvVsiKASHP94IMpTz7PMsoI=; b=DHr85nr/hYiWH7CkoT6hDydHnO/Omo1u9azgQHSqTOO+VR3MSSERLyz0wftN8vSJGG AHhVG+8SvLqF6l24Z5UnVaYeug5MaB/6lQhr6Sd0ALWM5Ckyx8eRmXeWQH34gNTZJepu becHrsk+QEPKjfh2Yv/QW/3Xdbl+4egaq9oy0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=wK0/9wNHRUmdcGGtH6j4nYd1M8K928VcDo0H64kDtglLvTuOssxV7eEQ/nsFFeBdbI 04bW8DShv/awCIthg9KaxYAO5Aoof1KhM0U1HhI9VpB5roQ6lB9etdW3OMwJGZIEmKGw k8k5glYTOr9j0E4a2u9lNNDC+ObgbvPQPHpXU= MIME-Version: 1.0 Received: by 10.231.59.75 with SMTP id k11mr1974569ibh.100.1276271946693; Fri, 11 Jun 2010 08:59:06 -0700 (PDT) Received: by 10.231.192.4 with HTTP; Fri, 11 Jun 2010 08:59:06 -0700 (PDT) In-Reply-To: <AANLkTilcpAw7hZuQK43_ybS-wy3bQnPqMfRXOdqY4iYa@mail.gmail.com> References: <AANLkTingSGlJNZ5e_stPd1qU5I4gfbh3rQhqYUmqXvdB@mail.gmail.com> <C833CEB4.6B81%cmortimore@salesforce.com> <AANLkTinVQEPBVzmiHEGgHhzaILL0nRSvZpjIlrVEJwTw@mail.gmail.com> <AANLkTil1j7vl8PU2tgCzlWY0U6KiWPmRKiVOxvsctB00@mail.gmail.com> <AANLkTimCL-O7RIsUlt_zGDfkEEYb9w4_sPh6zxCMBsf0@mail.gmail.com> <AANLkTin7B9pPgSu3cNlJGkp_gCed-5aPGRZalzXd2Wg8@mail.gmail.com> <4C124A70.2000002@aol.com> <1276268753.31840.50.camel@localhost.localdomain> <4C1257B5.9080706@comlounge.net> <AANLkTilcpAw7hZuQK43_ybS-wy3bQnPqMfRXOdqY4iYa@mail.gmail.com> Date: Fri, 11 Jun 2010 08:59:06 -0700 Message-ID: <AANLkTimGnTj1HseMsPBaRXjBThM3uktqq0R6P30jsjaZ@mail.gmail.com> From: David Recordon <recordond@gmail.com> To: Marius Scurtescu <mscurtescu@google.com> Content-Type: text/plain; charset=ISO-8859-1 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] User-agent flow and pre-registered redirect_uri X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 11 Jun 2010 15:59:09 -0000 That sounds like a security consideration to me! :) I imagine that authorization servers will verify ownership in different manners depending on their tolerance of risk. On Fri, Jun 11, 2010 at 8:54 AM, Marius Scurtescu <mscurtescu@google.com> wrote: > On Fri, Jun 11, 2010 at 8:35 AM, Christian Scholz <cs@comlounge.net> wrote: >> Hi! >> >> Am 11.06.10 17:05, schrieb Justin Richer: >>> Along these lines, I'd like to propose an extension for per-client >>> instance information to be passed from a client to the server. Things >>> like a human-readable client name/description, instance name/description >>> (could be tied to host name, ip, label like "home" or "Work"), and even >>> something like a display icon. This is especially useful for things like >>> device clients (where I might have a bunch of devices with the same >>> client ID) or unregistered clients, where the client id string ends up >>> being closer to a user-agent string from a browser than a trusted >>> identifier, especially since it can't have a reliable secret. >> >> We have the need for dynamic binding of clients in the User Managed >> Access group (UMA) as well. I did look into OpenID Connect but felt that >> reusing an OAuth flow based on a different type is maybe mixing things a >> bit too much. To me using a flow means that in the end usually >> you end up with an access token which here is not the case. Especially I >> don't like the reuse of the token URI as IMHO it's better to use >> separate endpoints for different APIs. >> >> I thus went along and crafted some simple handshake in the UMA >> specification which I also wanted to move out into a single >> specification over the next days. >> >> You can find it here: >> >> http://kantarainitiative.org/confluence/display/~christianscholz/Step+1+experimental+version+v1 >> >> under "Dynamic binding of OAuth clients". >> >> It is a simple handshake where you provide a JSON formatted client >> descriptor containing the information you describe above and the results >> is a set of client credentials plus optionally additional information >> (in UMA we eventually need to pass back more information like additional >> endpoints). > > In general during registration an authz server will verify that the > client really owns the domain it claims it does. Does any validation > like that happen in the suggested "Dynamic binding of OAuth clients"? > > Marius > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From atom@yahoo-inc.com Fri Jun 11 09:01:36 2010 Return-Path: <atom@yahoo-inc.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA8703A68A3 for <oauth@core3.amsl.com>; Fri, 11 Jun 2010 09:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.869 X-Spam-Level: X-Spam-Status: No, score=-15.869 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jn1fmuHeZK1h for <oauth@core3.amsl.com>; Fri, 11 Jun 2010 09:01:35 -0700 (PDT) Received: from mrout2-b.corp.re1.yahoo.com (mrout2-b.corp.re1.yahoo.com [69.147.107.21]) by core3.amsl.com (Postfix) with ESMTP id 6242C3A6935 for <oauth@ietf.org>; Fri, 11 Jun 2010 09:01:35 -0700 (PDT) Received: from SNV-EXBH01.ds.corp.yahoo.com (snv-exbh01.ds.corp.yahoo.com [207.126.227.249]) by mrout2-b.corp.re1.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o5BFxOjd072292; Fri, 11 Jun 2010 08:59:24 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:user-agent:date:subject:from:to:cc:message-id: thread-topic:thread-index:in-reply-to:mime-version:content-type: content-transfer-encoding:x-originalarrivaltime; b=uipH2abv1qos27RsM8Z4sK6pxu2GoQsnfgolzBJaLnRAWKJuzOv/W7ksaYxYhjqT Received: from SNV-EXVS03.ds.corp.yahoo.com ([207.126.227.235]) by SNV-EXBH01.ds.corp.yahoo.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 11 Jun 2010 08:59:23 -0700 Received: from 10.72.244.162 ([10.72.244.162]) by SNV-EXVS03.ds.corp.yahoo.com ([207.126.227.239]) via Exchange Front-End Server snv-webmail.corp.yahoo.com ([207.126.227.59]) with Microsoft Exchange Server HTTP-DAV ; Fri, 11 Jun 2010 15:59:23 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Fri, 11 Jun 2010 08:59:22 -0700 From: Allen Tom <atom@yahoo-inc.com> To: David Recordon <recordond@gmail.com>, Eran Hammer-Lahav <eran@hueniverse.com> Message-ID: <C837AB6A.33EBA%atom@yahoo-inc.com> Thread-Topic: [OAUTH-WG] A display parameter for user authorization requests Thread-Index: AcsJfw6PLrH8YmhcTE6JZEZcqei59g== In-Reply-To: <AANLkTilJcCY470WSJfWlPlal07PNjQ6lLUq9Dy1UeQXk@mail.gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 11 Jun 2010 15:59:23.0859 (UTC) FILETIME=[0FAB9230:01CB097F] Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] A display parameter for user authorization requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 11 Jun 2010 16:01:36 -0000 Hi David, Thanks a lot for writing this up! Some feedback: 1) If the user is required to enter their credentials (aka their password), the UI must be displayed in an independent browser window (not in an inline= d iframe), with the address bar displayed. The AS must return framebusting JS code to ensure that the login form is not iframed 2) It might be desirable to inline/lightbox the approval UI, if the user already is logged into the AS and does not have to enter their password to approve the request. In this case, the AS does not need to return framebusting code, but should return anti-clickjacking code to protect the approval button from being clickjacked 3) #2 implies that the client will have a way of determining if the user is already logged into the AS before spawning either a popup window (if the user is not logged in) or displaying an inline lightbox (if the user is already logged in) An API similar to the OpenID openid.ui.mode=3Dx-has-sessio= n parameter or the FB.getLoginStatus() API is needed. http://developers.facebook.com/docs/reference/javascript/FB.getLoginStatus http://code.google.com/apis/accounts/docs/OpenID.html#Parameters I'll be happy to contribute some of the text. Thanks Allen On 6/10/10 9:13 PM, "David Recordon" <recordond@gmail.com> wrote: > http://github.com/daveman692/OAuth-2.0/raw/master/draft-recordon-oauth-v2= -ux-0 > 1.txt >=20 >=20 > On Thu, Jun 10, 2010 at 5:32 PM, David Recordon <recordond@gmail.com> wro= te: >> +1 for moving immediate here as well. >>=20 >>=20 >> On Thu, Jun 10, 2010 at 4:18 PM, Eran Hammer-Lahav <eran@hueniverse.com> >> wrote: >>> Since these are all extensions to the end-user endpoint, I'd suggest we= move >>> the 'immediate' parameter here as well. >>>=20 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0<t hangText=3D'immediate'> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<vspace /> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0OPTIONAL. The parameter value must be set to <spanx >>> style=3D'verb'>true</spanx> or >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<spanx style=3D'verb'>false</spanx>. If set to >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<spanx style=3D'verb'>true</spanx>, the authorization serv= er >>> MUST NOT prompt the >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0end-user to authenticate or approve access. Instead, the >>> authorization server >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0attempts to establish the end-user's identity via other = means >>> (e.g. browser >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0cookies) and checks if the end-user has previously appro= ved >>> an identical access >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0request by the same client and if that access grant is s= till >>> active. If the >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0authorization server does not support an immediate check= or >>> if it is unable to >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0establish the end-user's identity or approval status, it= MUST >>> deny the request >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0without prompting the end-user. Defaults to <spanx >>> style=3D'verb'>false</spanx> if >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0omitted. >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0</t> >>> EHL >>>=20 >>>> -----Original Message----- >>>> From: David Recordon [mailto:recordond@gmail.com] >>>> Sent: Wednesday, June 09, 2010 12:06 PM >>>> To: Eran Hammer-Lahav; Allen Tom; Breno de Medeiros; Luke Shepard >>>> Cc: OAuth WG >>>> Subject: Re: [OAUTH-WG] A display parameter for user authorization >>>> requests >>>>=20 >>>> First draft of the UX Extension is at >>>> http://github.com/daveman692/OAuth-2.0/raw/master/draft-recordon- >>>> oauth-v2-ux-00.txt. >>>>=20 >>>> Eran, I'm more than happy to have you take over as editor. >>>>=20 >>>> I included Allen and Breno as authors since I followed Allen's suggest= ion >>>> and >>>> adopted the language preference parameter from the OpenID extension. I >>>> also included Luke as an author since he wrote the first pass of a dis= play >>>> parameter. That said, none of them have seen this draft yet. >>>>=20 >>>> --David >>>>=20 >>>>=20 >>>> On Tue, Apr 13, 2010 at 12:36 PM, Allen Tom <atom@yahoo-inc.com> wrote= : >>>>> At least with regards to the language preference, how about if we jus= t >>>>> copy the openid.ui.lang parameter from the OpenID UI Extension? >>>>>=20 >>>>> http://svn.openid.net/repos/specifications/user_interface/1.0/trunk/o= p >>>>> enid-user-interface-extension-1_0.html#anchor3 >>>>>=20 >>>>> In flows in which the client redirects the user's web browser to >>>>> authorize access, the client MAY send the Authorization Server a hint >>>>> regarding the user's preferred language by sending the following >>>> parameter: >>>>>=20 >>>>> =A0=A0=A0=A0lang >>>>> =A0=A0=A0=A0=A0=A0=A0=A0The user's preferred languages as a [BCP 47] language priorit= y >>>>> list, represented as a comma-separated list of BCP 47 basic language >>>>> ranges in decending priority order. For instance, the value >>>>> "fr-CA,fr-FR,en- >>>> CA" >>>>> represents the preference for French spoken in Canada, French spoken >>>>> in France, followed by English spoken in Canada. >>>>>=20 >>>>> The language preference hint SHOULD take precedence over the >>>>> Accept-Language HTTP header sent by the user's browser, and SHOULD >>>>> take precedence over the language preference inferred by the user's I= P >>>> Address. >>>>>=20 >>>>> BCP 47: =A0http://tools.ietf.org/html/bcp47 >>>>>=20 >>>>> Allen >>>>>=20 >>>>>=20 >>>>> On 4/12/10 1:32 PM, "Eran Hammer-Lahav" <eran@hueniverse.com> >>>> wrote: >>>>>=20 >>>>> Between language preferences, display configuration, and immediate >>>>> check, I think it might be worth to move that work to another draft. >>>>> Timeline-wise, this has the potential of slowing us down. I also fear >>>>> getting what is now a pretty simple spec much more complicated. >>>>>=20 >>>>> Anyone cares to try a first draft or outline? I can do the editorial >>>>> work if needed, but someone needs to write something first. >>>>>=20 >>>>> EHL >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>>=20 >>>=20 >>=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From recordond@gmail.com Fri Jun 11 09:03:39 2010 Return-Path: <recordond@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D68F28C0E1 for <oauth@core3.amsl.com>; Fri, 11 Jun 2010 09:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.056 X-Spam-Level: X-Spam-Status: No, score=-2.056 tagged_above=-999 required=5 tests=[AWL=0.543, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IwKbe23JUBjW for <oauth@core3.amsl.com>; Fri, 11 Jun 2010 09:03:34 -0700 (PDT) Received: from mail-yw0-f179.google.com (mail-yw0-f179.google.com [209.85.211.179]) by core3.amsl.com (Postfix) with ESMTP id 1D82A28C0DD for <oauth@ietf.org>; Fri, 11 Jun 2010 09:03:32 -0700 (PDT) Received: by ywh9 with SMTP id 9so1453735ywh.17 for <oauth@ietf.org>; Fri, 11 Jun 2010 09:03:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=c9AZNUQSUV76s/4dY7puue2Qz7QXSaxi/VS4VIT4GoE=; b=RmiiyViAPzuNDe1e5DBmF1ReVA4m0Iu2l1VPe7uPsy5S5o+S7BI+p1llx25yoA0psy M+wrm0BmaK5kvNRdhJT/T7Nw4yCMfbjhZib2pLIxT9qVqb/zAUblAd7JX9SBar5mkUw7 Efyb6+XP0mYbwof5CRRzxsIJSxx3IFK+nVmq4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=FXOe3eGXWfdsUJ7W84kPZldsK1A7xzg6JOP0dd5DOZjPEFFa7zTNKMOD9KPeSVt+nP twy4mUSkOaklmvallYY01rIMJH0HmWBq7gdTR3Ordln0EoVcd5Ot6ozv/Hln+25BYUVo Wl2SN+v3GG1WaXPVsyv42h60uR5p4zCfBI8vs= MIME-Version: 1.0 Received: by 10.101.132.2 with SMTP id j2mr1975802ann.44.1276272206140; Fri, 11 Jun 2010 09:03:26 -0700 (PDT) Received: by 10.231.192.4 with HTTP; Fri, 11 Jun 2010 09:03:26 -0700 (PDT) In-Reply-To: <C837AB6A.33EBA%atom@yahoo-inc.com> References: <AANLkTilJcCY470WSJfWlPlal07PNjQ6lLUq9Dy1UeQXk@mail.gmail.com> <C837AB6A.33EBA%atom@yahoo-inc.com> Date: Fri, 11 Jun 2010 09:03:26 -0700 Message-ID: <AANLkTilP4Pr1vfpAsdqtKhdNyu9VCiCP-FcEqGY5M3g5@mail.gmail.com> From: David Recordon <recordond@gmail.com> To: Allen Tom <atom@yahoo-inc.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] A display parameter for user authorization requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 11 Jun 2010 16:03:39 -0000 Cool, want to take a stab at the security considerations section of this? #1 and #2 feel like they fit there. I agree with #3 being nice, but without an API wouldn't you make an immediate mode request, see that it failed, and then make a normal request? --David On Fri, Jun 11, 2010 at 8:59 AM, Allen Tom <atom@yahoo-inc.com> wrote: > Hi David, > > Thanks a lot for writing this up! Some feedback: > > 1) If the user is required to enter their credentials (aka their password= ), > the UI must be displayed in an independent browser window (not in an inli= ned > iframe), with the address bar displayed. The AS must return framebusting = JS > code to ensure that the login form is not iframed > > 2) It might be desirable to inline/lightbox the approval UI, if the user > already is logged into the AS and does not have to enter their password t= o > approve the request. In this case, the AS does not need to return > framebusting code, but should return anti-clickjacking code to protect th= e > approval button from being clickjacked > > 3) #2 implies that the client will have a way of determining if the user = is > already logged into the AS before spawning either a popup window (if the > user is not logged in) or displaying an inline lightbox (if the user is > already logged in) An API similar to the OpenID openid.ui.mode=3Dx-has-se= ssion > parameter or the FB.getLoginStatus() API is needed. > > http://developers.facebook.com/docs/reference/javascript/FB.getLoginStatu= s > http://code.google.com/apis/accounts/docs/OpenID.html#Parameters > > I'll be happy to contribute some of the text. > > Thanks > Allen > > > > On 6/10/10 9:13 PM, "David Recordon" <recordond@gmail.com> wrote: > >> http://github.com/daveman692/OAuth-2.0/raw/master/draft-recordon-oauth-v= 2-ux-0 >> 1.txt >> >> >> On Thu, Jun 10, 2010 at 5:32 PM, David Recordon <recordond@gmail.com> wr= ote: >>> +1 for moving immediate here as well. >>> >>> >>> On Thu, Jun 10, 2010 at 4:18 PM, Eran Hammer-Lahav <eran@hueniverse.com= > >>> wrote: >>>> Since these are all extensions to the end-user endpoint, I'd suggest w= e move >>>> the 'immediate' parameter here as well. >>>> >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0<t hangText=3D'immediate'> >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<vspace /> >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0OPTIONAL. The parameter value must be s= et to <spanx >>>> style=3D'verb'>true</spanx> or >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<spanx style=3D'verb'>false</spanx>. If= set to >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<spanx style=3D'verb'>true</spanx>, the= authorization server >>>> MUST NOT prompt the >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0end-user to authenticate or approve acc= ess. Instead, the >>>> authorization server >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0attempts to establish the end-user's id= entity via other means >>>> (e.g. browser >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0cookies) and checks if the end-user has= previously approved >>>> an identical access >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0request by the same client and if that = access grant is still >>>> active. If the >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0authorization server does not support a= n immediate check or >>>> if it is unable to >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0establish the end-user's identity or ap= proval status, it MUST >>>> deny the request >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0without prompting the end-user. Default= s to <spanx >>>> style=3D'verb'>false</spanx> if >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0omitted. >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0</t> >>>> EHL >>>> >>>>> -----Original Message----- >>>>> From: David Recordon [mailto:recordond@gmail.com] >>>>> Sent: Wednesday, June 09, 2010 12:06 PM >>>>> To: Eran Hammer-Lahav; Allen Tom; Breno de Medeiros; Luke Shepard >>>>> Cc: OAuth WG >>>>> Subject: Re: [OAUTH-WG] A display parameter for user authorization >>>>> requests >>>>> >>>>> First draft of the UX Extension is at >>>>> http://github.com/daveman692/OAuth-2.0/raw/master/draft-recordon- >>>>> oauth-v2-ux-00.txt. >>>>> >>>>> Eran, I'm more than happy to have you take over as editor. >>>>> >>>>> I included Allen and Breno as authors since I followed Allen's sugges= tion >>>>> and >>>>> adopted the language preference parameter from the OpenID extension. = I >>>>> also included Luke as an author since he wrote the first pass of a di= splay >>>>> parameter. That said, none of them have seen this draft yet. >>>>> >>>>> --David >>>>> >>>>> >>>>> On Tue, Apr 13, 2010 at 12:36 PM, Allen Tom <atom@yahoo-inc.com> wrot= e: >>>>>> At least with regards to the language preference, how about if we ju= st >>>>>> copy the openid.ui.lang parameter from the OpenID UI Extension? >>>>>> >>>>>> http://svn.openid.net/repos/specifications/user_interface/1.0/trunk/= op >>>>>> enid-user-interface-extension-1_0.html#anchor3 >>>>>> >>>>>> In flows in which the client redirects the user's web browser to >>>>>> authorize access, the client MAY send the Authorization Server a hin= t >>>>>> regarding the user's preferred language by sending the following >>>>> parameter: >>>>>> >>>>>> =A0=A0=A0=A0lang >>>>>> =A0=A0=A0=A0=A0=A0=A0=A0The user's preferred languages as a [BCP 47]= language priority >>>>>> list, represented as a comma-separated list of BCP 47 basic language >>>>>> ranges in decending priority order. For instance, the value >>>>>> "fr-CA,fr-FR,en- >>>>> CA" >>>>>> represents the preference for French spoken in Canada, French spoken >>>>>> in France, followed by English spoken in Canada. >>>>>> >>>>>> The language preference hint SHOULD take precedence over the >>>>>> Accept-Language HTTP header sent by the user's browser, and SHOULD >>>>>> take precedence over the language preference inferred by the user's = IP >>>>> Address. >>>>>> >>>>>> BCP 47: =A0http://tools.ietf.org/html/bcp47 >>>>>> >>>>>> Allen >>>>>> >>>>>> >>>>>> On 4/12/10 1:32 PM, "Eran Hammer-Lahav" <eran@hueniverse.com> >>>>> wrote: >>>>>> >>>>>> Between language preferences, display configuration, and immediate >>>>>> check, I think it might be worth to move that work to another draft. >>>>>> Timeline-wise, this has the potential of slowing us down. I also fea= r >>>>>> getting what is now a pretty simple spec much more complicated. >>>>>> >>>>>> Anyone cares to try a first draft or outline? I can do the editorial >>>>>> work if needed, but someone needs to write something first. >>>>>> >>>>>> 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 mscurtescu@google.com Fri Jun 11 09:08:04 2010 Return-Path: <mscurtescu@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FDC928C0E8 for <oauth@core3.amsl.com>; Fri, 11 Jun 2010 09:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.453 X-Spam-Level: X-Spam-Status: No, score=-101.453 tagged_above=-999 required=5 tests=[AWL=0.524, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uu4EGTGI-IT1 for <oauth@core3.amsl.com>; Fri, 11 Jun 2010 09:08:01 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 959BD28C0E1 for <oauth@ietf.org>; Fri, 11 Jun 2010 09:08:00 -0700 (PDT) Received: from kpbe17.cbf.corp.google.com (kpbe17.cbf.corp.google.com [172.25.105.81]) by smtp-out.google.com with ESMTP id o5BG80V0015740 for <oauth@ietf.org>; Fri, 11 Jun 2010 09:08:00 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1276272480; bh=pezDYQhfk6Obz9T/rmBRI6OADgw=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=dgmAOpKCiW4FTL2gcf/Ion893znNJ6d7iloMsqzAM3wyzkvkJN3R8FqbEeSDIIPaV NRBymyPpU7b5PKhX3TrvA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type; b=x1zVRSWYmCo9P6Q21J68HejpgKoMu2VWgIeVaIZk9Sh2VU23tWXnhnYw3OCzdO0zE 0VSNcuauTps4+UBk3PeOA== Received: from pwi7 (pwi7.prod.google.com [10.241.219.7]) by kpbe17.cbf.corp.google.com with ESMTP id o5BG7xVo009246 for <oauth@ietf.org>; Fri, 11 Jun 2010 09:07:59 -0700 Received: by pwi7 with SMTP id 7so1542725pwi.0 for <oauth@ietf.org>; Fri, 11 Jun 2010 09:07:58 -0700 (PDT) Received: by 10.141.125.10 with SMTP id c10mr1542732rvn.214.1276272478251; Fri, 11 Jun 2010 09:07:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.124.13 with HTTP; Fri, 11 Jun 2010 09:07:38 -0700 (PDT) In-Reply-To: <AANLkTimGnTj1HseMsPBaRXjBThM3uktqq0R6P30jsjaZ@mail.gmail.com> References: <AANLkTingSGlJNZ5e_stPd1qU5I4gfbh3rQhqYUmqXvdB@mail.gmail.com> <C833CEB4.6B81%cmortimore@salesforce.com> <AANLkTinVQEPBVzmiHEGgHhzaILL0nRSvZpjIlrVEJwTw@mail.gmail.com> <AANLkTil1j7vl8PU2tgCzlWY0U6KiWPmRKiVOxvsctB00@mail.gmail.com> <AANLkTimCL-O7RIsUlt_zGDfkEEYb9w4_sPh6zxCMBsf0@mail.gmail.com> <AANLkTin7B9pPgSu3cNlJGkp_gCed-5aPGRZalzXd2Wg8@mail.gmail.com> <4C124A70.2000002@aol.com> <1276268753.31840.50.camel@localhost.localdomain> <4C1257B5.9080706@comlounge.net> <AANLkTilcpAw7hZuQK43_ybS-wy3bQnPqMfRXOdqY4iYa@mail.gmail.com> <AANLkTimGnTj1HseMsPBaRXjBThM3uktqq0R6P30jsjaZ@mail.gmail.com> From: Marius Scurtescu <mscurtescu@google.com> Date: Fri, 11 Jun 2010 09:07:38 -0700 Message-ID: <AANLkTimyvpXmlOXRKSA4Oe0s3rqoiLQgtgvbRlvniEJ6@mail.gmail.com> To: David Recordon <recordond@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] User-agent flow and pre-registered redirect_uri X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 11 Jun 2010 16:08:04 -0000 On Fri, Jun 11, 2010 at 8:59 AM, David Recordon <recordond@gmail.com> wrote: > That sounds like a security consideration to me! :) > > I imagine that authorization servers will verify ownership in > different manners depending on their tolerance of risk. Instead of POSTing a JSON with all the details, dynamic binding could send only a host name. The authz server would then do discovery on this host and get a pointer to this JSON from host-meta. Marius > > > On Fri, Jun 11, 2010 at 8:54 AM, Marius Scurtescu <mscurtescu@google.com> wrote: >> On Fri, Jun 11, 2010 at 8:35 AM, Christian Scholz <cs@comlounge.net> wrote: >>> Hi! >>> >>> Am 11.06.10 17:05, schrieb Justin Richer: >>>> Along these lines, I'd like to propose an extension for per-client >>>> instance information to be passed from a client to the server. Things >>>> like a human-readable client name/description, instance name/description >>>> (could be tied to host name, ip, label like "home" or "Work"), and even >>>> something like a display icon. This is especially useful for things like >>>> device clients (where I might have a bunch of devices with the same >>>> client ID) or unregistered clients, where the client id string ends up >>>> being closer to a user-agent string from a browser than a trusted >>>> identifier, especially since it can't have a reliable secret. >>> >>> We have the need for dynamic binding of clients in the User Managed >>> Access group (UMA) as well. I did look into OpenID Connect but felt that >>> reusing an OAuth flow based on a different type is maybe mixing things a >>> bit too much. To me using a flow means that in the end usually >>> you end up with an access token which here is not the case. Especially I >>> don't like the reuse of the token URI as IMHO it's better to use >>> separate endpoints for different APIs. >>> >>> I thus went along and crafted some simple handshake in the UMA >>> specification which I also wanted to move out into a single >>> specification over the next days. >>> >>> You can find it here: >>> >>> http://kantarainitiative.org/confluence/display/~christianscholz/Step+1+experimental+version+v1 >>> >>> under "Dynamic binding of OAuth clients". >>> >>> It is a simple handshake where you provide a JSON formatted client >>> descriptor containing the information you describe above and the results >>> is a set of client credentials plus optionally additional information >>> (in UMA we eventually need to pass back more information like additional >>> endpoints). >> >> In general during registration an authz server will verify that the >> client really owns the domain it claims it does. Does any validation >> like that happen in the suggested "Dynamic binding of OAuth clients"? >> >> Marius >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > From gffletch@aol.com Fri Jun 11 09:25:39 2010 Return-Path: <gffletch@aol.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3A0A3A68DA for <oauth@core3.amsl.com>; Fri, 11 Jun 2010 09:25:39 -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=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id stQF4iJmxh32 for <oauth@core3.amsl.com>; Fri, 11 Jun 2010 09:25:38 -0700 (PDT) Received: from imr-ma03.mx.aol.com (imr-ma03.mx.aol.com [64.12.206.41]) by core3.amsl.com (Postfix) with ESMTP id 60D263A6879 for <oauth@ietf.org>; Fri, 11 Jun 2010 09:25:38 -0700 (PDT) Received: from mtaout-da03.r1000.mx.aol.com (mtaout-da03.r1000.mx.aol.com [172.29.51.131]) by imr-ma03.mx.aol.com (8.14.1/8.14.1) with ESMTP id o5BGPBHN017672; Fri, 11 Jun 2010 12:25:12 -0400 Received: from palantir.local (unknown [10.172.1.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-da03.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 3CD18E000087; Fri, 11 Jun 2010 12:25:12 -0400 (EDT) Message-ID: <4C126367.40403@aol.com> Date: Fri, 11 Jun 2010 12:25:11 -0400 From: George Fletcher <gffletch@aol.com> Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: oauth@ietf.org References: <AANLkTingSGlJNZ5e_stPd1qU5I4gfbh3rQhqYUmqXvdB@mail.gmail.com> <C833CEB4.6B81%cmortimore@salesforce.com> <AANLkTinVQEPBVzmiHEGgHhzaILL0nRSvZpjIlrVEJwTw@mail.gmail.com> <AANLkTil1j7vl8PU2tgCzlWY0U6KiWPmRKiVOxvsctB00@mail.gmail.com> <AANLkTimCL-O7RIsUlt_zGDfkEEYb9w4_sPh6zxCMBsf0@mail.gmail.com> <AANLkTin7B9pPgSu3cNlJGkp_gCed-5aPGRZalzXd2Wg8@mail.gmail.com> <4C124A70.2000002@aol.com> <1276268753.31840.50.camel@localhost.localdomain> <4C1257B5.9080706@comlounge.net> <AANLkTilcpAw7hZuQK43_ybS-wy3bQnPqMfRXOdqY4iYa@mail.gmail.com> <AANLkTimGnTj1HseMsPBaRXjBThM3uktqq0R6P30jsjaZ@mail.gmail.com> <AANLkTimyvpXmlOXRKSA4Oe0s3rqoiLQgtgvbRlvniEJ6@mail.gmail.com> In-Reply-To: <AANLkTimyvpXmlOXRKSA4Oe0s3rqoiLQgtgvbRlvniEJ6@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit x-aol-global-disposition: G X-AOL-SCOLL-SCORE: 0:2:420239392:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d33834c126368353a X-AOL-IP: 10.172.1.149 Subject: Re: [OAUTH-WG] User-agent flow and pre-registered redirect_uri X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 11 Jun 2010 16:25:39 -0000 On 6/11/10 12:07 PM, Marius Scurtescu wrote: > On Fri, Jun 11, 2010 at 8:59 AM, David Recordon<recordond@gmail.com> wrote: > >> That sounds like a security consideration to me! :) >> >> I imagine that authorization servers will verify ownership in >> different manners depending on their tolerance of risk. >> > Instead of POSTing a JSON with all the details, dynamic binding could > send only a host name. The authz server would then do discovery on > this host and get a pointer to this JSON from host-meta. > > Marius > > I think most all of this could be described in the host-meta XRD directly to save yet another round trip. And I believe there are some security advantages to using this approach, but it does require the "client" to be a web-server. This might not always be the case (rich desktop app). For native/desktop apps, it seems that posting some set of parameters (equivalent security-wise to a browser user-agent) makes sense and keeps the protocol simple. Thanks, George >> >> On Fri, Jun 11, 2010 at 8:54 AM, Marius Scurtescu<mscurtescu@google.com> wrote: >> >>> On Fri, Jun 11, 2010 at 8:35 AM, Christian Scholz<cs@comlounge.net> wrote: >>> >>>> Hi! >>>> >>>> Am 11.06.10 17:05, schrieb Justin Richer: >>>> >>>>> Along these lines, I'd like to propose an extension for per-client >>>>> instance information to be passed from a client to the server. Things >>>>> like a human-readable client name/description, instance name/description >>>>> (could be tied to host name, ip, label like "home" or "Work"), and even >>>>> something like a display icon. This is especially useful for things like >>>>> device clients (where I might have a bunch of devices with the same >>>>> client ID) or unregistered clients, where the client id string ends up >>>>> being closer to a user-agent string from a browser than a trusted >>>>> identifier, especially since it can't have a reliable secret. >>>>> >>>> We have the need for dynamic binding of clients in the User Managed >>>> Access group (UMA) as well. I did look into OpenID Connect but felt that >>>> reusing an OAuth flow based on a different type is maybe mixing things a >>>> bit too much. To me using a flow means that in the end usually >>>> you end up with an access token which here is not the case. Especially I >>>> don't like the reuse of the token URI as IMHO it's better to use >>>> separate endpoints for different APIs. >>>> >>>> I thus went along and crafted some simple handshake in the UMA >>>> specification which I also wanted to move out into a single >>>> specification over the next days. >>>> >>>> You can find it here: >>>> >>>> http://kantarainitiative.org/confluence/display/~christianscholz/Step+1+experimental+version+v1 >>>> >>>> under "Dynamic binding of OAuth clients". >>>> >>>> It is a simple handshake where you provide a JSON formatted client >>>> descriptor containing the information you describe above and the results >>>> is a set of client credentials plus optionally additional information >>>> (in UMA we eventually need to pass back more information like additional >>>> endpoints). >>>> >>> In general during registration an authz server will verify that the >>> client really owns the domain it claims it does. Does any validation >>> like that happen in the suggested "Dynamic binding of OAuth clients"? >>> >>> Marius >>> _______________________________________________ >>> OAuth mailing 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 Fri Jun 11 09:35:25 2010 Return-Path: <mscurtescu@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 374CA3A69EE for <oauth@core3.amsl.com>; Fri, 11 Jun 2010 09:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.497 X-Spam-Level: X-Spam-Status: No, score=-101.497 tagged_above=-999 required=5 tests=[AWL=0.480, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jp-uBlkLtS49 for <oauth@core3.amsl.com>; Fri, 11 Jun 2010 09:35:23 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 177263A684F for <oauth@ietf.org>; Fri, 11 Jun 2010 09:35:07 -0700 (PDT) Received: from wpaz1.hot.corp.google.com (wpaz1.hot.corp.google.com [172.24.198.65]) by smtp-out.google.com with ESMTP id o5BGYxl2016146 for <oauth@ietf.org>; Fri, 11 Jun 2010 09:34:59 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1276274099; bh=Zu3kTVIaySc0HMfmFM2WTv8Bxv4=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=C0g2FMWBXr8MU/4MbNGwBNSlsKskloK/qWI5Mju6yxkPow2BA/hYAFPQLDcsejLLV QalUllH0rxUd2tyldvvMw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding; b=UR88ZeBhAS2llA5oe3pooQ/3fkFc/E89B5Z0BUYuXs4uPfJ4fv19JHmiGHf56Rthl hhsApFCA5ZOP6ap/++8Lw== Received: from pvf33 (pvf33.prod.google.com [10.241.210.97]) by wpaz1.hot.corp.google.com with ESMTP id o5BGYvn7001983 for <oauth@ietf.org>; Fri, 11 Jun 2010 09:34:58 -0700 Received: by pvf33 with SMTP id 33so281457pvf.3 for <oauth@ietf.org>; Fri, 11 Jun 2010 09:34:57 -0700 (PDT) Received: by 10.141.125.10 with SMTP id c10mr1570876rvn.214.1276274094140; Fri, 11 Jun 2010 09:34:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.124.13 with HTTP; Fri, 11 Jun 2010 09:34:34 -0700 (PDT) In-Reply-To: <4C126367.40403@aol.com> References: <AANLkTingSGlJNZ5e_stPd1qU5I4gfbh3rQhqYUmqXvdB@mail.gmail.com> <C833CEB4.6B81%cmortimore@salesforce.com> <AANLkTinVQEPBVzmiHEGgHhzaILL0nRSvZpjIlrVEJwTw@mail.gmail.com> <AANLkTil1j7vl8PU2tgCzlWY0U6KiWPmRKiVOxvsctB00@mail.gmail.com> <AANLkTimCL-O7RIsUlt_zGDfkEEYb9w4_sPh6zxCMBsf0@mail.gmail.com> <AANLkTin7B9pPgSu3cNlJGkp_gCed-5aPGRZalzXd2Wg8@mail.gmail.com> <4C124A70.2000002@aol.com> <1276268753.31840.50.camel@localhost.localdomain> <4C1257B5.9080706@comlounge.net> <AANLkTilcpAw7hZuQK43_ybS-wy3bQnPqMfRXOdqY4iYa@mail.gmail.com> <AANLkTimGnTj1HseMsPBaRXjBThM3uktqq0R6P30jsjaZ@mail.gmail.com> <AANLkTimyvpXmlOXRKSA4Oe0s3rqoiLQgtgvbRlvniEJ6@mail.gmail.com> <4C126367.40403@aol.com> From: Marius Scurtescu <mscurtescu@google.com> Date: Fri, 11 Jun 2010 09:34:34 -0700 Message-ID: <AANLkTimKEFRu-PboKcpXFlFN7Q_675ZjICBnK9IliUzs@mail.gmail.com> To: George Fletcher <gffletch@aol.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] User-agent flow and pre-registered redirect_uri X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 11 Jun 2010 16:35:25 -0000 On Fri, Jun 11, 2010 at 9:25 AM, George Fletcher <gffletch@aol.com> wrote: > On 6/11/10 12:07 PM, Marius Scurtescu wrote: >> >> On Fri, Jun 11, 2010 at 8:59 AM, David Recordon<recordond@gmail.com> >> =A0wrote: >> >>> >>> That sounds like a security consideration to me! :) >>> >>> I imagine that authorization servers will verify ownership in >>> different manners depending on their tolerance of risk. >>> >> >> Instead of POSTing a JSON with all the details, dynamic binding could >> send only a host name. The authz server would then do discovery on >> this host and get a pointer to this JSON from host-meta. >> >> Marius >> >> > > I think most all of this could be described in the host-meta XRD directly= to > save yet another round trip. And I believe there are some security > advantages to using this approach, but it does require the "client" to be= a > web-server. This might not always be the case (rich desktop app). For > native/desktop apps, it seems that posting some set of parameters > (equivalent security-wise to a browser user-agent) makes sense and keeps = the > protocol simple. Yes, but in this case (desktop app) the "url" and "icon" parameters don't work and what is left is "name" and "description". I think that the suggested "client_name" parameter does exactly the same thing, much simpler. Is there any value in this case in a client_secret? Marius From torsten@lodderstedt.net Fri Jun 11 10:02:42 2010 Return-Path: <torsten@lodderstedt.net> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C19E23A68A3 for <oauth@core3.amsl.com>; Fri, 11 Jun 2010 10:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.726 X-Spam-Level: X-Spam-Status: No, score=0.726 tagged_above=-999 required=5 tests=[AWL=-1.426, BAYES_50=0.001, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, J_CHICKENPOX_66=0.6, J_CHICKENPOX_83=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sBQ1EL3fW3ED for <oauth@core3.amsl.com>; Fri, 11 Jun 2010 10:02:41 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.26]) by core3.amsl.com (Postfix) with ESMTP id 0FF533A6A07 for <oauth@ietf.org>; Fri, 11 Jun 2010 10:02:40 -0700 (PDT) Received: from p4fff06ec.dip.t-dialin.net ([79.255.6.236] helo=[127.0.0.1]) by smtprelay03.ispgateway.de with esmtpa (Exim 4.68) (envelope-from <torsten@lodderstedt.net>) id 1ON7cv-00065P-SN; Fri, 11 Jun 2010 19:02:41 +0200 Message-ID: <4C126C30.3040701@lodderstedt.net> Date: Fri, 11 Jun 2010 19:02:40 +0200 From: Torsten Lodderstedt <torsten@lodderstedt.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Eran Hammer-Lahav <eran@hueniverse.com> Content-Type: multipart/alternative; boundary="------------010107040107090002030203" X-Df-Sender: 141509 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: [OAUTH-WG] Fwd: Re: in-app logout? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 11 Jun 2010 17:02:42 -0000 This is a multi-part message in MIME format. --------------010107040107090002030203 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Eran, you probably didn't notice my posting. What do you think about adding a revocation request to the spec? regards, Torsten. -------- Original-Nachricht -------- Betreff: Re: [OAUTH-WG] in-app logout? Datum: Wed, 26 May 2010 20:26:18 +0200 Von: Torsten Lodderstedt <torsten@lodderstedt.net> An: Eran Hammer-Lahav <eran@hueniverse.com> CC: OAuth WG (oauth@ietf.org) <oauth@ietf.org> Hi Eran, in my perception, there is some support on the list for having a request to revoke refresh tokens. Will you add such a request to the specification? Do you need a text proposal? regards, Torsten. > IMHO this would look more like a hack than proper protocol design. We need > a delete/revoke operation that's the pendant to the other token operations (i.e. > crud ops). > > Hubert > > > > On Fri, May 21, 2010 at 7:05 PM, Beau Lebens<beau@dentedreality.com.au> wrote: > >> Could this just be implemented through support for a scope change >> where scope=none or revoke or something? >> >> On Friday, May 21, 2010, Lukas Rosenstock<lr@lukasrosenstock.net> wrote: >> >>> Why not simply add this functionality to the token endpoint?The same place that was used to fetch the access token first or refresh it could be used to revoke the same token with another request. The only requirement would be to define something like type=revoke. >>> I feel that is much easier than making the token a URL which supports DELETE. >>> However, any mechanism will break implementations that rely on minimal or no communication between authorization server and protected resource, because all protected resources have to be informed. >>> >>> Regards, Lukas >>> >>> 2010/5/16 Dick Hardt<dick.hardt@gmail.com> >>> >>> James: An important capability of the refresh token is that it *can* be a self contained token in that is not an id, but a signed token that can be examined and acted upon on presentation. >>> Torsten: enabling a client to revoke a refresh token looks like a useful mechanism. I anticipate it will be viewed as a vitamin feature rather than a painkiller and will fall by the wayside unless the security conscience rally to have it included. >>> >>> >>> -- Dick >>> >>> >>> On Thu, May 13, 2010 at 7:10 AM, Manger, James H<James.H.Manger@team.telstra.com> wrote: >>> Torsten, >>> >>> >>>> What about refresh token revocation/deletion? >>>> >>> HTTP already has a method to do this: DELETE >>> It just needs each token to have a URI. >>> >>> Tokens (almost) already have URIs -- its just not immediately obvious because the URI has to be built from a common token endpoint and a refresh_token. >>> >>> I think it would improve the spec if refresh_token was renamed to, say, token_id; and its value defined as a URI (which can be a relative URI so the string may not need to change at all). >>> >>> To refresh a token you POST to the token's URI. >>> To delete a token you send a DELETE request to the token's URI. >>> >>> It doesn't cause major changes, but there are some benefits. >>> It is a more web-style design. >>> It leaves only 1 type of token in the spec -- an access token -- which simplifies the text and aids understanding. >>> There are no arguments about length, allowed chars etc because it is a URI -- a well-known type, often with native support. >>> Its obvious how to delete the token as there is a standard HTTP method DELETE to apply to the token URI. >>> >>> If a particular service supported an additional way to delete items in its API (eg POST with a method=delete query parameter) that could apply to the OAuth part as well. >>> >>> -- >>> James Manger >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> -- >>> http://lukasrosenstock.net/ >>> >>> >>> >> _______________________________________________ >> OAuth mailing 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 --------------010107040107090002030203 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> </head> <body bgcolor="#ffffff" text="#000000"> Hi Eran,<br> <br> you probably didn't notice my posting. What do you think about adding a revocation request to the spec?<br> <br> regards,<br> Torsten.<br> <br> -------- Original-Nachricht -------- <table class="moz-email-headers-table" border="0" cellpadding="0" cellspacing="0"> <tbody> <tr> <th valign="BASELINE" align="RIGHT" nowrap="nowrap">Betreff: </th> <td>Re: [OAUTH-WG] in-app logout?</td> </tr> <tr> <th valign="BASELINE" align="RIGHT" nowrap="nowrap">Datum: </th> <td>Wed, 26 May 2010 20:26:18 +0200</td> </tr> <tr> <th valign="BASELINE" align="RIGHT" nowrap="nowrap">Von: </th> <td>Torsten Lodderstedt <a class="moz-txt-link-rfc2396E" href="mailto:torsten@lodderstedt.net"><torsten@lodderstedt.net></a></td> </tr> <tr> <th valign="BASELINE" align="RIGHT" nowrap="nowrap">An: </th> <td>Eran Hammer-Lahav <a class="moz-txt-link-rfc2396E" href="mailto:eran@hueniverse.com"><eran@hueniverse.com></a></td> </tr> <tr> <th valign="BASELINE" align="RIGHT" nowrap="nowrap">CC: </th> <td>OAuth WG (<a class="moz-txt-link-abbreviated" href="mailto:oauth@ietf.org">oauth@ietf.org</a>) <a class="moz-txt-link-rfc2396E" href="mailto:oauth@ietf.org"><oauth@ietf.org></a></td> </tr> </tbody> </table> <br> <br> <pre>Hi Eran, in my perception, there is some support on the list for having a request to revoke refresh tokens. Will you add such a request to the specification? Do you need a text proposal? regards, Torsten. > IMHO this would look more like a hack than proper protocol design. We need > a delete/revoke operation that's the pendant to the other token operations (i.e. > crud ops). > > Hubert > > > > On Fri, May 21, 2010 at 7:05 PM, Beau Lebens<a class="moz-txt-link-rfc2396E" href="mailto:beau@dentedreality.com.au"><beau@dentedreality.com.au></a> wrote: > >> Could this just be implemented through support for a scope change >> where scope=none or revoke or something? >> >> On Friday, May 21, 2010, Lukas Rosenstock<a class="moz-txt-link-rfc2396E" href="mailto:lr@lukasrosenstock.net"><lr@lukasrosenstock.net></a> wrote: >> >>> Why not simply add this functionality to the token endpoint?The same place that was used to fetch the access token first or refresh it could be used to revoke the same token with another request. The only requirement would be to define something like type=revoke. >>> I feel that is much easier than making the token a URL which supports DELETE. >>> However, any mechanism will break implementations that rely on minimal or no communication between authorization server and protected resource, because all protected resources have to be informed. >>> >>> Regards, Lukas >>> >>> 2010/5/16 Dick Hardt<a class="moz-txt-link-rfc2396E" href="mailto:dick.hardt@gmail.com"><dick.hardt@gmail.com></a> >>> >>> James: An important capability of the refresh token is that it *can* be a self contained token in that is not an id, but a signed token that can be examined and acted upon on presentation. >>> Torsten: enabling a client to revoke a refresh token looks like a useful mechanism. I anticipate it will be viewed as a vitamin feature rather than a painkiller and will fall by the wayside unless the security conscience rally to have it included. >>> >>> >>> -- Dick >>> >>> >>> On Thu, May 13, 2010 at 7:10 AM, Manger, James H<a class="moz-txt-link-rfc2396E" href="mailto:James.H.Manger@team.telstra.com"><James.H.Manger@team.telstra.com></a> wrote: >>> Torsten, >>> >>> >>>> What about refresh token revocation/deletion? >>>> >>> HTTP already has a method to do this: DELETE >>> It just needs each token to have a URI. >>> >>> Tokens (almost) already have URIs -- its just not immediately obvious because the URI has to be built from a common token endpoint and a refresh_token. >>> >>> I think it would improve the spec if refresh_token was renamed to, say, token_id; and its value defined as a URI (which can be a relative URI so the string may not need to change at all). >>> >>> To refresh a token you POST to the token's URI. >>> To delete a token you send a DELETE request to the token's URI. >>> >>> It doesn't cause major changes, but there are some benefits. >>> It is a more web-style design. >>> It leaves only 1 type of token in the spec -- an access token -- which simplifies the text and aids understanding. >>> There are no arguments about length, allowed chars etc because it is a URI -- a well-known type, often with native support. >>> Its obvious how to delete the token as there is a standard HTTP method DELETE to apply to the token URI. >>> >>> If a particular service supported an additional way to delete items in its API (eg POST with a method=delete query parameter) that could apply to the OAuth part as well. >>> >>> -- >>> James Manger >>> _______________________________________________ >>> OAuth mailing list >>> <a class="moz-txt-link-abbreviated" href="mailto:OAuth@ietf.org">OAuth@ietf.org</a> >>> <a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/oauth">https://www.ietf.org/mailman/listinfo/oauth</a> >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> <a class="moz-txt-link-abbreviated" href="mailto:OAuth@ietf.org">OAuth@ietf.org</a> >>> <a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/oauth">https://www.ietf.org/mailman/listinfo/oauth</a> >>> >>> >>> >>> -- >>> <a class="moz-txt-link-freetext" href="http://lukasrosenstock.net/">http://lukasrosenstock.net/</a> >>> >>> >>> >> _______________________________________________ >> OAuth mailing list >> <a class="moz-txt-link-abbreviated" href="mailto:OAuth@ietf.org">OAuth@ietf.org</a> >> <a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/oauth">https://www.ietf.org/mailman/listinfo/oauth</a> >> >> > _______________________________________________ > OAuth mailing list > <a class="moz-txt-link-abbreviated" href="mailto:OAuth@ietf.org">OAuth@ietf.org</a> > <a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/oauth">https://www.ietf.org/mailman/listinfo/oauth</a> > _______________________________________________ OAuth mailing list <a class="moz-txt-link-abbreviated" href="mailto:OAuth@ietf.org">OAuth@ietf.org</a> <a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/oauth">https://www.ietf.org/mailman/listinfo/oauth</a> </pre> </body> </html> --------------010107040107090002030203-- From gffletch@aol.com Fri Jun 11 10:08:20 2010 Return-Path: <gffletch@aol.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2F0C3A6A09 for <oauth@core3.amsl.com>; Fri, 11 Jun 2010 10:08:19 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mc0DTuCwmR-4 for <oauth@core3.amsl.com>; Fri, 11 Jun 2010 10:08:19 -0700 (PDT) Received: from imr-ma01.mx.aol.com (imr-ma01.mx.aol.com [64.12.206.39]) by core3.amsl.com (Postfix) with ESMTP id D743C3A68A3 for <oauth@ietf.org>; Fri, 11 Jun 2010 10:08:18 -0700 (PDT) Received: from mtaout-da03.r1000.mx.aol.com (mtaout-da03.r1000.mx.aol.com [172.29.51.131]) by imr-ma01.mx.aol.com (8.14.1/8.14.1) with ESMTP id o5BH7gPq015834; Fri, 11 Jun 2010 13:07:56 -0400 Received: from palantir.local (unknown [10.172.1.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-da03.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id BD8F0E0000C5; Fri, 11 Jun 2010 13:07:53 -0400 (EDT) Message-ID: <4C126D63.9090903@aol.com> Date: Fri, 11 Jun 2010 13:07:47 -0400 From: George Fletcher <gffletch@aol.com> Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: oauth@ietf.org References: <AANLkTingSGlJNZ5e_stPd1qU5I4gfbh3rQhqYUmqXvdB@mail.gmail.com> <C833CEB4.6B81%cmortimore@salesforce.com> <AANLkTinVQEPBVzmiHEGgHhzaILL0nRSvZpjIlrVEJwTw@mail.gmail.com> <AANLkTil1j7vl8PU2tgCzlWY0U6KiWPmRKiVOxvsctB00@mail.gmail.com> <AANLkTimCL-O7RIsUlt_zGDfkEEYb9w4_sPh6zxCMBsf0@mail.gmail.com> <AANLkTin7B9pPgSu3cNlJGkp_gCed-5aPGRZalzXd2Wg8@mail.gmail.com> <4C124A70.2000002@aol.com> <1276268753.31840.50.camel@localhost.localdomain> <4C1257B5.9080706@comlounge.net> <AANLkTilcpAw7hZuQK43_ybS-wy3bQnPqMfRXOdqY4iYa@mail.gmail.com> <AANLkTimGnTj1HseMsPBaRXjBThM3uktqq0R6P30jsjaZ@mail.gmail.com> <AANLkTimyvpXmlOXRKSA4Oe0s3rqoiLQgtgvbRlvniEJ6@mail.gmail.com> <4C126367.40403@aol.com> <AANLkTimKEFRu-PboKcpXFlFN7Q_675ZjICBnK9IliUzs@mail.gmail.com> In-Reply-To: <AANLkTimKEFRu-PboKcpXFlFN7Q_675ZjICBnK9IliUzs@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit x-aol-global-disposition: G X-AOL-SCOLL-SCORE: 0:2:378371968:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d33834c126d6960bd X-AOL-IP: 10.172.1.149 Subject: Re: [OAUTH-WG] User-agent flow and pre-registered redirect_uri X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 11 Jun 2010 17:08:20 -0000 On 6/11/10 12:34 PM, Marius Scurtescu wrote: > On Fri, Jun 11, 2010 at 9:25 AM, George Fletcher<gffletch@aol.com> wrote: > >> On 6/11/10 12:07 PM, Marius Scurtescu wrote: >> >>> On Fri, Jun 11, 2010 at 8:59 AM, David Recordon<recordond@gmail.com> >>> wrote: >>> >>> >>>> That sounds like a security consideration to me! :) >>>> >>>> I imagine that authorization servers will verify ownership in >>>> different manners depending on their tolerance of risk. >>>> >>>> >>> Instead of POSTing a JSON with all the details, dynamic binding could >>> send only a host name. The authz server would then do discovery on >>> this host and get a pointer to this JSON from host-meta. >>> >>> Marius >>> >>> >>> >> I think most all of this could be described in the host-meta XRD directly to >> save yet another round trip. And I believe there are some security >> advantages to using this approach, but it does require the "client" to be a >> web-server. This might not always be the case (rich desktop app). For >> native/desktop apps, it seems that posting some set of parameters >> (equivalent security-wise to a browser user-agent) makes sense and keeps the >> protocol simple. >> > Yes, but in this case (desktop app) the "url" and "icon" parameters > don't work and what is left is "name" and "description". I think that > the suggested "client_name" parameter does exactly the same thing, > much simpler. Is there any value in this case in a client_secret? > > Marius > Well... given this is a POST and structured data... it would be possible for the desktop app to post the raw icon data (though I suppose it could also POST a URL to the web server of the company the produces the app). In which case your previous suggestion would work (parameters discovered via the URL). I do believe the client_secret is valuable in this case because the AS is returning both the client_id and the client_secret. This then becomes a way for provisioning a unique client_id and client_secret to every instance of the app. A lot more for the AS to keep track of, but also makes it more difficult for an attacker to compromise a client. The attacker could impersonate the POST'd client description data (just like user-agent strings can be impersonated), but then the attacker just has a client_id and client_secret for it's instance. This should force the attacker to get explicit user consent from the user to authorize that unique client_id. I wouldn't recommend for the AS to track authorization against the POST'd client description but rather the client_id. Thanks, George From eran@hueniverse.com Fri Jun 11 10:24:35 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6C893A68A3 for <oauth@core3.amsl.com>; Fri, 11 Jun 2010 10:24:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.173 X-Spam-Level: X-Spam-Status: No, score=0.173 tagged_above=-999 required=5 tests=[AWL=-1.629, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, J_CHICKENPOX_66=0.6, J_CHICKENPOX_83=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GpNT0EJvtQC6 for <oauth@core3.amsl.com>; Fri, 11 Jun 2010 10:24:28 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id F3B5D3A6A13 for <oauth@ietf.org>; Fri, 11 Jun 2010 10:24:27 -0700 (PDT) Received: (qmail 2464 invoked from network); 11 Jun 2010 17:24:30 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 11 Jun 2010 17:24:28 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Fri, 11 Jun 2010 10:24:25 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: Torsten Lodderstedt <torsten@lodderstedt.net> Date: Fri, 11 Jun 2010 10:24:22 -0700 Thread-Topic: Re: [OAUTH-WG] in-app logout? Thread-Index: AcsJh+rOgsmJscJsT/+gclGw/7ueUgAAveDA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF7603@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4C126C30.3040701@lodderstedt.net> In-Reply-To: <4C126C30.3040701@lodderstedt.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_90C41DD21FB7C64BB94121FBBC2E72343B3EAF7603P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] in-app logout? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 11 Jun 2010 17:24:36 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EAF7603P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm 135 messages behind on the list. I'm knee deep in -07. EHL From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] Sent: Friday, June 11, 2010 10:03 AM To: Eran Hammer-Lahav Cc: OAuth WG (oauth@ietf.org) Subject: Fwd: Re: [OAUTH-WG] in-app logout? Hi Eran, you probably didn't notice my posting. What do you think about adding a rev= ocation request to the spec? regards, Torsten. -------- Original-Nachricht -------- Betreff: Re: [OAUTH-WG] in-app logout? Datum: Wed, 26 May 2010 20:26:18 +0200 Von: Torsten Lodderstedt <torsten@lodderstedt.net><mailto:torsten@lodderstedt.ne= t> An: Eran Hammer-Lahav <eran@hueniverse.com><mailto:eran@hueniverse.com> CC: OAuth WG (oauth@ietf.org<mailto:oauth@ietf.org>) <oauth@ietf.org><mailto:oa= uth@ietf.org> Hi Eran, in my perception, there is some support on the list for having a request to revoke refresh tokens. Will you add such a request to the specification? Do you need a text proposal? regards, Torsten. > IMHO this would look more like a hack than proper protocol design. We nee= d > a delete/revoke operation that's the pendant to the other token operation= s (i.e. > crud ops). > > Hubert > > > > On Fri, May 21, 2010 at 7:05 PM, Beau Lebens<beau@dentedreality.com.au><m= ailto:beau@dentedreality.com.au> wrote: > >> Could this just be implemented through support for a scope change >> where scope=3Dnone or revoke or something? >> >> On Friday, May 21, 2010, Lukas Rosenstock<lr@lukasrosenstock.net><mailto= :lr@lukasrosenstock.net> wrote: >> >>> Why not simply add this functionality to the token endpoint?The same pl= ace that was used to fetch the access token first or refresh it could be us= ed to revoke the same token with another request. The only requirement woul= d be to define something like type=3Drevoke. >>> I feel that is much easier than making the token a URL which supports D= ELETE. >>> However, any mechanism will break implementations that rely on minimal = or no communication between authorization server and protected resource, be= cause all protected resources have to be informed. >>> >>> Regards, Lukas >>> >>> 2010/5/16 Dick Hardt<dick.hardt@gmail.com><mailto:dick.hardt@gmail.com> >>> >>> James: An important capability of the refresh token is that it *can* be= a self contained token in that is not an id, but a signed token that can b= e examined and acted upon on presentation. >>> Torsten: enabling a client to revoke a refresh token looks like a usefu= l mechanism. I anticipate it will be viewed as a vitamin feature rather tha= n a painkiller and will fall by the wayside unless the security conscience = rally to have it included. >>> >>> >>> -- Dick >>> >>> >>> On Thu, May 13, 2010 at 7:10 AM, Manger, James H<James.H.Manger@team.te= lstra.com><mailto:James.H.Manger@team.telstra.com> wrote: >>> Torsten, >>> >>> >>>> What about refresh token revocation/deletion? >>>> >>> HTTP already has a method to do this: DELETE >>> It just needs each token to have a URI. >>> >>> Tokens (almost) already have URIs -- its just not immediately obvious b= ecause the URI has to be built from a common token endpoint and a refresh_t= oken. >>> >>> I think it would improve the spec if refresh_token was renamed to, say,= token_id; and its value defined as a URI (which can be a relative URI so t= he string may not need to change at all). >>> >>> To refresh a token you POST to the token's URI. >>> To delete a token you send a DELETE request to the token's URI. >>> >>> It doesn't cause major changes, but there are some benefits. >>> It is a more web-style design. >>> It leaves only 1 type of token in the spec -- an access token -- which = simplifies the text and aids understanding. >>> There are no arguments about length, allowed chars etc because it is a = URI -- a well-known type, often with native support. >>> Its obvious how to delete the token as there is a standard HTTP method = DELETE to apply to the token URI. >>> >>> If a particular service supported an additional way to delete items in = its API (eg POST with a method=3Ddelete query parameter) that could apply t= o the OAuth part as well. >>> >>> -- >>> James Manger >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org<mailto:OAuth@ietf.org> >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org<mailto:OAuth@ietf.org> >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> -- >>> http://lukasrosenstock.net/ >>> >>> >>> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org<mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org<mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EAF7603P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV=3D"Content-Type" CONTENT= =3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros= oft Word 14 (filtered medium)"><style><!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} @font-face {font-family:Consolas; panose-1:2 11 6 9 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif"; color:black;} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} pre {mso-style-priority:99; mso-style-link:"HTML Preformatted Char"; margin:0in; margin-bottom:.0001pt; font-size:10.0pt; font-family:"Courier New"; color:black;} span.HTMLPreformattedChar {mso-style-name:"HTML Preformatted Char"; mso-style-priority:99; mso-style-link:"HTML Preformatted"; font-family:Consolas; color:black;} span.EmailStyle19 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--></head><body bgcolor=3Dwhite lang=3DEN-US= link=3Dblue vlink=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal>= <span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1= F497D'>I’m 135 messages behind on the list. I’m knee deep in -0= 7.<o:p></o:p></span></p><p class=3DMsoNormal><span style=3D'font-size:11.0p= t;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span= ></p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Cali= bri","sans-serif";color:#1F497D'>EHL<o:p></o:p></span></p><p class=3DMsoNor= mal><span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";colo= r:#1F497D'><o:p> </o:p></span></p><div style=3D'border:none;border-lef= t:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><div><div style=3D'border:non= e;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=3DMsoN= ormal><b><span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";= color:windowtext'>From:</span></b><span style=3D'font-size:10.0pt;font-fami= ly:"Tahoma","sans-serif";color:windowtext'> Torsten Lodderstedt [mailto:tor= sten@lodderstedt.net] <br><b>Sent:</b> Friday, June 11, 2010 10:03 AM<br><b= >To:</b> Eran Hammer-Lahav<br><b>Cc:</b> OAuth WG (oauth@ietf.org)<br><b>Su= bject:</b> Fwd: Re: [OAUTH-WG] in-app logout?<o:p></o:p></span></p></div></= div><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>Hi Eran,= <br><br>you probably didn't notice my posting. What do you think about addi= ng a revocation request to the spec?<br><br>regards,<br>Torsten.<br><br>---= ----- Original-Nachricht -------- <o:p></o:p></p><table class=3DMsoNormalTa= ble border=3D0 cellspacing=3D0 cellpadding=3D0><tr><td nowrap valign=3Dtop = style=3D'padding:0in 0in 0in 0in'><p class=3DMsoNormal align=3Dright style= =3D'text-align:right'><b>Betreff: <o:p></o:p></b></p></td><td style=3D'padd= ing:0in 0in 0in 0in'><p class=3DMsoNormal>Re: [OAUTH-WG] in-app logout?<o:p= ></o:p></p></td></tr><tr><td nowrap valign=3Dtop style=3D'padding:0in 0in 0= in 0in'><p class=3DMsoNormal align=3Dright style=3D'text-align:right'><b>Da= tum: <o:p></o:p></b></p></td><td style=3D'padding:0in 0in 0in 0in'><p class= =3DMsoNormal>Wed, 26 May 2010 20:26:18 +0200<o:p></o:p></p></td></tr><tr><t= d nowrap valign=3Dtop style=3D'padding:0in 0in 0in 0in'><p class=3DMsoNorma= l align=3Dright style=3D'text-align:right'><b>Von: <o:p></o:p></b></p></td>= <td style=3D'padding:0in 0in 0in 0in'><p class=3DMsoNormal>Torsten Lodderst= edt <a href=3D"mailto:torsten@lodderstedt.net"><torsten@lodderstedt.net&= gt;</a><o:p></o:p></p></td></tr><tr><td nowrap valign=3Dtop style=3D'paddin= g:0in 0in 0in 0in'><p class=3DMsoNormal align=3Dright style=3D'text-align:r= ight'><b>An: <o:p></o:p></b></p></td><td style=3D'padding:0in 0in 0in 0in'>= <p class=3DMsoNormal>Eran Hammer-Lahav <a href=3D"mailto:eran@hueniverse.co= m"><eran@hueniverse.com></a><o:p></o:p></p></td></tr><tr><td nowrap v= align=3Dtop style=3D'padding:0in 0in 0in 0in'><p class=3DMsoNormal align=3D= right style=3D'text-align:right'><b>CC: <o:p></o:p></b></p></td><td style= =3D'padding:0in 0in 0in 0in'><p class=3DMsoNormal>OAuth WG (<a href=3D"mail= to:oauth@ietf.org">oauth@ietf.org</a>) <a href=3D"mailto:oauth@ietf.org">&l= t;oauth@ietf.org></a><o:p></o:p></p></td></tr></table><p class=3DMsoNorm= al style=3D'margin-bottom:12.0pt'><o:p> </o:p></p><pre>Hi Eran,<o:p></= o:p></pre><pre><o:p> </o:p></pre><pre>in my perception, there is some = support on the list for having a request <o:p></o:p></pre><pre>to revoke re= fresh tokens. Will you add such a request to the <o:p></o:p></pre><pre>spec= ification? Do you need a text proposal?<o:p></o:p></pre><pre><o:p> </o= :p></pre><pre>regards,<o:p></o:p></pre><pre>Torsten.<o:p></o:p></pre><pre><= o:p> </o:p></pre><pre>> IMHO this would look more like a hack than = proper protocol design. We need<o:p></o:p></pre><pre>> a delete/revoke o= peration that's the pendant to the other token operations (i.e.<o:p></o:p><= /pre><pre>> crud ops).<o:p></o:p></pre><pre>><o:p> </o:p></pre><= pre>> Hubert<o:p></o:p></pre><pre>><o:p> </o:p></pre><pre>><o= :p> </o:p></pre><pre>><o:p> </o:p></pre><pre>> On Fri, May = 21, 2010 at 7:05 PM, Beau Lebens<a href=3D"mailto:beau@dentedreality.com.au= "><beau@dentedreality.com.au></a>  wrote:<o:p></o:p></pre><pre>&= gt;    <o:p></o:p></pre><pre>>> Could this just be imp= lemented through support for a scope change<o:p></o:p></pre><pre>>> w= here scope=3Dnone or revoke or something?<o:p></o:p></pre><pre>>><o:p= > </o:p></pre><pre>>> On Friday, May 21, 2010, Lukas Rosenstock<= a href=3D"mailto:lr@lukasrosenstock.net"><lr@lukasrosenstock.net></a>=   wrote:<o:p></o:p></pre><pre>>>      <= o:p></o:p></pre><pre>>>> Why not simply add this functionality to = the token endpoint?The same place that was used to fetch the access token f= irst or refresh it could be used to revoke the same token with another requ= est. The only requirement would be to define something like type=3Drevoke.<= o:p></o:p></pre><pre>>>> I feel that is much easier than making th= e token a URL which supports DELETE.<o:p></o:p></pre><pre>>>> Howe= ver, any mechanism will break implementations that rely on minimal or no co= mmunication between authorization server and protected resource, because al= l protected resources have to be informed.<o:p></o:p></pre><pre>>>>= ;<o:p> </o:p></pre><pre>>>> Regards, Lukas<o:p></o:p></pre><p= re>>>><o:p> </o:p></pre><pre>>>> 2010/5/16 Dick Hard= t<a href=3D"mailto:dick.hardt@gmail.com"><dick.hardt@gmail.com></a><o= :p></o:p></pre><pre>>>><o:p> </o:p></pre><pre>>>> Ja= mes: An important capability of the refresh token is that it *can* be a sel= f contained token in that is not an id, but a signed token that can be exam= ined and acted upon on presentation.<o:p></o:p></pre><pre>>>> Tors= ten: enabling a client to revoke a refresh token looks like a useful mechan= ism. I anticipate it will be viewed as a vitamin feature rather than a pain= killer and will fall by the wayside unless the security conscience rally to= have it included.<o:p></o:p></pre><pre>>>><o:p> </o:p></pre>= <pre>>>><o:p> </o:p></pre><pre>>>> -- Dick<o:p></o:p= ></pre><pre>>>><o:p> </o:p></pre><pre>>>><o:p> = </o:p></pre><pre>>>> On Thu, May 13, 2010 at 7:10 AM, Manger, Jame= s H<a href=3D"mailto:James.H.Manger@team.telstra.com"><James.H.Manger@te= am.telstra.com></a>  wrote:<o:p></o:p></pre><pre>>>> Torst= en,<o:p></o:p></pre><pre>>>><o:p> </o:p></pre><pre>>>&g= t;        <o:p></o:p></pre><pre>>>= >> What about refresh token revocation/deletion?<o:p></o:p></pre><pre= >>>>>          <o:= p></o:p></pre><pre>>>> HTTP already has a method to do this: DELET= E<o:p></o:p></pre><pre>>>> It just needs each token to have a URI.= <o:p></o:p></pre><pre>>>><o:p> </o:p></pre><pre>>>> = Tokens (almost) already have URIs -- its just not immediately obvious becau= se the URI has to be built from a common token endpoint and a refresh_token= .<o:p></o:p></pre><pre>>>><o:p> </o:p></pre><pre>>>>= I think it would improve the spec if refresh_token was renamed to, say, to= ken_id; and its value defined as a URI (which can be a relative URI so the = string may not need to change at all).<o:p></o:p></pre><pre>>>><o:= p> </o:p></pre><pre>>>> To refresh a token you POST to the to= ken's URI.<o:p></o:p></pre><pre>>>> To delete a token you send a D= ELETE request to the token's URI.<o:p></o:p></pre><pre>>>><o:p>&nb= sp;</o:p></pre><pre>>>> It doesn't cause major changes, but there = are some benefits.<o:p></o:p></pre><pre>>>> It is a more web-style= design.<o:p></o:p></pre><pre>>>> It leaves only 1 type of token i= n the spec -- an access token -- which simplifies the text and aids underst= anding.<o:p></o:p></pre><pre>>>> There are no arguments about leng= th, allowed chars etc because it is a URI -- a well-known type, often with = native support.<o:p></o:p></pre><pre>>>> Its obvious how to delete= the token as there is a standard HTTP method DELETE to apply to the token = URI.<o:p></o:p></pre><pre>>>><o:p> </o:p></pre><pre>>>&= gt; If a particular service supported an additional way to delete items in = its API (eg POST with a method=3Ddelete query parameter) that could apply t= o the OAuth part as well.<o:p></o:p></pre><pre>>>><o:p> </o:p= ></pre><pre>>>> --<o:p></o:p></pre><pre>>>> James Manger<= o:p></o:p></pre><pre>>>> _________________________________________= ______<o:p></o:p></pre><pre>>>> OAuth mailing list<o:p></o:p></pre= ><pre>>>> <a href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a><o:p= ></o:p></pre><pre>>>> <a href=3D"https://www.ietf.org/mailman/list= info/oauth">https://www.ietf.org/mailman/listinfo/oauth</a><o:p></o:p></pre= ><pre>>>><o:p> </o:p></pre><pre>>>><o:p> </o:p>= </pre><pre>>>><o:p> </o:p></pre><pre>>>> ___________= ____________________________________<o:p></o:p></pre><pre>>>> OAut= h mailing list<o:p></o:p></pre><pre>>>> <a href=3D"mailto:OAuth@ie= tf.org">OAuth@ietf.org</a><o:p></o:p></pre><pre>>>> <a href=3D"htt= ps://www.ietf.org/mailman/listinfo/oauth">https://www.ietf.org/mailman/list= info/oauth</a><o:p></o:p></pre><pre>>>><o:p> </o:p></pre><pre= >>>><o:p> </o:p></pre><pre>>>><o:p> </o:p></pre= ><pre>>>> --<o:p></o:p></pre><pre>>>> <a href=3D"http://l= ukasrosenstock.net/">http://lukasrosenstock.net/</a><o:p></o:p></pre><pre>&= gt;>><o:p> </o:p></pre><pre>>>><o:p> </o:p></pre><= pre>>>>        <o:p></o:p></pre= ><pre>>> _______________________________________________<o:p></o:p></= pre><pre>>> OAuth mailing list<o:p></o:p></pre><pre>>> <a href= =3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a><o:p></o:p></pre><pre>>>= <a href=3D"https://www.ietf.org/mailman/listinfo/oauth">https://www.ietf.o= rg/mailman/listinfo/oauth</a><o:p></o:p></pre><pre>>><o:p> </o:p= ></pre><pre>>>      <o:p></o:p></pre><pre>&g= t; _______________________________________________<o:p></o:p></pre><pre>>= ; OAuth mailing list<o:p></o:p></pre><pre>> <a href=3D"mailto:OAuth@ietf= .org">OAuth@ietf.org</a><o:p></o:p></pre><pre>> <a href=3D"https://www.i= etf.org/mailman/listinfo/oauth">https://www.ietf.org/mailman/listinfo/oauth= </a><o:p></o:p></pre><pre>>    <o:p></o:p></pre><pre><o:p= > </o:p></pre><pre><o:p> </o:p></pre><pre>_______________________= ________________________<o:p></o:p></pre><pre>OAuth mailing list<o:p></o:p>= </pre><pre><a href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a><o:p></o:p><= /pre><pre><a href=3D"https://www.ietf.org/mailman/listinfo/oauth">https://w= ww.ietf.org/mailman/listinfo/oauth</a><o:p></o:p></pre></div></div></body><= /html>= --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EAF7603P3PW5EX1MB01E_-- From eran@hueniverse.com Fri Jun 11 10:25:01 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 461F53A6A13 for <oauth@core3.amsl.com>; Fri, 11 Jun 2010 10:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[AWL=0.649, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i2flHemwai7C for <oauth@core3.amsl.com>; Fri, 11 Jun 2010 10:25:00 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 0390B3A68FC for <oauth@ietf.org>; Fri, 11 Jun 2010 10:24:59 -0700 (PDT) Received: (qmail 3387 invoked from network); 11 Jun 2010 17:25:02 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 11 Jun 2010 17:25:02 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Fri, 11 Jun 2010 10:25:02 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: George Fletcher <gffletch@aol.com>, "oauth@ietf.org" <oauth@ietf.org> Date: Fri, 11 Jun 2010 10:25:00 -0700 Thread-Topic: [OAUTH-WG] User-agent flow and pre-registered redirect_uri Thread-Index: AcsJgr97UWuNXhieTr+Gbc6/HgvQswACDKVA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF7604@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <AANLkTingSGlJNZ5e_stPd1qU5I4gfbh3rQhqYUmqXvdB@mail.gmail.com> <C833CEB4.6B81%cmortimore@salesforce.com> <AANLkTinVQEPBVzmiHEGgHhzaILL0nRSvZpjIlrVEJwTw@mail.gmail.com> <AANLkTil1j7vl8PU2tgCzlWY0U6KiWPmRKiVOxvsctB00@mail.gmail.com> <AANLkTimCL-O7RIsUlt_zGDfkEEYb9w4_sPh6zxCMBsf0@mail.gmail.com> <AANLkTin7B9pPgSu3cNlJGkp_gCed-5aPGRZalzXd2Wg8@mail.gmail.com> <4C124A70.2000002@aol.com> <1276268753.31840.50.camel@localhost.localdomain> <4C1257B5.9080706@comlounge.net> <AANLkTilcpAw7hZuQK43_ybS-wy3bQnPqMfRXOdqY4iYa@mail.gmail.com> <AANLkTimGnTj1HseMsPBaRXjBThM3uktqq0R6P30jsjaZ@mail.gmail.com> <AANLkTimyvpXmlOXRKSA4Oe0s3rqoiLQgtgvbRlvniEJ6@mail.gmail.com> <4C126367.40403@aol.com> In-Reply-To: <4C126367.40403@aol.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] User-agent flow and pre-registered redirect_uri X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 11 Jun 2010 17:25:01 -0000 Client doesn't need to *be* a web server, just *have* a web server availabl= e. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of George Fletcher > Sent: Friday, June 11, 2010 9:25 AM > To: oauth@ietf.org > Subject: Re: [OAUTH-WG] User-agent flow and pre-registered redirect_uri >=20 > On 6/11/10 12:07 PM, Marius Scurtescu wrote: > > On Fri, Jun 11, 2010 at 8:59 AM, David Recordon<recordond@gmail.com> > wrote: > > > >> That sounds like a security consideration to me! :) > >> > >> I imagine that authorization servers will verify ownership in > >> different manners depending on their tolerance of risk. > >> > > Instead of POSTing a JSON with all the details, dynamic binding could > > send only a host name. The authz server would then do discovery on > > this host and get a pointer to this JSON from host-meta. > > > > Marius > > > > > I think most all of this could be described in the host-meta XRD directly= to > save yet another round trip. And I believe there are some security > advantages to using this approach, but it does require the "client" to be= a > web-server. This might not always be the case (rich desktop app). For > native/desktop apps, it seems that posting some set of parameters > (equivalent security-wise to a browser user-agent) makes sense and keeps > the protocol simple. >=20 > Thanks, > George > >> > >> On Fri, Jun 11, 2010 at 8:54 AM, Marius > Scurtescu<mscurtescu@google.com> wrote: > >> > >>> On Fri, Jun 11, 2010 at 8:35 AM, Christian Scholz<cs@comlounge.net> > wrote: > >>> > >>>> Hi! > >>>> > >>>> Am 11.06.10 17:05, schrieb Justin Richer: > >>>> > >>>>> Along these lines, I'd like to propose an extension for per-client > >>>>> instance information to be passed from a client to the server. > >>>>> Things like a human-readable client name/description, instance > >>>>> name/description (could be tied to host name, ip, label like > >>>>> "home" or "Work"), and even something like a display icon. This is > >>>>> especially useful for things like device clients (where I might > >>>>> have a bunch of devices with the same client ID) or unregistered > >>>>> clients, where the client id string ends up being closer to a > >>>>> user-agent string from a browser than a trusted identifier, especia= lly > since it can't have a reliable secret. > >>>>> > >>>> We have the need for dynamic binding of clients in the User Managed > >>>> Access group (UMA) as well. I did look into OpenID Connect but felt > >>>> that reusing an OAuth flow based on a different type is maybe > >>>> mixing things a bit too much. To me using a flow means that in the > >>>> end usually you end up with an access token which here is not the > >>>> case. Especially I don't like the reuse of the token URI as IMHO > >>>> it's better to use separate endpoints for different APIs. > >>>> > >>>> I thus went along and crafted some simple handshake in the UMA > >>>> specification which I also wanted to move out into a single > >>>> specification over the next days. > >>>> > >>>> You can find it here: > >>>> > >>>> http://kantarainitiative.org/confluence/display/~christianscholz/St > >>>> ep+1+experimental+version+v1 > >>>> > >>>> under "Dynamic binding of OAuth clients". > >>>> > >>>> It is a simple handshake where you provide a JSON formatted client > >>>> descriptor containing the information you describe above and the > >>>> results is a set of client credentials plus optionally additional > >>>> information (in UMA we eventually need to pass back more > >>>> information like additional endpoints). > >>>> > >>> In general during registration an authz server will verify that the > >>> client really owns the domain it claims it does. Does any validation > >>> like that happen in the suggested "Dynamic binding of OAuth clients"? > >>> > >>> Marius > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth > >>> > >>> > >> > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From mscurtescu@google.com Fri Jun 11 11:09:50 2010 Return-Path: <mscurtescu@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF7CE3A6977 for <oauth@core3.amsl.com>; Fri, 11 Jun 2010 11:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.79 X-Spam-Level: X-Spam-Status: No, score=-100.79 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FIcKUC34hwya for <oauth@core3.amsl.com>; Fri, 11 Jun 2010 11:09:49 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 7E9273A6992 for <oauth@ietf.org>; Fri, 11 Jun 2010 11:09:49 -0700 (PDT) Received: from hpaq1.eem.corp.google.com (hpaq1.eem.corp.google.com [172.25.149.1]) by smtp-out.google.com with ESMTP id o5BI9ocR022292 for <oauth@ietf.org>; Fri, 11 Jun 2010 11:09:50 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1276279790; bh=M+iZJl9f70zCnLIUxaZYS+Eu3lw=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=i3e1+R2vJXDvsnIqYkYCu+oXIaVFY8afqo7kT1aCqMmTRnjwrbej2nlgNMuSKUTnQ DwhCPH7jGXpr7I5rOs+vw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding; b=SXO6zUh/PCsXaAhIg4xRe2wq9qZbAIZsveSAyGGcsi3gEq3tXQaggg/8H8tlDzzzW Vq6zYrYGUrXNr2bKL+REQ== Received: from pxi11 (pxi11.prod.google.com [10.243.27.11]) by hpaq1.eem.corp.google.com with ESMTP id o5BI9mno029925 for <oauth@ietf.org>; Fri, 11 Jun 2010 11:09:49 -0700 Received: by pxi11 with SMTP id 11so597424pxi.40 for <oauth@ietf.org>; Fri, 11 Jun 2010 11:09:48 -0700 (PDT) Received: by 10.141.105.16 with SMTP id h16mr1650170rvm.274.1276279788147; Fri, 11 Jun 2010 11:09:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.124.13 with HTTP; Fri, 11 Jun 2010 11:09:28 -0700 (PDT) In-Reply-To: <4C126D63.9090903@aol.com> References: <AANLkTingSGlJNZ5e_stPd1qU5I4gfbh3rQhqYUmqXvdB@mail.gmail.com> <C833CEB4.6B81%cmortimore@salesforce.com> <AANLkTinVQEPBVzmiHEGgHhzaILL0nRSvZpjIlrVEJwTw@mail.gmail.com> <AANLkTil1j7vl8PU2tgCzlWY0U6KiWPmRKiVOxvsctB00@mail.gmail.com> <AANLkTimCL-O7RIsUlt_zGDfkEEYb9w4_sPh6zxCMBsf0@mail.gmail.com> <AANLkTin7B9pPgSu3cNlJGkp_gCed-5aPGRZalzXd2Wg8@mail.gmail.com> <4C124A70.2000002@aol.com> <1276268753.31840.50.camel@localhost.localdomain> <4C1257B5.9080706@comlounge.net> <AANLkTilcpAw7hZuQK43_ybS-wy3bQnPqMfRXOdqY4iYa@mail.gmail.com> <AANLkTimGnTj1HseMsPBaRXjBThM3uktqq0R6P30jsjaZ@mail.gmail.com> <AANLkTimyvpXmlOXRKSA4Oe0s3rqoiLQgtgvbRlvniEJ6@mail.gmail.com> <4C126367.40403@aol.com> <AANLkTimKEFRu-PboKcpXFlFN7Q_675ZjICBnK9IliUzs@mail.gmail.com> <4C126D63.9090903@aol.com> From: Marius Scurtescu <mscurtescu@google.com> Date: Fri, 11 Jun 2010 11:09:28 -0700 Message-ID: <AANLkTinryo8AMgqgQoPgn0cAxuYNXhHtBS--rx5A52Zb@mail.gmail.com> To: George Fletcher <gffletch@aol.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] User-agent flow and pre-registered redirect_uri X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 11 Jun 2010 18:09:50 -0000 On Fri, Jun 11, 2010 at 10:07 AM, George Fletcher <gffletch@aol.com> wrote: > On 6/11/10 12:34 PM, Marius Scurtescu wrote: >> >> On Fri, Jun 11, 2010 at 9:25 AM, George Fletcher<gffletch@aol.com> =A0wr= ote: >> >>> >>> On 6/11/10 12:07 PM, Marius Scurtescu wrote: >>> >>>> >>>> On Fri, Jun 11, 2010 at 8:59 AM, David Recordon<recordond@gmail.com> >>>> =A0wrote: >>>> >>>> >>>>> >>>>> That sounds like a security consideration to me! :) >>>>> >>>>> I imagine that authorization servers will verify ownership in >>>>> different manners depending on their tolerance of risk. >>>>> >>>>> >>>> >>>> Instead of POSTing a JSON with all the details, dynamic binding could >>>> send only a host name. The authz server would then do discovery on >>>> this host and get a pointer to this JSON from host-meta. >>>> >>>> Marius >>>> >>>> >>>> >>> >>> I think most all of this could be described in the host-meta XRD direct= ly >>> to >>> save yet another round trip. And I believe there are some security >>> advantages to using this approach, but it does require the "client" to = be >>> a >>> web-server. This might not always be the case (rich desktop app). For >>> native/desktop apps, it seems that posting some set of parameters >>> (equivalent security-wise to a browser user-agent) makes sense and keep= s >>> the >>> protocol simple. >>> >> >> Yes, but in this case (desktop app) the "url" and "icon" parameters >> don't work and what is left is "name" and "description". I think that >> the suggested "client_name" parameter does exactly the same thing, >> much simpler. Is there any value in this case in a client_secret? >> >> Marius >> > > Well... given this is a POST and structured data... it would be possible = for > the desktop app to post the raw icon data (though I suppose it could also > POST a URL to the web server of the company the produces the app). In whi= ch > case your previous suggestion would work (parameters discovered via the > URL). > > I do believe the client_secret is valuable in this case because the AS is > returning both the client_id and the client_secret. This then becomes a w= ay > for provisioning a unique client_id and client_secret to every instance o= f > the app. A lot more for the AS to keep track of, but also makes it more > difficult for an attacker to compromise a client. The attacker could > impersonate the POST'd client description data (just like user-agent stri= ngs > can be impersonated), but then the attacker just has a client_id and > client_secret for it's instance. > > This should force the attacker to get explicit user consent from the user= to > authorize that unique client_id. I wouldn't recommend for the AS to track > authorization against the POST'd client description but rather the > client_id. An attacker can also dynamically register a very similar client name/description and trick the user. The authz server is issuing a unique refresh token for each client, and I still don't see how an extra client_secret helps in this case. For a web client the client secret helps if the refresh token is compromised. The web client most likely will store many refresh tokens, one for each user, in the database, with SQL injection all of these can be compromised, but the client secret (if it was not in the same database) makes them useless. This could be a reason why dynamic registration for web clients is a bad idea, the client secret will end up in the database, instead of a config file. For a desktop client, this is not the case. Marius From gffletch@aol.com Fri Jun 11 11:47:33 2010 Return-Path: <gffletch@aol.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2257E3A67F2 for <oauth@core3.amsl.com>; Fri, 11 Jun 2010 11:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.462 X-Spam-Level: X-Spam-Status: No, score=-0.462 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lwEJDSys7poM for <oauth@core3.amsl.com>; Fri, 11 Jun 2010 11:47:08 -0700 (PDT) Received: from imr-db03.mx.aol.com (imr-db03.mx.aol.com [205.188.91.97]) by core3.amsl.com (Postfix) with ESMTP id 05D2B3A6933 for <oauth@ietf.org>; Fri, 11 Jun 2010 11:47:07 -0700 (PDT) Received: from mtaout-da06.r1000.mx.aol.com (mtaout-da06.r1000.mx.aol.com [172.29.51.134]) by imr-db03.mx.aol.com (8.14.1/8.14.1) with ESMTP id o5BIkcKD010907; Fri, 11 Jun 2010 14:46:41 -0400 Received: from palantir.local (unknown [10.172.1.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-da06.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id BC1E5E000149; Fri, 11 Jun 2010 14:46:39 -0400 (EDT) Message-ID: <4C12848E.8090105@aol.com> Date: Fri, 11 Jun 2010 14:46:38 -0400 From: George Fletcher <gffletch@aol.com> Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: oauth@ietf.org References: <AANLkTingSGlJNZ5e_stPd1qU5I4gfbh3rQhqYUmqXvdB@mail.gmail.com> <C833CEB4.6B81%cmortimore@salesforce.com> <AANLkTinVQEPBVzmiHEGgHhzaILL0nRSvZpjIlrVEJwTw@mail.gmail.com> <AANLkTil1j7vl8PU2tgCzlWY0U6KiWPmRKiVOxvsctB00@mail.gmail.com> <AANLkTimCL-O7RIsUlt_zGDfkEEYb9w4_sPh6zxCMBsf0@mail.gmail.com> <AANLkTin7B9pPgSu3cNlJGkp_gCed-5aPGRZalzXd2Wg8@mail.gmail.com> <4C124A70.2000002@aol.com> <1276268753.31840.50.camel@localhost.localdomain> <4C1257B5.9080706@comlounge.net> <AANLkTilcpAw7hZuQK43_ybS-wy3bQnPqMfRXOdqY4iYa@mail.gmail.com> <AANLkTimGnTj1HseMsPBaRXjBThM3uktqq0R6P30jsjaZ@mail.gmail.com> <AANLkTimyvpXmlOXRKSA4Oe0s3rqoiLQgtgvbRlvniEJ6@mail.gmail.com> <4C126367.40403@aol.com> <AANLkTimKEFRu-PboKcpXFlFN7Q_675ZjICBnK9IliUzs@mail.gmail.com> <4C126D63.9090903@aol.com> <AANLkTinryo8AMgqgQoPgn0cAxuYNXhHtBS--rx5A52Zb@mail.gmail.com> In-Reply-To: <AANLkTinryo8AMgqgQoPgn0cAxuYNXhHtBS--rx5A52Zb@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit x-aol-global-disposition: G X-AOL-SCOLL-SCORE: 0:2:401258496:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d33864c12848f6761 X-AOL-IP: 10.172.1.149 Subject: Re: [OAUTH-WG] User-agent flow and pre-registered redirect_uri X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 11 Jun 2010 18:47:33 -0000 On 6/11/10 2:09 PM, Marius Scurtescu wrote: > On Fri, Jun 11, 2010 at 10:07 AM, George Fletcher<gffletch@aol.com> wrote: > >> On 6/11/10 12:34 PM, Marius Scurtescu wrote: >> >>> On Fri, Jun 11, 2010 at 9:25 AM, George Fletcher<gffletch@aol.com> wrote: >>> >>> >>>> On 6/11/10 12:07 PM, Marius Scurtescu wrote: >>>> >>>> >>>>> On Fri, Jun 11, 2010 at 8:59 AM, David Recordon<recordond@gmail.com> >>>>> wrote: >>>>> >>>>> >>>>> >>>>>> That sounds like a security consideration to me! :) >>>>>> >>>>>> I imagine that authorization servers will verify ownership in >>>>>> different manners depending on their tolerance of risk. >>>>>> >>>>>> >>>>>> >>>>> Instead of POSTing a JSON with all the details, dynamic binding could >>>>> send only a host name. The authz server would then do discovery on >>>>> this host and get a pointer to this JSON from host-meta. >>>>> >>>>> Marius >>>>> >>>>> >>>>> >>>>> >>>> I think most all of this could be described in the host-meta XRD directly >>>> to >>>> save yet another round trip. And I believe there are some security >>>> advantages to using this approach, but it does require the "client" to be >>>> a >>>> web-server. This might not always be the case (rich desktop app). For >>>> native/desktop apps, it seems that posting some set of parameters >>>> (equivalent security-wise to a browser user-agent) makes sense and keeps >>>> the >>>> protocol simple. >>>> >>>> >>> Yes, but in this case (desktop app) the "url" and "icon" parameters >>> don't work and what is left is "name" and "description". I think that >>> the suggested "client_name" parameter does exactly the same thing, >>> much simpler. Is there any value in this case in a client_secret? >>> >>> Marius >>> >>> >> Well... given this is a POST and structured data... it would be possible for >> the desktop app to post the raw icon data (though I suppose it could also >> POST a URL to the web server of the company the produces the app). In which >> case your previous suggestion would work (parameters discovered via the >> URL). >> >> I do believe the client_secret is valuable in this case because the AS is >> returning both the client_id and the client_secret. This then becomes a way >> for provisioning a unique client_id and client_secret to every instance of >> the app. A lot more for the AS to keep track of, but also makes it more >> difficult for an attacker to compromise a client. The attacker could >> impersonate the POST'd client description data (just like user-agent strings >> can be impersonated), but then the attacker just has a client_id and >> client_secret for it's instance. >> >> This should force the attacker to get explicit user consent from the user to >> authorize that unique client_id. I wouldn't recommend for the AS to track >> authorization against the POST'd client description but rather the >> client_id. >> > An attacker can also dynamically register a very similar client > name/description and trick the user. > True... but the user will see another consent form. This might be a minor hurdle but at least it's not totally seamless. I think that is an advantage. > The authz server is issuing a unique refresh token for each client, > and I still don't see how an extra client_secret helps in this case. > Good point. With SSL and bearer tokens the client_secret doesn't do much good. Now if we signed the requests with the unique client_secret from the desktop app... :) > For a web client the client secret helps if the refresh token is > compromised. The web client most likely will store many refresh > tokens, one for each user, in the database, with SQL injection all of > these can be compromised, but the client secret (if it was not in the > same database) makes them useless. This could be a reason why dynamic > registration for web clients is a bad idea, the client secret will end > up in the database, instead of a config file. > The web site could store client_secrets in a different database that is not exposed to the same SQL Injection attacks. Where the data is stored doesn't seem like it affects it's ability to be compromised or protected. If the web server is not well protected, getting the config file with the client_secret might be easier than getting data out of the database. I think the security of where the web app stores the data is orthogonal to the security of the protocol. > For a desktop client, this is not the case. > > Marius > I suppose this also depends on which flow the desktop app is following. If using the web-user flow (by launching the default browser, then the client_secret (v2-06) is required. If following the device flow... then it's not (though it seems this flow is still being defined). So maybe the solution is that if the authorization server doesn't think the client_secret is useful, it doesn't return it. Or it always returns it and the client can throw it away as it knows it won't use it. However, it seems like the rest of the registration flow still holds. Thanks, George From jricher@mitre.org Fri Jun 11 11:49:52 2010 Return-Path: <jricher@mitre.org> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB79628C13F for <oauth@core3.amsl.com>; Fri, 11 Jun 2010 11:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.633 X-Spam-Level: X-Spam-Status: No, score=-3.633 tagged_above=-999 required=5 tests=[AWL=-1.434, BAYES_50=0.001, J_CHICKENPOX_54=0.6, J_CHICKENPOX_66=0.6, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sXL+0k5xecT5 for <oauth@core3.amsl.com>; Fri, 11 Jun 2010 11:49:51 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 1B9B43A6990 for <oauth@ietf.org>; Fri, 11 Jun 2010 11:49:51 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o5BInqdG013283 for <oauth@ietf.org>; Fri, 11 Jun 2010 14:49:53 -0400 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o5BInqlt013271; Fri, 11 Jun 2010 14:49:52 -0400 Received: from [129.83.50.65] (129.83.50.65) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server id 8.2.254.0; Fri, 11 Jun 2010 14:49:52 -0400 From: Justin Richer <jricher@mitre.org> To: Torsten Lodderstedt <torsten@lodderstedt.net> In-Reply-To: <4C126C30.3040701@lodderstedt.net> References: <4C126C30.3040701@lodderstedt.net> Content-Type: text/plain; charset="UTF-8" Date: Fri, 11 Jun 2010 14:49:51 -0400 Message-ID: <1276282191.31840.74.camel@localhost.localdomain> MIME-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Fwd: Re: in-app logout? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 11 Jun 2010 18:49:53 -0000 I'd like to voice support for Dick's proposal of re-scoping[1] and (in later discussion) revoking access tokens using the refresh token as authentication. I'd like to see us give clients a way to manipulate tokens through OAuth entirely. I also think that revoke should be a separate mechanism from rescoping, and that it should be handled through a parameter, such as "type" in Dick's proposal. It would not only give us more full token management, I think it will actually help with some redelegation situations that I've been talking about with some of my colleagues here. You can scope an access token down to a subset of your original scopes without user intervention, and then hand that subscoped token to another client. I'll be getting together with folks to talk about this redelegation stuff shortly, so more on that later; but it is something we're definitely interested in, and I've seen others voice interest in it as well. This does raise the question of one refresh token (and therefore one user authorization) being associated with multiple simultaneously-valid access tokens, though. The spec seems to assume a single access token is valid for a given authorization at a time, but is mostly silent on the matter. -- Justin [1] http://www.ietf.org/mail-archive/web/oauth/current/msg02408.html On Fri, 2010-06-11 at 13:02 -0400, Torsten Lodderstedt wrote: > Hi Eran, > > you probably didn't notice my posting. What do you think about adding > a revocation request to the spec? > > regards, > Torsten. > > -------- Original-Nachricht -------- > Betreff: > Re: [OAUTH-WG] in-app logout? > Datum: > Wed, 26 May 2010 20:26:18 +0200 > Von: > Torsten Lodderstedt > <torsten@lodderstedt.net> > An: > Eran Hammer-Lahav > <eran@hueniverse.com> > CC: > OAuth WG (oauth@ietf.org) > <oauth@ietf.org> > > > Hi Eran, > > in my perception, there is some support on the list for having a request > to revoke refresh tokens. Will you add such a request to the > specification? Do you need a text proposal? > > regards, > Torsten. > > > IMHO this would look more like a hack than proper protocol design. We need > > a delete/revoke operation that's the pendant to the other token operations (i.e. > > crud ops). > > > > Hubert > > > > > > > > On Fri, May 21, 2010 at 7:05 PM, Beau Lebens<beau@dentedreality.com.au> wrote: > > > >> Could this just be implemented through support for a scope change > >> where scope=none or revoke or something? > >> > >> On Friday, May 21, 2010, Lukas Rosenstock<lr@lukasrosenstock.net> wrote: > >> > >>> Why not simply add this functionality to the token endpoint?The same place that was used to fetch the access token first or refresh it could be used to revoke the same token with another request. The only requirement would be to define something like type=revoke. > >>> I feel that is much easier than making the token a URL which supports DELETE. > >>> However, any mechanism will break implementations that rely on minimal or no communication between authorization server and protected resource, because all protected resources have to be informed. > >>> > >>> Regards, Lukas > >>> > >>> 2010/5/16 Dick Hardt<dick.hardt@gmail.com> > >>> > >>> James: An important capability of the refresh token is that it *can* be a self contained token in that is not an id, but a signed token that can be examined and acted upon on presentation. > >>> Torsten: enabling a client to revoke a refresh token looks like a useful mechanism. I anticipate it will be viewed as a vitamin feature rather than a painkiller and will fall by the wayside unless the security conscience rally to have it included. > >>> > >>> > >>> -- Dick > >>> > >>> > >>> On Thu, May 13, 2010 at 7:10 AM, Manger, James H<James.H.Manger@team.telstra.com> wrote: > >>> Torsten, > >>> > >>> > >>>> What about refresh token revocation/deletion? > >>>> > >>> HTTP already has a method to do this: DELETE > >>> It just needs each token to have a URI. > >>> > >>> Tokens (almost) already have URIs -- its just not immediately obvious because the URI has to be built from a common token endpoint and a refresh_token. > >>> > >>> I think it would improve the spec if refresh_token was renamed to, say, token_id; and its value defined as a URI (which can be a relative URI so the string may not need to change at all). > >>> > >>> To refresh a token you POST to the token's URI. > >>> To delete a token you send a DELETE request to the token's URI. > >>> > >>> It doesn't cause major changes, but there are some benefits. > >>> It is a more web-style design. > >>> It leaves only 1 type of token in the spec -- an access token -- which simplifies the text and aids understanding. > >>> There are no arguments about length, allowed chars etc because it is a URI -- a well-known type, often with native support. > >>> Its obvious how to delete the token as there is a standard HTTP method DELETE to apply to the token URI. > >>> > >>> If a particular service supported an additional way to delete items in its API (eg POST with a method=delete query parameter) that could apply to the OAuth part as well. > >>> > >>> -- > >>> James Manger > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth > >>> > >>> > >>> > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth > >>> > >>> > >>> > >>> -- > >>> http://lukasrosenstock.net/ > >>> > >>> > >>> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > >> > >> > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From gffletch@aol.com Fri Jun 11 12:03:02 2010 Return-Path: <gffletch@aol.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82F853A6A41 for <oauth@core3.amsl.com>; Fri, 11 Jun 2010 12:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.547 X-Spam-Level: X-Spam-Status: No, score=-0.547 tagged_above=-999 required=5 tests=[AWL=0.252, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, J_CHICKENPOX_66=0.6, J_CHICKENPOX_83=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fosQwVFwY+nl for <oauth@core3.amsl.com>; Fri, 11 Jun 2010 12:03:00 -0700 (PDT) Received: from imr-db01.mx.aol.com (imr-db01.mx.aol.com [205.188.91.95]) by core3.amsl.com (Postfix) with ESMTP id D15073A699D for <oauth@ietf.org>; Fri, 11 Jun 2010 12:02:57 -0700 (PDT) Received: from mtaout-da05.r1000.mx.aol.com (mtaout-da05.r1000.mx.aol.com [172.29.51.133]) by imr-db01.mx.aol.com (8.14.1/8.14.1) with ESMTP id o5BJ2ReG022571; Fri, 11 Jun 2010 15:02:33 -0400 Received: from palantir.local (unknown [10.172.1.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-da05.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 3CC1AE000098; Fri, 11 Jun 2010 15:02:28 -0400 (EDT) Message-ID: <4C12883E.2040107@aol.com> Date: Fri, 11 Jun 2010 15:02:22 -0400 From: George Fletcher <gffletch@aol.com> Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org> References: <4C126C30.3040701@lodderstedt.net> <1276282191.31840.74.camel@localhost.localdomain> In-Reply-To: <1276282191.31840.74.camel@localhost.localdomain> Content-Type: multipart/alternative; boundary="------------000408020407020300000603" x-aol-global-disposition: G X-AOL-SCOLL-SCORE: 0:2:488886752:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d33854c12884413f9 X-AOL-IP: 10.172.1.149 Subject: Re: [OAUTH-WG] Fwd: Re: in-app logout? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 11 Jun 2010 19:03:02 -0000 This is a multi-part message in MIME format. --------------000408020407020300000603 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit +1 to re-delegation I'd like to add that with down-scoping and re-delegation it would be nice to be able to bind a re-delegated access token to the client that will present it. With re-delegation, the down-stream client doesn't have an easy "refresh" token so a short-lived access token might not be the best solution. I realize this may not be the main stream use case, but I would like to make sure it's not prohibited in any proposed solution. Thanks, George On 6/11/10 2:49 PM, Justin Richer wrote: > I'd like to voice support for Dick's proposal of re-scoping[1] and (in > later discussion) revoking access tokens using the refresh token as > authentication. I'd like to see us give clients a way to manipulate > tokens through OAuth entirely. I also think that revoke should be a > separate mechanism from rescoping, and that it should be handled through > a parameter, such as "type" in Dick's proposal. > > It would not only give us more full token management, I think it will > actually help with some redelegation situations that I've been talking > about with some of my colleagues here. You can scope an access token > down to a subset of your original scopes without user intervention, and > then hand that subscoped token to another client. I'll be getting > together with folks to talk about this redelegation stuff shortly, so > more on that later; but it is something we're definitely interested in, > and I've seen others voice interest in it as well. > > This does raise the question of one refresh token (and therefore one > user authorization) being associated with multiple simultaneously-valid > access tokens, though. The spec seems to assume a single access token is > valid for a given authorization at a time, but is mostly silent on the > matter. > > -- Justin > > [1] http://www.ietf.org/mail-archive/web/oauth/current/msg02408.html > > On Fri, 2010-06-11 at 13:02 -0400, Torsten Lodderstedt wrote: > >> Hi Eran, >> >> you probably didn't notice my posting. What do you think about adding >> a revocation request to the spec? >> >> regards, >> Torsten. >> >> -------- Original-Nachricht -------- >> Betreff: >> Re: [OAUTH-WG] in-app logout? >> Datum: >> Wed, 26 May 2010 20:26:18 +0200 >> Von: >> Torsten Lodderstedt >> <torsten@lodderstedt.net> >> An: >> Eran Hammer-Lahav >> <eran@hueniverse.com> >> CC: >> OAuth WG (oauth@ietf.org) >> <oauth@ietf.org> >> >> >> Hi Eran, >> >> in my perception, there is some support on the list for having a request >> to revoke refresh tokens. Will you add such a request to the >> specification? Do you need a text proposal? >> >> regards, >> Torsten. >> >> >>> IMHO this would look more like a hack than proper protocol design. We need >>> a delete/revoke operation that's the pendant to the other token operations (i.e. >>> crud ops). >>> >>> Hubert >>> >>> >>> >>> On Fri, May 21, 2010 at 7:05 PM, Beau Lebens<beau@dentedreality.com.au> wrote: >>> >>> >>>> Could this just be implemented through support for a scope change >>>> where scope=none or revoke or something? >>>> >>>> On Friday, May 21, 2010, Lukas Rosenstock<lr@lukasrosenstock.net> wrote: >>>> >>>> >>>>> Why not simply add this functionality to the token endpoint?The same place that was used to fetch the access token first or refresh it could be used to revoke the same token with another request. The only requirement would be to define something like type=revoke. >>>>> I feel that is much easier than making the token a URL which supports DELETE. >>>>> However, any mechanism will break implementations that rely on minimal or no communication between authorization server and protected resource, because all protected resources have to be informed. >>>>> >>>>> Regards, Lukas >>>>> >>>>> 2010/5/16 Dick Hardt<dick.hardt@gmail.com> >>>>> >>>>> James: An important capability of the refresh token is that it *can* be a self contained token in that is not an id, but a signed token that can be examined and acted upon on presentation. >>>>> Torsten: enabling a client to revoke a refresh token looks like a useful mechanism. I anticipate it will be viewed as a vitamin feature rather than a painkiller and will fall by the wayside unless the security conscience rally to have it included. >>>>> >>>>> >>>>> -- Dick >>>>> >>>>> >>>>> On Thu, May 13, 2010 at 7:10 AM, Manger, James H<James.H.Manger@team.telstra.com> wrote: >>>>> Torsten, >>>>> >>>>> >>>>> >>>>>> What about refresh token revocation/deletion? >>>>>> >>>>>> >>>>> HTTP already has a method to do this: DELETE >>>>> It just needs each token to have a URI. >>>>> >>>>> Tokens (almost) already have URIs -- its just not immediately obvious because the URI has to be built from a common token endpoint and a refresh_token. >>>>> >>>>> I think it would improve the spec if refresh_token was renamed to, say, token_id; and its value defined as a URI (which can be a relative URI so the string may not need to change at all). >>>>> >>>>> To refresh a token you POST to the token's URI. >>>>> To delete a token you send a DELETE request to the token's URI. >>>>> >>>>> It doesn't cause major changes, but there are some benefits. >>>>> It is a more web-style design. >>>>> It leaves only 1 type of token in the spec -- an access token -- which simplifies the text and aids understanding. >>>>> There are no arguments about length, allowed chars etc because it is a URI -- a well-known type, often with native support. >>>>> Its obvious how to delete the token as there is a standard HTTP method DELETE to apply to the token URI. >>>>> >>>>> If a particular service supported an additional way to delete items in its API (eg POST with a method=delete query parameter) that could apply to the OAuth part as well. >>>>> >>>>> -- >>>>> James Manger >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> >>>>> >>>>> -- >>>>> http://lukasrosenstock.net/ >>>>> >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> OAuth mailing 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 > --------------000408020407020300000603 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> <font face="Helvetica, Arial, sans-serif">+1 to re-delegation<br> <br> I'd like to add that with down-scoping and re-delegation it would be nice to be able to bind a re-delegated access token to the client that will present it. With re-delegation, the down-stream client doesn't have an easy "refresh" token so a short-lived access token might not be the best solution. <br> <br> I realize this may not be the main stream use case, but I would like to make sure it's not prohibited in any proposed solution.<br> <br> Thanks,<br> George<br> </font><br> On 6/11/10 2:49 PM, Justin Richer wrote: <blockquote cite="mid:1276282191.31840.74.camel@localhost.localdomain" type="cite"> <pre wrap="">I'd like to voice support for Dick's proposal of re-scoping[1] and (in later discussion) revoking access tokens using the refresh token as authentication. I'd like to see us give clients a way to manipulate tokens through OAuth entirely. I also think that revoke should be a separate mechanism from rescoping, and that it should be handled through a parameter, such as "type" in Dick's proposal. It would not only give us more full token management, I think it will actually help with some redelegation situations that I've been talking about with some of my colleagues here. You can scope an access token down to a subset of your original scopes without user intervention, and then hand that subscoped token to another client. I'll be getting together with folks to talk about this redelegation stuff shortly, so more on that later; but it is something we're definitely interested in, and I've seen others voice interest in it as well. This does raise the question of one refresh token (and therefore one user authorization) being associated with multiple simultaneously-valid access tokens, though. The spec seems to assume a single access token is valid for a given authorization at a time, but is mostly silent on the matter. -- Justin [1] <a class="moz-txt-link-freetext" href="http://www.ietf.org/mail-archive/web/oauth/current/msg02408.html">http://www.ietf.org/mail-archive/web/oauth/current/msg02408.html</a> On Fri, 2010-06-11 at 13:02 -0400, Torsten Lodderstedt wrote: </pre> <blockquote type="cite"> <pre wrap="">Hi Eran, you probably didn't notice my posting. What do you think about adding a revocation request to the spec? regards, Torsten. -------- Original-Nachricht -------- Betreff: Re: [OAUTH-WG] in-app logout? Datum: Wed, 26 May 2010 20:26:18 +0200 Von: Torsten Lodderstedt <a class="moz-txt-link-rfc2396E" href="mailto:torsten@lodderstedt.net"><torsten@lodderstedt.net></a> An: Eran Hammer-Lahav <a class="moz-txt-link-rfc2396E" href="mailto:eran@hueniverse.com"><eran@hueniverse.com></a> CC: OAuth WG (<a class="moz-txt-link-abbreviated" href="mailto:oauth@ietf.org">oauth@ietf.org</a>) <a class="moz-txt-link-rfc2396E" href="mailto:oauth@ietf.org"><oauth@ietf.org></a> Hi Eran, in my perception, there is some support on the list for having a request to revoke refresh tokens. Will you add such a request to the specification? Do you need a text proposal? regards, Torsten. </pre> <blockquote type="cite"> <pre wrap="">IMHO this would look more like a hack than proper protocol design. We need a delete/revoke operation that's the pendant to the other token operations (i.e. crud ops). Hubert On Fri, May 21, 2010 at 7:05 PM, Beau Lebens<a class="moz-txt-link-rfc2396E" href="mailto:beau@dentedreality.com.au"><beau@dentedreality.com.au></a> wrote: </pre> <blockquote type="cite"> <pre wrap="">Could this just be implemented through support for a scope change where scope=none or revoke or something? On Friday, May 21, 2010, Lukas Rosenstock<a class="moz-txt-link-rfc2396E" href="mailto:lr@lukasrosenstock.net"><lr@lukasrosenstock.net></a> wrote: </pre> <blockquote type="cite"> <pre wrap="">Why not simply add this functionality to the token endpoint?The same place that was used to fetch the access token first or refresh it could be used to revoke the same token with another request. The only requirement would be to define something like type=revoke. I feel that is much easier than making the token a URL which supports DELETE. However, any mechanism will break implementations that rely on minimal or no communication between authorization server and protected resource, because all protected resources have to be informed. Regards, Lukas 2010/5/16 Dick Hardt<a class="moz-txt-link-rfc2396E" href="mailto:dick.hardt@gmail.com"><dick.hardt@gmail.com></a> James: An important capability of the refresh token is that it *can* be a self contained token in that is not an id, but a signed token that can be examined and acted upon on presentation. Torsten: enabling a client to revoke a refresh token looks like a useful mechanism. I anticipate it will be viewed as a vitamin feature rather than a painkiller and will fall by the wayside unless the security conscience rally to have it included. -- Dick On Thu, May 13, 2010 at 7:10 AM, Manger, James H<a class="moz-txt-link-rfc2396E" href="mailto:James.H.Manger@team.telstra.com"><James.H.Manger@team.telstra.com></a> wrote: Torsten, </pre> <blockquote type="cite"> <pre wrap="">What about refresh token revocation/deletion? </pre> </blockquote> <pre wrap="">HTTP already has a method to do this: DELETE It just needs each token to have a URI. Tokens (almost) already have URIs -- its just not immediately obvious because the URI has to be built from a common token endpoint and a refresh_token. I think it would improve the spec if refresh_token was renamed to, say, token_id; and its value defined as a URI (which can be a relative URI so the string may not need to change at all). To refresh a token you POST to the token's URI. To delete a token you send a DELETE request to the token's URI. It doesn't cause major changes, but there are some benefits. It is a more web-style design. It leaves only 1 type of token in the spec -- an access token -- which simplifies the text and aids understanding. There are no arguments about length, allowed chars etc because it is a URI -- a well-known type, often with native support. Its obvious how to delete the token as there is a standard HTTP method DELETE to apply to the token URI. If a particular service supported an additional way to delete items in its API (eg POST with a method=delete query parameter) that could apply to the OAuth part as well. -- James Manger _______________________________________________ OAuth mailing list <a class="moz-txt-link-abbreviated" href="mailto:OAuth@ietf.org">OAuth@ietf.org</a> <a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/oauth">https://www.ietf.org/mailman/listinfo/oauth</a> _______________________________________________ OAuth mailing list <a class="moz-txt-link-abbreviated" href="mailto:OAuth@ietf.org">OAuth@ietf.org</a> <a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/oauth">https://www.ietf.org/mailman/listinfo/oauth</a> -- <a class="moz-txt-link-freetext" href="http://lukasrosenstock.net/">http://lukasrosenstock.net/</a> </pre> </blockquote> <pre wrap="">_______________________________________________ OAuth mailing list <a class="moz-txt-link-abbreviated" href="mailto:OAuth@ietf.org">OAuth@ietf.org</a> <a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/oauth">https://www.ietf.org/mailman/listinfo/oauth</a> </pre> </blockquote> <pre wrap="">_______________________________________________ OAuth mailing list <a class="moz-txt-link-abbreviated" href="mailto:OAuth@ietf.org">OAuth@ietf.org</a> <a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/oauth">https://www.ietf.org/mailman/listinfo/oauth</a> </pre> </blockquote> <pre wrap=""> _______________________________________________ OAuth mailing list <a class="moz-txt-link-abbreviated" href="mailto:OAuth@ietf.org">OAuth@ietf.org</a> <a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/oauth">https://www.ietf.org/mailman/listinfo/oauth</a> </pre> </blockquote> <pre wrap=""> _______________________________________________ OAuth mailing list <a class="moz-txt-link-abbreviated" href="mailto:OAuth@ietf.org">OAuth@ietf.org</a> <a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/oauth">https://www.ietf.org/mailman/listinfo/oauth</a> </pre> </blockquote> <br> </body> </html> --------------000408020407020300000603-- From mscurtescu@google.com Fri Jun 11 12:16:04 2010 Return-Path: <mscurtescu@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2ED1B28C13B for <oauth@core3.amsl.com>; Fri, 11 Jun 2010 12:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.305 X-Spam-Level: X-Spam-Status: No, score=-100.305 tagged_above=-999 required=5 tests=[AWL=-0.742, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQT-kcPOdtnU for <oauth@core3.amsl.com>; Fri, 11 Jun 2010 12:16:02 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 93B3628C143 for <oauth@ietf.org>; Fri, 11 Jun 2010 12:15:54 -0700 (PDT) Received: from wpaz37.hot.corp.google.com (wpaz37.hot.corp.google.com [172.24.198.101]) by smtp-out.google.com with ESMTP id o5BJFs5M015883 for <oauth@ietf.org>; Fri, 11 Jun 2010 12:15:54 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1276283755; bh=9TSGnfXEg12onHrDORzacLcmHiM=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=riyGYxYfsQ2V3wnga6KEprMvUDJvuAnzEMNlsvQgsaxqwy4eGzB9VYXDs2I5HTYNb gSC7uRs3DqEQg+wh5lMJQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding; b=Dg/YrFF3BpUrjn7IvMxAczoTfNjiOjZSk7LkUFGGZOyefflUrO0BTbABJ2vtbdVSM F1tg80w91TeC++IAT4QYg== Received: from pwi9 (pwi9.prod.google.com [10.241.219.9]) by wpaz37.hot.corp.google.com with ESMTP id o5BJFqtC026789 for <oauth@ietf.org>; Fri, 11 Jun 2010 12:15:53 -0700 Received: by pwi9 with SMTP id 9so766289pwi.30 for <oauth@ietf.org>; Fri, 11 Jun 2010 12:15:52 -0700 (PDT) Received: by 10.141.91.19 with SMTP id t19mr1743134rvl.104.1276283752090; Fri, 11 Jun 2010 12:15:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.124.13 with HTTP; Fri, 11 Jun 2010 12:15:32 -0700 (PDT) In-Reply-To: <4C12848E.8090105@aol.com> References: <AANLkTingSGlJNZ5e_stPd1qU5I4gfbh3rQhqYUmqXvdB@mail.gmail.com> <C833CEB4.6B81%cmortimore@salesforce.com> <AANLkTinVQEPBVzmiHEGgHhzaILL0nRSvZpjIlrVEJwTw@mail.gmail.com> <AANLkTil1j7vl8PU2tgCzlWY0U6KiWPmRKiVOxvsctB00@mail.gmail.com> <AANLkTimCL-O7RIsUlt_zGDfkEEYb9w4_sPh6zxCMBsf0@mail.gmail.com> <AANLkTin7B9pPgSu3cNlJGkp_gCed-5aPGRZalzXd2Wg8@mail.gmail.com> <4C124A70.2000002@aol.com> <1276268753.31840.50.camel@localhost.localdomain> <4C1257B5.9080706@comlounge.net> <AANLkTilcpAw7hZuQK43_ybS-wy3bQnPqMfRXOdqY4iYa@mail.gmail.com> <AANLkTimGnTj1HseMsPBaRXjBThM3uktqq0R6P30jsjaZ@mail.gmail.com> <AANLkTimyvpXmlOXRKSA4Oe0s3rqoiLQgtgvbRlvniEJ6@mail.gmail.com> <4C126367.40403@aol.com> <AANLkTimKEFRu-PboKcpXFlFN7Q_675ZjICBnK9IliUzs@mail.gmail.com> <4C126D63.9090903@aol.com> <AANLkTinryo8AMgqgQoPgn0cAxuYNXhHtBS--rx5A52Zb@mail.gmail.com> <4C12848E.8090105@aol.com> From: Marius Scurtescu <mscurtescu@google.com> Date: Fri, 11 Jun 2010 12:15:32 -0700 Message-ID: <AANLkTimIkVSldwpWtKgRjZushfH9_JzzzoJ7PIsp97ET@mail.gmail.com> To: George Fletcher <gffletch@aol.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] User-agent flow and pre-registered redirect_uri X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 11 Jun 2010 19:16:04 -0000 On Fri, Jun 11, 2010 at 11:46 AM, George Fletcher <gffletch@aol.com> wrote: > On 6/11/10 2:09 PM, Marius Scurtescu wrote: >> >> On Fri, Jun 11, 2010 at 10:07 AM, George Fletcher<gffletch@aol.com> >> =A0wrote: >> >>> >>> On 6/11/10 12:34 PM, Marius Scurtescu wrote: >>> >>>> >>>> On Fri, Jun 11, 2010 at 9:25 AM, George Fletcher<gffletch@aol.com> >>>> =A0wrote: >>>> >>>> >>>>> >>>>> On 6/11/10 12:07 PM, Marius Scurtescu wrote: >>>>> >>>>> >>>>>> >>>>>> On Fri, Jun 11, 2010 at 8:59 AM, David Recordon<recordond@gmail.com> >>>>>> =A0wrote: >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> That sounds like a security consideration to me! :) >>>>>>> >>>>>>> I imagine that authorization servers will verify ownership in >>>>>>> different manners depending on their tolerance of risk. >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> Instead of POSTing a JSON with all the details, dynamic binding coul= d >>>>>> send only a host name. The authz server would then do discovery on >>>>>> this host and get a pointer to this JSON from host-meta. >>>>>> >>>>>> Marius >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> I think most all of this could be described in the host-meta XRD >>>>> directly >>>>> to >>>>> save yet another round trip. And I believe there are some security >>>>> advantages to using this approach, but it does require the "client" t= o >>>>> be >>>>> a >>>>> web-server. This might not always be the case (rich desktop app). For >>>>> native/desktop apps, it seems that posting some set of parameters >>>>> (equivalent security-wise to a browser user-agent) makes sense and >>>>> keeps >>>>> the >>>>> protocol simple. >>>>> >>>>> >>>> >>>> Yes, but in this case (desktop app) the "url" and "icon" parameters >>>> don't work and what is left is "name" and "description". I think that >>>> the suggested "client_name" parameter does exactly the same thing, >>>> much simpler. Is there any value in this case in a client_secret? >>>> >>>> Marius >>>> >>>> >>> >>> Well... given this is a POST and structured data... it would be possibl= e >>> for >>> the desktop app to post the raw icon data (though I suppose it could al= so >>> POST a URL to the web server of the company the produces the app). In >>> which >>> case your previous suggestion would work (parameters discovered via the >>> URL). >>> >>> I do believe the client_secret is valuable in this case because the AS = is >>> returning both the client_id and the client_secret. This then becomes a >>> way >>> for provisioning a unique client_id and client_secret to every instance >>> of >>> the app. A lot more for the AS to keep track of, but also makes it more >>> difficult for an attacker to compromise a client. The attacker could >>> impersonate the POST'd client description data (just like user-agent >>> strings >>> can be impersonated), but then the attacker just has a client_id and >>> client_secret for it's instance. >>> >>> This should force the attacker to get explicit user consent from the us= er >>> to >>> authorize that unique client_id. I wouldn't recommend for the AS to tra= ck >>> authorization against the POST'd client description but rather the >>> client_id. >>> >> >> An attacker can also dynamically register a very similar client >> name/description and trick the user. >> > > True... but the user will see another consent form. This might be a minor > hurdle but at least it's not totally seamless. I think that is an advanta= ge. Why would the user see another consent form? Were you thinking auto-approvals? For desktop apps auto-approvals don't make much sense and authz servers should probably never do that. >> The authz server is issuing a unique refresh token for each client, >> and I still don't see how an extra client_secret helps in this case. >> > > Good point. With SSL and bearer tokens the client_secret doesn't do much > good. Now if we signed the requests with the unique client_secret from th= e > desktop app... :) Yes, but let's see how the signature specs work out. >> For a web client the client secret helps if the refresh token is >> compromised. The web client most likely will store many refresh >> tokens, one for each user, in the database, with SQL injection all of >> these can be compromised, but the client secret (if it was not in the >> same database) makes them useless. This could be a reason why dynamic >> registration for web clients is a bad idea, the client secret will end >> up in the database, instead of a config file. >> > > The web site could store client_secrets in a different database that is n= ot > exposed to the same SQL Injection attacks. Where the data is stored doesn= 't > seem like it affects it's ability to be compromised or protected. If the = web > server is not well protected, getting the config file with the client_sec= ret > might be easier than getting data out of the database. I think the securi= ty > of where the web app stores the data is orthogonal to the security of the > protocol. Maybe, not sure. If web clients are encouraged to put the secret in the database then it will end up next to the refresh token, for sure. > I suppose this also depends on which flow the desktop app is following. I= f > using the web-user flow (by launching the default browser, then the > client_secret (v2-06) is required. If following the device flow... then i= t's > not (though it seems this flow is still being defined). client_secret is required only if one was issued, "REQUIRED if the client identifier has a matching secret." So the Web Server flow should work just fine for unregistered or unsecure (registered but no secret was issued) clients. > So maybe the solution is that if the authorization server doesn't think t= he > client_secret is useful, it doesn't return it. Or it always returns it an= d > the client can throw it away as it knows it won't use it. However, it see= ms > like the rest of the registration flow still holds. Without client_secret I still don't see the point. Registration then boils down to self asserted name, which can also be achieved with the client_name paramter, no? Marius From torsten@lodderstedt.net Fri Jun 11 12:35:07 2010 Return-Path: <torsten@lodderstedt.net> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0CF63A67DA for <oauth@core3.amsl.com>; Fri, 11 Jun 2010 12:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.732 X-Spam-Level: X-Spam-Status: No, score=-0.732 tagged_above=-999 required=5 tests=[AWL=0.316, BAYES_50=0.001, GB_I_LETTER=-2, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ANyZ+cBFnVNM for <oauth@core3.amsl.com>; Fri, 11 Jun 2010 12:35:04 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.35]) by core3.amsl.com (Postfix) with ESMTP id 8928F3A68CC for <oauth@ietf.org>; Fri, 11 Jun 2010 12:35:03 -0700 (PDT) Received: from p4fff06ec.dip.t-dialin.net ([79.255.6.236] helo=[127.0.0.1]) by smtprelay01.ispgateway.de with esmtpa (Exim 4.68) (envelope-from <torsten@lodderstedt.net>) id 1ONA0O-0000KB-AS; Fri, 11 Jun 2010 21:35:04 +0200 Message-ID: <4C128FE6.3020801@lodderstedt.net> Date: Fri, 11 Jun 2010 21:35:02 +0200 From: Torsten Lodderstedt <torsten@lodderstedt.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Christian Holm <cho@cubitech.dk> References: <AANLkTikSRWuuIwPxqbCZqis1e6gQ_Q6Yg5j7gDAVB606@mail.gmail.com> In-Reply-To: <AANLkTikSRWuuIwPxqbCZqis1e6gQ_Q6Yg5j7gDAVB606@mail.gmail.com> Content-Type: multipart/alternative; boundary="------------020903010306040603040802" X-Df-Sender: 141509 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Recommended token format X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 11 Jun 2010 19:35:07 -0000 This is a multi-part message in MIME format. --------------020903010306040603040802 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Christian, in my opinion, the token should be digitally signed in order to detect modifications. HMAC-SHA256 or RSA are good candidates for that. If you really need encryption depends on your privacy and security requirements. Typical token contents are: issuer, validity/expiration, audience (could be scope), user id, user attributes, digital signature. If revocation is a topic, a token id could also be required. You may take a look at standards like SAML2 or Kerberos to get inspiration. For simple use cases, simple web tokens (http://groups.google.com/group/oauth-wrap-wg/files) could also be an option. Note: I don't think a public format is less secure than a private one if the security is based on cryptography instead of obscurity :-) regards, Torsten Am 09.06.2010 22:58, schrieb Christian Holm: > Hi > We are in the process of defining a REST interface for our > application, and are looking to use OAuth 2 as the authentication > mechanism. I have read through the latest specification, and it seems > like a perfect fit for our needs. Our main dilemma is with regard to > the format of the access token. As I understand there are basicly two > options: > * Use the token as an "artifact", ie. just a randomly generated string > which is stored centrally. When accessing a resource with the token, > the token is verified by looking it up in the central repository and > making sure the requested resource can be accessed. > * Encrypt the authentication into the token. This way the resource > server can verify the access directly from the token without checking > with the central repository. This is particularly a good idea if the > authentication servers and resource servers are hosted in different > data centers. > We would like to go with the second option, but since my cryptology > knowledge is less than could be wished, I have a had time deciding on > the format. I would assume we would have to put the user, the expiry > time and the scopes into the token (perhaps with some random letters > in between) and then encrypt that using f.ex. AES. Are there any > recommendations on the format and encryption method to use? I realize > that publicly disclosing the format could weaken it slightly, so the > recommendations will have to be fairly generic. > Thanks for the help and the excellent work on the OAuth 2.0. > Christian Holm > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --------------020903010306040603040802 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> Hi Christian,<br> <br> in my opinion, the token should be digitally signed in order to detect modifications. HMAC-SHA256 or RSA are good candidates for that. If you really need encryption depends on your privacy and security requirements.<br> <br> Typical token contents are: issuer, validity/expiration, audience (could be scope), user id, user attributes, digital signature. If revocation is a topic, a token id could also be required. You may take a look at standards like SAML2 or Kerberos to get inspiration. For simple use cases, simple web tokens (<a class="moz-txt-link-freetext" href="http://groups.google.com/group/oauth-wrap-wg/files">http://groups.google.com/group/oauth-wrap-wg/files</a>) could also be an option. <br> <br> Note: I don't think a public format is less secure than a private one if the security is based on cryptography instead of obscurity :-) <br> <br> regards,<br> Torsten<br> <br> Am 09.06.2010 22:58, schrieb Christian Holm: <blockquote cite="mid:AANLkTikSRWuuIwPxqbCZqis1e6gQ_Q6Yg5j7gDAVB606@mail.gmail.com" type="cite"> <div>Hi</div> <div> </div> <div>We are in the process of defining a REST interface for our application, and are looking to use OAuth 2 as the authentication mechanism. I have read through the latest specification, and it seems like a perfect fit for our needs. Our main dilemma is with regard to the format of the access token. As I understand there are basicly two options:</div> <div> </div> <div>* Use the token as an "artifact", ie. just a randomly generated string which is stored centrally. When accessing a resource with the token, the token is verified by looking it up in the central repository and making sure the requested resource can be accessed.</div> <div>* Encrypt the authentication into the token. This way the resource server can verify the access directly from the token without checking with the central repository. This is particularly a good idea if the authentication servers and resource servers are hosted in different data centers.</div> <div> </div> <div>We would like to go with the second option, but since my cryptology knowledge is less than could be wished, I have a had time deciding on the format. I would assume we would have to put the user, the expiry time and the scopes into the token (perhaps with some random letters in between) and then encrypt that using f.ex. AES. Are there any recommendations on the format and encryption method to use? I realize that publicly disclosing the format could weaken it slightly, so the recommendations will have to be fairly generic.</div> <div> </div> <div>Thanks for the help and the excellent work on the OAuth 2.0.</div> <div> </div> <div>Christian Holm</div> <pre wrap=""> <fieldset class="mimeAttachmentHeader"></fieldset> _______________________________________________ OAuth mailing list <a class="moz-txt-link-abbreviated" href="mailto:OAuth@ietf.org">OAuth@ietf.org</a> <a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/oauth">https://www.ietf.org/mailman/listinfo/oauth</a> </pre> </blockquote> </body> </html> --------------020903010306040603040802-- From torsten@lodderstedt.net Fri Jun 11 12:42:09 2010 Return-Path: <torsten@lodderstedt.net> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AA0628C107 for <oauth@core3.amsl.com>; Fri, 11 Jun 2010 12:42:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.24 X-Spam-Level: X-Spam-Status: No, score=0.24 tagged_above=-999 required=5 tests=[AWL=-0.712, BAYES_50=0.001, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mCx3rmvf0XUF for <oauth@core3.amsl.com>; Fri, 11 Jun 2010 12:42:06 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.29]) by core3.amsl.com (Postfix) with ESMTP id 3AB1728C11C for <oauth@ietf.org>; Fri, 11 Jun 2010 12:42:06 -0700 (PDT) Received: from p4fff06ec.dip.t-dialin.net ([79.255.6.236] helo=[127.0.0.1]) by smtprelay02.ispgateway.de with esmtpa (Exim 4.68) (envelope-from <torsten@lodderstedt.net>) id 1ONA7D-0002Mq-EA; Fri, 11 Jun 2010 21:42:07 +0200 Message-ID: <4C12918E.3000503@lodderstedt.net> Date: Fri, 11 Jun 2010 21:42:06 +0200 From: Torsten Lodderstedt <torsten@lodderstedt.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Kevin Smith <mrkrcsmith@googlemail.com> References: <042e8761-8bb6-44b5-8b6f-5507bf254abf@e35g2000yqm.googlegroups.com> <k2ifd6741651005052213ye98c90f3wde4afededb8542a8@mail.gmail.com> <AANLkTimD4N9zG4xZGMq_SETXOI5rd2XFZhJc_KAaQPfa@mail.gmail.com> In-Reply-To: <AANLkTimD4N9zG4xZGMq_SETXOI5rd2XFZhJc_KAaQPfa@mail.gmail.com> Content-Type: multipart/alternative; boundary="------------050108020709020508000800" X-Df-Sender: 141509 Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] [WRAP] WRAP in GSMA OneAPI X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 11 Jun 2010 19:42:09 -0000 This is a multi-part message in MIME format. --------------050108020709020508000800 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Kevin, what problems do you have with pre-paid users? Is your network unable to authenticate them (by IMSI or MSISDN)? regards, Torsten. Am 08.06.2010 18:31, schrieb Kevin Smith: > Hi David, Blaine, > > We (the OneAPI group) have been looking further into OAUTH 2.0 and > would like to see how it can work in a mobile network scenario: for > example, a desktop Web application wants to locate a mobile user to > plot their location on a map. So the client is the Web application and > the server is an HTTP platform sitting on top of the mobile core network. > > It seems that the Web application could register a client ID and > client secret with the OneAPI-implementing server. When location is > requested by this client, the server would prompt the user, and if > permission were received, would enable the client to access the > location via an access token/secret. > > One difference to the regular OAUTH flow is that 'post-pay' contract > network subscribers would not have to enter a username/password to > identify themselves since they would be implicitly identified on the > network anyway; they would just need to confirm authorisation > ('Allow/Block'). We are not sure how to handle pre-pay users that buy > phone credits in advance. > > In case either of you (or any other OAUTH expert) would be available > to lead a discussion on the technology, and to answer questions from > mobile operators and platform vendors, we are having a meeting next > Tuesday in London. The meeting is also accessible over Webex. Please > let me know if you would be willing to do so, as I'm sure it will help > kick-start our implementation work. > > Cheers! > Kevin > > On Thu, May 6, 2010 at 6:13 AM, David Recordon <recordond@gmail.com > <mailto:recordond@gmail.com>> wrote: > > +OAuth IETF list > -WRAP list to BCC > > Hi Kevin, > OAuth 2.0 should be pretty simple for you to implement and any > feedback your team has would be really appreciated! There are > already implementations in Cocoa, Python, and Ruby list on the > wiki at http://wiki.oauth.net/OAuth-2.0 and you find find the spec > at http://tools.ietf.org/html/draft-hammer-oauth2-00. > > You may also be interested in the mobile web implementation we've > built at Facebook. http://developers.facebook.com/docs/guides/mobile/ > > I'm also cc'ing Blaine Cook who lives in Ireland and might be able > to present. > > Cheers, > --David > > > On Tue, May 4, 2010 at 4:20 AM, Kevin Smith, Vodafone > <mrkrcsmith@googlemail.com <mailto:mrkrcsmith@googlemail.com>> wrote: > > Dear OAUTH WRAP group, > > My name is Kevin Smith of Vodafone R&D, and I lead a cross-mobile > operator project called OneAPI ('Open Network Enablers') [1]. > The aim > is to provide a RESTful API to expose network functions such as > location, messaging, payments and more to developers; with the > reckoning that this will make it far easier to mash-up Web > applications with network capabilities and reduce the time to > reach > all mobile subscribers in a territory. Thus far we have a live > pilot > implementation across the 3 major Canadian operators [2] and a > non- > commercial test site connected to > 12 European operators [3], and will be releasing v1.0 > specifications > backed by the OMA this month. > > For the first release we did not attempt to prescribe an AAA > model to > operators, instead leaving them to reuse their own SDP AAA > implementation for OneAPI. For our second phase now underway > we would > like to provide a recommended reference implementation AAA > model for > operators who are unsure how to allow secure API access whilst > allowing user consent and privacy to be respected. Therefore > we have > discussed OAUTH as an ideal candidate that will be well-known > to Web > developers. > > My question regards the suitability of WRAP for such a reference > implementation: the decoupling of authentication is good sense and > would be welcome by operators, however it appears that WRAP is > deprecated and is intended to be replaced by OAUTH 2.0 - is that > right? Please could you provide any details on the plans for > if/how > the two will interoperate? If it's at all possible, we would > very much > welcome a member of the group to present on WRAP at one of our > face-to- > face meetings in London - if that is of interest please let me > know > and I can make arrangements. > > Thanks for your time and look forward to your advice. > > Kind regards, > Kevin > > [1] http://www.gsmworld.com/oneapi > [2] http://canada.oneapi.gsmworld.com/ > [3] http://oneapi.aepona.com/ > > Kevin Smith > Senior Technology Strategist, R&D > Vodafone Technology > > E-mail: kevin.smith@vodafone.com <mailto:kevin.smith@vodafone.com> > > -- > You received this message because you are subscribed to the > Google Groups "OAuth WRAP WG" group. > To post to this group, send email to > oauth-wrap-wg@googlegroups.com > <mailto:oauth-wrap-wg@googlegroups.com>. > To unsubscribe from this group, send email to > oauth-wrap-wg+unsubscribe@googlegroups.com > <mailto:oauth-wrap-wg%2Bunsubscribe@googlegroups.com>. > For more options, visit this group at > http://groups.google.com/group/oauth-wrap-wg?hl=en. > > > -- > You received this message because you are subscribed to the Google > Groups "OAuth WRAP WG" group. > To post to this group, send email to > oauth-wrap-wg@googlegroups.com > <mailto:oauth-wrap-wg@googlegroups.com>. > To unsubscribe from this group, send email to > oauth-wrap-wg+unsubscribe@googlegroups.com > <mailto:oauth-wrap-wg%2Bunsubscribe@googlegroups.com>. > For more options, visit this group at > http://groups.google.com/group/oauth-wrap-wg?hl=en. > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --------------050108020709020508000800 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> Hi Kevin,<br> <br> what problems do you have with pre-paid users? Is your network unable to authenticate them (by IMSI or MSISDN)?<br> <br> regards,<br> Torsten.<br> <br> Am 08.06.2010 18:31, schrieb Kevin Smith: <blockquote cite="mid:AANLkTimD4N9zG4xZGMq_SETXOI5rd2XFZhJc_KAaQPfa@mail.gmail.com" type="cite">Hi David, Blaine,<br> <br> We (the OneAPI group) have been looking further into OAUTH 2.0 and would like to see how it can work in a mobile network scenario: for example, a desktop Web application wants to locate a mobile user to plot their location on a map. So the client is the Web application and the server is an HTTP platform sitting on top of the mobile core network.<br> <br>  It seems that the Web application could register a client ID and client secret with the OneAPI-implementing server. When location is requested by this client, the server would prompt the user, and if permission were received, would enable the client to access the location via an access token/secret.<br> <br> One difference to the regular OAUTH flow is that  'post-pay' contract network subscribers would not have to enter a username/password to identify themselves since they would be implicitly identified on the network anyway; they would just need to confirm authorisation ('Allow/Block'). We are not sure how to handle pre-pay users that buy phone credits in advance.<br> <br> In case either of you (or any other OAUTH expert) would be available to lead a discussion on the technology, and to answer questions from mobile operators and platform vendors, we are having a meeting next Tuesday in London. The meeting is also accessible over Webex. Please let me know if you would be willing to do so, as I'm sure it will help kick-start our implementation work.<br> <br> Cheers!<br> Kevin<br> <br> <div class="gmail_quote">On Thu, May 6, 2010 at 6:13 AM, David Recordon <span dir="ltr"><<a moz-do-not-send="true" href="mailto:recordond@gmail.com">recordond@gmail.com</a>></span> wrote:<br> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div>+OAuth IETF list</div> <div>-WRAP list to BCC</div> <div><br> </div> Hi Kevin, <div>OAuth 2.0 should be pretty simple for you to implement and any feedback your team has would be really appreciated! There are already implementations in Cocoa, Python, and Ruby list on the wiki at <a moz-do-not-send="true" href="http://wiki.oauth.net/OAuth-2.0" target="_blank">http://wiki.oauth.net/OAuth-2.0</a> and you find find the spec at <a moz-do-not-send="true" href="http://tools.ietf.org/html/draft-hammer-oauth2-00" target="_blank">http://tools.ietf.org/html/draft-hammer-oauth2-00</a>.</div> <div><br> </div> <div>You may also be interested in the mobile web implementation we've built at Facebook. <a moz-do-not-send="true" href="http://developers.facebook.com/docs/guides/mobile/" target="_blank">http://developers.facebook.com/docs/guides/mobile/</a></div> <div><br> </div> <div>I'm also cc'ing Blaine Cook who lives in Ireland and might be able to present.</div> <div><br> </div> <div>Cheers,</div> <div>--David</div> <div> <div class="h5"> <div><br> <br> <div class="gmail_quote">On Tue, May 4, 2010 at 4:20 AM, Kevin Smith, Vodafone <span dir="ltr"><<a moz-do-not-send="true" href="mailto:mrkrcsmith@googlemail.com" target="_blank">mrkrcsmith@googlemail.com</a>></span> wrote:<br> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Dear OAUTH WRAP group,<br> <br> My name is Kevin Smith of Vodafone R&D, and I lead a cross-mobile<br> operator project called OneAPI ('Open Network Enablers') [1]. The aim<br> is to provide a RESTful API to expose network functions such as<br> location, messaging, payments and more to developers; with the<br> reckoning that this will make it far easier to mash-up Web<br> applications with network capabilities and reduce the time to reach<br> all mobile subscribers in a territory. Thus far we have a live pilot<br> implementation across the 3 major Canadian operators [2] and a non-<br> commercial test site connected to<br> 12 European operators [3], and will be releasing v1.0 specifications<br> backed by the OMA this month.<br> <br> For the first release we did not attempt to prescribe an AAA model to<br> operators, instead leaving them to reuse their own SDP AAA<br> implementation for OneAPI. For our second phase now underway we would<br> like to provide a recommended reference implementation AAA model for<br> operators who are unsure how to allow secure API access whilst<br> allowing user consent and privacy to be respected. Therefore we have<br> discussed OAUTH as an ideal candidate that will be well-known to Web<br> developers.<br> <br> My question regards the suitability of WRAP for such a reference<br> implementation: the decoupling of authentication is good sense and<br> would be welcome by operators, however it appears that WRAP is<br> deprecated and is intended to be replaced by OAUTH 2.0 - is that<br> right?  Please could you provide any details on the plans for if/how<br> the two will interoperate? If it's at all possible, we would very much<br> welcome a member of the group to present on WRAP at one of our face-to-<br> face meetings in London - if that is of interest please let me know<br> and I can make arrangements.<br> <br> Thanks for your time and look forward to your advice.<br> <br> Kind regards,<br> Kevin<br> <br> [1] <a moz-do-not-send="true" href="http://www.gsmworld.com/oneapi" target="_blank">http://www.gsmworld.com/oneapi</a><br> [2] <a moz-do-not-send="true" href="http://canada.oneapi.gsmworld.com/" target="_blank">http://canada.oneapi.gsmworld.com/</a><br> [3] <a moz-do-not-send="true" href="http://oneapi.aepona.com/" target="_blank">http://oneapi.aepona.com/</a><br> <br> Kevin Smith<br> Senior Technology Strategist, R&D<br> Vodafone Technology<br> <br> E-mail: <a moz-do-not-send="true" href="mailto:kevin.smith@vodafone.com" target="_blank">kevin.smith@vodafone.com</a><br> <font color="#888888"><br> --<br> You received this message because you are subscribed to the Google Groups "OAuth WRAP WG" group.<br> To post to this group, send email to <a moz-do-not-send="true" href="mailto:oauth-wrap-wg@googlegroups.com" target="_blank">oauth-wrap-wg@googlegroups.com</a>.<br> To unsubscribe from this group, send email to <a moz-do-not-send="true" href="mailto:oauth-wrap-wg%2Bunsubscribe@googlegroups.com" target="_blank">oauth-wrap-wg+unsubscribe@googlegroups.com</a>.<br> For more options, visit this group at <a moz-do-not-send="true" href="http://groups.google.com/group/oauth-wrap-wg?hl=en" target="_blank">http://groups.google.com/group/oauth-wrap-wg?hl=en</a>.<br> <br> </font></blockquote> </div> <br> </div> -- <br> You received this message because you are subscribed to the Google Groups "OAuth WRAP WG" group.<br> To post to this group, send email to <a moz-do-not-send="true" href="mailto:oauth-wrap-wg@googlegroups.com" target="_blank">oauth-wrap-wg@googlegroups.com</a>.<br> To unsubscribe from this group, send email to <a moz-do-not-send="true" href="mailto:oauth-wrap-wg%2Bunsubscribe@googlegroups.com" target="_blank">oauth-wrap-wg+unsubscribe@googlegroups.com</a>.<br> For more options, visit this group at <a moz-do-not-send="true" href="http://groups.google.com/group/oauth-wrap-wg?hl=en" target="_blank">http://groups.google.com/group/oauth-wrap-wg?hl=en</a>.<br> </div> </div> </blockquote> </div> <br> <pre wrap=""> <fieldset class="mimeAttachmentHeader"></fieldset> _______________________________________________ OAuth mailing list <a class="moz-txt-link-abbreviated" href="mailto:OAuth@ietf.org">OAuth@ietf.org</a> <a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/oauth">https://www.ietf.org/mailman/listinfo/oauth</a> </pre> </blockquote> </body> </html> --------------050108020709020508000800-- From torsten@lodderstedt.net Fri Jun 11 12:50:32 2010 Return-Path: <torsten@lodderstedt.net> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C443A3A6A3A for <oauth@core3.amsl.com>; Fri, 11 Jun 2010 12:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[AWL=0.947, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kWQiYMO6iNI4 for <oauth@core3.amsl.com>; Fri, 11 Jun 2010 12:50:31 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.28]) by core3.amsl.com (Postfix) with ESMTP id CCD573A67DA for <oauth@ietf.org>; Fri, 11 Jun 2010 12:50:30 -0700 (PDT) Received: from p4fff06ec.dip.t-dialin.net ([79.255.6.236] helo=[127.0.0.1]) by smtprelay01.ispgateway.de with esmtpa (Exim 4.68) (envelope-from <torsten@lodderstedt.net>) id 1ONAFM-0008Ll-Bz; Fri, 11 Jun 2010 21:50:32 +0200 Message-ID: <4C129387.1090703@lodderstedt.net> Date: Fri, 11 Jun 2010 21:50:31 +0200 From: Torsten Lodderstedt <torsten@lodderstedt.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Eran Hammer-Lahav <eran@hueniverse.com> References: <4BFAA6AB.8040809@lodderstedt.net> <4BFC3142.6010506@lodderstedt.net> <AANLkTilRireowt1v8SidOiMJ-7ilBfvSqAiNfecA7uwR@mail.gmail.com> <4BFC371A.5040109@lodderstedt.net> <AANLkTikF1wk5eqme-N4RHviB5M7HzGYzy0p1mGuaux5g@mail.gmail.com> <4C07F407.4050305@lodderstedt.net> <1275663845.7068.94.camel@localhost.localdomain> <4C09732B.5040800@lodderstedt.net> <4C0F6A9C.2060607@lodderstedt.net> <4C1108C4.9040501@lodderstedt.net> <AANLkTils4bwYtv5u9yXJycqTQ_NFt0BUtA7P0kBTITpX@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3EAF7473@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF7473@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] proposal: multiple access tokens from a single authorization flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 11 Jun 2010 19:50:32 -0000 Hi, thanks for your advice. I described the new parameter in my proposal. What additional text/information would you expect in an I-D? regards, Torsten. Am 11.06.2010 01:02, schrieb Eran Hammer-Lahav: > I strongly believe that it should be first presented as an I-D. This is true in general for most proposed changes of this size. It is hard to tell how big of an impact a change like this will have without some actual text. Once proposed, the WG can decide if this is of interest as a WG item. If it is, we discuss the technical details. Then, we can have a chat about editorial work and how to best fit it within the OAuth specifications framework. > > Hope this helps. > > EHL > > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of David Recordon >> Sent: Thursday, June 10, 2010 8:54 AM >> To: Torsten Lodderstedt >> Cc: OAuth WG (oauth@ietf.org) >> Subject: Re: [OAUTH-WG] proposal: multiple access tokens from a single >> authorization flow >> >> I strongly believe that it should be an extension. Even optional response >> parameters increase the complexity for client developers and this in >> particular affects the data model used to store access tokens. >> >> --David >> >> >> On Thu, Jun 10, 2010 at 8:46 AM, Torsten Lodderstedt >> <torsten@lodderstedt.net> wrote: >> >>> no one in the WG having an opinion on this topic? >>> >>> Am 09.06.2010 12:19, schrieb Torsten Lodderstedt: >>> >>>> Hi all, >>>> >>>> I would like to see support in OAuth2 for the authorization of >>>> arbitrary scopes in a single authorization flow for all kinds of >>>> deployments. In some deployments this may require to issue multiple >>>> >> access tokens at once. >> >>>> Therefore, I would like to propose the following addition to section >>>> 2.3.2.1. (Access Token Response): >>>> >>>> Add an optional parameter "additional_access_tokens". >>>> >>>> additional_access_tokens >>>> OPTIONAL. Array of access tokens issued by the authorization >>>> server along with respective expiration and scope. >>>> Used >>>> if the authorization server decides to issue more >>>> than >>>> one access token. The scopes of the different >>>> tokens may >>>> not overlap. >>>> >>>> Example: >>>> HTTP/1.1 200 OK >>>> Content-Type: application/json >>>> Cache-Control: no-store >>>> >>>> { >>>> "access_token":"SlAV32hkKG", >>>> "expires_in":3600, >>>> "refresh_token":"8xLOxBtZp8", >>>> scope:"https://imap.example.com", >>>> additional_access_tokens:[ >>>> { >>>> "access_token":"SlAV32hkKG2", >>>> "expires_in":3600, >>>> scope:"https://sip.example.com" >>>> }, >>>> { >>>> "access_token":"SlAV32hkKG3", >>>> "expires_in":3600, >>>> scope:"https://contacts.example.com/read" >>>> }, >>>> { >>>> "access_token":"SlAV32hkKG4", >>>> "expires_in":3600, >>>> scope:"https://webdav.example.com/read" >>>> } >>>> ] >>>> } >>>> >>>> --- Some motivation --- >>>> >>>> I think we will see more and more clients integrating different >>>> end-user services (like mashups). Based on the current draft, some >>>> OAuth authorization servers may not be able to support such clients >>>> with an acceptable user experiences. >>>> >>>> Suppose a communication client integrating the following services: >>>> - e-Mail via IMAP >>>> - Voice over IP using the SIP protocol >>>> - Contacts via SyncML over HTTP >>>> - Webstorage access (e.g. for e-Mail attachments) using HTTP/WebDAV >>>> >>>> For a particular end-user, the client may discover that all of the >>>> end-user's services rely on the same OAuth2-based authorization >>>> server because they are provided by the same organization (e.g. an isp or >>>> >> a telco). >> >>>> The services are distinguished at the authorization server by >>>> different scopes (probably including permissions as well), e.g. : >>>> >>>> imap - https://imap.example.com >>>> sip - https://sip.example.com >>>> contacts - https://contacts.example.com/read webstorage - >>>> https://contacts.example.com/read >>>> >>>> Some providers may want to issue different service-specific tokens in >>>> such a setup (Deutsche Telekom does it already), for the following >>>> >> reasons: >> >>>> 1) Security >>>> >>>> a) minimize impact of token abuse - tokens may leak in many ways, e.g. >>>> through log files, proxies or HTTP referer. If a provider just uses a >>>> single token for all services, the impact of token leakage is much >>>> higher. For example, if a token gets exposed by the _contacts_ >>>> service via HTTP referer, an adversary may place long-distance calls >>>> using that token on the _VoIP_ service at the expense of the >>>> end-user. This threat holds for all kinds of tokens (handles and self- >>>> >> contained tokens). >> >>>> b) use a shared secret between authz server and a single service >>>> only - a major critism from the operational security perspective to >>>> OAuth 1.0a was the need to spread client secrets to resource servers. >>>> Using the same shared secret to sign/encrypt tokens for different >>>> services is a comparable problem. This aspect is relevant for self- >>>> >> contained tokens, only. >> >>>> 2) Privacy - the provider wants to restrict access of services to >>>> personal data to the data a particular service is allowed and >>>> authorized to see. This is good style (IMHO), it might also be >>>> required by law (e.g. German Federal Data Protection Act). This >>>> aspect is relevant for self-contained tokens, only. >>>> >>>> 3) Bandwith efficiency - putting only the data required by the >>>> services into the token saves bandwith. This aspect is relevant for >>>> self-contained tokens, only. >>>> >>>> In my opinion, most of these aspects are just a consequence of the >>>> decoupling of authorization server and resource server(s) in OAuth2. >>>> If a single authorization server is responsible for several resource >>>> servers, it has to ensure privacy protection and prevention of token >>>> abuse for all of its services. This should also include some >>>> separation between services, no matter if one uses self-contained tokens >>>> >> or handles. >> >>>> Without the change I proposed, the authorization server in the >>>> example scenario would need to force the client to perform _four_ >>>> subsequent authorization flows in order to obtain all required >>>> tokens. Moreover, the client would need to manage four refresh tokens. >>>> >>>> I would kindly ask you to support my proposal. In my opinion, it >>>> significantly improves the applicability of OAuth2 while the change >>>> to the current draft is minimal. Moreover, deployments w/o the need >>>> to issue multiple tokens are not affected at all. >>>> >>>> Any thoughts? >>>> >>>> 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 >>> >>> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> From gffletch@aol.com Fri Jun 11 13:02:13 2010 Return-Path: <gffletch@aol.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8F1F28C0F8 for <oauth@core3.amsl.com>; Fri, 11 Jun 2010 13:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ejPNTgigPAdx for <oauth@core3.amsl.com>; Fri, 11 Jun 2010 13:02:12 -0700 (PDT) Received: from imr-mb02.mx.aol.com (imr-mb02.mx.aol.com [64.12.207.163]) by core3.amsl.com (Postfix) with ESMTP id 239963A699D for <oauth@ietf.org>; Fri, 11 Jun 2010 13:02:09 -0700 (PDT) Received: from mtaout-ma02.r1000.mx.aol.com (mtaout-ma02.r1000.mx.aol.com [172.29.41.2]) by imr-mb02.mx.aol.com (8.14.1/8.14.1) with ESMTP id o5BK21es020994 for <oauth@ietf.org>; Fri, 11 Jun 2010 16:02:01 -0400 Received: from palantir.local (unknown [10.172.1.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-ma02.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id CF152E00009C for <oauth@ietf.org>; Fri, 11 Jun 2010 16:01:59 -0400 (EDT) Message-ID: <4C129636.8060004@aol.com> Date: Fri, 11 Jun 2010 16:01:58 -0400 From: George Fletcher <gffletch@aol.com> Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: oauth@ietf.org References: <AANLkTingSGlJNZ5e_stPd1qU5I4gfbh3rQhqYUmqXvdB@mail.gmail.com> <C833CEB4.6B81%cmortimore@salesforce.com> <AANLkTinVQEPBVzmiHEGgHhzaILL0nRSvZpjIlrVEJwTw@mail.gmail.com> <AANLkTil1j7vl8PU2tgCzlWY0U6KiWPmRKiVOxvsctB00@mail.gmail.com> <AANLkTimCL-O7RIsUlt_zGDfkEEYb9w4_sPh6zxCMBsf0@mail.gmail.com> <AANLkTin7B9pPgSu3cNlJGkp_gCed-5aPGRZalzXd2Wg8@mail.gmail.com> <4C124A70.2000002@aol.com> <1276268753.31840.50.camel@localhost.localdomain> <4C1257B5.9080706@comlounge.net> <AANLkTilcpAw7hZuQK43_ybS-wy3bQnPqMfRXOdqY4iYa@mail.gmail.com> <AANLkTimGnTj1HseMsPBaRXjBThM3uktqq0R6P30jsjaZ@mail.gmail.com> <AANLkTimyvpXmlOXRKSA4Oe0s3rqoiLQgtgvbRlvniEJ6@mail.gmail.com> <4C126367.40403@aol.com> <AANLkTimKEFRu-PboKcpXFlFN7Q_675ZjICBnK9IliUzs@mail.gmail.com> <4C126D63.9090903@aol.com> <AANLkTinryo8AMgqgQoPgn0cAxuYNXhHtBS--rx5A52Zb@mail.gmail.com> <4C12848E.8090105@aol.com> <AANLkTimIkVSldwpWtKgRjZushfH9_JzzzoJ7PIsp97ET@mail.gmail.com> In-Reply-To: <AANLkTimIkVSldwpWtKgRjZushfH9_JzzzoJ7PIsp97ET@mail.gmail.com> Content-Type: multipart/alternative; boundary="------------030901080908030500010500" x-aol-global-disposition: G X-AOL-SCOLL-SCORE: 0:2:406275808:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d29024c1296372a1b X-AOL-IP: 10.172.1.149 Subject: Re: [OAUTH-WG] User-agent flow and pre-registered redirect_uri X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 11 Jun 2010 20:02:14 -0000 This is a multi-part message in MIME format. --------------030901080908030500010500 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 6/11/10 3:15 PM, Marius Scurtescu wrote: > On Fri, Jun 11, 2010 at 11:46 AM, George Fletcher<gffletch@aol.com> wrote: > >> On 6/11/10 2:09 PM, Marius Scurtescu wrote: >> >>> On Fri, Jun 11, 2010 at 10:07 AM, George Fletcher<gffletch@aol.com> >>> wrote: >>> >>> >>>> Well... given this is a POST and structured data... it would be possible >>>> for >>>> the desktop app to post the raw icon data (though I suppose it could also >>>> POST a URL to the web server of the company the produces the app). In >>>> which >>>> case your previous suggestion would work (parameters discovered via the >>>> URL). >>>> >>>> I do believe the client_secret is valuable in this case because the AS is >>>> returning both the client_id and the client_secret. This then becomes a >>>> way >>>> for provisioning a unique client_id and client_secret to every instance >>>> of >>>> the app. A lot more for the AS to keep track of, but also makes it more >>>> difficult for an attacker to compromise a client. The attacker could >>>> impersonate the POST'd client description data (just like user-agent >>>> strings >>>> can be impersonated), but then the attacker just has a client_id and >>>> client_secret for it's instance. >>>> >>>> This should force the attacker to get explicit user consent from the user >>>> to >>>> authorize that unique client_id. I wouldn't recommend for the AS to track >>>> authorization against the POST'd client description but rather the >>>> client_id. >>>> >>>> >>> An attacker can also dynamically register a very similar client >>> name/description and trick the user. >>> >>> >> True... but the user will see another consent form. This might be a minor >> hurdle but at least it's not totally seamless. I think that is an advantage. >> > Why would the user see another consent form? Were you thinking > auto-approvals? For desktop apps auto-approvals don't make much sense > and authz servers should probably never do that. > This based on my assumptions about authorization approvals. In my experience, the authorization is based off the client_id (or it's equivalent... developer key, api key, etc). So if a user has already given consent to that client_id, why would the authorization service ask the user for consent again if presented with the same client_id? To do this, the authorization would have to consider some additional parameters beside client_id when determining whether to ask the user to consent to the authorization or not. I suppose if the authorization server required user consent every time the client requested authorization ( 2.5.1. Client Requests Authorization), then I agree that having a unique client_id doesn't provide much value. >> So maybe the solution is that if the authorization server doesn't think the >> client_secret is useful, it doesn't return it. Or it always returns it and >> the client can throw it away as it knows it won't use it. However, it seems >> like the rest of the registration flow still holds. >> > Without client_secret I still don't see the point. Registration then > boils down to self asserted name, which can also be achieved with the > client_name paramter, no? > Well.. there might be a slight difference. By having a specific endpoint for registering a client, the authorization server can chose to give out a unique client_id every time the API is called (or based on some other rules). This prevents one level of "impersonation". It also keeps the existing model the same (clients are represented uniquely by a client_id). Some registered out-of-band, some registered dynamically. As far as how to represent the client, I think that more than just the client_name (as in a string) is valuable. However, this can be accomplished via client_name being a URL with discoverable meta-data or a POST'd data structure. Thanks, George --------------030901080908030500010500 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> On 6/11/10 3:15 PM, Marius Scurtescu wrote: <blockquote cite="mid:AANLkTimIkVSldwpWtKgRjZushfH9_JzzzoJ7PIsp97ET@mail.gmail.com" type="cite"> <pre wrap="">On Fri, Jun 11, 2010 at 11:46 AM, George Fletcher <a class="moz-txt-link-rfc2396E" href="mailto:gffletch@aol.com"><gffletch@aol.com></a> wrote: </pre> <blockquote type="cite"> <pre wrap="">On 6/11/10 2:09 PM, Marius Scurtescu wrote: </pre> <blockquote type="cite"> <pre wrap=""> On Fri, Jun 11, 2010 at 10:07 AM, George Fletcher<a class="moz-txt-link-rfc2396E" href="mailto:gffletch@aol.com"><gffletch@aol.com></a>  wrote: </pre> <blockquote type="cite"> <pre wrap="">Well... given this is a POST and structured data... it would be possible for the desktop app to post the raw icon data (though I suppose it could also POST a URL to the web server of the company the produces the app). In which case your previous suggestion would work (parameters discovered via the URL). I do believe the client_secret is valuable in this case because the AS is returning both the client_id and the client_secret. This then becomes a way for provisioning a unique client_id and client_secret to every instance of the app. A lot more for the AS to keep track of, but also makes it more difficult for an attacker to compromise a client. The attacker could impersonate the POST'd client description data (just like user-agent strings can be impersonated), but then the attacker just has a client_id and client_secret for it's instance. This should force the attacker to get explicit user consent from the user to authorize that unique client_id. I wouldn't recommend for the AS to track authorization against the POST'd client description but rather the client_id. </pre> </blockquote> <pre wrap=""> An attacker can also dynamically register a very similar client name/description and trick the user. </pre> </blockquote> <pre wrap=""> True... but the user will see another consent form. This might be a minor hurdle but at least it's not totally seamless. I think that is an advantage. </pre> </blockquote> <pre wrap=""> Why would the user see another consent form? Were you thinking auto-approvals? For desktop apps auto-approvals don't make much sense and authz servers should probably never do that. </pre> </blockquote> This based on my assumptions about authorization approvals. In my experience, the authorization is based off the client_id (or it's equivalent... developer key, api key, etc). So if a user has already given consent to that client_id, why would the authorization service ask the user for consent again if presented with the same client_id? To do this, the authorization would have to consider some additional parameters beside client_id when determining whether to ask the user to consent to the authorization or not. I suppose if the authorization server required user consent every time the client requested authorization ( <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> 2.5.1. Client Requests Authorization), then I agree that having a unique client_id doesn't provide much value.<br> <br> <blockquote cite="mid:AANLkTimIkVSldwpWtKgRjZushfH9_JzzzoJ7PIsp97ET@mail.gmail.com" type="cite"> <pre wrap=""></pre> <blockquote type="cite"> <pre wrap="">So maybe the solution is that if the authorization server doesn't think the client_secret is useful, it doesn't return it. Or it always returns it and the client can throw it away as it knows it won't use it. However, it seems like the rest of the registration flow still holds. </pre> </blockquote> <pre wrap=""> Without client_secret I still don't see the point. Registration then boils down to self asserted name, which can also be achieved with the client_name paramter, no? </pre> </blockquote> Well.. there might be a slight difference. By having a specific endpoint for registering a client, the authorization server can chose to give out a unique client_id every time the API is called (or based on some other rules). This prevents one level of "impersonation". It also keeps the existing model the same (clients are represented uniquely by a client_id). Some registered out-of-band, some registered dynamically. <br> <br> As far as how to represent the client, I think that more than just the client_name (as in a string) is valuable. However, this can be accomplished via client_name being a URL with discoverable meta-data or a POST'd data structure.<br> <br> Thanks,<br> George<br> </body> </html> --------------030901080908030500010500-- From eran@hueniverse.com Fri Jun 11 13:11:22 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 395A13A6A51 for <oauth@core3.amsl.com>; Fri, 11 Jun 2010 13:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xl17ie2-Qd-N for <oauth@core3.amsl.com>; Fri, 11 Jun 2010 13:11:21 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 259F03A6A59 for <oauth@ietf.org>; Fri, 11 Jun 2010 13:11:21 -0700 (PDT) Received: (qmail 23234 invoked from network); 11 Jun 2010 20:11:23 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 11 Jun 2010 20:11:23 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Fri, 11 Jun 2010 13:11:21 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org> Date: Fri, 11 Jun 2010 13:11:19 -0700 Thread-Topic: Draft -07 (major rewrite) Thread-Index: AcsJokGOtHDVAz8iTfmBRAsuvMMFnA== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF76BC@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 -07 (major rewrite) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 11 Jun 2010 20:11:22 -0000 Draft -07 represents a major rearrangement of the document. I still have a = lot of work to do but wanted to share my progress and get some general feed= back. The draft includes a few normative language changes but the main focu= s is on the document structure and how the architecture is explained. Changes include: o Removed device profile. o Added verification code support to user-agent flow. o Removed multiple formats support, leaving JSON as the only format. o Changed assertion "assertion_format" parameter to "assertion_type". o Removed "type" parameter from token endpoint. The spec is now 36 pages, 19 pages shorter than -05. EHL From igor.faynberg@alcatel-lucent.com Fri Jun 11 13:12:40 2010 Return-Path: <igor.faynberg@alcatel-lucent.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E03C3A69A8 for <oauth@core3.amsl.com>; Fri, 11 Jun 2010 13:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.601 X-Spam-Level: X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bd9Gbf5YlsYg for <oauth@core3.amsl.com>; Fri, 11 Jun 2010 13:12:38 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id CD3823A6A55 for <oauth@ietf.org>; Fri, 11 Jun 2010 13:12:35 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id o5BKCbdu026754 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Jun 2010 15:12:37 -0500 (CDT) Received: from [135.244.20.229] (faynberg.lra.lucent.com [135.244.20.229]) by umail.lucent.com (8.13.8/TPES) with ESMTP id o5BKCaOG012018; Fri, 11 Jun 2010 15:12:36 -0500 (CDT) Message-ID: <4C1298B4.7010304@alcatel-lucent.com> Date: Fri, 11 Jun 2010 16:12:36 -0400 From: Igor Faynberg <igor.faynberg@alcatel-lucent.com> Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Torsten Lodderstedt <torsten@lodderstedt.net> References: <042e8761-8bb6-44b5-8b6f-5507bf254abf@e35g2000yqm.googlegroups.com> <k2ifd6741651005052213ye98c90f3wde4afededb8542a8@mail.gmail.com> <AANLkTimD4N9zG4xZGMq_SETXOI5rd2XFZhJc_KAaQPfa@mail.gmail.com> <4C12918E.3000503@lodderstedt.net> In-Reply-To: <4C12918E.3000503@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 Cc: Kevin Smith <mrkrcsmith@googlemail.com>, OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] [WRAP] WRAP in GSMA OneAPI X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 11 Jun 2010 20:12:40 -0000 A good question! I suspect I know the problem here. In mobile networks users are authenticated separately and for separate purposes. So, one gets authenticated via MSISDN for the link layer connection, with IMSI--for UMTS, with IMPI--for IMS. (All of these are achieved by using the AKA protocol.) There is a Generic 3GPP Bootstrapping Architecture standard, which specifies the method for application authentication, but it has not been widely deployed, and--to the best of my knowledge--it is not supported by browsers. I do think that AKA can be used directly, with the IETF version of AKA digest, and we have in fact researched and found the solution for OpenID (http://www3.interscience.wiley.com/journal/123441615/abstract), which can be extended to geolocation. This would indeed allow to authenticate on IMSI or MSISDN. Igor Torsten Lodderstedt wrote: > Hi Kevin, > > what problems do you have with pre-paid users? Is your network unable > to authenticate them (by IMSI or MSISDN)? > > regards, > Torsten. > > Am 08.06.2010 18:31, schrieb Kevin Smith: >> Hi David, Blaine, >> >> We (the OneAPI group) have been looking further into OAUTH 2.0 and >> would like to see how it can work in a mobile network scenario: for >> example, a desktop Web application wants to locate a mobile user to >> plot their location on a map. So the client is the Web application >> and the server is an HTTP platform sitting on top of the mobile core >> network. >> >> It seems that the Web application could register a client ID and >> client secret with the OneAPI-implementing server. When location is >> requested by this client, the server would prompt the user, and if >> permission were received, would enable the client to access the >> location via an access token/secret. >> >> One difference to the regular OAUTH flow is that 'post-pay' contract >> network subscribers would not have to enter a username/password to >> identify themselves since they would be implicitly identified on the >> network anyway; they would just need to confirm authorisation >> ('Allow/Block'). We are not sure how to handle pre-pay users that buy >> phone credits in advance. >> >> In case either of you (or any other OAUTH expert) would be available >> to lead a discussion on the technology, and to answer questions from >> mobile operators and platform vendors, we are having a meeting next >> Tuesday in London. The meeting is also accessible over Webex. Please >> let me know if you would be willing to do so, as I'm sure it will >> help kick-start our implementation work. >> >> Cheers! >> Kevin >> >> On Thu, May 6, 2010 at 6:13 AM, David Recordon <recordond@gmail.com >> <mailto:recordond@gmail.com>> wrote: >> >> +OAuth IETF list >> -WRAP list to BCC >> >> Hi Kevin, >> OAuth 2.0 should be pretty simple for you to implement and any >> feedback your team has would be really appreciated! There are >> already implementations in Cocoa, Python, and Ruby list on the >> wiki at http://wiki.oauth.net/OAuth-2.0 and you find find the >> spec at http://tools.ietf.org/html/draft-hammer-oauth2-00. >> >> You may also be interested in the mobile web implementation we've >> built at Facebook. http://developers.facebook.com/docs/guides/mobile/ >> >> I'm also cc'ing Blaine Cook who lives in Ireland and might be >> able to present. >> >> Cheers, >> --David >> >> >> On Tue, May 4, 2010 at 4:20 AM, Kevin Smith, Vodafone >> <mrkrcsmith@googlemail.com <mailto:mrkrcsmith@googlemail.com>> wrote: >> >> Dear OAUTH WRAP group, >> >> My name is Kevin Smith of Vodafone R&D, and I lead a cross-mobile >> operator project called OneAPI ('Open Network Enablers') [1]. >> The aim >> is to provide a RESTful API to expose network functions such as >> location, messaging, payments and more to developers; with the >> reckoning that this will make it far easier to mash-up Web >> applications with network capabilities and reduce the time to >> reach >> all mobile subscribers in a territory. Thus far we have a >> live pilot >> implementation across the 3 major Canadian operators [2] and >> a non- >> commercial test site connected to >> 12 European operators [3], and will be releasing v1.0 >> specifications >> backed by the OMA this month. >> >> For the first release we did not attempt to prescribe an AAA >> model to >> operators, instead leaving them to reuse their own SDP AAA >> implementation for OneAPI. For our second phase now underway >> we would >> like to provide a recommended reference implementation AAA >> model for >> operators who are unsure how to allow secure API access whilst >> allowing user consent and privacy to be respected. Therefore >> we have >> discussed OAUTH as an ideal candidate that will be well-known >> to Web >> developers. >> >> My question regards the suitability of WRAP for such a reference >> implementation: the decoupling of authentication is good >> sense and >> would be welcome by operators, however it appears that WRAP is >> deprecated and is intended to be replaced by OAUTH 2.0 - is that >> right? Please could you provide any details on the plans for >> if/how >> the two will interoperate? If it's at all possible, we would >> very much >> welcome a member of the group to present on WRAP at one of >> our face-to- >> face meetings in London - if that is of interest please let >> me know >> and I can make arrangements. >> >> Thanks for your time and look forward to your advice. >> >> Kind regards, >> Kevin >> >> [1] http://www.gsmworld.com/oneapi >> [2] http://canada.oneapi.gsmworld.com/ >> [3] http://oneapi.aepona.com/ >> >> Kevin Smith >> Senior Technology Strategist, R&D >> Vodafone Technology >> >> E-mail: kevin.smith@vodafone.com >> <mailto:kevin.smith@vodafone.com> >> >> -- >> You received this message because you are subscribed to the >> Google Groups "OAuth WRAP WG" group. >> To post to this group, send email to >> oauth-wrap-wg@googlegroups.com >> <mailto:oauth-wrap-wg@googlegroups.com>. >> To unsubscribe from this group, send email to >> oauth-wrap-wg+unsubscribe@googlegroups.com >> <mailto:oauth-wrap-wg%2Bunsubscribe@googlegroups.com>. >> For more options, visit this group at >> http://groups.google.com/group/oauth-wrap-wg?hl=en. >> >> >> -- >> You received this message because you are subscribed to the >> Google Groups "OAuth WRAP WG" group. >> To post to this group, send email to >> oauth-wrap-wg@googlegroups.com >> <mailto:oauth-wrap-wg@googlegroups.com>. >> To unsubscribe from this group, send email to >> oauth-wrap-wg+unsubscribe@googlegroups.com >> <mailto:oauth-wrap-wg%2Bunsubscribe@googlegroups.com>. >> For more options, visit this group at >> http://groups.google.com/group/oauth-wrap-wg?hl=en. >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > ------------------------------------------------------------------------ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From eran@hueniverse.com Fri Jun 11 13:12:47 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D16FC3A69A8 for <oauth@core3.amsl.com>; Fri, 11 Jun 2010 13:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.974 X-Spam-Level: X-Spam-Status: No, score=-1.974 tagged_above=-999 required=5 tests=[AWL=0.625, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ls-gnHejFN1 for <oauth@core3.amsl.com>; Fri, 11 Jun 2010 13:12:43 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 4F5193A6A56 for <oauth@ietf.org>; Fri, 11 Jun 2010 13:12:42 -0700 (PDT) Received: (qmail 24290 invoked from network); 11 Jun 2010 20:12:45 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 11 Jun 2010 20:12:45 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Fri, 11 Jun 2010 13:12:36 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: Torsten Lodderstedt <torsten@lodderstedt.net> Date: Fri, 11 Jun 2010 13:12:35 -0700 Thread-Topic: [OAUTH-WG] proposal: multiple access tokens from a single authorization flow Thread-Index: AcsJn1xY9EmUmWPHTSCOBO44uKYUYgAAwyUA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF76BD@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4BFAA6AB.8040809@lodderstedt.net> <4BFC3142.6010506@lodderstedt.net> <AANLkTilRireowt1v8SidOiMJ-7ilBfvSqAiNfecA7uwR@mail.gmail.com> <4BFC371A.5040109@lodderstedt.net> <AANLkTikF1wk5eqme-N4RHviB5M7HzGYzy0p1mGuaux5g@mail.gmail.com> <4C07F407.4050305@lodderstedt.net> <1275663845.7068.94.camel@localhost.localdomain> <4C09732B.5040800@lodderstedt.net> <4C0F6A9C.2060607@lodderstedt.net> <4C1108C4.9040501@lodderstedt.net> <AANLkTils4bwYtv5u9yXJycqTQ_NFt0BUtA7P0kBTITpX@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3EAF7473@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C129387.1090703@lodderstedt.net> In-Reply-To: <4C129387.1090703@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 \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] proposal: multiple access tokens from a single authorization flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 11 Jun 2010 20:12:47 -0000 I'll let you know when I see the I-D :-) EHL > -----Original Message----- > From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > Sent: Friday, June 11, 2010 12:51 PM > To: Eran Hammer-Lahav > Cc: David Recordon; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] proposal: multiple access tokens from a single > authorization flow >=20 > Hi, >=20 > thanks for your advice. I described the new parameter in my proposal. > What additional text/information would you expect in an I-D? >=20 > regards, > Torsten. >=20 > Am 11.06.2010 01:02, schrieb Eran Hammer-Lahav: > > I strongly believe that it should be first presented as an I-D. This is= true in > general for most proposed changes of this size. It is hard to tell how bi= g of an > impact a change like this will have without some actual text. Once propos= ed, > the WG can decide if this is of interest as a WG item. If it is, we discu= ss the > technical details. Then, we can have a chat about editorial work and how = to > best fit it within the OAuth specifications framework. > > > > Hope this helps. > > > > EHL > > > > > >> -----Original Message----- > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >> Behalf Of David Recordon > >> Sent: Thursday, June 10, 2010 8:54 AM > >> To: Torsten Lodderstedt > >> Cc: OAuth WG (oauth@ietf.org) > >> Subject: Re: [OAUTH-WG] proposal: multiple access tokens from a > >> single authorization flow > >> > >> I strongly believe that it should be an extension. Even optional > >> response parameters increase the complexity for client developers and > >> this in particular affects the data model used to store access tokens. > >> > >> --David > >> > >> > >> On Thu, Jun 10, 2010 at 8:46 AM, Torsten Lodderstedt > >> <torsten@lodderstedt.net> wrote: > >> > >>> no one in the WG having an opinion on this topic? > >>> > >>> Am 09.06.2010 12:19, schrieb Torsten Lodderstedt: > >>> > >>>> Hi all, > >>>> > >>>> I would like to see support in OAuth2 for the authorization of > >>>> arbitrary scopes in a single authorization flow for all kinds of > >>>> deployments. In some deployments this may require to issue multiple > >>>> > >> access tokens at once. > >> > >>>> Therefore, I would like to propose the following addition to > >>>> section 2.3.2.1. (Access Token Response): > >>>> > >>>> Add an optional parameter "additional_access_tokens". > >>>> > >>>> additional_access_tokens > >>>> OPTIONAL. Array of access tokens issued by the authorizati= on > >>>> server along with respective expiration and scop= e. > >>>> Used > >>>> if the authorization server decides to issue > >>>> more than > >>>> one access token. The scopes of the different > >>>> tokens may > >>>> not overlap. > >>>> > >>>> Example: > >>>> HTTP/1.1 200 OK > >>>> Content-Type: application/json > >>>> Cache-Control: no-store > >>>> > >>>> { > >>>> "access_token":"SlAV32hkKG", > >>>> "expires_in":3600, > >>>> "refresh_token":"8xLOxBtZp8", > >>>> scope:"https://imap.example.com", > >>>> additional_access_tokens:[ > >>>> { > >>>> "access_token":"SlAV32hkKG2", > >>>> "expires_in":3600, > >>>> scope:"https://sip.example.com" > >>>> }, > >>>> { > >>>> "access_token":"SlAV32hkKG3", > >>>> "expires_in":3600, > >>>> scope:"https://contacts.example.com/read" > >>>> }, > >>>> { > >>>> "access_token":"SlAV32hkKG4", > >>>> "expires_in":3600, > >>>> scope:"https://webdav.example.com/read" > >>>> } > >>>> ] > >>>> } > >>>> > >>>> --- Some motivation --- > >>>> > >>>> I think we will see more and more clients integrating different > >>>> end-user services (like mashups). Based on the current draft, some > >>>> OAuth authorization servers may not be able to support such clients > >>>> with an acceptable user experiences. > >>>> > >>>> Suppose a communication client integrating the following services: > >>>> - e-Mail via IMAP > >>>> - Voice over IP using the SIP protocol > >>>> - Contacts via SyncML over HTTP > >>>> - Webstorage access (e.g. for e-Mail attachments) using HTTP/WebDAV > >>>> > >>>> For a particular end-user, the client may discover that all of the > >>>> end-user's services rely on the same OAuth2-based authorization > >>>> server because they are provided by the same organization (e.g. an > >>>> isp or > >>>> > >> a telco). > >> > >>>> The services are distinguished at the authorization server by > >>>> different scopes (probably including permissions as well), e.g. : > >>>> > >>>> imap - https://imap.example.com > >>>> sip - https://sip.example.com > >>>> contacts - https://contacts.example.com/read webstorage - > >>>> https://contacts.example.com/read > >>>> > >>>> Some providers may want to issue different service-specific tokens > >>>> in such a setup (Deutsche Telekom does it already), for the > >>>> following > >>>> > >> reasons: > >> > >>>> 1) Security > >>>> > >>>> a) minimize impact of token abuse - tokens may leak in many ways, > e.g. > >>>> through log files, proxies or HTTP referer. If a provider just uses > >>>> a single token for all services, the impact of token leakage is > >>>> much higher. For example, if a token gets exposed by the _contacts_ > >>>> service via HTTP referer, an adversary may place long-distance > >>>> calls using that token on the _VoIP_ service at the expense of the > >>>> end-user. This threat holds for all kinds of tokens (handles and > >>>> self- > >>>> > >> contained tokens). > >> > >>>> b) use a shared secret between authz server and a single service > >>>> only - a major critism from the operational security perspective to > >>>> OAuth 1.0a was the need to spread client secrets to resource servers= . > >>>> Using the same shared secret to sign/encrypt tokens for different > >>>> services is a comparable problem. This aspect is relevant for self- > >>>> > >> contained tokens, only. > >> > >>>> 2) Privacy - the provider wants to restrict access of services to > >>>> personal data to the data a particular service is allowed and > >>>> authorized to see. This is good style (IMHO), it might also be > >>>> required by law (e.g. German Federal Data Protection Act). This > >>>> aspect is relevant for self-contained tokens, only. > >>>> > >>>> 3) Bandwith efficiency - putting only the data required by the > >>>> services into the token saves bandwith. This aspect is relevant for > >>>> self-contained tokens, only. > >>>> > >>>> In my opinion, most of these aspects are just a consequence of the > >>>> decoupling of authorization server and resource server(s) in OAuth2. > >>>> If a single authorization server is responsible for several > >>>> resource servers, it has to ensure privacy protection and > >>>> prevention of token abuse for all of its services. This should also > >>>> include some separation between services, no matter if one uses > >>>> self-contained tokens > >>>> > >> or handles. > >> > >>>> Without the change I proposed, the authorization server in the > >>>> example scenario would need to force the client to perform _four_ > >>>> subsequent authorization flows in order to obtain all required > >>>> tokens. Moreover, the client would need to manage four refresh > tokens. > >>>> > >>>> I would kindly ask you to support my proposal. In my opinion, it > >>>> significantly improves the applicability of OAuth2 while the change > >>>> to the current draft is minimal. Moreover, deployments w/o the need > >>>> to issue multiple tokens are not affected at all. > >>>> > >>>> Any thoughts? > >>>> > >>>> 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 > >>> > >>> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > >> From root@core3.amsl.com Fri Jun 11 13:15:06 2010 Return-Path: <root@core3.amsl.com> X-Original-To: oauth@ietf.org Delivered-To: oauth@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 0FD863A6A56; Fri, 11 Jun 2010 13:15:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100611201503.0FD863A6A56@core3.amsl.com> Date: Fri, 11 Jun 2010 13:15:02 -0700 (PDT) Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-07.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 11 Jun 2010 20:15:07 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Authentication Protocol Working Group of the IETF. Title : The OAuth 2.0 Protocol Author(s) : E. Hammer-Lahav, et al. Filename : draft-ietf-oauth-v2-07.txt Pages : 36 Date : 2010-06-11 This specification describes the OAuth 2.0 protocol. OAuth provides a method for making authenticated HTTP requests using a token - an string used to denote an access grant with specific scope, duration, and other attributes. Tokens are issued to third-party clients by an authorization server with the approval of the resource owner. OAuth defines multiple flows for obtaining a token to support a wide range of client types and user experience. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-oauth-v2-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-06-11130647.I-D@ietf.org> --NextPart-- From mscurtescu@google.com Fri Jun 11 13:48:16 2010 Return-Path: <mscurtescu@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0711D3A6A4A for <oauth@core3.amsl.com>; Fri, 11 Jun 2010 13:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.025 X-Spam-Level: X-Spam-Status: No, score=-105.025 tagged_above=-999 required=5 tests=[AWL=0.952, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6sS9u+SnXVWS for <oauth@core3.amsl.com>; Fri, 11 Jun 2010 13:48:15 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 1A4383A6767 for <oauth@ietf.org>; Fri, 11 Jun 2010 13:48:15 -0700 (PDT) Received: from hpaq13.eem.corp.google.com (hpaq13.eem.corp.google.com [172.25.149.13]) by smtp-out.google.com with ESMTP id o5BKmG42028947 for <oauth@ietf.org>; Fri, 11 Jun 2010 13:48:16 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1276289297; bh=ZaUeOBuWhtTbYffnkSQepZP+f50=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=X5gkYt7yUFdSCC29JN4aWK7pRbzlRIZ2yDwGBiVR2WDXZD7ewLyl60l+NUqJ38IhZ G1UYgNxgcrKE7/rGFjxbg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding; b=JxT5Hftyyr6BDycxtO7e1R/b0x11Gm/Qlu5idmF+fNPy9KIr1ByTgzNyWWXnHYE4C o2fHS5vfuhXdi7gDlOzIQ== Received: from pva18 (pva18.prod.google.com [10.241.209.18]) by hpaq13.eem.corp.google.com with ESMTP id o5BKmEDp005416 for <oauth@ietf.org>; Fri, 11 Jun 2010 13:48:15 -0700 Received: by pva18 with SMTP id 18so1007489pva.14 for <oauth@ietf.org>; Fri, 11 Jun 2010 13:48:14 -0700 (PDT) Received: by 10.142.152.12 with SMTP id z12mr1685882wfd.71.1276289294122; Fri, 11 Jun 2010 13:48:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.124.13 with HTTP; Fri, 11 Jun 2010 13:47:54 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF76BC@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF76BC@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu <mscurtescu@google.com> Date: Fri, 11 Jun 2010 13:47:54 -0700 Message-ID: <AANLkTimwF01iyhC7ua35scgMIPqVv3J5d_Z1lHSTXLUo@mail.gmail.com> To: Eran Hammer-Lahav <eran@hueniverse.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Draft -07 (major rewrite) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 11 Jun 2010 20:48:16 -0000 On Fri, Jun 11, 2010 at 1:11 PM, Eran Hammer-Lahav <eran@hueniverse.com> wr= ote: > Draft -07 represents a major rearrangement of the document. I still have = a lot of work to do but wanted to share my progress and get some general fe= edback. The draft includes a few normative language changes but the main fo= cus is on the document structure and how the architecture is explained. > > Changes include: > > =A0 o =A0Removed device profile. > =A0 o =A0Added verification code support to user-agent flow. > =A0 o =A0Removed multiple formats support, leaving JSON as the only forma= t. > =A0 o =A0Changed assertion "assertion_format" parameter to "assertion_typ= e". > =A0 o =A0Removed "type" parameter from token endpoint. It would be really useful if each request had a unique type, now we are back to guessing what is requested, like in WRAP. One small error that I noticed: section "5.1.4. Refresh Token" is not listing client_id and client_secret as optional parameters. In general I found previous versions much easier to read and understand, but maybe I just need more time... Marius From sayrer@gmail.com Fri Jun 11 13:51:47 2010 Return-Path: <sayrer@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E942D3A6877 for <oauth@core3.amsl.com>; Fri, 11 Jun 2010 13:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0PZNzeEeuqma for <oauth@core3.amsl.com>; Fri, 11 Jun 2010 13:51:47 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 21D233A6767 for <oauth@ietf.org>; Fri, 11 Jun 2010 13:51:47 -0700 (PDT) Received: by gxk8 with SMTP id 8so316617gxk.31 for <oauth@ietf.org>; Fri, 11 Jun 2010 13:51:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=7xsvUORhd8EOrPsCZ00aiSc70+IFOBTShLXDGrryGaE=; b=DT99oBxvXIyxPcfnODDvwZwqdS5iq0s5U1Ogl22SZIGxnSZ/vMboopsjaI4hq798ml rBSZ+E70vqOScKMcCy15JzOdvqhNaCrlBfmxMvGEPUqWyUPRENDV15lo80LOotd++sl0 6SJfujIB1Yh3XcBc5cwMG7FCiAIuRbX8fnCOs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=R9kXJSAmHHiOu49MUhKi5hXhcnEP6WJ6hhWfooOzGfms20tfZY544f5e5Un3LD24mT bdeIQFwLKSUhoh3rwKRu6kQQfMysFkbln/9C00zpRQKTibBdydSUGVyEiZ9F23T8yifh m+k14hECTVhVBi7KSqNgFkRrkzjBKzEbdj42Q= MIME-Version: 1.0 Received: by 10.229.86.10 with SMTP id q10mr1461931qcl.36.1276289506385; Fri, 11 Jun 2010 13:51:46 -0700 (PDT) Received: by 10.229.99.142 with HTTP; Fri, 11 Jun 2010 13:51:46 -0700 (PDT) In-Reply-To: <AANLkTik1HYTYa-Bc5kImyr6Oh6OLR0tqPgHiP7Hjeeu7@mail.gmail.com> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF73EF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E11263FEC9FC@WSMSG3153V.srv.dir.telstra.com> <4A5E1C55-D589-4F25-9D45-E640BA7C833F@facebook.com> <AANLkTik1HYTYa-Bc5kImyr6Oh6OLR0tqPgHiP7Hjeeu7@mail.gmail.com> Date: Fri, 11 Jun 2010 16:51:46 -0400 Message-ID: <AANLkTikdUoT_K9ls4kwCH4zbmWiUTzIYGM1eeIi2d8xB@mail.gmail.com> From: Robert Sayre <sayrer@gmail.com> To: Naitik Shah <n@daaku.org> Content-Type: text/plain; charset=ISO-8859-1 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Proposal for single JSON response format X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 11 Jun 2010 20:51:48 -0000 +1 On Fri, Jun 11, 2010 at 1:17 AM, Naitik Shah <n@daaku.org> wrote: > +1 > > On Thu, Jun 10, 2010 at 5:50 PM, Luke Shepard <lshepard@facebook.com> wrote: >> >> +1 >> >> On Jun 10, 2010, at 5:46 PM, Manger, James H wrote: >> >> > +1 >> > >> > -- >> > James Manger >> > >> > ---------- >> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> > Of Eran Hammer-Lahav >> > Sent: Friday, 11 June 2010 6:29 AM >> > To: OAuth WG (oauth@ietf.org) >> > Subject: [OAUTH-WG] Proposal for single JSON response format >> > >> > - Support a single response format (including in the user-agent >> > fragment) using JSON. >> > _______________________________________________ >> > OAuth mailing 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 > > -- Robert Sayre "I would have written a shorter letter, but I did not have the time." From jricher@mitre.org Fri Jun 11 14:05:24 2010 Return-Path: <jricher@mitre.org> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F118528C115 for <oauth@core3.amsl.com>; Fri, 11 Jun 2010 14:05:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.594 X-Spam-Level: X-Spam-Status: No, score=-5.594 tagged_above=-999 required=5 tests=[AWL=1.005, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTsWJz8mJAa8 for <oauth@core3.amsl.com>; Fri, 11 Jun 2010 14:05:21 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 8CCDE3A6A17 for <oauth@ietf.org>; Fri, 11 Jun 2010 14:05:00 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o5BL52JQ025507 for <oauth@ietf.org>; Fri, 11 Jun 2010 17:05:02 -0400 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o5BL526O025504; Fri, 11 Jun 2010 17:05:02 -0400 Received: from [129.83.50.65] (129.83.50.65) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server id 8.2.254.0; Fri, 11 Jun 2010 17:05:02 -0400 From: Justin Richer <jricher@mitre.org> To: Marius Scurtescu <mscurtescu@google.com> In-Reply-To: <AANLkTimwF01iyhC7ua35scgMIPqVv3J5d_Z1lHSTXLUo@mail.gmail.com> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF76BC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTimwF01iyhC7ua35scgMIPqVv3J5d_Z1lHSTXLUo@mail.gmail.com> Content-Type: text/plain; charset="UTF-8" Date: Fri, 11 Jun 2010 17:05:01 -0400 Message-ID: <1276290301.31840.78.camel@localhost.localdomain> MIME-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Draft -07 (major rewrite) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 11 Jun 2010 21:05:24 -0000 I agree with Marius: I think we should keep the explicit flow name in there (in the 'type' parameter or equivalent), as it (among other things) opens the possibility for the rescope and revoke operations. It makes it very clear how both client and server expect things to behave. -- Justin On Fri, 2010-06-11 at 16:47 -0400, Marius Scurtescu wrote: > On Fri, Jun 11, 2010 at 1:11 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote: > > Draft -07 represents a major rearrangement of the document. I still have a lot of work to do but wanted to share my progress and get some general feedback. The draft includes a few normative language changes but the main focus is on the document structure and how the architecture is explained. > > > > Changes include: > > > > o Removed device profile. > > o Added verification code support to user-agent flow. > > o Removed multiple formats support, leaving JSON as the only format. > > o Changed assertion "assertion_format" parameter to "assertion_type". > > o Removed "type" parameter from token endpoint. > > It would be really useful if each request had a unique type, now we > are back to guessing what is requested, like in WRAP. > > One small error that I noticed: section "5.1.4. Refresh Token" is not > listing client_id and client_secret as optional parameters. > > In general I found previous versions much easier to read and > understand, but maybe I just need more time... > > > Marius > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From cs@comlounge.net Fri Jun 11 14:24:14 2010 Return-Path: <cs@comlounge.net> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C86828C0F4 for <oauth@core3.amsl.com>; Fri, 11 Jun 2010 14:24:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_36=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7JCf2Wu01tN for <oauth@core3.amsl.com>; Fri, 11 Jun 2010 14:24:12 -0700 (PDT) Received: from post.comlounge.net (post.comlounge.net [85.214.59.142]) by core3.amsl.com (Postfix) with ESMTP id 156FE3A63CB for <oauth@ietf.org>; Fri, 11 Jun 2010 14:24:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by post.comlounge.net (Postfix) with ESMTP id C38326F40B4 for <oauth@ietf.org>; Fri, 11 Jun 2010 23:24:13 +0200 (CEST) Received: from post.comlounge.net ([127.0.0.1]) by localhost (h1346004.stratoserver.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q89LdGLz0awT for <oauth@ietf.org>; Fri, 11 Jun 2010 23:24:13 +0200 (CEST) Received: from [192.168.2.113] (p5B3D7469.dip.t-dialin.net [91.61.116.105]) by post.comlounge.net (Postfix) with ESMTPSA id 236716F40AB for <oauth@ietf.org>; Fri, 11 Jun 2010 23:24:11 +0200 (CEST) Message-ID: <4C12A97A.8020505@comlounge.net> Date: Fri, 11 Jun 2010 23:24:10 +0200 From: Christian Scholz <cs@comlounge.net> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; de; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: oauth@ietf.org References: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF76BC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTimwF01iyhC7ua35scgMIPqVv3J5d_Z1lHSTXLUo@mail.gmail.com> In-Reply-To: <AANLkTimwF01iyhC7ua35scgMIPqVv3J5d_Z1lHSTXLUo@mail.gmail.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [OAUTH-WG] Draft -07 (major rewrite) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 11 Jun 2010 21:24:14 -0000 Hi! Am 11.06.10 22:47, schrieb Marius Scurtescu: > On Fri, Jun 11, 2010 at 1:11 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote: >> Draft -07 represents a major rearrangement of the document. I still have a lot of work to do but wanted to share my progress and get some general feedback. The draft includes a few normative language changes but the main focus is on the document structure and how the architecture is explained. >> >> Changes include: >> >> o Removed device profile. >> o Added verification code support to user-agent flow. >> o Removed multiple formats support, leaving JSON as the only format. >> o Changed assertion "assertion_format" parameter to "assertion_type". >> o Removed "type" parameter from token endpoint. > > It would be really useful if each request had a unique type, now we > are back to guessing what is requested, like in WRAP. I am just wondering why having a separate endpoint for this isn't enough. I would rather map another library call to another endpoint instead of relying on guessing on the contents. That's why we have separate endpoints, I guess. (I might be missing something though) -- Christian -- Christian Scholz Homepage: http://comlounge.net COM.lounge GmbH blog: http://mrtopf.de/blog Hanbrucher Str. 33 Skype: HerrTopf 52064 Aachen Video Blog: http://comlounge.tv Tel: +49 241 400 730 0 E-Mail cs@comlounge.net Fax: +49 241 979 00 850 IRC: MrTopf, Tao_T Podcasts: Der OpenWeb-Podcast (http://openwebpodcast.de) Data Without Borders (http://datawithoutborders.net) Politisches: http://politfunk.de/ Technical: http://comlounge.tv/ From eran@hueniverse.com Fri Jun 11 14:25:40 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 203AF3A63CB for <oauth@core3.amsl.com>; Fri, 11 Jun 2010 14:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[AWL=0.598, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qG7jdoPSdrIe for <oauth@core3.amsl.com>; Fri, 11 Jun 2010 14:25:34 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id A3CF328C0FA for <oauth@ietf.org>; Fri, 11 Jun 2010 14:25:33 -0700 (PDT) Received: (qmail 1179 invoked from network); 11 Jun 2010 21:25:35 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 11 Jun 2010 21:25:35 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Fri, 11 Jun 2010 14:25:33 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: Justin Richer <jricher@mitre.org>, Marius Scurtescu <mscurtescu@google.com> Date: Fri, 11 Jun 2010 14:25:30 -0700 Thread-Topic: [OAUTH-WG] Draft -07 (major rewrite) Thread-Index: AcsJqcOFVAfpyGJ0RN6xn3Kh5pfHJwAAtp6/ Message-ID: <C837F7DA.358C4%eran@hueniverse.com> In-Reply-To: <1276290301.31840.78.camel@localhost.localdomain> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C837F7DA358C4eranhueniversecom_" MIME-Version: 1.0 Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] Draft -07 (major rewrite) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 11 Jun 2010 21:25:40 -0000 --_000_C837F7DA358C4eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It doesn't really. It is completely clear what kind of authorization grant = the client is providing simply by looking at the parameter. It might make t= he code a few lines longer (a few if-else instead of a switch-case) but bec= ause these are all post parameters, you access them the same way (i.e. this= is not a case where header information is moved to post body, etc.). As for the rescope and revoke operations, we still need to figure out how t= o accomplish that. For example, revoking can be done using an HTTP DELETE o= peration which is more consistent with HTTP, and rescoping (which is still = tricky because scope can only be decreased) is more a function of a refresh= operation (asking for a new access token using a refresh token and simply = providing a new, lesser scope). EHL On 6/11/10 2:05 PM, "Justin Richer" <jricher@mitre.org> wrote: I agree with Marius: I think we should keep the explicit flow name in there (in the 'type' parameter or equivalent), as it (among other things) opens the possibility for the rescope and revoke operations. It makes it very clear how both client and server expect things to behave. -- Justin On Fri, 2010-06-11 at 16:47 -0400, Marius Scurtescu wrote: > On Fri, Jun 11, 2010 at 1:11 PM, Eran Hammer-Lahav <eran@hueniverse.com> = wrote: > > Draft -07 represents a major rearrangement of the document. I still hav= e a lot of work to do but wanted to share my progress and get some general = feedback. The draft includes a few normative language changes but the main = focus is on the document structure and how the architecture is explained. > > > > Changes include: > > > > o Removed device profile. > > o Added verification code support to user-agent flow. > > o Removed multiple formats support, leaving JSON as the only format. > > o Changed assertion "assertion_format" parameter to "assertion_type"= . > > o Removed "type" parameter from token endpoint. > > It would be really useful if each request had a unique type, now we > are back to guessing what is requested, like in WRAP. > > One small error that I noticed: section "5.1.4. Refresh Token" is not > listing client_id and client_secret as optional parameters. > > In general I found previous versions much easier to read and > understand, but maybe I just need more time... > > > Marius > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --_000_C837F7DA358C4eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <HTML> <HEAD> <TITLE>Re: [OAUTH-WG] Draft -07 (major rewrite) It doesn’t really. It is completely clear what kind of authoriz= ation grant the client is providing simply by looking at the parameter. It = might make the code a few lines longer (a few if-else instead of a switch-c= ase) but because these are all post parameters, you access them the same wa= y (i.e. this is not a case where header information is moved to post body, = etc.).

As for the rescope and revoke operations, we still need to figure out how t= o accomplish that. For example, revoking can be done using an HTTP DELETE o= peration which is more consistent with HTTP, and rescoping (which is still = tricky because scope can only be decreased) is more a function of a refresh= operation (asking for a new access token using a refresh token and simply = providing a new, lesser scope).

EHL


On 6/11/10 2:05 PM, "Justin Richer" <jricher@mitre.org> wrote:

I agree with Marius: I think we should keep= the explicit flow name in
there (in the 'type' parameter or equivalent), as it (among other
things) opens the possibility for the rescope and revoke operations. It
makes it very clear how both client and server expect things to behave.

 -- Justin

On Fri, 2010-06-11 at 16:47 -0400, Marius Scurtescu wrote:
> On Fri, Jun 11, 2010 at 1:11 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
> > Draft -07 represents a major rearrangement of the document. I sti= ll have a lot of work to do but wanted to share my progress and get some ge= neral feedback. The draft includes a few normative language changes but the= main focus is on the document structure and how the architecture is explai= ned.
> >
> > Changes include:
> >
> >   o  Removed device profile.
> >   o  Added verification code support to user-agent= flow.
> >   o  Removed multiple formats support, leaving JSO= N as the only format.
> >   o  Changed assertion "assertion_format"= ; parameter to "assertion_type".
> >   o  Removed "type" parameter from token= endpoint.
>
> It would be really useful if each request had a unique type, now we > are back to guessing what is requested, like in WRAP.
>
> One small error that I noticed: section "5.1.4.  Refresh Tok= en" is not
> listing client_id and client_secret as optional parameters.
>
> In general I found previous versions much easier to read and
> understand, but maybe I just need more time...
>
>
> Marius
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ie= tf.org/mailman/listinfo/oauth



--_000_C837F7DA358C4eranhueniversecom_-- From eran@hueniverse.com Fri Jun 11 14:33:05 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFB8228C137 for ; Fri, 11 Jun 2010 14:33:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.28 X-Spam-Level: X-Spam-Status: No, score=-1.28 tagged_above=-999 required=5 tests=[AWL=-0.170, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YcVoiIlHwKFI for ; Fri, 11 Jun 2010 14:33:01 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id B74EC28C145 for ; Fri, 11 Jun 2010 14:33:01 -0700 (PDT) Received: (qmail 26856 invoked from network); 11 Jun 2010 21:32:46 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 11 Jun 2010 21:32:46 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Fri, 11 Jun 2010 14:32:44 -0700 From: Eran Hammer-Lahav To: Marius Scurtescu Date: Fri, 11 Jun 2010 14:32:41 -0700 Thread-Topic: [OAUTH-WG] Draft -07 (major rewrite) Thread-Index: AcsJp2u8gDaOLgL6R465pG1L4yC49wABjMru Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en 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] Draft -07 (major rewrite) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 21:33:05 -0000 On 6/11/10 1:47 PM, "Marius Scurtescu" wrote: > On Fri, Jun 11, 2010 at 1:11 PM, Eran Hammer-Lahav > wrote: >> Draft -07 represents a major rearrangement of the document. I still have= a >> lot of work to do but wanted to share my progress and get some general >> feedback. The draft includes a few normative language changes but the ma= in >> focus is on the document structure and how the architecture is explained= . >>=20 >> Changes include: >>=20 >> =A0 o =A0Removed device profile. >> =A0 o =A0Added verification code support to user-agent flow. >> =A0 o =A0Removed multiple formats support, leaving JSON as the only form= at. >> =A0 o =A0Changed assertion "assertion_format" parameter to "assertion_ty= pe". >> =A0 o =A0Removed "type" parameter from token endpoint. >=20 > It would be really useful if each request had a unique type, now we > are back to guessing what is requested, like in WRAP. You are always requesting an access token. What you probably mean is what kind of authorization grant the client is presenting, which I think is pretty obvious from, well, what the client is presenting... > One small error that I noticed: section "5.1.4. Refresh Token" is not > listing client_id and client_secret as optional parameters. This is because client authentication is now handled in a separate section. This is required (I still have a lot of work in this one) to separate the client credentials from the flows which was a much requested change during the meeting. Previous drafts made it very hard to specify client credential= s other than basic (i.e. Username and password like). I plan to actually name the client identifier and password 'basic client credentials' (which I think I already did in one spot), and say that if the client was issued such basic credentials, this is how to use them (basic auth or client_id/client_password parameters). Otherwise, this can be extended to other credential types such as client identifier with PKI. > In general I found previous versions much easier to read and > understand, but maybe I just need more time... This new structure requires much more clarity in the introduction and in th= e client flows section. But it I think it makes implementation easier because it gives all the technical details of the two endpoints in one place, listing all the parameters and error codes. Also, there is something to be said about dropping 20 pages. What would be really useful is to get specific feedback about which new sections are confusing, based on information not yet explained, etc. EHL From eran@hueniverse.com Fri Jun 11 14:34:02 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89A2A28C144 for ; Fri, 11 Jun 2010 14:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.717 X-Spam-Level: X-Spam-Status: No, score=-1.717 tagged_above=-999 required=5 tests=[AWL=0.281, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-H0FZAEyb7p for ; Fri, 11 Jun 2010 14:33:53 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 357D428C129 for ; Fri, 11 Jun 2010 14:33:53 -0700 (PDT) Received: (qmail 28047 invoked from network); 11 Jun 2010 21:33:54 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 11 Jun 2010 21:33:50 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Fri, 11 Jun 2010 14:33:48 -0700 From: Eran Hammer-Lahav To: Christian Scholz , OAuth WG Date: Fri, 11 Jun 2010 14:33:45 -0700 Thread-Topic: [OAUTH-WG] Draft -07 (major rewrite) Thread-Index: AcsJrIBcxA1CQxnMT7GubfnlQ78/fgAAUSu/ Message-ID: In-Reply-To: <4C12A97A.8020505@comlounge.net> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C837F9C9358C9eranhueniversecom_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Draft -07 (major rewrite) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 21:34:02 -0000 --_000_C837F9C9358C9eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The comment was about the token endpoint which used to include a 'type' par= ameter (indicating the flow being used). All the flows share the same token= endpoint. EHL On 6/11/10 2:24 PM, "Christian Scholz" wrote: Hi! Am 11.06.10 22:47, schrieb Marius Scurtescu: > On Fri, Jun 11, 2010 at 1:11 PM, Eran Hammer-Lahav = wrote: >> Draft -07 represents a major rearrangement of the document. I still have= a lot of work to do but wanted to share my progress and get some general f= eedback. The draft includes a few normative language changes but the main f= ocus is on the document structure and how the architecture is explained. >> >> Changes include: >> >> o Removed device profile. >> o Added verification code support to user-agent flow. >> o Removed multiple formats support, leaving JSON as the only format. >> o Changed assertion "assertion_format" parameter to "assertion_type". >> o Removed "type" parameter from token endpoint. > > It would be really useful if each request had a unique type, now we > are back to guessing what is requested, like in WRAP. I am just wondering why having a separate endpoint for this isn't enough. I would rather map another library call to another endpoint instead of relying on guessing on the contents. That's why we have separate endpoints, I guess. (I might be missing something though) -- Christian -- Christian Scholz Homepage: http://comlounge.net COM.lounge GmbH blog: http://mrtopf.de/blog Hanbrucher Str. 33 Skype: HerrTopf 52064 Aachen Video Blog: http://comlounge.tv Tel: +49 241 400 730 0 E-Mail cs@comlounge.net Fax: +49 241 979 00 850 IRC: MrTopf, Tao_T Podcasts: Der OpenWeb-Podcast (http://openwebpodcast.de) Data Without Borders (http://datawithoutborders.net) Politisches: http://politfunk.de/ Technical: http://comlounge.tv/ _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_C837F9C9358C9eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] Draft -07 (major rewrite) The comment was about the token endpoint which used to include a R= 16;type’ parameter (indicating the flow being used). All the flows sh= are the same token endpoint.

EHL


On 6/11/10 2:24 PM, "Christian Scholz" <cs@comlounge.net> wrote:

Hi!

Am 11.06.10 22:47, schrieb Marius Scurtescu:
> On Fri, Jun 11, 2010 at 1:11 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
>> Draft -07 represents a major rearrangement of the document. I stil= l have a lot of work to do but wanted to share my progress and get some gen= eral feedback. The draft includes a few normative language changes but the = main focus is on the document structure and how the architecture is explain= ed.
>>
>> Changes include:
>>
>>   o  Removed device profile.
>>   o  Added verification code support to user-agent = flow.
>>   o  Removed multiple formats support, leaving JSON= as the only format.
>>   o  Changed assertion "assertion_format"= parameter to "assertion_type".
>>   o  Removed "type" parameter from token = endpoint.
>
> It would be really useful if each request had a unique type, now we > are back to guessing what is requested, like in WRAP.

I am just wondering why having a separate endpoint for this isn't
enough. I would rather map another library call to another endpoint
instead of relying on guessing on the contents. That's why we have
separate endpoints, I guess.

(I might be missing something though)

-- Christian


--
Christian Scholz          &nbs= p;            &= nbsp;  Homepage: http://comloung= e.net
COM.lounge GmbH           = ;            &n= bsp;      blog: http://mrtopf.de/blog
Hanbrucher Str. 33          &n= bsp;            = ;            &n= bsp;   Skype: HerrTopf
52064 Aachen           &n= bsp;            = ;     Video Blog: = http://comlounge.tv
Tel: +49 241 400 730 0         &nbs= p;            &= nbsp;    E-Mail cs@comloun= ge.net
Fax: +49 241 979 00 850         &nb= sp;            =          IRC: MrTopf, Tao_T
Podcasts:
Der OpenWeb-Podcast (http://openwebpod= cast.de)
Data Without Borders (http://data= withoutborders.net)
Politisches: http://politfunk.de/
Technical: http://comlounge.tv/

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

--_000_C837F9C9358C9eranhueniversecom_-- From eran@hueniverse.com Fri Jun 11 14:57:27 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDF7E3A6783 for ; Fri, 11 Jun 2010 14:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.027 X-Spam-Level: X-Spam-Status: No, score=-2.027 tagged_above=-999 required=5 tests=[AWL=0.571, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M+ubjWT4Qa0O for ; Fri, 11 Jun 2010 14:57:23 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id B504F3A697D for ; Fri, 11 Jun 2010 14:57:23 -0700 (PDT) Received: (qmail 14935 invoked from network); 11 Jun 2010 21:57:25 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 11 Jun 2010 21:57:25 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Fri, 11 Jun 2010 14:57:26 -0700 From: Eran Hammer-Lahav To: Nat Sakimura , James Manger Date: Fri, 11 Jun 2010 14:57:22 -0700 Thread-Topic: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow Thread-Index: AcsGw8pgn3wY4yWjRDWz+Stub3TdcgC7UdDs Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C837FF52358CCeranhueniversecom_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 21:57:27 -0000 --_000_C837FF52358CCeranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'd still like to see this proposed as a new I-D. It can be very short. I w= ill have the extensibility guidelines in the next draft or two, but you can= start by just declaring a new parameter for the relevant endpoints. EHL On 6/7/10 7:53 PM, "Nat Sakimura" wrote: I fully agree on it. Instead of doing as a flow, defining request_url as one of the core variabl= e would be better. The question then is, whether this community accepts the idea. On Mon, Jun 7, 2010 at 10:51 PM, Manger, James H wrote: Nat, > On the other hand, you are starting to think of it as a generic "include"= mechanism, are you? Yes. That feels like the simplest mental model for this functionality, and = the simplest way to specify it. -- James Manger --_000_C837FF52358CCeranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow I’d still like to see this proposed as a new I-D. It can be ver= y short. I will have the extensibility guidelines in the next draft or two,= but you can start by just declaring a new parameter for the relevant endpo= ints.

EHL


On 6/7/10 7:53 PM, "Nat Sakimura" <sakimura@gmail.com> wrote:

I fully agree on it.=A0

Instead of doing as a flow, defining request_url as one of the core variabl= e would be better.=A0
The question then is, whether this community accepts the idea.=A0

On Mon, Jun 7, 2010 at 10:51 PM, Manger, James H <James.H.Manger@team.telstra.com> wrote:
Nat,

> On the other hand, you are starting to think of it as a generic "= include" mechanism, are you?

Yes. That feels like the simplest mental model for this functionality, and = the simplest way to specify it.

--
James Manger


--_000_C837FF52358CCeranhueniversecom_-- From uidude@google.com Sun Jun 13 02:47:04 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D93A13A67D3 for ; Sun, 13 Jun 2010 02:47:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.492 X-Spam-Level: X-Spam-Status: No, score=-100.492 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVuFjkWYH4Ay for ; Sun, 13 Jun 2010 02:47:03 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id D10E03A68F0 for ; Sun, 13 Jun 2010 02:47:02 -0700 (PDT) Received: from hpaq13.eem.corp.google.com (hpaq13.eem.corp.google.com [172.25.149.13]) by smtp-out.google.com with ESMTP id o5D9l4Bn016203 for ; Sun, 13 Jun 2010 02:47:04 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1276422424; bh=bWkrACRqSG+0oVKRiicv/fpJjP0=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=fjpWwJQz3LoShUgBzYpuZfqyyOVUixw1qs7IxRV2qlupLx0un5kltheYiKWtUoPaX 7Gk724d1kh/IyOlvs6Pmw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type; b=KulTLkJuvOLLBfrfCL3HRW9PHX6fH8lROsVUL4RqdH/aoCvcLJ7JgeINM8uozc2gV s5I0Uq+X9NTyKgD9pkJ0Q== Received: from vws16 (vws16.prod.google.com [10.241.21.144]) by hpaq13.eem.corp.google.com with ESMTP id o5D9l2b6016749 for ; Sun, 13 Jun 2010 02:47:03 -0700 Received: by vws16 with SMTP id 16so3705427vws.26 for ; Sun, 13 Jun 2010 02:47:02 -0700 (PDT) Received: by 10.224.81.84 with SMTP id w20mr1416658qak.259.1276422422184; Sun, 13 Jun 2010 02:47:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.107.13 with HTTP; Sun, 13 Jun 2010 02:46:42 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF73EF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E11263FEC9FC@WSMSG3153V.srv.dir.telstra.com> <4A5E1C55-D589-4F25-9D45-E640BA7C833F@facebook.com> From: Evan Gilbert Date: Sun, 13 Jun 2010 02:46:42 -0700 Message-ID: To: Robert Sayre Content-Type: multipart/alternative; boundary=00148531a6130ec47f0488e641f1 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Proposal for single JSON response format X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jun 2010 09:47:05 -0000 --00148531a6130ec47f0488e641f1 Content-Type: text/plain; charset=ISO-8859-1 -1 I disagree very strongly with this approach if I'm understanding correctly. Let me paraphrase to make sure I understand: All responses, even those encoded in a browser URL redirect back from the AS (redirect with verification code in the web server flow and the redirect with token in the user-agent flow) will be JSON This means that we will have a URL-encoded JSON blob as a form parameter (as it has to play nicely with existing URL parameters). So the response back in the web server flow would be: https://client.com/receiveVerificationCode?existingParam=value&oauth2=%7Bcode%3A'abc123'%2C+state%3A+'randomstatedata'%7D and the response back in the user-agent flow would be https://client.com/page?existingParam=value&oauth2=%7Baccess_token%3A+'accesstoken1234'%2Cexpires_in%3A3600%2Cstate%3A'randomstatedata'%7D Reasons why this is of concern: - Requires clients to do URL decoding *and* JSON decoding - Encourages unsafe JSON handling in the User-Agent flow (eval(JSON) = XSS hole) - Breaks the simple model we've been creating in these flows. Evan On Fri, Jun 11, 2010 at 1:51 PM, Robert Sayre wrote: > +1 > > On Fri, Jun 11, 2010 at 1:17 AM, Naitik Shah wrote: > > +1 > > > > On Thu, Jun 10, 2010 at 5:50 PM, Luke Shepard > wrote: > >> > >> +1 > >> > >> On Jun 10, 2010, at 5:46 PM, Manger, James H wrote: > >> > >> > +1 > >> > > >> > -- > >> > James Manger > >> > > >> > ---------- > >> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > Behalf > >> > Of Eran Hammer-Lahav > >> > Sent: Friday, 11 June 2010 6:29 AM > >> > To: OAuth WG (oauth@ietf.org) > >> > Subject: [OAUTH-WG] Proposal for single JSON response format > >> > > >> > - Support a single response format (including in the user-agent > >> > fragment) using JSON. > >> > _______________________________________________ > >> > OAuth mailing 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 > > > > > > > > -- > > Robert Sayre > > "I would have written a shorter letter, but I did not have the time." > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --00148531a6130ec47f0488e641f1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable -1=A0

I disagree very strongly with this = approach if I'm understanding correctly.=A0Let me paraphrase to make su= re I understand:

All responses, even those encoded= in a browser URL redirect back from the AS (redirect with verification cod= e in the web server flow and the redirect with token in the user-agent flow= ) will be JSON

This means that we will have a URL-encoded JSON blob as a form par= ameter (as it has to play nicely with existing URL parameters). So the resp= onse back in the web server flow would be:
=A0=A0https://client.= com/receiveVerificationCode?existingParam=3Dvalue&oauth2=3D%7Bcode%3A&#= 39;abc123'%2C+state%3A+'randomstatedata'%7D

Reasons why this is of concern:
- Requires clients to do= URL decoding and=A0JSON decoding
- Encourages unsafe JSON= handling in the User-Agent flow (eval(JSON) =3D XSS hole)
- Brea= ks the simple model we've been creating in these flows.

Evan

On Fri, Jun 11, 2010 at 1:51 PM, Robert Sayre <= sayrer@gmail.com&= gt; wrote:
+1

On Fri, Jun 11, 2010 at 1:17 AM, Naitik Shah <n@daaku.org> wrote:
> +1
>
> On Thu, Jun 10, 2010 at 5:50 PM, Luke Shepard <lshepard@facebook.com> wrote:=
>>
>> +1
>>
>> On Jun 10, 2010, at 5:46 PM, Manger, James H wrote:
>>
>> > +1
>> >
>> > --
>> > James Manger
>> >
>> > ----------
>> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
>> > Of Eran Hammer-Lahav
>> > Sent: Friday, 11 June 2010 6:29 AM
>> > To: OAuth WG (oauth@ietf.org)
>> > Subject: [OAUTH-WG] Proposal for single JSON response format<= br> >> >
>> > - Support a single response format (including in the user-age= nt
>> > fragment) using JSON.
>> > _______________________________________________
>> > OAuth mailing list
>> > OAuth@iet= f.org
>> > https://www.ietf.org/mailman/listinfo/oauth
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org=
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth
>
>



--

Robert Sayre

"I would have written a shorter letter, but I did not have the time.&q= uot;
_______________________________________________=
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--00148531a6130ec47f0488e641f1-- From uidude@google.com Sun Jun 13 03:07:33 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88C1B3A6863 for ; Sun, 13 Jun 2010 03:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.934 X-Spam-Level: X-Spam-Status: No, score=-99.934 tagged_above=-999 required=5 tests=[AWL=-0.558, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KuhO+tlj-uKx for ; Sun, 13 Jun 2010 03:07:31 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id D0D663A68DF for ; Sun, 13 Jun 2010 03:07:28 -0700 (PDT) Received: from hpaq5.eem.corp.google.com (hpaq5.eem.corp.google.com [172.25.149.5]) by smtp-out.google.com with ESMTP id o5DA7RPW011300 for ; Sun, 13 Jun 2010 03:07:31 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1276423651; bh=4Y/2jSNhu63E9dWSwXTx/NmOrhY=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=PcH3DRxjPsFRCWEUFnxk8fzViwmbFhC+DUCovnt0zigD82NfkUkTSTUwbYFVetLVW cStPGsAXWZj2OTF0zxKmw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type; b=hjIUesiEQbXCF6uYaY/YlyQAtMbE0kVOTmrBACq7pw3XpYEy8wRDQdG7Eg2qDuJbe M2UuIXz9ftRBKcSvpsmGw== Received: from vws1 (vws1.prod.google.com [10.241.21.129]) by hpaq5.eem.corp.google.com with ESMTP id o5DA7P8Q016646 for ; Sun, 13 Jun 2010 03:07:26 -0700 Received: by vws1 with SMTP id 1so407840vws.34 for ; Sun, 13 Jun 2010 03:07:25 -0700 (PDT) Received: by 10.224.99.66 with SMTP id t2mr1370550qan.255.1276423645361; Sun, 13 Jun 2010 03:07:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.106.204 with HTTP; Sun, 13 Jun 2010 03:07:03 -0700 (PDT) In-Reply-To: References: From: Evan Gilbert Date: Sun, 13 Jun 2010 03:07:03 -0700 Message-ID: To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=000feaedf106f6f9660488e6898b Cc: OAuth WG Subject: Re: [OAUTH-WG] A display parameter for user authorization requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jun 2010 10:07:33 -0000 --000feaedf106f6f9660488e6898b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable The "immediate" parameter is can have unintended consequences without some way to attach it to an existing user. Examples here: http://trac.tools.ietf.org/wg/oauth/trac/wiki/OAuth2UsernameParameter. I'd prefer to link these two parameters (username and immediate) in one spe= c - @David, this can be the User Experience Extension if you'd like, although= t my preference would probably be to move both to a separate doc. On Fri, Jun 11, 2010 at 8:09 AM, Eran Hammer-Lahav wro= te: > I think username needs to be covered in the OpenID Connect spec (i.e. > Identity layer on top of OAuth). Just a hint isn=92t enough. The client n= eeds > to be able to verify that the server response is what was asked, and also > the server needs to inform the client of who logged in. > > EHL > > > > On 6/11/10 6:57 AM, "Marius Scurtescu" wrote: > > There was discussion about a username hint parameter, in general this > is needed when immediate is used. Should username go to this UX > Extension, or rather immediate and username should go to a separate > one together? > > Marius > > > > On Thu, Jun 10, 2010 at 5:32 PM, David Recordon > wrote: > > +1 for moving immediate here as well. > > > > > > On Thu, Jun 10, 2010 at 4:18 PM, Eran Hammer-Lahav > wrote: > >> Since these are all extensions to the end-user endpoint, I'd suggest w= e > move the 'immediate' parameter here as well. > >> > >> > >> > >> OPTIONAL. The parameter value must be set to style=3D'verb'>true or > >> false. If set to > >> true, the authorization > server MUST NOT prompt the > >> end-user to authenticate or approve access. Instead, th= e > authorization server > >> attempts to establish the end-user's identity via other > means (e.g. browser > >> cookies) and checks if the end-user has previously > approved an identical access > >> request by the same client and if that access grant is > still active. If the > >> authorization server does not support an immediate chec= k > or if it is unable to > >> establish the end-user's identity or approval status, i= t > MUST deny the request > >> without prompting the end-user. Defaults to style=3D'verb'>false if > >> omitted. > >> > >> EHL > >> > >>> -----Original Message----- > >>> From: David Recordon [mailto:recordond@gmail.com > ] > >>> Sent: Wednesday, June 09, 2010 12:06 PM > >>> To: Eran Hammer-Lahav; Allen Tom; Breno de Medeiros; Luke Shepard > >>> Cc: OAuth WG > >>> Subject: Re: [OAUTH-WG] A display parameter for user authorization > >>> requests > >>> > >>> First draft of the UX Extension is at > >>> http://github.com/daveman692/OAuth-2.0/raw/master/draft-recordon- > >>> oauth-v2-ux-00.txt. > >>> > >>> Eran, I'm more than happy to have you take over as editor. > >>> > >>> I included Allen and Breno as authors since I followed Allen's > suggestion and > >>> adopted the language preference parameter from the OpenID extension. = I > >>> also included Luke as an author since he wrote the first pass of a > display > >>> parameter. That said, none of them have seen this draft yet. > >>> > >>> --David > >>> > >>> > >>> On Tue, Apr 13, 2010 at 12:36 PM, Allen Tom > wrote: > >>> > At least with regards to the language preference, how about if we > just > >>> > copy the openid.ui.lang parameter from the OpenID UI Extension? > >>> > > >>> > > http://svn.openid.net/repos/specifications/user_interface/1.0/trunk/op > >>> > enid-user-interface-extension-1_0.html#anchor3 > >>> > > >>> > In flows in which the client redirects the user's web browser to > >>> > authorize access, the client MAY send the Authorization Server a hi= nt > >>> > regarding the user's preferred language by sending the following > >>> parameter: > >>> > > >>> > lang > >>> > The user's preferred languages as a [BCP 47] language > priority > >>> > list, represented as a comma-separated list of BCP 47 basic languag= e > >>> > ranges in decending priority order. For instance, the value > "fr-CA,fr-FR,en- > >>> CA" > >>> > represents the preference for French spoken in Canada, French spoke= n > >>> > in France, followed by English spoken in Canada. > >>> > > >>> > The language preference hint SHOULD take precedence over the > >>> > Accept-Language HTTP header sent by the user's browser, and SHOULD > >>> > take precedence over the language preference inferred by the user's > IP > >>> Address. > >>> > > >>> > BCP 47: http://tools.ietf.org/html/bcp47 > >>> > > >>> > Allen > >>> > > >>> > > >>> > On 4/12/10 1:32 PM, "Eran Hammer-Lahav" > >>> wrote: > >>> > > >>> > Between language preferences, display configuration, and immediate > >>> > check, I think it might be worth to move that work to another draft= . > >>> > Timeline-wise, this has the potential of slowing us down. I also fe= ar > >>> > getting what is now a pretty simple spec much more complicated. > >>> > > >>> > Anyone cares to try a first draft or outline? I can do the editoria= l > >>> > work if needed, but someone needs to write something first. > >>> > > >>> > 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 > > --000feaedf106f6f9660488e6898b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable The "immediate" parameter is can have unintended consequences wit= hout some way to attach it to an existing user. Examples here:=A0htt= p://trac.tools.ietf.org/wg/oauth/trac/wiki/OAuth2UsernameParameter.
I'd prefer to link these two parameters (username and im= mediate) in one spec - @David, this can be the User Experience Extension if= you'd like, althought my preference would probably be to move both to = a separate doc.

On Fri, Jun 11, 2010 at 8:09 AM, E= ran Hammer-Lahav <eran@hueniverse.com> wrote:
I think username needs to be covered in the OpenID Connect spec (i.e.= Identity layer on top of OAuth). Just a hint isn=92t enough. The client ne= eds to be able to verify that the server response is what was asked, and al= so the server needs to inform the client of who logged in.

EHL



On 6/11/10 6:57 AM, "Marius Scurtescu" <mscurtescu@google.com> wrote:
There was discussion about a username hint parameter, in general this is needed when immediate is used. Should username go to this UX
Extension, or rather immediate and username should go to a separate
one together?

Marius



On Thu, Jun 10, 2010 at 5:32 PM, David Recordon <recordond@gmail.com> wrote:
> +1 for moving immediate here as well.
>
>
> On Thu, Jun 10, 2010 at 4:18 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote= :
>> Since these are all extensions to the end-user endpoint, I'd s= uggest we move the 'immediate' parameter here as well.
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0<t hangText=3D'immediate'>= ;
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<vspace />
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0OPTIONAL. The parameter value must = be set to <spanx style=3D'verb'>true</spanx> or
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<spanx style=3D'verb'>= ;false</spanx>. If set to
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<spanx style=3D'verb'>= ;true</spanx>, the authorization server MUST NOT prompt the
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0end-user to authenticate or approve= access. Instead, the authorization server
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0attempts to establish the end-user&= #39;s identity via other means (e.g. browser
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0cookies) and checks if the end-user= has previously approved an identical access
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0request by the same client and if t= hat access grant is still active. If the
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0authorization server does not suppo= rt an immediate check or if it is unable to
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0establish the end-user's identi= ty or approval status, it MUST deny the request
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0without prompting the end-user. Def= aults to <spanx style=3D'verb'>false</spanx> if
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0omitted.
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0</t>
>> EHL
>>
>>> -----Original Message-----
>>> From: David Recordon [mailto:recordond@gmail.com]
>>> Sent: Wednesday, June 09, 2010 12:06 PM
>>> To: Eran Hammer-Lahav; Allen Tom; Breno de Medeiros; Luke Shep= ard
>>> Cc: OAuth WG
>>> Subject: Re: [OAUTH-WG] A display parameter for user authoriza= tion
>>> requests
>>>
>>> First draft of the UX Extension is at
>>> http://github.com/daveman692/OAuth-2.0/ra= w/master/draft-recordon-
>>> oauth-v2-ux-00.txt.
>>>
>>> Eran, I'm more than happy to have you take over as editor.=
>>>
>>> I included Allen and Breno as authors since I followed Allen&#= 39;s suggestion and
>>> adopted the language preference parameter from the OpenID exte= nsion. I
>>> also included Luke as an author since he wrote the first pass = of a display
>>> parameter. That said, none of them have seen this draft yet. >>>
>>> --David
>>>
>>>
>>> On Tue, Apr 13, 2010 at 12:36 PM, Allen Tom <atom@yahoo-inc.com> wrote:=
>>> > At least with regards to the language preference, how abo= ut if we just
>>> > copy the openid.ui.lang parameter from the OpenID UI Exte= nsion?
>>> >
>>> > http://svn.openid.net/repos/spe= cifications/user_interface/1.0/trunk/op
>>> > enid-user-interface-extension-1_0.html#anchor3
>>> >
>>> > In flows in which the client redirects the user's web= browser to
>>> > authorize access, the client MAY send the Authorization S= erver a hint
>>> > regarding the user's preferred language by sending th= e following
>>> parameter:
>>> >
>>> > =A0=A0=A0=A0lang
>>> > =A0=A0=A0=A0=A0=A0=A0=A0The user's preferred language= s as a [BCP 47] language priority
>>> > list, represented as a comma-separated list of BCP 47 bas= ic language
>>> > ranges in decending priority order. For instance, the val= ue "fr-CA,fr-FR,en-
>>> CA"
>>> > represents the preference for French spoken in Canada, Fr= ench spoken
>>> > in France, followed by English spoken in Canada.
>>> >
>>> > The language preference hint SHOULD take precedence over = the
>>> > Accept-Language HTTP header sent by the user's browse= r, and SHOULD
>>> > take precedence over the language preference inferred by = the user's IP
>>> Address.
>>> >
>>> > BCP 47: =A0http://tools.ietf.org/html/bcp47
>>> >
>>> > Allen
>>> >
>>> >
>>> > On 4/12/10 1:32 PM, "Eran Hammer-Lahav" <eran@hueniverse.com>
>>> wrote:
>>> >
>>> > Between language preferences, display configuration, and = immediate
>>> > check, I think it might be worth to move that work to ano= ther draft.
>>> > Timeline-wise, this has the potential of slowing us down.= I also fear
>>> > getting what is now a pretty simple spec much more compli= cated.
>>> >
>>> > Anyone cares to try a first draft or outline? I can do th= e editorial
>>> > work if needed, but someone needs to write something firs= t.
>>> >
>>> > 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
h= ttps://www.ietf.org/mailman/listinfo/oauth


--000feaedf106f6f9660488e6898b-- From torsten@lodderstedt.net Sun Jun 13 05:03:26 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D6383A691B for ; Sun, 13 Jun 2010 05:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.074 X-Spam-Level: X-Spam-Status: No, score=-0.074 tagged_above=-999 required=5 tests=[AWL=-0.425, BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YzGvP0LZ7OSQ for ; Sun, 13 Jun 2010 05:03:25 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.29.23]) by core3.amsl.com (Postfix) with ESMTP id 254673A6914 for ; Sun, 13 Jun 2010 05:03:24 -0700 (PDT) Received: from p4fff3537.dip.t-dialin.net ([79.255.53.55] helo=[127.0.0.1]) by smtprelay01.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1ONluQ-0003Gw-5K; Sun, 13 Jun 2010 14:03:26 +0200 Message-ID: <4C14C90D.9050407@lodderstedt.net> Date: Sun, 13 Jun 2010 14:03:25 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF76BC@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF76BC@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Df-Sender: 141509 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Draft -07 (major rewrite) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jun 2010 12:03:26 -0000 some comments on the new draft from my side. In my opinion, the raised abstraction level makes the spec harder to read but more elegant :-) Rearranging conceptual statements and endpoint/request descriptions would probably further improve readability. For example, the end-user authorization endpoint is one of the two interfaces exposed by the OAuth authz server. Thus it's specification is very important for AS and client implementors. Why not making 4.1.1 a first level section or a second level section underneath an "endpoints" section? The same holds for §5.1. You decoupled flows (==use cases) from request types, a change a welcome very much. But why do you stick to flow types in 4.1.1? From my point of view, the parameter "type" is only used to control the way the authz server responds to the authorization request. There are currently two options: (1) verification code as URI query parameter and (2) access token as URI fragment. Why not rename "type" to "response_type" and use values like "code" and "fragment"? This would also allow to add other response types for web server clients, like "token as encrypted URI parameter". Minor notes: 1 . Introduction I would propose to extend the sentence Instead, she authenticates directly with the photo sharing service (authorization server) which issues the printing service delegation-specific credentials (token). to also mention the option of a dedicated authorization server, e.g. Instead, she authenticates directly with the photo sharing service, or an OAuth authorization server the photo sharing service trusts for that purpose, ... section 5.1.6. Status code 400 is not appropriate from my point of view for all error situations. I would propose to use 401 and 403 for unauthenticated and unauthorized requests, respectively. regards, Torsten. Am 11.06.2010 22:11, schrieb Eran Hammer-Lahav: > Draft -07 represents a major rearrangement of the document. I still have a lot of work to do but wanted to share my progress and get some general feedback. The draft includes a few normative language changes but the main focus is on the document structure and how the architecture is explained. > > Changes include: > > o Removed device profile. > o Added verification code support to user-agent flow. > o Removed multiple formats support, leaving JSON as the only format. > o Changed assertion "assertion_format" parameter to "assertion_type". > o Removed "type" parameter from token endpoint. > > The spec is now 36 pages, 19 pages shorter than -05. > > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From eran@hueniverse.com Sun Jun 13 08:18:19 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B30983A68BA for ; Sun, 13 Jun 2010 08:18:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.048 X-Spam-Level: X-Spam-Status: No, score=-3.048 tagged_above=-999 required=5 tests=[AWL=1.550, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CUOxIOQw1-PA for ; Sun, 13 Jun 2010 08:18:12 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id B01373A6947 for ; Sun, 13 Jun 2010 08:18:12 -0700 (PDT) Received: (qmail 19077 invoked from network); 13 Jun 2010 15:18:15 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 13 Jun 2010 15:18:14 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Sun, 13 Jun 2010 08:18:14 -0700 From: Eran Hammer-Lahav To: Evan Gilbert , Robert Sayre Date: Sun, 13 Jun 2010 08:18:12 -0700 Thread-Topic: [OAUTH-WG] Proposal for single JSON response format Thread-Index: AcsK3WYs+znB84DmQyGvVMurXTB4uQALai3A Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB6597@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF73EF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E11263FEC9FC@WSMSG3153V.srv.dir.telstra.com> <4A5E1C55-D589-4F25-9D45-E640BA7C833F@facebook.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_90C41DD21FB7C64BB94121FBBC2E72343B3EBB6597P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Proposal for single JSON response format X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jun 2010 15:18:19 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EBB6597P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Using JSON in the end-user authorization endpoint response is still somethi= ng we need to discuss. In the web server flow, it makes more sense to use f= orm-encoded because the URI is processed by a typical query processor (auto= matic in every web server). In the fragment, it is a question of preference= , and I was told that there are many benefits to using JSON. I think Facebo= ok uses JSON in such a way. However, there is still value in using JSON across all server responses bec= ause it allows returning the same structured data. Can you explain the XSS hole from parsing a random JSON string? If all server responses are JSON, why does the client have to do form-decod= ing? What simple model? Format isn't a model. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= van Gilbert Sent: Sunday, June 13, 2010 2:47 AM To: Robert Sayre Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Proposal for single JSON response format -1 I disagree very strongly with this approach if I'm understanding correctly.= Let me paraphrase to make sure I understand: All responses, even those encoded in a browser URL redirect back from the A= S (redirect with verification code in the web server flow and the redirect = with token in the user-agent flow) will be JSON This means that we will have a URL-encoded JSON blob as a form parameter (a= s it has to play nicely with existing URL parameters). So the response back= in the web server flow would be: https://client.com/receiveVerificationCode?existingParam=3Dvalue&oauth2= =3D%7Bcode%3A'abc123'%2C+state%3A+'randomstatedata'%7D and the response back in the user-agent flow would be https://client.com/page?existingParam=3Dvalue&oauth2=3D%7Baccess_token%3A= +'accesstoken1234'%2Cexpires_in%3A3600%2Cstate%3A'randomstatedata'%7D Reasons why this is of concern: - Requires clients to do URL decoding and JSON decoding - Encourages unsafe JSON handling in the User-Agent flow (eval(JSON) =3D XS= S hole) - Breaks the simple model we've been creating in these flows. Evan On Fri, Jun 11, 2010 at 1:51 PM, Robert Sayre > wrote: +1 On Fri, Jun 11, 2010 at 1:17 AM, Naitik Shah > wrote: > +1 > > On Thu, Jun 10, 2010 at 5:50 PM, Luke Shepard > wrote: >> >> +1 >> >> On Jun 10, 2010, at 5:46 PM, Manger, James H wrote: >> >> > +1 >> > >> > -- >> > James Manger >> > >> > ---------- >> > From: oauth-bounces@ietf.org [mailto:oa= uth-bounces@ietf.org] On Behalf >> > Of Eran Hammer-Lahav >> > Sent: Friday, 11 June 2010 6:29 AM >> > To: OAuth WG (oauth@ietf.org) >> > Subject: [OAUTH-WG] Proposal for single JSON response format >> > >> > - Support a single response format (including in the user-agent >> > fragment) using JSON. >> > _______________________________________________ >> > OAuth mailing 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 > > -- Robert Sayre "I would have written a shorter letter, but I did not have the time." _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EBB6597P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Using JSO= N in the end-user authorization endpoint response is still something we nee= d to discuss. In the web server flow, it makes more sense to use form-encod= ed because the URI is processed by a typical query processor (automatic in = every web server). In the fragment, it is a question of preference, and I w= as told that there are many benefits to using JSON. I think Facebook uses J= SON in such a way.

&n= bsp;

However, there is still va= lue in using JSON across all server responses because it allows returning t= he same structured data.

<= o:p> 

Can you explain the = XSS hole from parsing a random JSON string?

 

If all server responses are JSON, why does the client have to do form-deco= ding?

 

What simple model? Format isn’t a= model.

 <= /span>

EHL

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] = On Behalf Of Evan Gilbert
Sent: Sunday, June 13, 2010 2:47 AM=
To: Robert Sayre
Cc: OAuth WG (oauth@ietf.org)
S= ubject: Re: [OAUTH-WG] Proposal for single JSON response format

 

-1 

 

I disagree very str= ongly with this approach if I'm understanding correctly. Let me paraph= rase to make sure I understand:

 

All responses, even= those encoded in a browser URL redirect back from the AS (redirect with ve= rification code in the web server flow and the redirect with token in the u= ser-agent flow) will be JSON


This means that we will have a URL-encod= ed JSON blob as a form parameter (as it has to play nicely with existing UR= L parameters). So the response back in the web server flow would be:
  https://client.com/receiveVerifi= cationCode?existingParam=3Dvalue&oauth2=3D%7Bcode%3A'abc123'%2C+state%3= A+'randomstatedata'%7D

Reasons why this is of concern:

- Requires clients to do URL decoding and JSON dec= oding

- Encourages unsafe JSO= N handling in the User-Agent flow (eval(JSON) =3D XSS hole)

<= /div>

- Breaks the simple model we've been creatin= g in these flows.

 =

Evan

 

On Fri, Jun 11, 2010 at 1:51 PM, Robert Sayre <sayrer@gmail.com> wrote:

+1


On Fri, Jun 11, 2010 at 1:17 AM, Naitik Shah = <n@daaku.org> wr= ote:
> +1
>
> On Thu, Jun 10, 2010 at 5:50 PM, Luke Shepa= rd <lshepard@= facebook.com> wrote:
>>
>> +1
>>
>&= gt; On Jun 10, 2010, at 5:46 PM, Manger, James H wrote:
>>
>= > > +1
>> >
>> > --
>> > James Ma= nger
>> >
>> > ----------
>> > From: oauth-bounces@iet= f.org [mailto:oauth-bounces@ietf.org] On Behalf
>> > Of Eran Hammer-La= hav
>> > Sent: Friday, 11 June 2010 6:29 AM
>> > To= : OAuth WG (oauth@ietf.= org)
>> > Subject: [OAUTH-WG] Proposal for single JSON resp= onse format
>> >
>> > - Support a single response f= ormat (including in the user-agent
>> > fragment) using JSON.>> > _______________________________________________
>>= > OAuth mailing 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
>
>
=

--

Robert Sayre

"I would have written a shorter let= ter, but I did not have the time."

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

=

 

= --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EBB6597P3PW5EX1MB01E_-- From eran@hueniverse.com Sun Jun 13 08:30:25 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5E643A68D9 for ; Sun, 13 Jun 2010 08:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[AWL=-0.803, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zI38a8GZVhQ9 for ; Sun, 13 Jun 2010 08:30:14 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 9B7C83A68D0 for ; Sun, 13 Jun 2010 08:30:01 -0700 (PDT) Received: (qmail 20712 invoked from network); 13 Jun 2010 15:30:05 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 13 Jun 2010 15:30:01 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Sun, 13 Jun 2010 08:30:02 -0700 From: Eran Hammer-Lahav To: Evan Gilbert Date: Sun, 13 Jun 2010 08:30:01 -0700 Thread-Topic: [OAUTH-WG] A display parameter for user authorization requests Thread-Index: AcsK4DxW6HYvpSRXSBKS4lYrnsVDYQAK4x6w Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB6599@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_90C41DD21FB7C64BB94121FBBC2E72343B3EBB6599P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] A display parameter for user authorization requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jun 2010 15:30:25 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EBB6599P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 'username' moves OAuth into the identity realm, which is something the Open= ID Connect proposal is going to address. I don't care if the immediate mode= moves into the OpenID Connect proposal, but I am against moving username i= nto the UX draft. As for yet another draft, I am not sure what its scope wi= ll be. EHL From: Evan Gilbert [mailto:uidude@google.com] Sent: Sunday, June 13, 2010 3:07 AM To: Eran Hammer-Lahav Cc: Marius Scurtescu; recordond@gmail.com; OAuth WG Subject: Re: [OAUTH-WG] A display parameter for user authorization requests The "immediate" parameter is can have unintended consequences without some = way to attach it to an existing user. Examples here: http://trac.tools.ietf= .org/wg/oauth/trac/wiki/OAuth2UsernameParameter. I'd prefer to link these two parameters (username and immediate) in one spe= c - @David, this can be the User Experience Extension if you'd like, althou= ght my preference would probably be to move both to a separate doc. On Fri, Jun 11, 2010 at 8:09 AM, Eran Hammer-Lahav > wrote: I think username needs to be covered in the OpenID Connect spec (i.e. Ident= ity layer on top of OAuth). Just a hint isn't enough. The client needs to b= e able to verify that the server response is what was asked, and also the s= erver needs to inform the client of who logged in. EHL On 6/11/10 6:57 AM, "Marius Scurtescu" > wrote: There was discussion about a username hint parameter, in general this is needed when immediate is used. Should username go to this UX Extension, or rather immediate and username should go to a separate one together? Marius On Thu, Jun 10, 2010 at 5:32 PM, David Recordon > wrote: > +1 for moving immediate here as well. > > > On Thu, Jun 10, 2010 at 4:18 PM, Eran Hammer-Lahav > wrote: >> Since these are all extensions to the end-user endpoint, I'd suggest we = move the 'immediate' parameter here as well. >> >> >> >> OPTIONAL. The parameter value must be set to true or >> false. If set to >> true, the authorization ser= ver MUST NOT prompt the >> end-user to authenticate or approve access. Instead, the = authorization server >> attempts to establish the end-user's identity via other m= eans (e.g. browser >> cookies) and checks if the end-user has previously approv= ed an identical access >> request by the same client and if that access grant is st= ill active. If the >> authorization server does not support an immediate check = or if it is unable to >> establish the end-user's identity or approval status, it = MUST deny the request >> without prompting the end-user. Defaults to false if >> omitted. >> >> EHL >> >>> -----Original Message----- >>> From: David Recordon [mailto:recordond@gmail.com] >>> Sent: Wednesday, June 09, 2010 12:06 PM >>> To: Eran Hammer-Lahav; Allen Tom; Breno de Medeiros; Luke Shepard >>> Cc: OAuth WG >>> Subject: Re: [OAUTH-WG] A display parameter for user authorization >>> requests >>> >>> First draft of the UX Extension is at >>> http://github.com/daveman692/OAuth-2.0/raw/master/draft-recordon- >>> oauth-v2-ux-00.txt. >>> >>> Eran, I'm more than happy to have you take over as editor. >>> >>> I included Allen and Breno as authors since I followed Allen's suggesti= on and >>> adopted the language preference parameter from the OpenID extension. I >>> also included Luke as an author since he wrote the first pass of a disp= lay >>> parameter. That said, none of them have seen this draft yet. >>> >>> --David >>> >>> >>> On Tue, Apr 13, 2010 at 12:36 PM, Allen Tom > wrote: >>> > At least with regards to the language preference, how about if we jus= t >>> > copy the openid.ui.lang parameter from the OpenID UI Extension? >>> > >>> > http://svn.openid.net/repos/specifications/user_interface/1.0/trunk/o= p >>> > enid-user-interface-extension-1_0.html#anchor3 >>> > >>> > In flows in which the client redirects the user's web browser to >>> > authorize access, the client MAY send the Authorization Server a hint >>> > regarding the user's preferred language by sending the following >>> parameter: >>> > >>> > lang >>> > The user's preferred languages as a [BCP 47] language priorit= y >>> > list, represented as a comma-separated list of BCP 47 basic language >>> > ranges in decending priority order. For instance, the value "fr-CA,fr= -FR,en- >>> CA" >>> > represents the preference for French spoken in Canada, French spoken >>> > in France, followed by English spoken in Canada. >>> > >>> > The language preference hint SHOULD take precedence over the >>> > Accept-Language HTTP header sent by the user's browser, and SHOULD >>> > take precedence over the language preference inferred by the user's I= P >>> Address. >>> > >>> > BCP 47: http://tools.ietf.org/html/bcp47 >>> > >>> > Allen >>> > >>> > >>> > On 4/12/10 1:32 PM, "Eran Hammer-Lahav" > >>> wrote: >>> > >>> > Between language preferences, display configuration, and immediate >>> > check, I think it might be worth to move that work to another draft. >>> > Timeline-wise, this has the potential of slowing us down. I also fear >>> > getting what is now a pretty simple spec much more complicated. >>> > >>> > Anyone cares to try a first draft or outline? I can do the editorial >>> > work if needed, but someone needs to write something first. >>> > >>> > 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 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EBB6599P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

‘us= ername’ moves OAuth into the identity realm, which is something the O= penID Connect proposal is going to address. I don’t care if the immed= iate mode moves into the OpenID Connect proposal, but I am against moving u= sername into the UX draft. As for yet another draft, I am not sure what its= scope will be.

 = ;

EHL

 

<= p class=3DMsoNormal>From: Evan Gilbert [mailto:uidude@google.com]
Sent= : Sunday, June 13, 2010 3:07 AM
To: Eran Hammer-Lahav
C= c: Marius Scurtescu; recordond@gmail.com; OAuth WG
Subject: R= e: [OAUTH-WG] A display parameter for user authorization requests

 

The "immediate" parameter is can have unintended con= sequences without some way to attach it to an existing user. Examples here:=  http://trac.tools.ietf.org/wg/oauth/trac/wiki/OAuth2UsernamePa= rameter.

 

<= /div>

I'd prefer to link these two parameters (use= rname and immediate) in one spec - @David, this can be the User Experience = Extension if you'd like, althought my preference would probably be to move = both to a separate doc.

=  

On Fri, Jun 11, 2010 at 8:09= AM, Eran Hammer-Lahav <eran@huen= iverse.com> wrote:

I think username= needs to be covered in the OpenID Connect spec (i.e. Identity layer on top= of OAuth). Just a hint isn’t enough. The client needs to be able to = verify that the server response is what was asked, and also the server need= s to inform the client of who logged in.
<= br>EHL




On 6/11/10 6:57 AM, "Marius Scurtescu"= <mscurtescu@= google.com> wrote:

There was discussion about a username hint parameter= , in general this
is needed when immediate is used. Should username go t= o this UX
Extension, or rather immediate and username should go to a sep= arate
one together?

Marius



On Thu, Jun 10, 2010 at= 5:32 PM, David Recordon <recordond@gmail.com> wrote:
> +1 for moving immedi= ate here as well.
>
>
> On Thu, Jun 10, 2010 at 4:18 PM, = Eran Hammer-Lahav <eran@hueniverse.com> wrote:
>> Since these are all exte= nsions to the end-user endpoint, I'd suggest we move the 'immediate' parame= ter here as well.
>>
>>          = ;    <t hangText=3D'immediate'>
>>     &= nbsp;          <vspace />
>>  =              OPTIONAL. The parameter va= lue must be set to <spanx style=3D'verb'>true</spanx> or
>= ;>                <spanx styl= e=3D'verb'>false</spanx>. If set to
>>     &nbs= p;          <spanx style=3D'verb'>true</s= panx>, the authorization server MUST NOT prompt the
>>   &= nbsp;            end-user to authenticate or = approve access. Instead, the authorization server
>>    =            attempts to establish the end-use= r's identity via other means (e.g. browser
>>      =          cookies) and checks if the end-user has = previously approved an identical access
>>       &n= bsp;        request by the same client and if that acce= ss grant is still active. If the
>>         &n= bsp;      authorization server does not support an immediate= check or if it is unable to
>>          =      establish the end-user's identity or approval status, = it MUST deny the request
>>           &nb= sp;    without prompting the end-user. Defaults to <spanx styl= e=3D'verb'>false</spanx> if
>>        = ;        omitted.
>>       &nbs= p;      </t>
>> EHL
>>
>>&g= t; -----Original Message-----
>>> From: David Recordon [mailto:recordond@gmail.co= m]
>>> Sent: Wednesday, June 09, 2010 12:06 PM
>>&= gt; To: Eran Hammer-Lahav; Allen Tom; Breno de Medeiros; Luke Shepard
&g= t;>> Cc: OAuth WG
>>> Subject: Re: [OAUTH-WG] A display p= arameter for user authorization
>>> requests
>>>>>> First draft of the UX Extension is at
>>> http://github.com/daveman692/OAuth-2.0/raw/master/draft-recor= don-
>>> oauth-v2-ux-00.txt.
>>>
>>>= ; Eran, I'm more than happy to have you take over as editor.
>>>= ;
>>> I included Allen and Breno as authors since I followed Al= len's suggestion and
>>> adopted the language preference parame= ter from the OpenID extension. I
>>> also included Luke as an a= uthor since he wrote the first pass of a display
>>> parameter.= That said, none of them have seen this draft yet.
>>>
>&= gt;> --David
>>>
>>>
>>> On Tue, Apr= 13, 2010 at 12:36 PM, Allen Tom <atom@yahoo-inc.com> wrote:
>>> > At= least with regards to the language preference, how about if we just
>= ;>> > copy the openid.ui.lang parameter from the OpenID UI Extensi= on?
>>> >
>>> > htt= p://svn.openid.net/repos/specifications/user_interface/1.0/trunk/op
= >>> > enid-user-interface-extension-1_0.html#anchor3
>>= ;> >
>>> > In flows in which the client redirects the = user's web browser to
>>> > authorize access, the client MAY= send the Authorization Server a hint
>>> > regarding the us= er's preferred language by sending the following
>>> parameter:=
>>> >
>>> >     lang
= >>> >         The user'= s preferred languages as a [BCP 47] language priority
>>> > = list, represented as a comma-separated list of BCP 47 basic language
>= ;>> > ranges in decending priority order. For instance, the value = "fr-CA,fr-FR,en-
>>> CA"
>>> > represe= nts the preference for French spoken in Canada, French spoken
>>&g= t; > in France, followed by English spoken in Canada.
>>> &g= t;
>>> > The language preference hint SHOULD take precedence= over the
>>> > Accept-Language HTTP header sent by the user= 's browser, and SHOULD
>>> > take precedence over the langua= ge preference inferred by the user's IP
>>> Address.
>>= ;> >
>>> > BCP 47:  http://tools.ietf.org/html/bcp47
&= gt;>> >
>>> > Allen
>>> >
>>= ;> >
>>> > On 4/12/10 1:32 PM, "Eran Hammer-Lahav= " <eran@hu= eniverse.com>
>>> wrote:
>>> >
>>= ;> > Between language preferences, display configuration, and immedia= te
>>> > check, I think it might be worth to move that work = to another draft.
>>> > Timeline-wise, this has the potentia= l of slowing us down. I also fear
>>> > getting what is now = a pretty simple spec much more complicated.
>>> >
>>= ;> > Anyone cares to try a first draft or outline? I can do the edito= rial
>>> > work if needed, but someone needs to write someth= ing first.
>>> >
>>> > EHL
>>> &g= t;
>>> >
>>> >
>>> > _________= ______________________________________
>>> > OAuth mailing l= ist
>>> > OAuth@ietf.org
>>> > https://www.ietf.org/mailman/listi= nfo/oauth
>>> >
>>> >
>>
>= _______________________________________________
> OAuth mailing list=
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth
><= o:p>


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

 

= --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EBB6599P3PW5EX1MB01E_-- From andrewarnott@gmail.com Sun Jun 13 09:57:46 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC33F3A69BF for ; Sun, 13 Jun 2010 09:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.308 X-Spam-Level: X-Spam-Status: No, score=-0.308 tagged_above=-999 required=5 tests=[AWL=-0.124, BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BRtDm2BXa1FJ for ; Sun, 13 Jun 2010 09:57:44 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 671B43A6981 for ; Sun, 13 Jun 2010 09:57:44 -0700 (PDT) Received: by gxk8 with SMTP id 8so657397gxk.31 for ; Sun, 13 Jun 2010 09:57:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=3bvJkqpk3q/WUv41052doMpOc+LpP6sOhxAxixtli44=; b=TyPIJom8SRBK8hOPHxXA8OhVQD4J2spcLGLKJudPXyefXlA2aH1WuQPxbDyu4aHXUe K9tNeGmUN6WTb6MobGoNr27J9i9t9pIfK1fDEDjTHGUbBcWLWZozHejK8aIy6AZFUjZY P9WVdo3jDAGyT0PYZTZrEcDQfUAfCeaIVz3uo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=OJxf6uui8x9zkDmlKTpNayy7kcF6L6XR8V4T8FLa4Txlq+Khe8iuqVGFCAGsYEpcaV K2TjypXTtskvTR0jsk/14BdJh0pk64bMfZdcWb22RBf26oi/GJNCRlZv0CXw3d0jt0ji 9EZDtEDpOecBvHd1hyEEXSIEbJwtdzw1bLeLQ= MIME-Version: 1.0 Received: by 10.150.131.3 with SMTP id e3mr5581534ybd.413.1276448265054; Sun, 13 Jun 2010 09:57:45 -0700 (PDT) Received: by 10.151.26.19 with HTTP; Sun, 13 Jun 2010 09:57:45 -0700 (PDT) In-Reply-To: References: <1276290301.31840.78.camel@localhost.localdomain> Date: Sun, 13 Jun 2010 09:57:45 -0700 Message-ID: From: Andrew Arnott To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=000e0cd4ce5069ac6c0488ec45a4 Cc: OAuth WG Subject: Re: [OAUTH-WG] Draft -07 (major rewrite) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jun 2010 16:57:46 -0000 --000e0cd4ce5069ac6c0488ec45a4 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Eran, While the flows in the spec today may have unique sets of required parameters, other flows may exist with overlapping initial parameters (why? perhaps the flows have different rules that don't come into effect until later in the flow). Keeping the type parameter in there would help differentiate those. Yes, the new flows could include a type parameter while the originals did not, but then a token endpoint not prepared for the unexpected flow would mistake the new flow for the old one. -- 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 Fri, Jun 11, 2010 at 2:25 PM, Eran Hammer-Lahav wro= te: > It doesn=92t really. It is completely clear what kind of authorization > grant the client is providing simply by looking at the parameter. It migh= t > make the code a few lines longer (a few if-else instead of a switch-case) > but because these are all post parameters, you access them the same way > (i.e. this is not a case where header information is moved to post body, > etc.). > > As for the rescope and revoke operations, we still need to figure out how > to accomplish that. For example, revoking can be done using an HTTP DELET= E > operation which is more consistent with HTTP, and rescoping (which is sti= ll > tricky because scope can only be decreased) is more a function of a refre= sh > operation (asking for a new access token using a refresh token and simply > providing a new, lesser scope). > > EHL > > > > On 6/11/10 2:05 PM, "Justin Richer" wrote: > > I agree with Marius: I think we should keep the explicit flow name in > there (in the 'type' parameter or equivalent), as it (among other > things) opens the possibility for the rescope and revoke operations. It > makes it very clear how both client and server expect things to behave. > > -- Justin > > On Fri, 2010-06-11 at 16:47 -0400, Marius Scurtescu wrote: > > On Fri, Jun 11, 2010 at 1:11 PM, Eran Hammer-Lahav > wrote: > > > Draft -07 represents a major rearrangement of the document. I still > have a lot of work to do but wanted to share my progress and get some > general feedback. The draft includes a few normative language changes but > the main focus is on the document structure and how the architecture is > explained. > > > > > > Changes include: > > > > > > o Removed device profile. > > > o Added verification code support to user-agent flow. > > > o Removed multiple formats support, leaving JSON as the only forma= t. > > > o Changed assertion "assertion_format" parameter to > "assertion_type". > > > o Removed "type" parameter from token endpoint. > > > > It would be really useful if each request had a unique type, now we > > are back to guessing what is requested, like in WRAP. > > > > One small error that I noticed: section "5.1.4. Refresh Token" is not > > listing client_id and client_secret as optional parameters. > > > > In general I found previous versions much easier to read and > > understand, but maybe I just need more time... > > > > > > Marius > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --000e0cd4ce5069ac6c0488ec45a4 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Eran,

While the flows in the spec today may have unique sets of requ= ired parameters, other flows may exist with overlapping initial parameters = (why? perhaps the flows have different rules that don't come into effec= t until later in the flow).=A0 Keeping the type parameter in there would he= lp differentiate those.=A0 Yes, the new flows could include a type paramete= r while the originals did not, but then a token endpoint not prepared for t= he unexpected flow would mistake the new flow for the old one.

--
Andrew Arnott
"I [may] not agree with what = you have to say, but I'll defend to the death your right to say it.&quo= t; - S. G. Tallentyre


On Fri, Jun 11, 2010 at 2:25 PM, Eran Ha= mmer-Lahav <era= n@hueniverse.com> wrote:
It doesn=92t really. It is completely clear what kind of authorizat= ion grant the client is providing simply by looking at the parameter. It mi= ght make the code a few lines longer (a few if-else instead of a switch-cas= e) but because these are all post parameters, you access them the same way = (i.e. this is not a case where header information is moved to post body, et= c.).

As for the rescope and revoke operations, we still need to figure out how t= o accomplish that. For example, revoking can be done using an HTTP DELETE o= peration which is more consistent with HTTP, and rescoping (which is still = tricky because scope can only be decreased) is more a function of a refresh= operation (asking for a new access token using a refresh token and simply = providing a new, lesser scope).

EHL



On 6/11/10 2:05 PM, "Justin Richer" <jricher@mitre.org> wrote:

I agree with Marius: I think we should keep the explicit flow name in<= br> there (in the 'type' parameter or equivalent), as it (among other things) opens the possibility for the rescope and revoke operations. It
makes it very clear how both client and server expect things to behave.

=A0-- Justin

On Fri, 2010-06-11 at 16:47 -0400, Marius Scurtescu wrote:
> On Fri, Jun 11, 2010 at 1:11 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote= :
> > Draft -07 represents a major rearrangement of the document. I sti= ll have a lot of work to do but wanted to share my progress and get some ge= neral feedback. The draft includes a few normative language changes but the= main focus is on the document structure and how the architecture is explai= ned.
> >
> > Changes include:
> >
> > =A0=A0o =A0Removed device profile.
> > =A0=A0o =A0Added verification code support to user-agent flow. > > =A0=A0o =A0Removed multiple formats support, leaving JSON as the = only format.
> > =A0=A0o =A0Changed assertion "assertion_format" paramet= er to "assertion_type".
> > =A0=A0o =A0Removed "type" parameter from token endpoint= .
>
> It would be really useful if each request had a unique type, now we > are back to guessing what is requested, like in WRAP.
>
> One small error that I noticed: section "5.1.4. =A0Refresh Token&= quot; is not
> listing client_id and client_secret as optional parameters.
>
> In general I found previous versions much easier to read and
> understand, but maybe I just need more time...
>
>
> Marius
> _______________________________________________
> 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


--000e0cd4ce5069ac6c0488ec45a4-- From uidude@google.com Sun Jun 13 11:20:42 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD52C3A6925 for ; Sun, 13 Jun 2010 11:20:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.092 X-Spam-Level: X-Spam-Status: No, score=-107.092 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xq1tzQW6MDCX for ; Sun, 13 Jun 2010 11:20:41 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 8DA073A6948 for ; Sun, 13 Jun 2010 11:20:40 -0700 (PDT) Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id o5DIKcLK017578 for ; Sun, 13 Jun 2010 11:20:38 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1276453239; bh=lybKn8tle8KXocBNIeLRRUkggwI=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=tr8Wdd8BSRXKf0BpVhCVTxqwQ9l9ecKOhx6Vnj4l6pxHt1jUxReLkosR0M0mkbRPv H/vzqBsJgrVKnxGVDvg7A== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type; b=hafAwnyDjVS7vVf75T7wqDtd1mZ7JejXjEaihT8rlD5JauaNLFTYpKPXd9o9blSov u+17NmJQc4L/YzZvrNNbw== Received: from qyk38 (qyk38.prod.google.com [10.241.83.166]) by wpaz24.hot.corp.google.com with ESMTP id o5DIKbCJ032126 for ; Sun, 13 Jun 2010 11:20:38 -0700 Received: by qyk38 with SMTP id 38so356692qyk.35 for ; Sun, 13 Jun 2010 11:20:37 -0700 (PDT) Received: by 10.224.79.209 with SMTP id q17mr1542044qak.340.1276453237433; Sun, 13 Jun 2010 11:20:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.106.204 with HTTP; Sun, 13 Jun 2010 11:20:17 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB6597@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF73EF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E11263FEC9FC@WSMSG3153V.srv.dir.telstra.com> <4A5E1C55-D589-4F25-9D45-E640BA7C833F@facebook.com> <90C41DD21FB7C64BB94121FBBC2E72343B3EBB6597@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Evan Gilbert Date: Sun, 13 Jun 2010 11:20:17 -0700 Message-ID: To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=00c09fa21c39ca26ee0488ed6dda Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Proposal for single JSON response format X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jun 2010 18:20:43 -0000 --00c09fa21c39ca26ee0488ed6dda Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Sun, Jun 13, 2010 at 8:18 AM, Eran Hammer-Lahav wro= te: > Using JSON in the end-user authorization endpoint response is still > something we need to discuss. In the web server flow, it makes more sense= to > use form-encoded because the URI is processed by a typical query processo= r > (automatic in every web server). In the fragment, it is a question of > preference, and I was told that there are many benefits to using JSON. I > think Facebook uses JSON in such a way. > > > > However, there is still value in using JSON across all server responses > because it allows returning the same structured data. > > > > Can you explain the XSS hole from parsing a random JSON string? > Naive processor calls: var href =3D document.location.href; var jsonBlob =3D href.substring(href.indexOf('#'), href.length) var userData =3D eval(jsonBlob); This code would allow executing arbitrary code by sending a user a link, which could, for example, steal your cookies on a site. The fix is just a really complicated RegEx match - here is sample codefrom Shindig that does this correctly - but I would worry that implementers would do the simple thing and just eval the JSON. It also seems like a sign of a design issue if the spec requires this regex. > > If all server responses are JSON, why does the client have to do > form-decoding? > Redirect_uri needs to be put into a URL somehow, and the URL may have other query parameters or other content in the fragment. I'm making the assumptio= n that we would put this into a query parameter - otherwise we need to specif= y ourselves how to encode the JSON to be URL-safe and not conflict with other parameters. > > > What simple model? Format isn=92t a model. > Sorry, the statement about "simple model" wasn't that helpful without context. Here's the context: - We currently have listed 4 named parameters that may be returned. - Using query parameters is an obvious / clear way to return these parameters when encoded in a URL (in the fragment, a common practice is = to use the same query parameter format, but after the hash). - All modern coding environments I know of can pull out simple key / value pairs encoded in URL parameters. Issues I've heard with URL parame= ters are all around: 1. Canonicalization of parameters for signing, and 2. Parameters that are not simple key/value pairs (i.e. how do you encode a linefeed. - The data returned on a URL should probably *not* be the same as what you would return on the server. This is because the data is untrusted - evildoers can construct a URL with the wrong JSON data. So my preference would be to leave the redirect URI as simple key/value pairs and actively try to discourage adding structured / complex content. W= e can use a followup call to the AS with the access token on the server side for complex data, and JSON is the right response format for this followup call. > > > EHL > > > > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf > Of *Evan Gilbert > *Sent:* Sunday, June 13, 2010 2:47 AM > *To:* Robert Sayre > *Cc:* OAuth WG (oauth@ietf.org) > *Subject:* Re: [OAUTH-WG] Proposal for single JSON response format > > > > -1 > > > > I disagree very strongly with this approach if I'm understanding > correctly. Let me paraphrase to make sure I understand: > > > > All responses, even those encoded in a browser URL redirect back from the > AS (redirect with verification code in the web server flow and the redire= ct > with token in the user-agent flow) will be JSON > > > This means that we will have a URL-encoded JSON blob as a form parameter > (as it has to play nicely with existing URL parameters). So the response > back in the web server flow would be: > > https://client.com/receiveVerificationCode?existingParam=3Dvalue&oauth2= =3D%7Bcode%3A'abc123'%2C+state%3A+'randomstatedata'%7D > > and the response back in the user-agent flow would be > > https://client.com/page?existingParam=3Dvalue&oauth2=3D%7Baccess_token%3A= +'accesstoken1234'%2Cexpires_in%3A3600%2Cstate%3A'randomstatedata'%7D > > > > Reasons why this is of concern: > > - Requires clients to do URL decoding *and* JSON decoding > > - Encourages unsafe JSON handling in the User-Agent flow (eval(JSON) =3D = XSS > hole) > > - Breaks the simple model we've been creating in these flows. > > > > Evan > > > > On Fri, Jun 11, 2010 at 1:51 PM, Robert Sayre wrote: > > +1 > > > On Fri, Jun 11, 2010 at 1:17 AM, Naitik Shah wrote: > > +1 > > > > On Thu, Jun 10, 2010 at 5:50 PM, Luke Shepard > wrote: > >> > >> +1 > >> > >> On Jun 10, 2010, at 5:46 PM, Manger, James H wrote: > >> > >> > +1 > >> > > >> > -- > >> > James Manger > >> > > >> > ---------- > >> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > Behalf > >> > Of Eran Hammer-Lahav > >> > Sent: Friday, 11 June 2010 6:29 AM > >> > To: OAuth WG (oauth@ietf.org) > >> > Subject: [OAUTH-WG] Proposal for single JSON response format > >> > > >> > - Support a single response format (including in the user-agent > >> > fragment) using JSON. > >> > _______________________________________________ > >> > OAuth mailing 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 > > > > > > > -- > > Robert Sayre > > "I would have written a shorter letter, but I did not have the time." > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --00c09fa21c39ca26ee0488ed6dda Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On Sun, Jun 13, 2010 at 8:18 AM, Eran Ha= mmer-Lahav <eran@hueniverse.com> wrote:

Using JSON in the end-us= er authorization endpoint response is still something we need to discuss. I= n the web server flow, it makes more sense to use form-encoded because the = URI is processed by a typical query processor (automatic in every web serve= r). In the fragment, it is a question of preference, and I was told that th= ere are many benefits to using JSON. I think Facebook uses JSON in such a w= ay.

=A0

However, there is still value in using JSON across all server responses= because it allows returning the same structured data.

=A0

Can you explain the XSS hole from parsing a random JSON string?<= /p>


Naive processor calls:
var href =3D document.location= .href;
var= jsonBlob =3D href.substring(href.indexOf('#'), href.length)=
var userData =A0=3D ev= al(jsonBlob);

This code would allow executi= ng arbitrary code by sending a user a link, which could, for example, steal= your cookies on a site.

The fix is just a really complicated RegEx match - here= is sample code from Shindig th= at does this correctly - but I would worry that implementers would do the s= imple thing and just eval the JSON. It also seems like a sign of a design i= ssue if the spec requires this regex.

=A0

If al= l server responses are JSON, why does the client have to do form-decoding?<= /span>


Redirect_uri needs t= o be put into a URL somehow, and the URL may have other query parameters or= other content in the fragment. I'm making the assumption that we would= put this into a query parameter - otherwise we need to specify ourselves h= ow to encode the JSON to be URL-safe and not conflict with other parameters= .

=A0

What = simple model? Format isn=92t a model.

Sorry, the statement about "simple model" wasn't that help= ful without context. Here's the context:
  • We currently have listed 4 named parameters that may be return= ed.
  • Using query parameters is an obvious / clear way to return thes= e parameters when encoded in a URL (in the fragment, a common practice is t= o use the same query parameter format, but after the hash).
  • All modern coding environments I know of can=A0pull out simple key / va= lue pairs encoded in=A0URL parameters. Issues I've heard with URL param= eters are all around:
    1. Canonicalization of parameters for signin= g, and
    2. Parameters that are not simple key/value pairs (i.e. how do you encode = a linefeed.
  • The data returned on a URL should probably *not* b= e the same as what you would return on the server. This is because the data= is untrusted - evildoers can construct a URL with the wrong JSON data.
So my preference would be to leave the redirect URI as simple key= /value pairs and actively try to discourage adding structured / complex con= tent.=A0We can use a followup call to the AS with the access token on the s= erver side for complex data, and JSON is the right response format for this= followup call.

=A0

EHL

=A0

From:= oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Be= half Of Evan Gilbert
Sent: Sunday, June 13, 2010 2:47 AM
To: Robert Sayre
Cc: OAuth WG (oaut= h@ietf.org)
Subject: Re: [OAUTH-WG] Proposal for single JSON = response format

=A0

-1=A0

=A0

I disagree very strongly with this approach if= I'm understanding correctly.=A0Let me paraphrase to make sure I unders= tand:

=A0

= All responses, even those encoded in a browser URL redirect back from the A= S (redirect with verification code in the web server flow and the redirect = with token in the user-agent flow) will be JSON


This m= eans that we will have a URL-encoded JSON blob as a form parameter (as it h= as to play nicely with existing URL parameters). So the response back in th= e web server flow would be:
=A0=A0https://client.com/receiveVerificationCode?existingParam=3Dvalue&a= mp;oauth2=3D%7Bcode%3A'abc123'%2C+state%3A+'randomstatedata'= ;%7D

and the response back in the user-agent f= low would be
=A0=A0<= a href=3D"https://client.com/page?existingParam=3Dvalue&oauth2=3D%7Bacc= ess_token%3A+'accesstoken1234'%2Cexpires_in%3A3600%2Cstate%3A'r= andomstatedata'%7D" target=3D"_blank">https://client.com/page?existingP= aram=3Dvalue&oauth2=3D%7Baccess_token%3A+'accesstoken1234'%2Cex= pires_in%3A3600%2Cstate%3A'randomstatedata'%7D

=A0

= Reasons why this is of concern:

- Requ= ires clients to do URL decoding and=A0JSON decoding

- Encourages unsafe JSON handling in the User-Agent flow (eval(JSON) =3D XS= S hole)

- Breaks the simple model we&#= 39;ve been creating in these flows.

= =A0

Evan

=A0

On Fri, Jun 11, 2010 at= 1:51 PM, Robert Sayre <sayrer@gmail.com> wrote:

+1


On Fri, Jun 11, 2010 at 1:17 AM, Naitik Shah <n@daaku.org> wrote:
>= ; +1
>
> On Thu, Jun 10, 2010 at 5:50 PM, Luke Shepard <lshepard@facebook.com>= ; wrote:
>>
>> +1
>>
>> On Jun 10, 2010= , at 5:46 PM, Manger, James H wrote:
>>
>> > +1
>> >
>> > --
>&g= t; > James Manger
>> >
>> > ----------
>&g= t; > From: o= auth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
>> > Of Eran Hammer-Lahav
>> > Sent: Friday, 11 June 2= 010 6:29 AM
>> > To: OAuth WG (oauth@ietf.org)
>> > Subject: [OAUTH-WG= ] Proposal for single JSON response format
>> >
>> > - Support a single response format (includin= g in the user-agent
>> > fragment) using JSON.
>> >= _______________________________________________
>> > OAuth mai= ling list
>> > OAuth@iet= f.org
>> > https://www.ietf.org/mailman/listinfo/oauth>>
>> _______________________________________________
>> OAuth = mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth=
>
>
> _______________________________________________
>= ; OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth=
>
>


--

Robert Sayre

"I would have written a shor= ter letter, but I did not have the time."

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

=A0


--00c09fa21c39ca26ee0488ed6dda-- From dick.hardt@gmail.com Sun Jun 13 17:23:52 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8351528C0E4 for ; Sun, 13 Jun 2010 17:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.816 X-Spam-Level: X-Spam-Status: No, score=-1.816 tagged_above=-999 required=5 tests=[AWL=-0.102, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MHli-R00NeK7 for ; Sun, 13 Jun 2010 17:23:51 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id A6DD428C0E1 for ; Sun, 13 Jun 2010 17:23:51 -0700 (PDT) Received: by pwi8 with SMTP id 8so2643036pwi.31 for ; Sun, 13 Jun 2010 17:23:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:message-id:references:to :x-mailer; bh=dmpCxzGIgdBh4Knx8IOmYRgO18LgDT/i3rgRHa1Dn0c=; b=cJWyf7uAaJclUoneaKVM7dlM3eA0mzEykPYf5fdIBuJ6fLjIZjNlQYTfOQlgWDb7wW FGVfLKfzN9DMY3Oj9DG6PYFrF0ZqWibAnnsOEFevXbXBOvalE4BsVyCGNfxUHj2amqwI oUBCcrSu58QVaP2wCRkd1GVYtiVERyxnvck2c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; b=ELdIYASWk760hHXHNGUSIlsY6x0gm0lB6SOWfmrgWFI7Ggl2dHajpWDAI3t+bXFY0L T4d3ZOxMVD5kTVpP7Qv+wQUcFbijN6rdZdy8sCDh9YKX4a3gUFZokRzUelZsg9O2SXKC 9BFPht+hxnGU/6chFx2SDs1piwcOaPwqAZYvs= Received: by 10.142.74.19 with SMTP id w19mr3442874wfa.20.1276475030562; Sun, 13 Jun 2010 17:23:50 -0700 (PDT) Received: from [192.168.1.5] ([24.130.32.55]) by mx.google.com with ESMTPS id n29sm47769684wae.16.2010.06.13.17.23.49 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 13 Jun 2010 17:23:50 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/alternative; boundary=Apple-Mail-1--332398468 From: Dick Hardt In-Reply-To: Date: Sun, 13 Jun 2010 17:23:48 -0700 Message-Id: <1D91AEDD-E5E6-4401-8C76-53E178595AE2@gmail.com> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF73EF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E11263FEC9FC@WSMSG3153V.srv.dir.telstra.com> <4A5E1C55-D589-4F25-9D45-E640BA7C833F@facebook.com> <90C41DD21FB7C64BB94121FBBC2E72343B3EBB6597@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Evan Gilbert X-Mailer: Apple Mail (2.1078) Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Proposal for single JSON response format X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2010 00:23:52 -0000 --Apple-Mail-1--332398468 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2010-06-13, at 11:20 AM, Evan Gilbert wrote: >=20 >=20 > On Sun, Jun 13, 2010 at 8:18 AM, Eran Hammer-Lahav = wrote: > Using JSON in the end-user authorization endpoint response is still = something we need to discuss. In the web server flow, it makes more = sense to use form-encoded because the URI is processed by a typical = query processor (automatic in every web server). In the fragment, it is = a question of preference, and I was told that there are many benefits to = using JSON. I think Facebook uses JSON in such a way. >=20 > =20 > However, there is still value in using JSON across all server = responses because it allows returning the same structured data. >=20 > =20 > Can you explain the XSS hole from parsing a random JSON string? >=20 >=20 > Naive processor calls: > var href =3D document.location.href; > var jsonBlob =3D href.substring(href.indexOf('#'), href.length) > var userData =3D eval(jsonBlob); >=20 > This code would allow executing arbitrary code by sending a user a = link, which could, for example, steal your cookies on a site. >=20 > The fix is just a really complicated RegEx match - here is sample code = from Shindig that does this correctly - but I would worry that = implementers would do the simple thing and just eval the JSON. It also = seems like a sign of a design issue if the spec requires this regex. If a response from the AS is untrusted, there are much bigger issues at = stake. ... or am I missing an obvious attack where random JSON would get = sent to the Client? -- Dick= --Apple-Mail-1--332398468 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii


On Sun, Jun 13, 2010 at 8:18 AM, Eran = Hammer-Lahav <eran@hueniverse.com> wrote:

Using JSON in the end-user = authorization endpoint response is still something we need to discuss. = In the web server flow, it makes more sense to use form-encoded because = the URI is processed by a typical query processor (automatic in every = web server). In the fragment, it is a question of preference, and I was = told that there are many benefits to using JSON. I think Facebook uses = JSON in such a way.

 

However, there is = still value in using JSON across all server responses because it allows = returning the same structured data.

 

Can you explain the = XSS hole from parsing a random JSON = string?


Naive = processor calls:
var = href =3D document.location.href;
var jsonBlob =3D href.substring(href.indexOf('#'), = href.length)
var userData  =3D = eval(jsonBlob);

This code would allow = executing arbitrary code by sending a user a link, which could, for = example, steal your cookies on a site.

The fix = is just a really complicated RegEx match - here is sample code from Shindig that does this = correctly - but I would worry that implementers would do the simple = thing and just eval the JSON. It also seems like a sign of a design = issue if the spec requires this = regex.

If a response from = the AS is untrusted, there are much bigger issues at stake. ... or am I = missing an obvious attack where random JSON would get sent to the = Client?

-- Dick
= --Apple-Mail-1--332398468-- From eran@hueniverse.com Sun Jun 13 17:52:46 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28C403A6987 for ; Sun, 13 Jun 2010 17:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.075 X-Spam-Level: X-Spam-Status: No, score=-2.075 tagged_above=-999 required=5 tests=[AWL=0.523, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TnLRPVSOV8bQ for ; Sun, 13 Jun 2010 17:52:39 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 9AA0D3A67AF for ; Sun, 13 Jun 2010 17:52:39 -0700 (PDT) Received: (qmail 25146 invoked from network); 14 Jun 2010 00:52:42 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 14 Jun 2010 00:52:41 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sun, 13 Jun 2010 17:52:35 -0700 From: Eran Hammer-Lahav To: Andrew Arnott Date: Sun, 13 Jun 2010 17:52:36 -0700 Thread-Topic: [OAUTH-WG] Draft -07 (major rewrite) Thread-Index: AcsLGYxsPl0rq3ViRA2tZ2LOAMdeGQAQfFww Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB65AC@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <1276290301.31840.78.camel@localhost.localdomain> 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_90C41DD21FB7C64BB94121FBBC2E72343B3EBB65ACP3PW5EX1MB01E_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Draft -07 (major rewrite) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2010 00:52:46 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EBB65ACP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I would argue that if a new flow doesn't fit into the existing framework, i= t should define a new endpoint. For example, the device flow doesn't fit wi= th the 2 endpoints model since the first call is really an half-authorizati= on with a custom URI returned. The second flow uses a verification code. The problem with the type parameter is that is break the clean abstraction = because it allows turning the endpoint into anything really. I rather make = it less appealing. Note that the new model unifies the refresh token flow w= ith other types of authorization grants. I think that shows how well this a= bstraction works. A type parameter is nothing but a duplication of the information sent. EHL From: Andrew Arnott [mailto:andrewarnott@gmail.com] Sent: Sunday, June 13, 2010 9:58 AM To: Eran Hammer-Lahav Cc: Justin Richer; Marius Scurtescu; OAuth WG Subject: Re: [OAUTH-WG] Draft -07 (major rewrite) Eran, While the flows in the spec today may have unique sets of required paramete= rs, other flows may exist with overlapping initial parameters (why? perhaps= the flows have different rules that don't come into effect until later in = the flow). Keeping the type parameter in there would help differentiate th= ose. Yes, the new flows could include a type parameter while the originals= did not, but then a token endpoint not prepared for the unexpected flow wo= uld mistake the new flow for the old one. -- 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 Fri, Jun 11, 2010 at 2:25 PM, Eran Hammer-Lahav > wrote: It doesn't really. It is completely clear what kind of authorization grant = the client is providing simply by looking at the parameter. It might make t= he code a few lines longer (a few if-else instead of a switch-case) but bec= ause these are all post parameters, you access them the same way (i.e. this= is not a case where header information is moved to post body, etc.). As for the rescope and revoke operations, we still need to figure out how t= o accomplish that. For example, revoking can be done using an HTTP DELETE o= peration which is more consistent with HTTP, and rescoping (which is still = tricky because scope can only be decreased) is more a function of a refresh= operation (asking for a new access token using a refresh token and simply = providing a new, lesser scope). EHL On 6/11/10 2:05 PM, "Justin Richer" > wrote: I agree with Marius: I think we should keep the explicit flow name in there (in the 'type' parameter or equivalent), as it (among other things) opens the possibility for the rescope and revoke operations. It makes it very clear how both client and server expect things to behave. -- Justin On Fri, 2010-06-11 at 16:47 -0400, Marius Scurtescu wrote: > On Fri, Jun 11, 2010 at 1:11 PM, Eran Hammer-Lahav > wrote: > > Draft -07 represents a major rearrangement of the document. I still hav= e a lot of work to do but wanted to share my progress and get some general = feedback. The draft includes a few normative language changes but the main = focus is on the document structure and how the architecture is explained. > > > > Changes include: > > > > o Removed device profile. > > o Added verification code support to user-agent flow. > > o Removed multiple formats support, leaving JSON as the only format. > > o Changed assertion "assertion_format" parameter to "assertion_type"= . > > o Removed "type" parameter from token endpoint. > > It would be really useful if each request had a unique type, now we > are back to guessing what is requested, like in WRAP. > > One small error that I noticed: section "5.1.4. Refresh Token" is not > listing client_id and client_secret as optional parameters. > > In general I found previous versions much easier to read and > understand, but maybe I just need more time... > > > Marius > _______________________________________________ > OAuth mailing 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_90C41DD21FB7C64BB94121FBBC2E72343B3EBB65ACP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I would a= rgue that if a new flow doesn’t fit into the existing framework, it s= hould define a new endpoint. For example, the device flow doesn’t fit= with the 2 endpoints model since the first call is really an half-authoriz= ation with a custom URI returned. The second flow uses a verification code.=

 <= /p>

The problem with the type parameter is that = is break the clean abstraction because it allows turning the endpoint into = anything really. I rather make it less appealing. Note that the new model u= nifies the refresh token flow with other types of authorization grants. I t= hink that shows how well this abstraction works.

 

A type parameter is nothing but a duplication of the information sent.<= o:p>

 

EHL

 

Fr= om: Andrew Arnott [mailto:andrewarnott@gmail.com]
Sent: Sunda= y, June 13, 2010 9:58 AM
To: Eran Hammer-Lahav
Cc: Just= in Richer; Marius Scurtescu; OAuth WG
Subject: Re: [OAUTH-WG] Dra= ft -07 (major rewrite)

 

= Eran,

While the flows in the spec today may have unique sets of requ= ired parameters, other flows may exist with overlapping initial parameters = (why? perhaps the flows have different rules that don't come into effect un= til later in the flow).  Keeping the type parameter in there would hel= p differentiate those.  Yes, the new flows could include a type parame= ter while the originals did not, but then a token endpoint not prepared for= the unexpected flow would mistake the new flow for the old one.

--
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. Ta= llentyre

On Fri, Jun 11, 20= 10 at 2:25 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

It doe= sn’t really. It is completely clear what kind of authorization grant = the client is providing simply by looking at the parameter. It might make t= he code a few lines longer (a few if-else instead of a switch-case) but bec= ause these are all post parameters, you access them the same way (i.e. this= is not a case where header information is moved to post body, etc.).
As for the rescope and revoke operations, we still need to figure out how= to accomplish that. For example, revoking can be done using an HTTP DELETE= operation which is more consistent with HTTP, and rescoping (which is stil= l tricky because scope can only be decreased) is more a function of a refre= sh operation (asking for a new access token using a refresh token and simpl= y providing a new, lesser scope).

EHL<= /span>




On 6/11/10 2:05 PM, "Justin Richer" <jricher@mitre.org>= wrote:

I agree with Marius: I think we should keep the explicit flow name in<= br>there (in the 'type' parameter or equivalent), as it (among other
thi= ngs) opens the possibility for the rescope and revoke operations. It
mak= es it very clear how both client and server expect things to behave.
 -- Justin

On Fri, 2010-06-11 at 16:47 -0400, Marius Scurtescu= wrote:
> On Fri, Jun 11, 2010 at 1:11 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
> > Draft -07 represents a major rearrangement of the= document. I still have a lot of work to do but wanted to share my progress= and get some general feedback. The draft includes a few normative language= changes but the main focus is on the document structure and how the archit= ecture is explained.
> >
> > Changes include:
> >= ;
> >   o  Removed device profile.
> > &nb= sp; o  Added verification code support to user-agent flow.
>= ; >   o  Removed multiple formats support, leaving JSON a= s the only format.
> >   o  Changed assertion "= ;assertion_format" parameter to "assertion_type".
> &g= t;   o  Removed "type" parameter from token endpoi= nt.
>
> It would be really useful if each request had a unique = type, now we
> are back to guessing what is requested, like in WRAP.<= br>>
> One small error that I noticed: section "5.1.4.  = Refresh Token" is not
> listing client_id and client_secret as o= ptional parameters.
>
> In general I found previous versions mu= ch easier to read and
> understand, but maybe I just need more time..= .
>
>
> Marius
> __________________________________= _____________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/ma= ilman/listinfo/oauth



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

 

= --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EBB65ACP3PW5EX1MB01E_-- From eran@hueniverse.com Sun Jun 13 17:55:45 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D085E28C0E1 for ; Sun, 13 Jun 2010 17:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.091 X-Spam-Level: X-Spam-Status: No, score=-3.091 tagged_above=-999 required=5 tests=[AWL=1.507, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id amVdQpmYk5WJ for ; Sun, 13 Jun 2010 17:55:36 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 4F62F3A67AF for ; Sun, 13 Jun 2010 17:55:36 -0700 (PDT) Received: (qmail 28680 invoked from network); 14 Jun 2010 00:55:39 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 14 Jun 2010 00:55:38 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Sun, 13 Jun 2010 17:55:39 -0700 From: Eran Hammer-Lahav To: Evan Gilbert Date: Sun, 13 Jun 2010 17:55:39 -0700 Thread-Topic: [OAUTH-WG] Proposal for single JSON response format Thread-Index: AcsLJSMiWhQ1c17GQEuK50wBV4cwxAANx23g Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB65AD@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF73EF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E11263FEC9FC@WSMSG3153V.srv.dir.telstra.com> <4A5E1C55-D589-4F25-9D45-E640BA7C833F@facebook.com> <90C41DD21FB7C64BB94121FBBC2E72343B3EBB6597@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_90C41DD21FB7C64BB94121FBBC2E72343B3EBB65ADP3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Proposal for single JSON response format X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2010 00:55:45 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EBB65ADP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable To be clear, you are +1 on using only JSON for server responses on the toke= n endpoint? EHL From: Evan Gilbert [mailto:uidude@google.com] Sent: Sunday, June 13, 2010 11:20 AM To: Eran Hammer-Lahav Cc: Robert Sayre; OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Proposal for single JSON response format On Sun, Jun 13, 2010 at 8:18 AM, Eran Hammer-Lahav > wrote: Using JSON in the end-user authorization endpoint response is still somethi= ng we need to discuss. In the web server flow, it makes more sense to use f= orm-encoded because the URI is processed by a typical query processor (auto= matic in every web server). In the fragment, it is a question of preference= , and I was told that there are many benefits to using JSON. I think Facebo= ok uses JSON in such a way. However, there is still value in using JSON across all server responses bec= ause it allows returning the same structured data. Can you explain the XSS hole from parsing a random JSON string? Naive processor calls: var href =3D document.location.href; var jsonBlob =3D href.substring(href.indexOf('#'), href.length) var userData =3D eval(jsonBlob); This code would allow executing arbitrary code by sending a user a link, wh= ich could, for example, steal your cookies on a site. The fix is just a really complicated RegEx match - here is sample code from Shindig = that does this correctly - but I would worry that implementers would do the= simple thing and just eval the JSON. It also seems like a sign of a design= issue if the spec requires this regex. If all server responses are JSON, why does the client have to do form-decod= ing? Redirect_uri needs to be put into a URL somehow, and the URL may have other= query parameters or other content in the fragment. I'm making the assumpti= on that we would put this into a query parameter - otherwise we need to spe= cify ourselves how to encode the JSON to be URL-safe and not conflict with = other parameters. What simple model? Format isn't a model. Sorry, the statement about "simple model" wasn't that helpful without conte= xt. Here's the context: * We currently have listed 4 named parameters that may be returned. * Using query parameters is an obvious / clear way to return these param= eters when encoded in a URL (in the fragment, a common practice is to use t= he same query parameter format, but after the hash). * All modern coding environments I know of can pull out simple key / val= ue pairs encoded in URL parameters. Issues I've heard with URL parameters a= re all around: * Canonicalization of parameters for signing, and * Parameters that are not simple key/value pairs (i.e. how do you enc= ode a linefeed. * The data returned on a URL should probably *not* be the same as what y= ou would return on the server. This is because the data is untrusted - evil= doers can construct a URL with the wrong JSON data. So my preference would be to leave the redirect URI as simple key/value pai= rs and actively try to discourage adding structured / complex content. We c= an use a followup call to the AS with the access token on the server side f= or complex data, and JSON is the right response format for this followup ca= ll. EHL From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Evan Gilbert Sent: Sunday, June 13, 2010 2:47 AM To: Robert Sayre Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Proposal for single JSON response format -1 I disagree very strongly with this approach if I'm understanding correctly.= Let me paraphrase to make sure I understand: All responses, even those encoded in a browser URL redirect back from the A= S (redirect with verification code in the web server flow and the redirect = with token in the user-agent flow) will be JSON This means that we will have a URL-encoded JSON blob as a form parameter (a= s it has to play nicely with existing URL parameters). So the response back= in the web server flow would be: https://client.com/receiveVerificationCode?existingParam=3Dvalue&oauth2= =3D%7Bcode%3A'abc123'%2C+state%3A+'randomstatedata'%7D and the response back in the user-agent flow would be https://client.com/page?existingParam=3Dvalue&oauth2=3D%7Baccess_token%3A= +'accesstoken1234'%2Cexpires_in%3A3600%2Cstate%3A'randomstatedata'%7D Reasons why this is of concern: - Requires clients to do URL decoding and JSON decoding - Encourages unsafe JSON handling in the User-Agent flow (eval(JSON) =3D XS= S hole) - Breaks the simple model we've been creating in these flows. Evan On Fri, Jun 11, 2010 at 1:51 PM, Robert Sayre > wrote: +1 On Fri, Jun 11, 2010 at 1:17 AM, Naitik Shah > wrote: > +1 > > On Thu, Jun 10, 2010 at 5:50 PM, Luke Shepard > wrote: >> >> +1 >> >> On Jun 10, 2010, at 5:46 PM, Manger, James H wrote: >> >> > +1 >> > >> > -- >> > James Manger >> > >> > ---------- >> > From: oauth-bounces@ietf.org [mailto:oa= uth-bounces@ietf.org] On Behalf >> > Of Eran Hammer-Lahav >> > Sent: Friday, 11 June 2010 6:29 AM >> > To: OAuth WG (oauth@ietf.org) >> > Subject: [OAUTH-WG] Proposal for single JSON response format >> > >> > - Support a single response format (including in the user-agent >> > fragment) using JSON. >> > _______________________________________________ >> > OAuth mailing 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 > > -- Robert Sayre "I would have written a shorter letter, but I did not have the time." _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EBB65ADP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

To be cle= ar, you are +1 on using only JSON for server responses on the token endpoin= t?

 

EHL

 

From: Evan Gilbert [mailto:uidude@google.com]
Sent: Sunday, = June 13, 2010 11:20 AM
To: Eran Hammer-Lahav
Cc: Robert= Sayre; OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Proposa= l for single JSON response format

 

 

On Sun, Jun 13, 2= 010 at 8:18 AM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

<= div>

Using JSON in the= end-user authorization endpoint response is still something we need to dis= cuss. In the web server flow, it makes more sense to use form-encoded becau= se the URI is processed by a typical query processor (automatic in every we= b server). In the fragment, it is a question of preference, and I was told = that there are many benefits to using JSON. I think Facebook uses JSON in s= uch a way.

 

However, there is still value in using JSON across all se= rver responses because it allows returning the same structured data.=

 =

Can you explain the XSS hole from parsing a random JSON string?

 

Naive processor calls:

=

var href =3D= document.location.href;

var jsonBlob =3D href.substrin= g(href.indexOf('#'), href.length)

var userData  = =3D eval(jsonBlob);

 

This code would allow ex= ecuting arbitrary code by sending a user a link, which could, for example, = steal your cookies on a site.

 

The fix is just a rea= lly complicated RegEx match - here is sample code from Shindig that does this correctly - but I would worr= y that implementers would do the simple thing and just eval the JSON. It al= so seems like a sign of a design issue if the spec requires this regex.

 

 

If all server responses are JSON= , why does the client have to do form-decoding?

=

 

Redirect_uri needs to be put into a URL somehow, and= the URL may have other query parameters or other content in the fragment. = I'm making the assumption that we would put this into a query parameter - o= therwise we need to specify ourselves how to encode the JSON to be URL-safe= and not conflict with other parameters.

 

What simple model? Format isn’t a= model.

Sorry, the statement about "simple model" wasn't that helpfu= l without context. Here's the context:

  • We currently have listed 4 named param= eters that may be returned.
  • = Using query parameters is an obvious / clear way to return these parameters= when encoded in a URL (in the fragment, a common practice is to use the sa= me query parameter format, but after the hash).
  • All modern coding environments I know of can pull = out simple key / value pairs encoded in URL parameters. Issues I've he= ard with URL parameters are all around:
    1. Canonicalization of= parameters for signing, and
    2. Parameters that are not simple key/value pairs (i.e. how do you encode a l= inefeed.
  • The data returned on a URL should probably *not* be the same as what= you would return on the server. This is because the data is untrusted - ev= ildoers can construct a URL with the wrong JSON data.
<= div>

So my preference would be to leave the redirect UR= I as simple key/value pairs and actively try to discourage adding structure= d / complex content. We can use a followup call to the AS with the acc= ess token on the server side for complex data, and JSON is the right respon= se format for this followup call.

 

EHL

 

=

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Beha= lf Of Evan Gilbert
Sent: Sunday, June 13, 2010 2:47 AM
= To: Robert Sayre
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG]= Proposal for single JSON response format

=

 

-1 

 

I disagree very = strongly with this approach if I'm understanding correctly. Let me par= aphrase to make sure I understand:

 

All responses, even those encoded in a brows= er URL redirect back from the AS (redirect with verification code in the we= b server flow and the redirect with token in the user-agent flow) will be J= SON


This means that we will have a URL-encode= d JSON blob as a form parameter (as it has to play nicely with existing URL= parameters). So the response back in the web server flow would be:
  https://client.= com/receiveVerificationCode?existingParam=3Dvalue&oauth2=3D%7Bcode%3A'a= bc123'%2C+state%3A+'randomstatedata'%7D

and the response back in the user-agent flow would be
  http= s://client.com/page?existingParam=3Dvalue&oauth2=3D%7Baccess_token%3A+'= accesstoken1234'%2Cexpires_in%3A3600%2Cstate%3A'randomstatedata'%7D

 

= Reasons why this is of concern:

- Requires = clients to do URL decoding and JSON decoding

- Encourages unsafe JSON handling in the User-Agent flow (eva= l(JSON) =3D XSS hole)

- Breaks the simple= model we've been creating in these flows.

=  

Evan

 

On Fri, Jun 11, 2010 at 1= :51 PM, Robert Sayre <sayrer@gmail.com> wrote:

+1

<= div>


On Fri, Jun 11, 2010 at 1:17 AM, Naitik Shah <n@daaku.org> wrote:
> +1
&g= t;
> On Thu, Jun 10, 2010 at 5:50 PM, Luke Shepard <lshepard@facebook.com> = wrote:
>>
>> +1
>>
>> On Jun 10, 2010, = at 5:46 PM, Manger, James H wrote:
>>
>> > +1
>&= gt; >
>> > --
>> > James Manger
>> >=
>> > ----------
>> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf= .org] On Behalf
>> > Of Eran Hammer-Lahav
>> > = Sent: Friday, 11 June 2010 6:29 AM
>> > To: OAuth WG (oauth@ietf.org)
>>= ; > Subject: [OAUTH-WG] Proposal for single JSON response format
>= > >
>> > - Support a single response format (including in= the user-agent
>> > fragment) using JSON.
>> > ___= ____________________________________________
>> > OAuth mailing= list
>> > = OAuth@ietf.org
>> > https://www.ietf.org/mailman/listinfo/oa= uth
>>
>> ___________________________________________= ____
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org= /mailman/listinfo/oauth
>
>
> _______________________= ________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.= ietf.org/mailman/listinfo/oauth
>
>

<= /div>

--

Robert Sayre

&qu= ot;I would have written a shorter letter, but I did not have the time."= ;

___________________________________= ____________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/o= auth

 

=
 

= --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EBB65ADP3PW5EX1MB01E_-- From mrkrcsmith@googlemail.com Mon Jun 14 04:54:08 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC8B53A68A9 for ; Mon, 14 Jun 2010 04:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.924 X-Spam-Level: X-Spam-Status: No, score=0.924 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, FROM_LOCAL_NOVOWEL=0.5, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4VMzJBQB-7Gi for ; Mon, 14 Jun 2010 04:54:06 -0700 (PDT) Received: from mail-fx0-f66.google.com (mail-fx0-f66.google.com [209.85.161.66]) by core3.amsl.com (Postfix) with ESMTP id B4E2E3A67A7 for ; Mon, 14 Jun 2010 04:54:05 -0700 (PDT) Received: by fxm7 with SMTP id 7so1007852fxm.1 for ; Mon, 14 Jun 2010 04:54:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=uTBdQh4IzrD4LthSz4GBJPoFWO97y68UCC1y0T/RaxQ=; b=WVNAuKJNTqhHF0Pg71G6ToZnLXasYtPJ1SovY4XDWAEX2MSYg+aZfsWmfkczkSZZVG fMNIha/XfOXIAq9S3nSCsLcfYLW21nbqkJ615iEsbLFBv+GqsvuC+xKRInIbe2OiF8WG gVSdZH5HnZwY1KqUFpWCQ9M0fypoGInS+8okM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=yAwcMjqkv/1ErYXqesTf0fpBILMpTqdHgW0QDUm4SOZ/gZatUGjz5H2J4SUycI3PYB KZX9QjgEp+qPchMpjSb6jDxSYTdllEl8TDLUtGc1qgjjAAM9wPXXTnUnw9rOZ9wsqYdC 7duLgbRMjMmR2t58UA4ljOwlylRxJDlIwJtHI= MIME-Version: 1.0 Received: by 10.239.188.202 with SMTP id q10mr363338hbh.126.1276516445345; Mon, 14 Jun 2010 04:54:05 -0700 (PDT) Received: by 10.239.175.145 with HTTP; Mon, 14 Jun 2010 04:54:05 -0700 (PDT) In-Reply-To: <4C1298B4.7010304@alcatel-lucent.com> References: <042e8761-8bb6-44b5-8b6f-5507bf254abf@e35g2000yqm.googlegroups.com> <4C12918E.3000503@lodderstedt.net> <4C1298B4.7010304@alcatel-lucent.com> Date: Mon, 14 Jun 2010 12:54:05 +0100 Message-ID: From: Kevin Smith To: igor.faynberg@alcatel-lucent.com Content-Type: multipart/alternative; boundary=001485f7cb50465a6b0488fc2516 Cc: OAuth WG Subject: Re: [OAUTH-WG] [WRAP] WRAP in GSMA OneAPI X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2010 11:54:08 -0000 --001485f7cb50465a6b0488fc2516 Content-Type: text/plain; charset=ISO-8859-1 Thanks for the good question Torsten - and thanks to Igor for answering it better than I could :) . We are looking at GBA within the OneAPI group but as you say the low deployment base may be a problem. Best, Kevin On Fri, Jun 11, 2010 at 9:12 PM, Igor Faynberg < igor.faynberg@alcatel-lucent.com> wrote: > A good question! > > I suspect I know the problem here. > > In mobile networks users are authenticated separately and for separate > purposes. So, one gets authenticated via MSISDN for the link layer > connection, with IMSI--for UMTS, with IMPI--for IMS. (All of these are > achieved by using the AKA protocol.) > > There is a Generic 3GPP Bootstrapping Architecture standard, which > specifies the method for application authentication, but it has not been > widely deployed, and--to the best of my knowledge--it is not supported by > browsers. > > I do think that AKA can be used directly, with the IETF version of AKA > digest, and we have in fact researched and found the solution for OpenID ( > http://www3.interscience.wiley.com/journal/123441615/abstract), which can > be extended to geolocation. This would indeed allow to authenticate on IMSI > or MSISDN. > > Igor > > Torsten Lodderstedt wrote: > >> Hi Kevin, >> >> what problems do you have with pre-paid users? Is your network unable to >> authenticate them (by IMSI or MSISDN)? >> >> regards, >> Torsten. >> >> Am 08.06.2010 18:31, schrieb Kevin Smith: >> >>> Hi David, Blaine, >>> >>> We (the OneAPI group) have been looking further into OAUTH 2.0 and would >>> like to see how it can work in a mobile network scenario: for example, a >>> desktop Web application wants to locate a mobile user to plot their location >>> on a map. So the client is the Web application and the server is an HTTP >>> platform sitting on top of the mobile core network. >>> >>> It seems that the Web application could register a client ID and client >>> secret with the OneAPI-implementing server. When location is requested by >>> this client, the server would prompt the user, and if permission were >>> received, would enable the client to access the location via an access >>> token/secret. >>> >>> One difference to the regular OAUTH flow is that 'post-pay' contract >>> network subscribers would not have to enter a username/password to identify >>> themselves since they would be implicitly identified on the network anyway; >>> they would just need to confirm authorisation ('Allow/Block'). We are not >>> sure how to handle pre-pay users that buy phone credits in advance. >>> >>> In case either of you (or any other OAUTH expert) would be available to >>> lead a discussion on the technology, and to answer questions from mobile >>> operators and platform vendors, we are having a meeting next Tuesday in >>> London. The meeting is also accessible over Webex. Please let me know if you >>> would be willing to do so, as I'm sure it will help kick-start our >>> implementation work. >>> >>> Cheers! >>> Kevin >>> >>> On Thu, May 6, 2010 at 6:13 AM, David Recordon >> recordond@gmail.com>> wrote: >>> >>> +OAuth IETF list >>> -WRAP list to BCC >>> >>> Hi Kevin, >>> OAuth 2.0 should be pretty simple for you to implement and any >>> feedback your team has would be really appreciated! There are >>> already implementations in Cocoa, Python, and Ruby list on the >>> wiki at http://wiki.oauth.net/OAuth-2.0 and you find find the >>> spec at http://tools.ietf.org/html/draft-hammer-oauth2-00. >>> >>> You may also be interested in the mobile web implementation we've >>> built at Facebook. http://developers.facebook.com/docs/guides/mobile/ >>> >>> I'm also cc'ing Blaine Cook who lives in Ireland and might be >>> able to present. >>> >>> Cheers, >>> --David >>> >>> >>> On Tue, May 4, 2010 at 4:20 AM, Kevin Smith, Vodafone >>> > wrote: >>> >>> Dear OAUTH WRAP group, >>> >>> My name is Kevin Smith of Vodafone R&D, and I lead a cross-mobile >>> operator project called OneAPI ('Open Network Enablers') [1]. >>> The aim >>> is to provide a RESTful API to expose network functions such as >>> location, messaging, payments and more to developers; with the >>> reckoning that this will make it far easier to mash-up Web >>> applications with network capabilities and reduce the time to >>> reach >>> all mobile subscribers in a territory. Thus far we have a >>> live pilot >>> implementation across the 3 major Canadian operators [2] and >>> a non- >>> commercial test site connected to >>> 12 European operators [3], and will be releasing v1.0 >>> specifications >>> backed by the OMA this month. >>> >>> For the first release we did not attempt to prescribe an AAA >>> model to >>> operators, instead leaving them to reuse their own SDP AAA >>> implementation for OneAPI. For our second phase now underway >>> we would >>> like to provide a recommended reference implementation AAA >>> model for >>> operators who are unsure how to allow secure API access whilst >>> allowing user consent and privacy to be respected. Therefore >>> we have >>> discussed OAUTH as an ideal candidate that will be well-known >>> to Web >>> developers. >>> >>> My question regards the suitability of WRAP for such a reference >>> implementation: the decoupling of authentication is good >>> sense and >>> would be welcome by operators, however it appears that WRAP is >>> deprecated and is intended to be replaced by OAUTH 2.0 - is that >>> right? Please could you provide any details on the plans for >>> if/how >>> the two will interoperate? If it's at all possible, we would >>> very much >>> welcome a member of the group to present on WRAP at one of >>> our face-to- >>> face meetings in London - if that is of interest please let >>> me know >>> and I can make arrangements. >>> >>> Thanks for your time and look forward to your advice. >>> >>> Kind regards, >>> Kevin >>> >>> [1] http://www.gsmworld.com/oneapi >>> [2] http://canada.oneapi.gsmworld.com/ >>> [3] http://oneapi.aepona.com/ >>> >>> Kevin Smith >>> Senior Technology Strategist, R&D >>> Vodafone Technology >>> >>> E-mail: kevin.smith@vodafone.com >>> >>> >>> >>> -- >>> You received this message because you are subscribed to the >>> Google Groups "OAuth WRAP WG" group. >>> To post to this group, send email to >>> oauth-wrap-wg@googlegroups.com >>> . >>> >>> To unsubscribe from this group, send email to >>> oauth-wrap-wg+unsubscribe@googlegroups.com >>> >>> >. >>> >>> For more options, visit this group at >>> http://groups.google.com/group/oauth-wrap-wg?hl=en. >>> >>> >>> -- You received this message because you are subscribed to the >>> Google Groups "OAuth WRAP WG" group. >>> To post to this group, send email to >>> oauth-wrap-wg@googlegroups.com >>> . >>> >>> To unsubscribe from this group, send email to >>> oauth-wrap-wg+unsubscribe@googlegroups.com >>> >>> >. >>> >>> For more options, visit this group at >>> http://groups.google.com/group/oauth-wrap-wg?hl=en. >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> ------------------------------------------------------------------------ >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > --001485f7cb50465a6b0488fc2516 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks for the good question Torsten - and thanks to Igor for answering it = better than I could :) . We are looking at GBA within the OneAPI group but = as you say the low deployment base may be a problem.

Best,
Kevin<= br>
On Fri, Jun 11, 2010 at 9:12 PM, Igor Faynbe= rg <igor.faynberg@alcatel-lucent.com> wrote:
A good question!

I suspect I know the problem here.

In mobile networks users are authenticated separately and for separate purp= oses. So, one gets authenticated via MSISDN for the link layer connection, = with IMSI--for UMTS, with IMPI--for IMS. (All of these are achieved by usin= g the AKA protocol.)

There is a Generic 3GPP Bootstrapping Architecture standard, which specifie= s the method for application authentication, but it has not been widely dep= loyed, and--to the best of my knowledge--it is not supported by browsers.
I do think that AKA can be used directly, with the IETF version of AKA dige= st, and we have in fact researched and found the solution for OpenID (http://www3.interscience.wiley.com/journal/123441615/abstract), which can be extended to geolocation. This would indeed allow to authe= nticate on IMSI or MSISDN.

Igor

Torsten Lodderstedt wrote:
Hi Kevin,

what problems do you have with pre-paid users? Is your network unable to au= thenticate them (by IMSI or MSISDN)?

regards,
Torsten.

Am 08.06.2010 18:31, schrieb Kevin Smith:
Hi David, Blaine,

We (the OneAPI group) have been looking further into OAUTH 2.0 and would li= ke to see how it can work in a mobile network scenario: for example, a desk= top Web application wants to locate a mobile user to plot their location on= a map. So the client is the Web application and the server is an HTTP plat= form sitting on top of the mobile core network.

=A0It seems that the Web application could register a client ID and client = secret with the OneAPI-implementing server. When location is requested by t= his client, the server would prompt the user, and if permission were receiv= ed, would enable the client to access the location via an access token/secr= et.

One difference to the regular OAUTH flow is that =A0'post-pay' cont= ract network subscribers would not have to enter a username/password to ide= ntify themselves since they would be implicitly identified on the network a= nyway; they would just need to confirm authorisation ('Allow/Block'= ). We are not sure how to handle pre-pay users that buy phone credits in ad= vance.

In case either of you (or any other OAUTH expert) would be available to lea= d a discussion on the technology, and to answer questions from mobile opera= tors and platform vendors, we are having a meeting next Tuesday in London. = The meeting is also accessible over Webex. Please let me know if you would = be willing to do so, as I'm sure it will help kick-start our implementa= tion work.

Cheers!
Kevin

On Thu, May 6, 2010 at 6:13 AM, David Recordon <recordond@gmail.com <mailto:recordond@gmail.com&g= t;> wrote:

=A0 =A0+OAuth IETF list
=A0 =A0-WRAP list to BCC

=A0 =A0Hi Kevin,
=A0 =A0OAuth 2.0 should be pretty simple for you to implement and any
=A0 =A0feedback your team has would be really appreciated! There are
=A0 =A0already implementations in Cocoa, Python, and Ruby list on the
=A0 =A0wiki at http://wiki.oauth.net/OAuth-2.0 and you find find the
=A0 =A0spec at http://tools.ietf.org/html/draft-hammer-oauth2-00.=

=A0 =A0You may also be interested in the mobile web implementation we'= ve
=A0 =A0built at Facebook. http://developers.facebook.com/docs/guides= /mobile/

=A0 =A0I'm also cc'ing Blaine Cook who lives in Ireland and might = be
=A0 =A0able to present.

=A0 =A0Cheers,
=A0 =A0--David


=A0 =A0On Tue, May 4, 2010 at 4:20 AM, Kevin Smith, Vodafone
=A0 =A0<= mrkrcsmith@googlemail.com <mailto:mrkrcsmith@googlemail.com>> wrote:
=A0 =A0 =A0 =A0Dear OAUTH WRAP group,

=A0 =A0 =A0 =A0My name is Kevin Smith of Vodafone R&D, and I lead a cr= oss-mobile
=A0 =A0 =A0 =A0operator project called OneAPI ('Open Network Enablers&= #39;) [1].
=A0 =A0 =A0 =A0The aim
=A0 =A0 =A0 =A0is to provide a RESTful API to expose network functions suc= h as
=A0 =A0 =A0 =A0location, messaging, payments and more to developers; with = the
=A0 =A0 =A0 =A0reckoning that this will make it far easier to mash-up Web<= br> =A0 =A0 =A0 =A0applications with network capabilities and reduce the time = to
=A0 =A0 =A0 =A0reach
=A0 =A0 =A0 =A0all mobile subscribers in a territory. Thus far we have a =A0 =A0 =A0 =A0live pilot
=A0 =A0 =A0 =A0implementation across the 3 major Canadian operators [2] an= d
=A0 =A0 =A0 =A0a non-
=A0 =A0 =A0 =A0commercial test site connected to
=A0 =A0 =A0 =A012 European operators [3], and will be releasing v1.0
=A0 =A0 =A0 =A0specifications
=A0 =A0 =A0 =A0backed by the OMA this month.

=A0 =A0 =A0 =A0For the first release we did not attempt to prescribe an AA= A
=A0 =A0 =A0 =A0model to
=A0 =A0 =A0 =A0operators, instead leaving them to reuse their own SDP AAA<= br> =A0 =A0 =A0 =A0implementation for OneAPI. For our second phase now underwa= y
=A0 =A0 =A0 =A0we would
=A0 =A0 =A0 =A0like to provide a recommended reference implementation AAA<= br> =A0 =A0 =A0 =A0model for
=A0 =A0 =A0 =A0operators who are unsure how to allow secure API access whi= lst
=A0 =A0 =A0 =A0allowing user consent and privacy to be respected. Therefor= e
=A0 =A0 =A0 =A0we have
=A0 =A0 =A0 =A0discussed OAUTH as an ideal candidate that will be well-kno= wn
=A0 =A0 =A0 =A0to Web
=A0 =A0 =A0 =A0developers.

=A0 =A0 =A0 =A0My question regards the suitability of WRAP for such a refe= rence
=A0 =A0 =A0 =A0implementation: the decoupling of authentication is good =A0 =A0 =A0 =A0sense and
=A0 =A0 =A0 =A0would be welcome by operators, however it appears that WRAP= is
=A0 =A0 =A0 =A0deprecated and is intended to be replaced by OAUTH 2.0 - is= that
=A0 =A0 =A0 =A0right? =A0Please could you provide any details on the plans= for
=A0 =A0 =A0 =A0if/how
=A0 =A0 =A0 =A0the two will interoperate? If it's at all possible, we = would
=A0 =A0 =A0 =A0very much
=A0 =A0 =A0 =A0welcome a member of the group to present on WRAP at one of<= br> =A0 =A0 =A0 =A0our face-to-
=A0 =A0 =A0 =A0face meetings in London - if that is of interest please let=
=A0 =A0 =A0 =A0me know
=A0 =A0 =A0 =A0and I can make arrangements.

=A0 =A0 =A0 =A0Thanks for your time and look forward to your advice.

=A0 =A0 =A0 =A0Kind regards,
=A0 =A0 =A0 =A0Kevin

=A0 =A0 =A0 =A0[1] http://www.gsmworld.com/oneapi
=A0 =A0 =A0 =A0[2] http://canada.oneapi.gsmworld.com/
=A0 =A0 =A0 =A0[3] http://oneapi.aepona.com/

=A0 =A0 =A0 =A0Kevin Smith
=A0 =A0 =A0 =A0Senior Technology Strategist, R&D
=A0 =A0 =A0 =A0Vodafone Technology

=A0 =A0 =A0 =A0E-mail: kevin.smith@vodafone.com
=A0 =A0 =A0 =A0<mailto:kevin.smith@vodafone.com>


=A0 =A0 =A0 =A0--
=A0 =A0 =A0 =A0You received this message because you are subscribed to the=
=A0 =A0 =A0 =A0Google Groups "OAuth WRAP WG" group.
=A0 =A0 =A0 =A0To post to this group, send email to
=A0 =A0 =A0 =A0oauth-wrap-wg@googlegroups.com
=A0 =A0 =A0 =A0<mailto:oauth-wrap-wg@googlegroups.com>.

=A0 =A0 =A0 =A0To unsubscribe from this group, send email to
=A0 =A0 =A0 =A0oauth-wrap-wg+unsubscribe@googlegroups.com
=A0 =A0 =A0 =A0<mailto:oauth-wrap-wg%2Bunsubscribe@googlegroup= s.com>.

=A0 =A0 =A0 =A0For more options, visit this group at
=A0 =A0 =A0 =A0http://groups.google.com/group/oauth-wrap-wg?hl=3D= en.


=A0 =A0-- =A0 =A0 You received this message because you are subscribed to = the
=A0 =A0Google Groups "OAuth WRAP WG" group.
=A0 =A0To post to this group, send email to
=A0 =A0oauth-wrap-wg@googlegroups.com
=A0 =A0<mailto:oauth-wrap-wg@googlegroups.com>.

=A0 =A0To unsubscribe from this group, send email to
=A0 =A0oauth-wrap-wg+unsubscribe@googlegroups.com
=A0 =A0<mailto:oauth-wrap-wg%2Bunsubscribe@googlegroups.com>.

=A0 =A0For more options, visit this group at
=A0 =A0http://groups.google.com/group/oauth-wrap-wg?hl=3Den.


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

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

--001485f7cb50465a6b0488fc2516-- From hannes.tschofenig@nsn.com Mon Jun 14 07:13:24 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00E353A6989 for ; Mon, 14 Jun 2010 07:13:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.226 X-Spam-Level: X-Spam-Status: No, score=-0.226 tagged_above=-999 required=5 tests=[AWL=-0.227, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xygMCu6ZlSTA for ; Mon, 14 Jun 2010 07:13:22 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 59D113A68A5 for ; Mon, 14 Jun 2010 07:13:22 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o5EEDLTn003452 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 14 Jun 2010 16:13:22 +0200 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o5EEDLGe001710 for ; Mon, 14 Jun 2010 16:13:21 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Jun 2010 16:13:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Jun 2010 17:13:42 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4502B29B75@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Planning for upcoming IETF meeting Thread-Index: AcsLy8sPSA9icRaVSoKjDkyLnDTOfw== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "OAuth WG" X-OriginalArrivalTime: 14 Jun 2010 14:13:21.0221 (UTC) FILETIME=[BE7B4F50:01CB0BCB] Subject: [OAUTH-WG] Planning for upcoming IETF meeting X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2010 14:13:24 -0000 Hi all,=20 Those who attended the last IETF meeting noticed that the actual working group slots are quite short (around 2 hours). The feedback I got was that this does not leave us with enough time to get work done. I understand that argument and acknowledge that not everyone wants to attend a punch of other working group (even though I believe it would be useful todo so) and therefore staying the entire week does not make a lot of sense either. Traveling to a remote location for a 2 hour meeting then does not sound super efficient.=20 The plan I had discussed with Blaine is the following: Once the final IETF meeting agenda is available we will pick time slots all over the week (one every day). I will organize a room and we can get together to discuss open issues until we reach a point where we need to dig into the details (often requiring text to be written). Writing such text contributions will then happen afterwards so that we can continue our discussion during the next slot.=20 This will hopefully help us to get some open issues investigated in detail and to have text proposals available. The official working group meeting slot would be used to summarize the work on the text proposals and to get input from the larger community.=20 Thoughts?=20 Ciao Hannes & Blaine From jricher@mitre.org Mon Jun 14 07:20:10 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDCFF3A6987 for ; Mon, 14 Jun 2010 07:20:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.438 X-Spam-Level: X-Spam-Status: No, score=-4.438 tagged_above=-999 required=5 tests=[AWL=-0.439, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LVRur91NlV2k for ; Mon, 14 Jun 2010 07:20:07 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id CEC5C3A67EA for ; Mon, 14 Jun 2010 07:20:06 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o5EEK9DU029960 for ; Mon, 14 Jun 2010 10:20:09 -0400 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o5EEK8jC029957; Mon, 14 Jun 2010 10:20:08 -0400 Received: from [129.83.50.65] (129.83.50.65) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server id 8.2.254.0; Mon, 14 Jun 2010 10:20:08 -0400 From: Justin Richer To: Eran Hammer-Lahav In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Mon, 14 Jun 2010 10:20:08 -0400 Message-ID: <1276525208.7940.7.camel@localhost.localdomain> MIME-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: OAuth WG Subject: Re: [OAUTH-WG] Draft -07 (major rewrite) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2010 14:20:10 -0000 I disagree. I don't think it's redundant, I think it's a clarifying piece of information that makes it completely unambiguous what the client is expecting to happen. On the server side, a single switch is a much simpler and less error-prone dispatch structure than a set of "if this-and-that parameter else if this-other parameter else if that-other-and-something-else parameter" statements. If one of our goals of OAuth2 is easing the implementation for developers, dropping the "type" field is a big lose. Also, as has already been pointed out, if a new flow comes in that wants to use existing parameters in a different way, then it won't fit into this framework or an extension. Decreasing ambiguity for a small price (a few extra required characters for the auth flow) is a good thing. Incidentally, I agree that the refresh flow should fit in with all of the other flows, but with "type=refresh". Maybe "type" is the wrong word for this parameter? Because I was envisioning the rescope and revoke operations to be similar to the refresh operation. Using HTTP DELETE is a bad idea since it would require each token to have a URL associated with it, and you can no longer manipulate the OAuth API with just query parameters. A "type=revoke" call with the refresh token as authentication and the token-to-be-revoked as parameter makes a whole lot more sense to me. It keeps these three operations parallel to the other authorization flows -- part of the whole "how to get a token" side of OAuth. -- Justin On Fri, 2010-06-11 at 17:25 -0400, Eran Hammer-Lahav wrote: > It doesn’t really. It is completely clear what kind of authorization > grant the client is providing simply by looking at the parameter. It > might make the code a few lines longer (a few if-else instead of a > switch-case) but because these are all post parameters, you access > them the same way (i.e. this is not a case where header information is > moved to post body, etc.). > > As for the rescope and revoke operations, we still need to figure out > how to accomplish that. For example, revoking can be done using an > HTTP DELETE operation which is more consistent with HTTP, and > rescoping (which is still tricky because scope can only be decreased) > is more a function of a refresh operation (asking for a new access > token using a refresh token and simply providing a new, lesser scope). > > EHL > > > On 6/11/10 2:05 PM, "Justin Richer" wrote: > > I agree with Marius: I think we should keep the explicit flow > name in > there (in the 'type' parameter or equivalent), as it (among > other > things) opens the possibility for the rescope and revoke > operations. It > makes it very clear how both client and server expect things > to behave. > > -- Justin > > On Fri, 2010-06-11 at 16:47 -0400, Marius Scurtescu wrote: > > On Fri, Jun 11, 2010 at 1:11 PM, Eran Hammer-Lahav > wrote: > > > Draft -07 represents a major rearrangement of the > document. I still have a lot of work to do but wanted to share > my progress and get some general feedback. The draft includes > a few normative language changes but the main focus is on the > document structure and how the architecture is explained. > > > > > > Changes include: > > > > > > o Removed device profile. > > > o Added verification code support to user-agent flow. > > > o Removed multiple formats support, leaving JSON as the > only format. > > > o Changed assertion "assertion_format" parameter to > "assertion_type". > > > o Removed "type" parameter from token endpoint. > > > > It would be really useful if each request had a unique type, > now we > > are back to guessing what is requested, like in WRAP. > > > > One small error that I noticed: section "5.1.4. Refresh > Token" is not > > listing client_id and client_secret as optional parameters. > > > > In general I found previous versions much easier to read and > > understand, but maybe I just need more time... > > > > > > Marius > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > From cmortimore@salesforce.com Mon Jun 14 07:55:37 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B49093A6910 for ; Mon, 14 Jun 2010 07:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.076 X-Spam-Level: X-Spam-Status: No, score=-5.076 tagged_above=-999 required=5 tests=[AWL=1.523, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pnHm-VBpGxaN for ; Mon, 14 Jun 2010 07:55:36 -0700 (PDT) Received: from exprod8og106.obsmtp.com (exprod8og106.obsmtp.com [64.18.3.92]) by core3.amsl.com (Postfix) with SMTP id 5DA7A3A68DC for ; Mon, 14 Jun 2010 07:55:36 -0700 (PDT) Received: from source ([204.14.239.239]) by exprod8ob106.postini.com ([64.18.7.12]) with SMTP ID DSNKTBZC7BGtLeAWnCnzej7uzuZ4h1+G7BE5@postini.com; Mon, 14 Jun 2010 07:55:40 PDT Received: from EXSFM-MB01.internal.salesforce.com ([10.1.127.45]) by exsfm-hub4.internal.salesforce.com ([10.1.127.8]) with mapi; Mon, 14 Jun 2010 07:55:39 -0700 From: Chuck Mortimore To: Eran Hammer-Lahav Date: Mon, 14 Jun 2010 07:54:28 -0700 Thread-Topic: [OAUTH-WG] Draft -07 (major rewrite) Thread-Index: AcsLzsIbf0fEOoFsShCROakzDenFpQAArqtg Message-ID: <77AEC44D4DA08A46ADAA723286626BC1659B86D585@EXSFM-MB01.internal.salesforce.com> References: , <1276525208.7940.7.camel@localhost.localdomain> In-Reply-To: <1276525208.7940.7.camel@localhost.localdomain> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Draft -07 (major rewrite) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2010 14:55:37 -0000 +1 for the type parameter. =20 Our internal server and client developers would both prefer it. =20 -cmort ________________________________________ From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Justin R= icher [jricher@mitre.org] Sent: Monday, June 14, 2010 7:20 AM To: Eran Hammer-Lahav Cc: OAuth WG Subject: Re: [OAUTH-WG] Draft -07 (major rewrite) I disagree. I don't think it's redundant, I think it's a clarifying piece of information that makes it completely unambiguous what the client is expecting to happen. On the server side, a single switch is a much simpler and less error-prone dispatch structure than a set of "if this-and-that parameter else if this-other parameter else if that-other-and-something-else parameter" statements. If one of our goals of OAuth2 is easing the implementation for developers, dropping the "type" field is a big lose. Also, as has already been pointed out, if a new flow comes in that wants to use existing parameters in a different way, then it won't fit into this framework or an extension. Decreasing ambiguity for a small price (a few extra required characters for the auth flow) is a good thing. Incidentally, I agree that the refresh flow should fit in with all of the other flows, but with "type=3Drefresh". Maybe "type" is the wrong word for this parameter? Because I was envisioning the rescope and revoke operations to be similar to the refresh operation. Using HTTP DELETE is a bad idea since it would require each token to have a URL associated with it, and you can no longer manipulate the OAuth API with just query parameters. A "type=3Drevoke" call with the refresh token as authentication and the token-to-be-revoked as parameter makes a whole lot more sense to me. It keeps these three operations parallel to the other authorization flows -- part of the whole "how to get a token" side of OAuth. -- Justin On Fri, 2010-06-11 at 17:25 -0400, Eran Hammer-Lahav wrote: > It doesn=92t really. It is completely clear what kind of authorization > grant the client is providing simply by looking at the parameter. It > might make the code a few lines longer (a few if-else instead of a > switch-case) but because these are all post parameters, you access > them the same way (i.e. this is not a case where header information is > moved to post body, etc.). > > As for the rescope and revoke operations, we still need to figure out > how to accomplish that. For example, revoking can be done using an > HTTP DELETE operation which is more consistent with HTTP, and > rescoping (which is still tricky because scope can only be decreased) > is more a function of a refresh operation (asking for a new access > token using a refresh token and simply providing a new, lesser scope). > > EHL > > > On 6/11/10 2:05 PM, "Justin Richer" wrote: > > I agree with Marius: I think we should keep the explicit flow > name in > there (in the 'type' parameter or equivalent), as it (among > other > things) opens the possibility for the rescope and revoke > operations. It > makes it very clear how both client and server expect things > to behave. > > -- Justin > > On Fri, 2010-06-11 at 16:47 -0400, Marius Scurtescu wrote: > > On Fri, Jun 11, 2010 at 1:11 PM, Eran Hammer-Lahav > wrote: > > > Draft -07 represents a major rearrangement of the > document. I still have a lot of work to do but wanted to share > my progress and get some general feedback. The draft includes > a few normative language changes but the main focus is on the > document structure and how the architecture is explained. > > > > > > Changes include: > > > > > > o Removed device profile. > > > o Added verification code support to user-agent flow. > > > o Removed multiple formats support, leaving JSON as the > only format. > > > o Changed assertion "assertion_format" parameter to > "assertion_type". > > > o Removed "type" parameter from token endpoint. > > > > It would be really useful if each request had a unique type, > now we > > are back to guessing what is requested, like in WRAP. > > > > One small error that I noticed: section "5.1.4. Refresh > Token" is not > > listing client_id and client_secret as optional parameters. > > > > In general I found previous versions much easier to read and > > understand, but maybe I just need more time... > > > > > > Marius > > _______________________________________________ > > OAuth mailing 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 andrewarnott@gmail.com Mon Jun 14 08:23:57 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DED43A68F8 for ; Mon, 14 Jun 2010 08:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.753 X-Spam-Level: X-Spam-Status: No, score=-0.753 tagged_above=-999 required=5 tests=[AWL=0.357, BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pALrrZYQKh3S for ; Mon, 14 Jun 2010 08:23:56 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 8EBB53A6915 for ; Mon, 14 Jun 2010 08:23:56 -0700 (PDT) Received: by gyh4 with SMTP id 4so2613048gyh.31 for ; Mon, 14 Jun 2010 08:23:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=u8vpaR4is6ZESPQ0I1p/lFwqVBQFWVe521vp7PGj65M=; b=supkHZBF7Ol2RNlR8Cqw8I3Irk3EYUm6l6rHhG9zOLNNRkPVpvnaxcN3DGZ6CE+TiK lqOcaOSF71c7zN8XpkkLmypOfCDTzRm5iz+dERgTrvD1ZhYQQi/qwtfRNFL6CFOu02ZJ 0CvBq0TP05WJGH8YUrVdl5PMmcWYLvOx5r3no= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=rOY/kzonrFI5/+6wNWAh73DMc/3O6nyZSJE8pX8neCs6NppMswgODo9ABKUKH/VFj/ 4G762KTj9bNKZm8j+L4F3R6UbqAtMr5pRg4mVy4uksmtV7obWTCEn91PTF8ZOTts6L/A eU1BQ6UHbS963mVY0Fle1qTw6LfgcVbaS8pMs= MIME-Version: 1.0 Received: by 10.151.59.13 with SMTP id m13mr6639341ybk.250.1276529037521; Mon, 14 Jun 2010 08:23:57 -0700 (PDT) Received: by 10.151.26.19 with HTTP; Mon, 14 Jun 2010 08:23:57 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF76BC@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF76BC@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 14 Jun 2010 08:23:57 -0700 Message-ID: From: Andrew Arnott To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=00151750e27ed3cede0488ff1374 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Draft -07 (major rewrite) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2010 15:23:57 -0000 --00151750e27ed3cede0488ff1374 Content-Type: text/plain; charset=ISO-8859-1 I find the combination of the web server and user agent flows for end user authorization unnatural -- particularly poignant in the success response, which has 4 parameters -- but one flow MUST have no more than 2, and the other must have 3. And apparently now the user-agent flow can receive a verification code as well as an access token? It's unclear what that's for or how that's used. I suggest the spec break the two flows back up to make it easier to parse what message shapes exist. -- 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 Fri, Jun 11, 2010 at 1:11 PM, Eran Hammer-Lahav wrote: > Draft -07 represents a major rearrangement of the document. I still have a > lot of work to do but wanted to share my progress and get some general > feedback. The draft includes a few normative language changes but the main > focus is on the document structure and how the architecture is explained. > > Changes include: > > o Removed device profile. > o Added verification code support to user-agent flow. > o Removed multiple formats support, leaving JSON as the only format. > o Changed assertion "assertion_format" parameter to "assertion_type". > o Removed "type" parameter from token endpoint. > > The spec is now 36 pages, 19 pages shorter than -05. > > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --00151750e27ed3cede0488ff1374 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I find the combination of the web server and user agent flows for end user = authorization unnatural -- particularly poignant in the success response, w= hich has 4 parameters -- but one flow MUST have no more than 2, and the oth= er must have 3.=A0 And apparently now the user-agent flow can receive a ver= ification code as well as an access token?=A0 It's unclear what that= 9;s for or how that's used.

I suggest the spec break the two flows back up to make it easier to par= se what message shapes exist.

--
Andrew Arnott
&= quot;I [may] not agree with what you have to say, but I'll defend to th= e death your right to say it." - S. G. Tallentyre


On Fri, Jun 11, 2010 at 1:11 PM, Eran Ha= mmer-Lahav <era= n@hueniverse.com> wrote:
Draft -07 represents a major rearrangement of the document. I still have a = lot of work to do but wanted to share my progress and get some general feed= back. The draft includes a few normative language changes but the main focu= s is on the document structure and how the architecture is explained.

Changes include:

=A0 o =A0Removed device profile.
=A0 o =A0Added verification code support to user-agent flow.
=A0 o =A0Removed multiple formats support, leaving JSON as the only format= .
=A0 o =A0Changed assertion "assertion_format" parameter to "= ;assertion_type".
=A0 o =A0Removed "type" parameter from token endpoint.

The spec is now 36 pages, 19 pages shorter than -05.

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

--00151750e27ed3cede0488ff1374-- From rrichards@cdatazone.org Mon Jun 14 09:05:49 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 842453A68D0 for ; Mon, 14 Jun 2010 09:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YiXXk6Koz9IZ for ; Mon, 14 Jun 2010 09:05:48 -0700 (PDT) Received: from smtp2go.com (smtp2go.com [207.58.142.213]) by core3.amsl.com (Postfix) with ESMTP id 717B93A69E9 for ; Mon, 14 Jun 2010 09:05:48 -0700 (PDT) Received: from [67.158.171.203] (helo=Rob-Richardss-MacBook-Pro.local) by smtp2go.com with esmtp (Exim 4.69) (envelope-from ) id 1OOCAQ-0005Fd-NA; Mon, 14 Jun 2010 16:05:43 +0000 Message-ID: <4C165356.3090505@cdatazone.org> Date: Mon, 14 Jun 2010 12:05:42 -0400 From: Rob Richards User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Paul Lindner References: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF729E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3EAF7328@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SMTP2Go-MailScanner-Information: Please contact support@smtp2go.com for more information X-SMTP2Go-MailScanner-ID: 1OOCAQ-0005Fd-NA X-SMTP2Go-MailScanner: Found to be clean X-SMTP2Go-MailScanner-From: rrichards@cdatazone.org Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Identifying OAuth 2.0 vs 1.0 requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2010 16:05:49 -0000 Wouldn't it make sense to require the oauth_version parameter under 2.0 for resource calls so that the two versions can be distinguished? Rob Paul Lindner wrote: > If you're routing requests with a load balancer it's not so trivial. > Instead of a substring match you're talking about a regex with > negative lookahead matching -- that's why the presence of the > signature param is essential to distinguishing between 2.0/1.0a. > > On Thu, Jun 10, 2010 at 10:42 AM, Eran Hammer-Lahav > > wrote: > > But in that case, all the other oauth_* parameters are missing. > It's trivial. > > EHL > > > -----Original Message----- > > From: Marius Scurtescu [mailto:mscurtescu@google.com > ] > > Sent: Thursday, June 10, 2010 10:39 AM > > To: Paul Lindner > > Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org > ) > > Subject: Re: [OAUTH-WG] Identifying OAuth 2.0 vs 1.0 requests > > > > I run into the same issue. In section "4.2. URI Query > Parameter", it would > > help if the parameter name, oauth_token, was different from OAuth 1. > > > > Marius > > > > > > > > On Thu, Jun 10, 2010 at 9:41 AM, Paul Lindner > wrote: > > > I am talking about the resource server. Specifically I want to > be able > > > to quickly determine if an incoming request is 1.0a vs 2.0. > And since > > > this is a library it can't make a lot of assumptions about the > > > specific environment it's running in. > > > At first I thought I would check the oauth_version parameter. It > > > turns out the 1.0a spec says that it is optional. The only > one that > > > is required for 1.0a is oauth_signature_method. > > > Sadly we're long past time to change the spec to optimize for > this use-case. > > > (It would have been better to have a parameter for oauth 2.0 > that is > > > distinct from 1.0a) At the very least this message will live > on in > > > the mailing list archives -- at best we document the proper way to > > > distinguish between the two versions somewhere. > > > On Thu, Jun 10, 2010 at 8:44 AM, Eran Hammer-Lahav > > > > > > > wrote: > > >> > > >> The request is very different on the resource server. On the > > >> authorization server, why would you use the same endpoint? > > >> > > >> > > >> > > >> EHL > > >> > > >> > > >> > > >> From: oauth-bounces@ietf.org > [mailto:oauth-bounces@ietf.org ] On > > >> Behalf Of Paul Lindner > > >> Sent: Thursday, June 10, 2010 8:24 AM > > >> To: OAuth WG (oauth@ietf.org ) > > >> Subject: [OAUTH-WG] Identifying OAuth 2.0 vs 1.0 requests > > >> > > >> > > >> > > >> Hi, > > >> > > >> > > >> > > >> As I've been working through our oauth2 implementation I've > noticed > > >> that it's not easy to disambiguate OAuth 1.0a vs 2.0 API > calls based > > >> on the request parameters alone. Based on some > investigative at the > > >> Shindig project it appears that the only standard way to to > determine > > >> 1.0a vs 2.0 is by checking for the oauth_signature_method > > parameter. More info here: > > >> > > >> > > >> > > >> https://issues.apache.org/jira/browse/SHINDIG-1361 > > >> > > >> > > >> > > >> Has anyone else considered this use case? How did you solve it? > > >> > > >> > > > > > > _______________________________________________ > > > OAuth mailing 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 Mon Jun 14 09:18:20 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09F903A68FB for ; Mon, 14 Jun 2010 09:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.394 X-Spam-Level: X-Spam-Status: No, score=-1.394 tagged_above=-999 required=5 tests=[AWL=-0.285, BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i+23cXezSL+1 for ; Mon, 14 Jun 2010 09:18:14 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id ABE883A69E3 for ; Mon, 14 Jun 2010 09:18:14 -0700 (PDT) Received: (qmail 19733 invoked from network); 14 Jun 2010 16:18:17 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 14 Jun 2010 16:18:16 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 14 Jun 2010 09:18:12 -0700 From: Eran Hammer-Lahav To: Andrew Arnott Date: Mon, 14 Jun 2010 09:18:15 -0700 Thread-Topic: [OAUTH-WG] Draft -07 (major rewrite) Thread-Index: AcsL1Z6IUVJsUz2DSfa1WenXWf59agABxlOw Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB66AC@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF76BC@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_90C41DD21FB7C64BB94121FBBC2E72343B3EBB66ACP3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Draft -07 (major rewrite) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2010 16:18:20 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EBB66ACP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Adding a verification code to the user-agent flow was suggested on this lis= t and received nothing but support. It was suggested as a solution to a Twi= tter use case. Once that is added in, the two flows only differ in how the = response is delivered and the presence of an access token in the response (= which currently is a MUST NOT for web-server but I don't know if this restr= iction is need). If we break them up, it is for editorial reasons only, which also means, ev= ery change needs to be made twice, as well as every extension needs to spel= l out which flavor it is for. EHL From: Andrew Arnott [mailto:andrewarnott@gmail.com] Sent: Monday, June 14, 2010 8:24 AM To: Eran Hammer-Lahav Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Draft -07 (major rewrite) I find the combination of the web server and user agent flows for end user = authorization unnatural -- particularly poignant in the success response, w= hich has 4 parameters -- but one flow MUST have no more than 2, and the oth= er must have 3. And apparently now the user-agent flow can receive a verif= ication code as well as an access token? It's unclear what that's for or h= ow that's used. I suggest the spec break the two flows back up to make it easier to parse w= hat message shapes exist. -- 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 Fri, Jun 11, 2010 at 1:11 PM, Eran Hammer-Lahav > wrote: Draft -07 represents a major rearrangement of the document. I still have a = lot of work to do but wanted to share my progress and get some general feed= back. The draft includes a few normative language changes but the main focu= s is on the document structure and how the architecture is explained. Changes include: o Removed device profile. o Added verification code support to user-agent flow. o Removed multiple formats support, leaving JSON as the only format. o Changed assertion "assertion_format" parameter to "assertion_type". o Removed "type" parameter from token endpoint. The spec is now 36 pages, 19 pages shorter than -05. EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EBB66ACP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Adding a = verification code to the user-agent flow was suggested on this list and rec= eived nothing but support. It was suggested as a solution to a Twitter use = case. Once that is added in, the two flows only differ in how the response = is delivered and the presence of an access token in the response (which cur= rently is a MUST NOT for web-server but I don’t know if this restrict= ion is need).

 <= /o:p>

If we break them up, it is for = editorial reasons only, which also means, every change needs to be made twi= ce, as well as every extension needs to spell out which flavor it is for.

 

EHL

=  

Fro= m: Andrew Arnott [mailto:andrewarnott@gmail.com]
Sent: Monday= , June 14, 2010 8:24 AM
To: Eran Hammer-Lahav
Cc: OAuth= WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Draft -07 (major rew= rite)

 

I find the combin= ation of the web server and user agent flows for end user authorization unn= atural -- particularly poignant in the success response, which has 4 parame= ters -- but one flow MUST have no more than 2, and the other must have 3.&n= bsp; And apparently now the user-agent flow can receive a verification code= as well as an access token?  It's unclear what that's for or how that= 's used.

I suggest the spec break the two flows back up to make it e= asier to parse what message shapes exist.

--
Andrew A= rnott
"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 Fri, Jun 11, 2010 at 1:11 PM, Eran Ham= mer-Lahav <eran@hueniverse.com> wrote:

Draft -07 represents a majo= r rearrangement of the document. I still have a lot of work to do but wante= d to share my progress and get some general feedback. The draft includes a = few normative language changes but the main focus is on the document struct= ure and how the architecture is explained.

Changes include:

&= nbsp; o  Removed device profile.
  o  Added verification = code support to user-agent flow.
  o  Removed multiple formats= support, leaving JSON as the only format.
  o  Changed assert= ion "assertion_format" parameter to "assertion_type".  o  Removed "type" parameter from token endpoint.
The spec is now 36 pages, 19 pages shorter than -05.

EHL
___= ____________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mail= man/listinfo/oauth

 =

= --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EBB66ACP3PW5EX1MB01E_-- From eran@hueniverse.com Mon Jun 14 09:23:31 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1555A3A67AA for ; Mon, 14 Jun 2010 09:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.13 X-Spam-Level: X-Spam-Status: No, score=-2.13 tagged_above=-999 required=5 tests=[AWL=0.469, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tqpe4B7wwqB5 for ; Mon, 14 Jun 2010 09:23:30 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id F094A3A69D4 for ; Mon, 14 Jun 2010 09:23:29 -0700 (PDT) Received: (qmail 23903 invoked from network); 14 Jun 2010 16:23:34 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 14 Jun 2010 16:23:34 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 14 Jun 2010 09:23:27 -0700 From: Eran Hammer-Lahav To: Chuck Mortimore Date: Mon, 14 Jun 2010 09:23:29 -0700 Thread-Topic: [OAUTH-WG] Draft -07 (major rewrite) Thread-Index: AcsLzsIbf0fEOoFsShCROakzDenFpQAArqtgAALzZuA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB66B2@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: , <1276525208.7940.7.camel@localhost.localdomain> <77AEC44D4DA08A46ADAA723286626BC1659B86D585@EXSFM-MB01.internal.salesforce.com> In-Reply-To: <77AEC44D4DA08A46ADAA723286626BC1659B86D585@EXSFM-MB01.internal.salesforce.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] Draft -07 (major rewrite) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2010 16:23:31 -0000 Why client developers? How does it make their life easier? An approach I'm more comfortable with is to redefine 'type' as the type of = authorization grant provided: refresh_token, user_basic, verification_code,= assertion. And if we use the name 'type', I would change the 'type' parame= ter on the end-user authorization endpoint to something else such as the pr= oposed 'response_type'. Otherwise change it to 'grant_type' or something li= ke that. EHL > -----Original Message----- > From: Chuck Mortimore [mailto:cmortimore@salesforce.com] > Sent: Monday, June 14, 2010 7:54 AM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: RE: [OAUTH-WG] Draft -07 (major rewrite) >=20 > +1 for the type parameter. >=20 > Our internal server and client developers would both prefer it. >=20 > -cmort > ________________________________________ > From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of > Justin Richer [jricher@mitre.org] > Sent: Monday, June 14, 2010 7:20 AM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Draft -07 (major rewrite) >=20 > I disagree. I don't think it's redundant, I think it's a clarifying piece= of > information that makes it completely unambiguous what the client is > expecting to happen. On the server side, a single switch is a much simple= r > and less error-prone dispatch structure than a set of "if this-and-that > parameter else if this-other parameter else if that-other-and-something-e= lse > parameter" statements. If one of our goals of OAuth2 is easing the > implementation for developers, dropping the "type" field is a big lose. >=20 > Also, as has already been pointed out, if a new flow comes in that wants = to > use existing parameters in a different way, then it won't fit into this > framework or an extension. Decreasing ambiguity for a small price (a few > extra required characters for the auth flow) is a good thing. >=20 > Incidentally, I agree that the refresh flow should fit in with all of the= other > flows, but with "type=3Drefresh". Maybe "type" is the wrong word for this > parameter? Because I was envisioning the rescope and revoke operations to > be similar to the refresh operation. Using HTTP DELETE is a bad idea sinc= e it > would require each token to have a URL associated with it, and you can no > longer manipulate the OAuth API with just query parameters. A > "type=3Drevoke" call with the refresh token as authentication and the tok= en- > to-be-revoked as parameter makes a whole lot more sense to me. It keeps > these three operations parallel to the other authorization flows -- part = of the > whole "how to get a token" side of OAuth. >=20 > -- Justin >=20 > On Fri, 2010-06-11 at 17:25 -0400, Eran Hammer-Lahav wrote: > > It doesn't really. It is completely clear what kind of authorization > > grant the client is providing simply by looking at the parameter. It > > might make the code a few lines longer (a few if-else instead of a > > switch-case) but because these are all post parameters, you access > > them the same way (i.e. this is not a case where header information is > > moved to post body, etc.). > > > > As for the rescope and revoke operations, we still need to figure out > > how to accomplish that. For example, revoking can be done using an > > HTTP DELETE operation which is more consistent with HTTP, and > > rescoping (which is still tricky because scope can only be decreased) > > is more a function of a refresh operation (asking for a new access > > token using a refresh token and simply providing a new, lesser scope). > > > > EHL > > > > > > On 6/11/10 2:05 PM, "Justin Richer" wrote: > > > > I agree with Marius: I think we should keep the explicit flow > > name in > > there (in the 'type' parameter or equivalent), as it (among > > other > > things) opens the possibility for the rescope and revoke > > operations. It > > makes it very clear how both client and server expect things > > to behave. > > > > -- Justin > > > > On Fri, 2010-06-11 at 16:47 -0400, Marius Scurtescu wrote: > > > On Fri, Jun 11, 2010 at 1:11 PM, Eran Hammer-Lahav > > wrote: > > > > Draft -07 represents a major rearrangement of the > > document. I still have a lot of work to do but wanted to share > > my progress and get some general feedback. The draft includes > > a few normative language changes but the main focus is on the > > document structure and how the architecture is explained. > > > > > > > > Changes include: > > > > > > > > o Removed device profile. > > > > o Added verification code support to user-agent flow. > > > > o Removed multiple formats support, leaving JSON as the > > only format. > > > > o Changed assertion "assertion_format" parameter to > > "assertion_type". > > > > o Removed "type" parameter from token endpoint. > > > > > > It would be really useful if each request had a unique type, > > now we > > > are back to guessing what is requested, like in WRAP. > > > > > > One small error that I noticed: section "5.1.4. Refresh > > Token" is not > > > listing client_id and client_secret as optional parameters. > > > > > > In general I found previous versions much easier to read and > > > understand, but maybe I just need more time... > > > > > > > > > Marius > > > _______________________________________________ > > > OAuth mailing list > > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From torsten@lodderstedt.net Mon Jun 14 09:24:13 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E4C83A69E9 for ; Mon, 14 Jun 2010 09:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.044 X-Spam-Level: X-Spam-Status: No, score=-0.044 tagged_above=-999 required=5 tests=[AWL=-0.395, BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GVfEy87LlULm for ; Mon, 14 Jun 2010 09:24:12 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.37]) by core3.amsl.com (Postfix) with ESMTP id B9C0A3A69EB for ; Mon, 14 Jun 2010 09:24:12 -0700 (PDT) Received: from p4fff0cbe.dip.t-dialin.net ([79.255.12.190] helo=[127.0.0.1]) by smtprelay03.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OOCSN-0006cs-CD; Mon, 14 Jun 2010 18:24:15 +0200 Message-ID: <4C1657AD.2000000@lodderstedt.net> Date: Mon, 14 Jun 2010 18:24:13 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Tschofenig, Hannes (NSN - FI/Espoo)" References: <3D3C75174CB95F42AD6BCC56E5555B4502B29B75@FIESEXC015.nsn-intra.net> In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B4502B29B75@FIESEXC015.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: OAuth WG Subject: Re: [OAUTH-WG] Planning for upcoming IETF meeting X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2010 16:24:13 -0000 +1 Am 14.06.2010 16:13, schrieb Tschofenig, Hannes (NSN - FI/Espoo): > Hi all, > > Those who attended the last IETF meeting noticed that the actual working > group slots are quite short (around 2 hours). The feedback I got was > that this does not leave us with enough time to get work done. I > understand that argument and acknowledge that not everyone wants to > attend a punch of other working group (even though I believe it would be > useful todo so) and therefore staying the entire week does not make a > lot of sense either. Traveling to a remote location for a 2 hour meeting > then does not sound super efficient. > > The plan I had discussed with Blaine is the following: Once the final > IETF meeting agenda is available we will pick time slots all over the > week (one every day). I will organize a room and we can get together to > discuss open issues until we reach a point where we need to dig into the > details (often requiring text to be written). Writing such text > contributions will then happen afterwards so that we can continue our > discussion during the next slot. > > This will hopefully help us to get some open issues investigated in > detail and to have text proposals available. The official working group > meeting slot would be used to summarize the work on the text proposals > and to get input from the larger community. > > Thoughts? > > Ciao > Hannes& Blaine > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From torsten@lodderstedt.net Mon Jun 14 09:30:43 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BE303A6881 for ; Mon, 14 Jun 2010 09:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.283 X-Spam-Level: X-Spam-Status: No, score=0.283 tagged_above=-999 required=5 tests=[AWL=-0.669, BAYES_50=0.001, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5geo2GRAtEq for ; Mon, 14 Jun 2010 09:30:40 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.37]) by core3.amsl.com (Postfix) with ESMTP id 5D7683A6887 for ; Mon, 14 Jun 2010 09:30:39 -0700 (PDT) Received: from p4fff0cbe.dip.t-dialin.net ([79.255.12.190] helo=[127.0.0.1]) by smtprelay03.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OOCYc-000256-6l; Mon, 14 Jun 2010 18:30:42 +0200 Message-ID: <4C165930.5070704@lodderstedt.net> Date: Mon, 14 Jun 2010 18:30:40 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Kevin Smith References: <042e8761-8bb6-44b5-8b6f-5507bf254abf@e35g2000yqm.googlegroups.com> <4C12918E.3000503@lodderstedt.net> <4C1298B4.7010304@alcatel-lucent.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090701000607050704000709" X-Df-Sender: 141509 Cc: OAuth WG Subject: Re: [OAUTH-WG] [WRAP] WRAP in GSMA OneAPI X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2010 16:30:43 -0000 This is a multi-part message in MIME format. --------------090701000607050704000709 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Kevin, out of curiosity: why do you experience this problem with pre-paid users only? regards, Torsten. Am 14.06.2010 13:54, schrieb Kevin Smith: > Thanks for the good question Torsten - and thanks to Igor for > answering it better than I could :) . We are looking at GBA within the > OneAPI group but as you say the low deployment base may be a problem. > > Best, > Kevin > > On Fri, Jun 11, 2010 at 9:12 PM, Igor Faynberg > > wrote: > > A good question! > > I suspect I know the problem here. > > In mobile networks users are authenticated separately and for > separate purposes. So, one gets authenticated via MSISDN for the > link layer connection, with IMSI--for UMTS, with IMPI--for IMS. > (All of these are achieved by using the AKA protocol.) > > There is a Generic 3GPP Bootstrapping Architecture standard, which > specifies the method for application authentication, but it has > not been widely deployed, and--to the best of my knowledge--it is > not supported by browsers. > > I do think that AKA can be used directly, with the IETF version of > AKA digest, and we have in fact researched and found the solution > for OpenID > (http://www3.interscience.wiley.com/journal/123441615/abstract), > which can be extended to geolocation. This would indeed allow to > authenticate on IMSI or MSISDN. > > Igor > > Torsten Lodderstedt wrote: > > Hi Kevin, > > what problems do you have with pre-paid users? Is your network > unable to authenticate them (by IMSI or MSISDN)? > > regards, > Torsten. > > Am 08.06.2010 18:31, schrieb Kevin Smith: > > Hi David, Blaine, > > We (the OneAPI group) have been looking further into OAUTH > 2.0 and would like to see how it can work in a mobile > network scenario: for example, a desktop Web application > wants to locate a mobile user to plot their location on a > map. So the client is the Web application and the server > is an HTTP platform sitting on top of the mobile core network. > > It seems that the Web application could register a client > ID and client secret with the OneAPI-implementing server. > When location is requested by this client, the server > would prompt the user, and if permission were received, > would enable the client to access the location via an > access token/secret. > > One difference to the regular OAUTH flow is that > 'post-pay' contract network subscribers would not have to > enter a username/password to identify themselves since > they would be implicitly identified on the network anyway; > they would just need to confirm authorisation > ('Allow/Block'). We are not sure how to handle pre-pay > users that buy phone credits in advance. > > In case either of you (or any other OAUTH expert) would be > available to lead a discussion on the technology, and to > answer questions from mobile operators and platform > vendors, we are having a meeting next Tuesday in London. > The meeting is also accessible over Webex. Please let me > know if you would be willing to do so, as I'm sure it will > help kick-start our implementation work. > > Cheers! > Kevin > > On Thu, May 6, 2010 at 6:13 AM, David Recordon > > >> > wrote: > > +OAuth IETF list > -WRAP list to BCC > > Hi Kevin, > OAuth 2.0 should be pretty simple for you to implement > and any > feedback your team has would be really appreciated! > There are > already implementations in Cocoa, Python, and Ruby list > on the > wiki at http://wiki.oauth.net/OAuth-2.0 and you find > find the > spec at http://tools.ietf.org/html/draft-hammer-oauth2-00. > > You may also be interested in the mobile web > implementation we've > built at Facebook. > http://developers.facebook.com/docs/guides/mobile/ > > I'm also cc'ing Blaine Cook who lives in Ireland and > might be > able to present. > > Cheers, > --David > > > On Tue, May 4, 2010 at 4:20 AM, Kevin Smith, Vodafone > > >> wrote: > > Dear OAUTH WRAP group, > > My name is Kevin Smith of Vodafone R&D, and I lead > a cross-mobile > operator project called OneAPI ('Open Network > Enablers') [1]. > The aim > is to provide a RESTful API to expose network > functions such as > location, messaging, payments and more to > developers; with the > reckoning that this will make it far easier to > mash-up Web > applications with network capabilities and reduce > the time to > reach > all mobile subscribers in a territory. Thus far we > have a > live pilot > implementation across the 3 major Canadian > operators [2] and > a non- > commercial test site connected to > 12 European operators [3], and will be releasing v1.0 > specifications > backed by the OMA this month. > > For the first release we did not attempt to > prescribe an AAA > model to > operators, instead leaving them to reuse their own > SDP AAA > implementation for OneAPI. For our second phase now > underway > we would > like to provide a recommended reference > implementation AAA > model for > operators who are unsure how to allow secure API > access whilst > allowing user consent and privacy to be respected. > Therefore > we have > discussed OAUTH as an ideal candidate that will be > well-known > to Web > developers. > > My question regards the suitability of WRAP for > such a reference > implementation: the decoupling of authentication is > good > sense and > would be welcome by operators, however it appears > that WRAP is > deprecated and is intended to be replaced by OAUTH > 2.0 - is that > right? Please could you provide any details on the > plans for > if/how > the two will interoperate? If it's at all possible, > we would > very much > welcome a member of the group to present on WRAP at > one of > our face-to- > face meetings in London - if that is of interest > please let > me know > and I can make arrangements. > > Thanks for your time and look forward to your advice. > > Kind regards, > Kevin > > [1] http://www.gsmworld.com/oneapi > [2] http://canada.oneapi.gsmworld.com/ > [3] http://oneapi.aepona.com/ > > Kevin Smith > Senior Technology Strategist, R&D > Vodafone Technology > > E-mail: kevin.smith@vodafone.com > > > > > > -- > You received this message because you are > subscribed to the > Google Groups "OAuth WRAP WG" group. > To post to this group, send email to > oauth-wrap-wg@googlegroups.com > > >. > > To unsubscribe from this group, send email to > oauth-wrap-wg+unsubscribe@googlegroups.com > > >. > > For more options, visit this group at > http://groups.google.com/group/oauth-wrap-wg?hl=en. > > > -- You received this message because you are > subscribed to the > Google Groups "OAuth WRAP WG" group. > To post to this group, send email to > oauth-wrap-wg@googlegroups.com > > >. > > To unsubscribe from this group, send email to > oauth-wrap-wg+unsubscribe@googlegroups.com > > >. > > For more options, visit this group at > http://groups.google.com/group/oauth-wrap-wg?hl=en. > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > ------------------------------------------------------------------------ > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --------------090701000607050704000709 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Kevin,

out of curiosity: why do you experience this problem with pre-paid users only?

regards,
Torsten.

Am 14.06.2010 13:54, schrieb Kevin Smith:
Thanks for the good question Torsten - and thanks to Igor for answering it better than I could :) . We are looking at GBA within the OneAPI group but as you say the low deployment base may be a problem.

Best,
Kevin

On Fri, Jun 11, 2010 at 9:12 PM, Igor Faynberg <igor.faynberg@alcatel-lucent.com> wrote:
A good question!

I suspect I know the problem here.

In mobile networks users are authenticated separately and for separate purposes. So, one gets authenticated via MSISDN for the link layer connection, with IMSI--for UMTS, with IMPI--for IMS. (All of these are achieved by using the AKA protocol.)

There is a Generic 3GPP Bootstrapping Architecture standard, which specifies the method for application authentication, but it has not been widely deployed, and--to the best of my knowledge--it is not supported by browsers.

I do think that AKA can be used directly, with the IETF version of AKA digest, and we have in fact researched and found the solution for OpenID (http://www3.interscience.wiley.com/journal/123441615/abstract), which can be extended to geolocation. This would indeed allow to authenticate on IMSI or MSISDN.

Igor

Torsten Lodderstedt wrote:
Hi Kevin,

what problems do you have with pre-paid users? Is your network unable to authenticate them (by IMSI or MSISDN)?

regards,
Torsten.

Am 08.06.2010 18:31, schrieb Kevin Smith:
Hi David, Blaine,

We (the OneAPI group) have been looking further into OAUTH 2.0 and would like to see how it can work in a mobile network scenario: for example, a desktop Web application wants to locate a mobile user to plot their location on a map. So the client is the Web application and the server is an HTTP platform sitting on top of the mobile core network.

 It seems that the Web application could register a client ID and client secret with the OneAPI-implementing server. When location is requested by this client, the server would prompt the user, and if permission were received, would enable the client to access the location via an access token/secret.

One difference to the regular OAUTH flow is that  'post-pay' contract network subscribers would not have to enter a username/password to identify themselves since they would be implicitly identified on the network anyway; they would just need to confirm authorisation ('Allow/Block'). We are not sure how to handle pre-pay users that buy phone credits in advance.

In case either of you (or any other OAUTH expert) would be available to lead a discussion on the technology, and to answer questions from mobile operators and platform vendors, we are having a meeting next Tuesday in London. The meeting is also accessible over Webex. Please let me know if you would be willing to do so, as I'm sure it will help kick-start our implementation work.

Cheers!
Kevin

On Thu, May 6, 2010 at 6:13 AM, David Recordon <recordond@gmail.com <mailto:recordond@gmail.com>> wrote:

   +OAuth IETF list
   -WRAP list to BCC

   Hi Kevin,
   OAuth 2.0 should be pretty simple for you to implement and any
   feedback your team has would be really appreciated! There are
   already implementations in Cocoa, Python, and Ruby list on the
   wiki at http://wiki.oauth.net/OAuth-2.0 and you find find the
   spec at http://tools.ietf.org/html/draft-hammer-oauth2-00.

   You may also be interested in the mobile web implementation we've
   built at Facebook. http://developers.facebook.com/docs/guides/mobile/

   I'm also cc'ing Blaine Cook who lives in Ireland and might be
   able to present.

   Cheers,
   --David


   On Tue, May 4, 2010 at 4:20 AM, Kevin Smith, Vodafone
   <mrkrcsmith@googlemail.com <mailto:mrkrcsmith@googlemail.com>> wrote:

       Dear OAUTH WRAP group,

       My name is Kevin Smith of Vodafone R&D, and I lead a cross-mobile
       operator project called OneAPI ('Open Network Enablers') [1].
       The aim
       is to provide a RESTful API to expose network functions such as
       location, messaging, payments and more to developers; with the
       reckoning that this will make it far easier to mash-up Web
       applications with network capabilities and reduce the time to
       reach
       all mobile subscribers in a territory. Thus far we have a
       live pilot
       implementation across the 3 major Canadian operators [2] and
       a non-
       commercial test site connected to
       12 European operators [3], and will be releasing v1.0
       specifications
       backed by the OMA this month.

       For the first release we did not attempt to prescribe an AAA
       model to
       operators, instead leaving them to reuse their own SDP AAA
       implementation for OneAPI. For our second phase now underway
       we would
       like to provide a recommended reference implementation AAA
       model for
       operators who are unsure how to allow secure API access whilst
       allowing user consent and privacy to be respected. Therefore
       we have
       discussed OAUTH as an ideal candidate that will be well-known
       to Web
       developers.

       My question regards the suitability of WRAP for such a reference
       implementation: the decoupling of authentication is good
       sense and
       would be welcome by operators, however it appears that WRAP is
       deprecated and is intended to be replaced by OAUTH 2.0 - is that
       right?  Please could you provide any details on the plans for
       if/how
       the two will interoperate? If it's at all possible, we would
       very much
       welcome a member of the group to present on WRAP at one of
       our face-to-
       face meetings in London - if that is of interest please let
       me know
       and I can make arrangements.

       Thanks for your time and look forward to your advice.

       Kind regards,
       Kevin

       [1] http://www.gsmworld.com/oneapi
       [2] http://canada.oneapi.gsmworld.com/
       [3] http://oneapi.aepona.com/

       Kevin Smith
       Senior Technology Strategist, R&D
       Vodafone Technology

       E-mail: kevin.smith@vodafone.com
       <mailto:kevin.smith@vodafone.com>


       --
       You received this message because you are subscribed to the
       Google Groups "OAuth WRAP WG" group.
       To post to this group, send email to
       oauth-wrap-wg@googlegroups.com
       <mailto:oauth-wrap-wg@googlegroups.com>.

       To unsubscribe from this group, send email to
       oauth-wrap-wg+unsubscribe@googlegroups.com
       <mailto:oauth-wrap-wg%2Bunsubscribe@googlegroups.com>.

       For more options, visit this group at
       http://groups.google.com/group/oauth-wrap-wg?hl=en.


   --     You received this message because you are subscribed to the
   Google Groups "OAuth WRAP WG" group.
   To post to this group, send email to
   oauth-wrap-wg@googlegroups.com
   <mailto:oauth-wrap-wg@googlegroups.com>.

   To unsubscribe from this group, send email to
   oauth-wrap-wg+unsubscribe@googlegroups.com
   <mailto:oauth-wrap-wg%2Bunsubscribe@googlegroups.com>.

   For more options, visit this group at
   http://groups.google.com/group/oauth-wrap-wg?hl=en.



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


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

--------------090701000607050704000709-- From balfanz@google.com Mon Jun 14 09:39:58 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CDEF3A6821 for ; Mon, 14 Jun 2010 09:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.132 X-Spam-Level: X-Spam-Status: No, score=-102.132 tagged_above=-999 required=5 tests=[AWL=0.960, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hSPlaYjhAzNr for ; Mon, 14 Jun 2010 09:39:57 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id A968C3A67AA for ; Mon, 14 Jun 2010 09:39:56 -0700 (PDT) Received: from hpaq13.eem.corp.google.com (hpaq13.eem.corp.google.com [172.25.149.13]) by smtp-out.google.com with ESMTP id o5EGdtk0010964 for ; Mon, 14 Jun 2010 09:39:55 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1276533595; bh=j488PERFYlcOrj7ZPjvsOEGo/e0=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Content-Type; b=ZWJzp7byePrdoI2Pbyofzp9jtt7fA480pBkSzMMylSMxvv9e82ct/3QNOxywzOopX zcTdAkZNK1XLgMLCg4HMg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to:content-type; b=jLTjCDehOUzmHA42/VKNBvXz/QDo9ycFy9Izic0+9fCKIv/DhcGggSVtwFoxcFVuQ zvSn34V5+Az4y2ZQAbaGw== Received: from iwn40 (iwn40.prod.google.com [10.241.68.104]) by hpaq13.eem.corp.google.com with ESMTP id o5EGdsIh007097 for ; Mon, 14 Jun 2010 09:39:54 -0700 Received: by iwn40 with SMTP id 40so4715906iwn.23 for ; Mon, 14 Jun 2010 09:39:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.0.68 with SMTP id 4mr1991524icb.98.1276533593783; Mon, 14 Jun 2010 09:39:53 -0700 (PDT) Received: by 10.231.68.144 with HTTP; Mon, 14 Jun 2010 09:39:53 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF73EF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E11263FEC9FC@WSMSG3153V.srv.dir.telstra.com> <4A5E1C55-D589-4F25-9D45-E640BA7C833F@facebook.com> Date: Mon, 14 Jun 2010 09:39:53 -0700 Message-ID: From: Dirk Balfanz To: "OAuth WG (oauth@ietf.org)" Content-Type: multipart/alternative; boundary=90e6ba180eaa66bf4c0489002316 Subject: Re: [OAUTH-WG] Proposal for single JSON response format X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2010 16:39:58 -0000 --90e6ba180eaa66bf4c0489002316 Content-Type: text/plain; charset=ISO-8859-1 +1 on JSON in response bodies -1 on JSON in URL query parameters or fragments. Dirk. On Sun, Jun 13, 2010 at 2:46 AM, Evan Gilbert wrote: > -1 > > I disagree very strongly with this approach if I'm understanding > correctly. Let me paraphrase to make sure I understand: > > All responses, even those encoded in a browser URL redirect back from the > AS (redirect with verification code in the web server flow and the redirect > with token in the user-agent flow) will be JSON > > This means that we will have a URL-encoded JSON blob as a form parameter > (as it has to play nicely with existing URL parameters). So the response > back in the web server flow would be: > > https://client.com/receiveVerificationCode?existingParam=value&oauth2=%7Bcode%3A'abc123'%2C+state%3A+'randomstatedata'%7D > > and the response back in the user-agent flow would be > > https://client.com/page?existingParam=value&oauth2=%7Baccess_token%3A+'accesstoken1234'%2Cexpires_in%3A3600%2Cstate%3A'randomstatedata'%7D > > Reasons why this is of concern: > - Requires clients to do URL decoding *and* JSON decoding > - Encourages unsafe JSON handling in the User-Agent flow (eval(JSON) = XSS > hole) > - Breaks the simple model we've been creating in these flows. > > Evan > > On Fri, Jun 11, 2010 at 1:51 PM, Robert Sayre wrote: > >> +1 >> >> On Fri, Jun 11, 2010 at 1:17 AM, Naitik Shah wrote: >> > +1 >> > >> > On Thu, Jun 10, 2010 at 5:50 PM, Luke Shepard >> wrote: >> >> >> >> +1 >> >> >> >> On Jun 10, 2010, at 5:46 PM, Manger, James H wrote: >> >> >> >> > +1 >> >> > >> >> > -- >> >> > James Manger >> >> > >> >> > ---------- >> >> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >> Behalf >> >> > Of Eran Hammer-Lahav >> >> > Sent: Friday, 11 June 2010 6:29 AM >> >> > To: OAuth WG (oauth@ietf.org) >> >> > Subject: [OAUTH-WG] Proposal for single JSON response format >> >> > >> >> > - Support a single response format (including in the user-agent >> >> > fragment) using JSON. >> >> > _______________________________________________ >> >> > OAuth mailing 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 >> > >> > >> >> >> >> -- >> >> Robert Sayre >> >> "I would have written a shorter letter, but I did not have the time." >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --90e6ba180eaa66bf4c0489002316 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1 on JSON in response bodies
-1 on JSON in URL query parameters or fra= gments.

Dirk.

On= Sun, Jun 13, 2010 at 2:46 AM, Evan Gilbert <uidude@google.com> wrote:
-1=A0

I d= isagree very strongly with this approach if I'm understanding correctly= .=A0Let me paraphrase to make sure I understand:

All responses, even those encoded in a browser URL redi= rect back from the AS (redirect with verification code in the web server fl= ow and the redirect with token in the user-agent flow) will be JSON

This means that we will have a URL-encoded JSON blob as a form par= ameter (as it has to play nicely with existing URL parameters). So the resp= onse back in the web server flow would be:
=A0=A0https://client.com/recei= veVerificationCode?existingParam=3Dvalue&oauth2=3D%7Bcode%3A'abc123= '%2C+state%3A+'randomstatedata'%7D

Reasons why this is of concern:
- Requires clients to do= URL decoding and=A0JSON decoding
- Encourages unsafe JSON= handling in the User-Agent flow (eval(JSON) =3D XSS hole)
- Brea= ks the simple model we've been creating in these flows.

Evan

On = Fri, Jun 11, 2010 at 1:51 PM, Robert Sayre <sayrer@gmail.com>= wrote:
+1

On Fri, Jun 11, 2010 at 1:17 AM, Naitik Shah <n@daaku.org> wrote:
> +1
>
> On Thu, Jun 10, 2010 at 5:50 PM, Luke Shepard <lshepard@facebook.com> wrote:=
>>
>> +1
>>
>> On Jun 10, 2010, at 5:46 PM, Manger, James H wrote:
>>
>> > +1
>> >
>> > --
>> > James Manger
>> >
>> > ----------
>> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
>> > Of Eran Hammer-Lahav
>> > Sent: Friday, 11 June 2010 6:29 AM
>> > To: OAuth WG (oauth@ietf.org)
>> > Subject: [OAUTH-WG] Proposal for single JSON response format<= br> >> >
>> > - Support a single response format (including in the user-age= nt
>> > fragment) using JSON.
>> > _______________________________________________
>> > OAuth mailing list
>> > OAuth@iet= f.org
>> > https://www.ietf.org/mailman/listinfo/oauth
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org=
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth
>
>



--

Robert Sayre

"I would have written a shorter letter, but I did not have the time.&q= uot;
_______________________________________________=
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


--90e6ba180eaa66bf4c0489002316-- From eran@hueniverse.com Mon Jun 14 09:49:36 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB3323A68BE for ; Mon, 14 Jun 2010 09:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.937 X-Spam-Level: X-Spam-Status: No, score=-0.937 tagged_above=-999 required=5 tests=[AWL=-0.752, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WS+pPL7Frd1x for ; Mon, 14 Jun 2010 09:49:35 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 9A63C3A6821 for ; Mon, 14 Jun 2010 09:49:35 -0700 (PDT) Received: (qmail 11894 invoked from network); 14 Jun 2010 16:49:38 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 14 Jun 2010 16:49:38 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Mon, 14 Jun 2010 09:49:36 -0700 From: Eran Hammer-Lahav To: Justin Richer Date: Mon, 14 Jun 2010 09:49:39 -0700 Thread-Topic: [OAUTH-WG] Draft -07 (major rewrite) Thread-Index: AcsLzLLiOJEY+x3OSoyPj6g7+MaHNwAEUJXg Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB66D4@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <1276525208.7940.7.camel@localhost.localdomain> In-Reply-To: <1276525208.7940.7.camel@localhost.localdomain> 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] Draft -07 (major rewrite) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2010 16:49:36 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSnVzdGluIFJpY2hlciBb bWFpbHRvOmpyaWNoZXJAbWl0cmUub3JnXQ0KPiBTZW50OiBNb25kYXksIEp1bmUgMTQsIDIwMTAg NzoyMCBBTQ0KPiBUbzogRXJhbiBIYW1tZXItTGFoYXYNCj4gQ2M6IE1hcml1cyBTY3VydGVzY3U7 IE9BdXRoIFdHDQo+IFN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIERyYWZ0IC0wNyAobWFqb3IgcmV3 cml0ZSkNCj4gDQo+IEkgZGlzYWdyZWUuIEkgZG9uJ3QgdGhpbmsgaXQncyByZWR1bmRhbnQsIEkg dGhpbmsgaXQncyBhIGNsYXJpZnlpbmcgcGllY2Ugb2YNCj4gaW5mb3JtYXRpb24gdGhhdCBtYWtl cyBpdCBjb21wbGV0ZWx5IHVuYW1iaWd1b3VzIHdoYXQgdGhlIGNsaWVudCBpcw0KPiBleHBlY3Rp bmcgdG8gaGFwcGVuLiBPbiB0aGUgc2VydmVyIHNpZGUsIGEgc2luZ2xlIHN3aXRjaCBpcyBhIG11 Y2ggc2ltcGxlcg0KPiBhbmQgbGVzcyBlcnJvci1wcm9uZSBkaXNwYXRjaCBzdHJ1Y3R1cmUgdGhh biBhIHNldCBvZiAiaWYgdGhpcy1hbmQtdGhhdA0KPiBwYXJhbWV0ZXIgZWxzZSBpZiB0aGlzLW90 aGVyIHBhcmFtZXRlciBlbHNlIGlmIHRoYXQtb3RoZXItYW5kLXNvbWV0aGluZy1lbHNlDQo+IHBh cmFtZXRlciIgc3RhdGVtZW50cy4gSWYgb25lIG9mIG91ciBnb2FscyBvZiBPQXV0aDIgaXMgZWFz aW5nIHRoZQ0KPiBpbXBsZW1lbnRhdGlvbiBmb3IgZGV2ZWxvcGVycywgZHJvcHBpbmcgdGhlICJ0 eXBlIiBmaWVsZCBpcyBhIGJpZyBsb3NlLg0KDQpUaGUgZ29hbCBpcyB0byBtYWtlIGNsaWVudCBk ZXZlbG9wZXJzIGxpZmUgZWFzaWVyLiBJIG5ldmVyIGhlYXJkIG1ha2luZyBpdCBlYXNpZXIgZm9y IHNlcnZlciBkZXZlbG9wZXJzIGlzIGEgZ29hbC4gSW4gZmFjdCwgd2l0aCBhbGwgdGhlIG5ldyBm bG93cyBhbmQgcmVmcmVzaCB0b2tlbiwgT0F1dGggMi4wIGFkZHMgYSBsb3QgbW9yZSBjb21wbGV4 aXR5IHRvIHNldmVyIGRldmVsb3BlcnMuDQoNCj4gQWxzbywgYXMgaGFzIGFscmVhZHkgYmVlbiBw b2ludGVkIG91dCwgaWYgYSBuZXcgZmxvdyBjb21lcyBpbiB0aGF0IHdhbnRzIHRvDQo+IHVzZSBl eGlzdGluZyBwYXJhbWV0ZXJzIGluIGEgZGlmZmVyZW50IHdheSwgdGhlbiBpdCB3b24ndCBmaXQg aW50byB0aGlzDQo+IGZyYW1ld29yayBvciBhbiBleHRlbnNpb24uIERlY3JlYXNpbmcgYW1iaWd1 aXR5IGZvciBhIHNtYWxsIHByaWNlIChhIGZldw0KPiBleHRyYSByZXF1aXJlZCBjaGFyYWN0ZXJz IGZvciB0aGUgYXV0aCBmbG93KSBpcyBhIGdvb2QgdGhpbmcuDQoNCkNyZWF0aW5nIGEgY2xlYXIg ZnJhbWV3b3JrIHdpdGggYSB3ZWxsLWRlZmluZWQgbW9kZWwgd2lucyBvdmVyIHRoZSBhYmlsaXR5 IHRvIGV4dGVuZCBhbnl0aGluZyB5b3UgZmVlbCBsaWtlIGJ5IGRlZmluaW5nIGEgbmV3IHBhcmFt ZXRlciB2YWx1ZS4gVGhlIG9yaWdpbmFsICd0eXBlJyBwYXJhbWV0ZXIgdGFsa2VkIGFib3V0IHRo ZSBraW5kIG9mICpmbG93KiBiZWluZyB1c2VkLiBJdCBiYXNpY2FsbHkgdXNlZCB0aGUgT3BlbklE ICdtb2RlJyBhcmNoaXRlY3R1cmUgb2YgYSBzaW5nbGUgZW5kcG9pbnQgb3ZlcmxvYWRlZCB3aXRo IHVucmVsYXRlZCBhY3Rpdml0aWVzLg0KDQpJdCB0dXJucyBvdXQgdGhhdCB3ZSBhY3R1YWxseSBj cmVhdGVkIGEgY2xlYW4gbW9kZWwgd2hlcmUgeW91IHJlcXVlc3QgYSB0b2tlbiB1c2luZyBvbmUg b2YgNCBhdXRob3JpemF0aW9uIGdyYW50IGNvbnN0cnVjdHMuIElmIHlvdSBpZ25vcmUgdGhlIGRl dmljZSByZXF1ZXN0IGZvciB2ZXJpZmljYXRpb24gY29kZSAod2hpY2ggZG9lc24ndCBmZWV0IHRo ZSAiVG9rZW4gRW5kcG9pbnQiIGRlZmluaXRpb24gYW55d2F5KSwgdGhlIG1vZGVsIGlzIGNvbXBs ZXRlbHkgY29uc2lzdGVudC4gVXNpbmcgdGhpcyBlbmRwb2ludCBub3cgdG8gZGVsZXRlIGEgdG9r ZW4gd291bGQgYnJlYWsgdGhpcy4NCg0KQSBtdWNoIGNsZWFuZXIgYXBwcm9hY2ggaXMgdG8gZGVm aW5lIGEgbmV3IGVuZHBvaW50LCBlaXRoZXIgYSBmaXhlZCBvbmUgb3IgYXMgYSByZXR1cm4gdmFs dWUgd2l0aCB0aGUgdG9rZW4gKGFzIHByZXZpb3VzbHkgc3VnZ2VzdGVkIGJ5IEphbWVzKS4NCiAN Cj4gSW5jaWRlbnRhbGx5LCBJIGFncmVlIHRoYXQgdGhlIHJlZnJlc2ggZmxvdyBzaG91bGQgZml0 IGluIHdpdGggYWxsIG9mIHRoZSBvdGhlcg0KPiBmbG93cywgYnV0IHdpdGggInR5cGU9cmVmcmVz aCIuIE1heWJlICJ0eXBlIiBpcyB0aGUgd3Jvbmcgd29yZCBmb3IgdGhpcw0KPiBwYXJhbWV0ZXI/ IEJlY2F1c2UgSSB3YXMgZW52aXNpb25pbmcgdGhlIHJlc2NvcGUgYW5kIHJldm9rZSBvcGVyYXRp b25zIHRvDQo+IGJlIHNpbWlsYXIgdG8gdGhlIHJlZnJlc2ggb3BlcmF0aW9uLg0KDQpSZWZyZXNo aW5nIGEgdG9rZW4gaXMgbm90aGluZyBtb3JlIHRoYW4gYXNraW5nIGZvciBhIG5ldyB0b2tlbiB1 c2luZyBhbiBhdXRob3JpemF0aW9uIGdyYW50IG9mIHR5cGUgcmVmcmVzaCB0b2tlbi4gSXQgaXMg ZXhhY3RseSB0aGUgc2FtZSBhcyB1c2luZyBhIHZlcmlmaWNhdGlvbiBjb2RlIG9yIGVuZC11c2Vy IGNyZWRlbnRpYWxzLg0KDQo+IFVzaW5nIEhUVFAgREVMRVRFIGlzIGEgYmFkIGlkZWEgc2luY2Ug aXQNCj4gd291bGQgcmVxdWlyZSBlYWNoIHRva2VuIHRvIGhhdmUgYSBVUkwgYXNzb2NpYXRlZCB3 aXRoIGl0DQoNCllvdSBzaG91bGQgc3RpbGwgYmUgYWJsZSB0byBwdXQgdGhlIGFjY2VzcyB0b2tl biBpbiBhIHBhcmFtZXRlciB1c2luZyBhIERFTEVURSBvcGVyYXRpb24uIEknbSBub3QgYXdhcmUg b2YgYW55IGxpbWl0YXRpb24gb24gdXNpbmcgcXVlcnkgcGFyYW1ldGVycyB3aXRoIGEgREVMRVRF IG9wZXJhdGlvbi4gQ2FuIHlvdSBwb2ludCBtZSB0byB3aGVyZSB0aGlzIHJlc3RyaWN0aW9uIGlz IGRlZmluZWQ/DQoNCj4gYW5kIHlvdSBjYW4gbm8gbG9uZ2VyIG1hbmlwdWxhdGUgdGhlIE9BdXRo IEFQSSB3aXRoIGp1c3QgcXVlcnkgcGFyYW1ldGVycy4NCg0KV2VsbCwgd2UgZG9uJ3QgYWN0dWFs bHkgdXNlIHF1ZXJ5IHBhcmFtZXRlcnMsIHdlIHVzZSBmb3JtLWVuY29kZWQgYm9keSBwYXJhbWV0 ZXJzLg0KDQo+IEEgInR5cGU9cmV2b2tlIiBjYWxsIHdpdGggdGhlIHJlZnJlc2ggdG9rZW4gYXMg YXV0aGVudGljYXRpb24gYW5kIHRoZSB0b2tlbi0NCj4gdG8tYmUtcmV2b2tlZCBhcyBwYXJhbWV0 ZXIgbWFrZXMgYSB3aG9sZSBsb3QgbW9yZSBzZW5zZSB0byBtZS4gIEl0IGtlZXBzDQo+IHRoZXNl IHRocmVlIG9wZXJhdGlvbnMgcGFyYWxsZWwgdG8gdGhlIG90aGVyIGF1dGhvcml6YXRpb24gZmxv d3MgLS0gcGFydCBvZiB0aGUNCj4gd2hvbGUgImhvdyB0byBnZXQgYSB0b2tlbiIgc2lkZSBvZiBP QXV0aC4NCg0KQXMgc3RhdGVkIGVhcmxpZXIsIEknbSBvayB3aXRoIGEgcGFyYW1ldGVyIGluZGlj YXRpbmcgdGhlIGtpbmQgb2YgYXV0aG9yaXphdGlvbiBncmFudCBiZWluZyB1c2VkLiBCdXQgdGhh dCB3aWxsIG5vdCBzb2x2ZSB5b3VyIHVzZSBjYXNlLg0KDQpVc2luZyB0aGUgcmVmcmVzaCB0b2tl biBhcyBhdXRoZW50aWNhdGlvbiB3aWxsIG5vdCB3b3JrIGZvciB0aGUgbWFueSBjYXNlcyB3aGVy ZSBubyBzdWNoIHRva2VuIGlzIGlzc3VlZC4gU2VuZGluZyBqdXN0IHRoZSBhY2Nlc3MgdG9rZW4g aXMgZW5vdWdoIC0gaWYgYW4gYWNjZXNzIHRva2VuIGFsb25lIGlzIHNlY3VyZSBlbm91Z2ggdG8g YWNjZXNzIHByb3RlY3RlZCByZXNvdXJjZXMsIGl0IGlzIGNsZWFybHkgc2VjdXJlIGVub3VnaCB0 byByZXZva2UgaXQuDQoNCkluIGdlbmVyYWwsIEkgYW0gc3RpbGwgbm90IGNsZWFyIG9uIHRoZSB0 b2tlbiBtb2RpZmljYXRpb24gcmVxdWlyZW1lbnRzIChkZWxldGUsIHJlLXNjb3BlKS4gSXQgd291 bGQgYmUgdXNlZnVsIHRvIGRpc2N1c3MgaG93IGl0IHdvdWxkIGJlIHVzZWQgaW4gcHJhY3RpY2Ug KHdoYXQga2luZCBvZiBjbGllbnRzLCBmb3Igd2hhdCBwdXJwb3NlLCBldGMuKSwgYW5kIHdoYXQg ZXhpc3RpbmcgZXhwZXJpZW5jZSB3ZSBoYXZlIHRvIHVzZSBhcyByZWZlcmVuY2UuIEZvciBub3cs IGFkZGluZyB0b2tlbiByZXZvY2F0aW9uIGFuZCByZS1zY29waW5nIHNlZW1zIGJldHRlciBzdWl0 ZWQgdG8gYW4gZXh0ZW5zaW9uIHRoYW4gdGhlIGNvcmUgc3BlY2lmaWNhdGlvbi4NCg0KRUhMDQoN Cg0K From eran@hueniverse.com Mon Jun 14 10:00:48 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA36C3A688E for ; Mon, 14 Jun 2010 10:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.916 X-Spam-Level: X-Spam-Status: No, score=-0.916 tagged_above=-999 required=5 tests=[AWL=-0.731, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lrh93dzw8yEW for ; Mon, 14 Jun 2010 10:00:47 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id D39733A6821 for ; Mon, 14 Jun 2010 10:00:47 -0700 (PDT) Received: (qmail 21094 invoked from network); 14 Jun 2010 17:00:52 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 14 Jun 2010 17:00:52 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 14 Jun 2010 10:00:43 -0700 From: Eran Hammer-Lahav To: "OAuth WG (oauth@ietf.org)" Date: Mon, 14 Jun 2010 10:00:46 -0700 Thread-Topic: [OAUTH-WG] Proposal for single JSON response format Thread-Index: AcsI3APo4e3qZ4sfTEm7y77nD5MoAADBovXQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB66E4@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF73EF@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] Proposal for single JSON response format X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2010 17:00:48 -0000 So far we have 16 people supporting using JSON as the only response format = for the token endpoint with no objections. Draft -07 reflects this change. = I am considering this matter closed, but if someone has a late objection, f= eel free to raise it. As for using JSON in the fragment or query of the end-user authorization en= dpoint response, two people voiced specific objections to that. For now, -0= 7 contains an editorial note about that option (using JSON). I think it is = worth further (separate) discussion. EHL On Jun 10, 2010, at 2:29 PM, Eran Hammer-Lahav wrote: > After taking a break from our previous debate(s) on the issue of which re= sponse format to support, I would like to suggest the following: >=20 > - Support a single response format (including in the user-agent fragment)= using JSON. >=20 > My reason for this is very simple, while right now we have a very limited= need (key/value pairs), we already have a few proposals which require a ri= cher syntax. As OAuth matures, I expect more and more extensions to make us= e of the server response to include additional parameters (flat or structur= ed). By using JSON, we can very easily support "namespaces" (i.e. { "access= _token":"xyz","ext":{...} }), multiple token in a single response, etc. >=20 > I appreciate the simplicity in using form-encoded (both code and library = dependency wise), but long term, it will create a real limitation and will = require extensions to also specify a different response format. >=20 > Those worried about the need to include a JSON library in cases where it = will be hard to do (embedded devices, etc.), can always extend the protocol= to provide a way to receive key/value form-encoded pairs. However, they wi= ll need to figure out how to accommodate structured responses if they wish = support it. I am certain that the vast majority of implementations will hav= e no problem including a JSON library. >=20 > Please respond only with yes or no (+/- 1). If you have a different propo= sal, please post it in a new thread. If you are going to vote against this,= please indicate if your objection is blocking (i.e. you are opposed to it = and will block a consensus call with this approach). >=20 > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Mon Jun 14 10:05:38 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 212C73A68BE for ; Mon, 14 Jun 2010 10:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[AWL=0.497, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a3IROsiWGVLC for ; Mon, 14 Jun 2010 10:05:37 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 4EBEA3A6817 for ; Mon, 14 Jun 2010 10:05:37 -0700 (PDT) Received: (qmail 23797 invoked from network); 14 Jun 2010 17:05:41 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 14 Jun 2010 17:05:41 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 14 Jun 2010 10:05:40 -0700 From: Eran Hammer-Lahav To: Dick Hardt , "OAuth WG (oauth@ietf.org)" Date: Mon, 14 Jun 2010 10:05:43 -0700 Thread-Topic: [OAUTH-WG] 5.3.1.2 Normalized String Construction Thread-Index: Acr88gBSNxOhOw4CThatkx4BGPnOAwO8aGVg Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB66ED@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <926FECBD-5AAE-4EC6-A238-09F75BD12B1A@gmail.com> In-Reply-To: <926FECBD-5AAE-4EC6-A238-09F75BD12B1A@gmail.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] 5.3.1.2 Normalized String Construction X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2010 17:05:38 -0000 Since the secret is bound to the token anyway, changing the access token wi= ll break the signature (unless you know that two tokens have the same secre= t - which implies you know the secret too). I can add it but I'm not sure how important it is. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Dick Hardt > Sent: Wednesday, May 26, 2010 9:39 AM > To: OAuth WG (oauth@ietf.org) > Subject: [OAUTH-WG] 5.3.1.2 Normalized String Construction >=20 > The access token is not in the string that is signed. Is this a mistake o= r am I > missing something? >=20 > -- Dick >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Mon Jun 14 10:10:46 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D45DF3A69B1 for ; Mon, 14 Jun 2010 10:10:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.084 X-Spam-Level: X-Spam-Status: No, score=0.084 tagged_above=-999 required=5 tests=[AWL=-1.717, BAYES_50=0.001, J_CHICKENPOX_54=0.6, J_CHICKENPOX_66=0.6, J_CHICKENPOX_83=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sIKPbqDXUw3c for ; Mon, 14 Jun 2010 10:10:40 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 46C4C3A699E for ; Mon, 14 Jun 2010 10:10:40 -0700 (PDT) Received: (qmail 26840 invoked from network); 14 Jun 2010 17:10:44 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 14 Jun 2010 17:10:44 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 14 Jun 2010 10:10:44 -0700 From: Eran Hammer-Lahav To: Torsten Lodderstedt Date: Mon, 14 Jun 2010 10:10:47 -0700 Thread-Topic: [OAUTH-WG] in-app logout? Thread-Index: Acr9APKTavEaYka8RjymzK/fm2BAmAO4w9QQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB66F0@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4BEBDCFB.7090503@lodderstedt.net> <255B9BB34FB7D647A506DC292726F6E11263465727@WSMSG3153V.srv.dir.telstra.com> <4BFD67CA.5040600@lodderstedt.net> In-Reply-To: <4BFD67CA.5040600@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 \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] in-app logout? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2010 17:10:47 -0000 Not so much text as details. Does revoking the refresh token also revokes any access token issued with i= t? Do we need a way to revoke other authorization grants, such as a verificati= on code? Do we need a way to revoke an individual access token? Does revoking means the end-user has to grant authorization again (explicit= ly)? Or just the refresh token and the server may issue another refresh tok= en to the client based on some client-end-user authorization mapping? EHL > -----Original Message----- > From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > Sent: Wednesday, May 26, 2010 11:26 AM > To: Eran Hammer-Lahav > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] in-app logout? >=20 > Hi Eran, >=20 > in my perception, there is some support on the list for having a request = to > revoke refresh tokens. Will you add such a request to the specification? = Do > you need a text proposal? >=20 > regards, > Torsten. >=20 > > IMHO this would look more like a hack than proper protocol design. We > > need a delete/revoke operation that's the pendant to the other token > operations (i.e. > > crud ops). > > > > Hubert > > > > > > > > On Fri, May 21, 2010 at 7:05 PM, Beau > Lebens wrote: > > > >> Could this just be implemented through support for a scope change > >> where scope=3Dnone or revoke or something? > >> > >> On Friday, May 21, 2010, Lukas Rosenstock > wrote: > >> > >>> Why not simply add this functionality to the token endpoint?The same > place that was used to fetch the access token first or refresh it could b= e used > to revoke the same token with another request. The only requirement > would be to define something like type=3Drevoke. > >>> I feel that is much easier than making the token a URL which supports > DELETE. > >>> However, any mechanism will break implementations that rely on > minimal or no communication between authorization server and protected > resource, because all protected resources have to be informed. > >>> > >>> Regards, Lukas > >>> > >>> 2010/5/16 Dick Hardt > >>> > >>> James: An important capability of the refresh token is that it *can* = be a > self contained token in that is not an id, but a signed token that can be > examined and acted upon on presentation. > >>> Torsten: enabling a client to revoke a refresh token looks like a use= ful > mechanism. I anticipate it will be viewed as a vitamin feature rather tha= n a > painkiller and will fall by the wayside unless the security conscience ra= lly to > have it included. > >>> > >>> > >>> -- Dick > >>> > >>> > >>> On Thu, May 13, 2010 at 7:10 AM, Manger, James > H wrote: > >>> Torsten, > >>> > >>> > >>>> What about refresh token revocation/deletion? > >>>> > >>> HTTP already has a method to do this: DELETE It just needs each > >>> token to have a URI. > >>> > >>> Tokens (almost) already have URIs -- its just not immediately obvious > because the URI has to be built from a common token endpoint and a > refresh_token. > >>> > >>> I think it would improve the spec if refresh_token was renamed to, sa= y, > token_id; and its value defined as a URI (which can be a relative URI so = the > string may not need to change at all). > >>> > >>> To refresh a token you POST to the token's URI. > >>> To delete a token you send a DELETE request to the token's URI. > >>> > >>> It doesn't cause major changes, but there are some benefits. > >>> It is a more web-style design. > >>> It leaves only 1 type of token in the spec -- an access token -- whic= h > simplifies the text and aids understanding. > >>> There are no arguments about length, allowed chars etc because it is = a > URI -- a well-known type, often with native support. > >>> Its obvious how to delete the token as there is a standard HTTP metho= d > DELETE to apply to the token URI. > >>> > >>> If a particular service supported an additional way to delete items i= n its > API (eg POST with a method=3Ddelete query parameter) that could apply to > the OAuth part as well. > >>> > >>> -- > >>> James Manger > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth > >>> > >>> > >>> > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth > >>> > >>> > >>> > >>> -- > >>> http://lukasrosenstock.net/ > >>> > >>> > >>> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > >> > >> > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > >=20 From eran@hueniverse.com Mon Jun 14 10:14:54 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72B503A68D9 for ; Mon, 14 Jun 2010 10:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.071 X-Spam-Level: X-Spam-Status: No, score=-2.071 tagged_above=-999 required=5 tests=[AWL=0.528, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wnf4iAnoLjZF for ; Mon, 14 Jun 2010 10:14:53 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 2DBE83A69BB for ; Mon, 14 Jun 2010 10:14:53 -0700 (PDT) Received: (qmail 28654 invoked from network); 14 Jun 2010 17:14:57 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 14 Jun 2010 17:14:56 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Mon, 14 Jun 2010 10:14:54 -0700 From: Eran Hammer-Lahav To: "OAuth WG (oauth@ietf.org)" Date: Mon, 14 Jun 2010 10:14:57 -0700 Thread-Topic: Draft iteration frequency Thread-Index: AcsL5R02SmpppNDcTe+6JgpsgZMEPA== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB66F1@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: NSI= BLOV BVzT Byky DFp9 DVNt FEqf Fkz/ F4z/ Ge4p GncY Hi1o Hk2U H7e7 ICey IF40; 1; bwBhAHUAdABoAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {10CC473D-30E0-4AF9-8180-E4193FD73FEF}; ZQByAGEAbgBAAGgAdQBlAG4AaQB2AGUAcgBzAGUALgBjAG8AbQA=; Mon, 14 Jun 2010 17:14:57 GMT; RAByAGEAZgB0ACAAaQB0AGUAcgBhAHQAaQBvAG4AIABmAHIAZQBxAHUAZQBuAGMAeQA= x-cr-puzzleid: {10CC473D-30E0-4AF9-8180-E4193FD73FEF} acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OAUTH-WG] Draft iteration frequency X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2010 17:14:54 -0000 I am now making daily changes to the draft. I check these changes in daily = (sometimes more) to my github account [1] but I'm not clear how often do pe= ople here wants me to submit those as I-D revisions. Frequent submission ma= kes it harder for people to read and provide feedback because there always = seems to be a newer draft, but also keeps the discussion focused on IETF do= cuments, not personal copies elsewhere. Preferences? EHL [1] http://github.com/theRazorBlade/draft-ietf-oauth From beaton@google.com Mon Jun 14 10:15:37 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E882828C0E8 for ; Mon, 14 Jun 2010 10:15:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.327 X-Spam-Level: X-Spam-Status: No, score=-101.327 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4rHRPyxtxlKL for ; Mon, 14 Jun 2010 10:15:35 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 763A03A69D4 for ; Mon, 14 Jun 2010 10:15:35 -0700 (PDT) Received: from hpaq12.eem.corp.google.com (hpaq12.eem.corp.google.com [172.25.149.12]) by smtp-out.google.com with ESMTP id o5EHFZiu027326 for ; Mon, 14 Jun 2010 10:15:35 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1276535736; bh=KYVIW8+nxND4wFOD+OjO5ptehlE=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=gtqfr+zSPJQZ26+PFhApU5EtjZ+MTR7tPpbojzorLUyOD7Vh+DZ8CFoEJmgDZ/h3S JiWhAz+/pkCbFgoYxyC4g== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type; b=lJBbP7/KCXAt4xFveYvUTJvsfkPTVdCokrPVw0Zko7QoszOI4x/kp0J2V+8JpyuHp QC+ebnGmQhd34OC0k9MfA== Received: from pwj8 (pwj8.prod.google.com [10.241.219.72]) by hpaq12.eem.corp.google.com with ESMTP id o5EHFYOv027721 for ; Mon, 14 Jun 2010 10:15:35 -0700 Received: by pwj8 with SMTP id 8so3035044pwj.4 for ; Mon, 14 Jun 2010 10:15:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.25.2 with SMTP id c2mr4212638wfj.147.1276535733950; Mon, 14 Jun 2010 10:15:33 -0700 (PDT) Received: by 10.142.207.21 with HTTP; Mon, 14 Jun 2010 10:15:33 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB66E4@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF73EF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3EBB66E4@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 14 Jun 2010 10:15:33 -0700 Message-ID: From: Brian Eaton To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Proposal for single JSON response format X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2010 17:15:37 -0000 On Mon, Jun 14, 2010 at 10:00 AM, Eran Hammer-Lahav wrote: > So far we have 16 people supporting using JSON as the only response format > for the token endpoint with no objections. Draft -07 reflects this change. I am > considering this matter closed, but if someone has a late objection, feel free to raise it. > > As for using JSON in the fragment or query of the end-user authorization > endpoint response, two people voiced specific objections to that. For now, > -07 contains an editorial note about that option (using JSON). I think it is > worth further (separate) discussion. Sounds good to me. (I completely missed that the proposal was to use JSON in redirect URLs. Evan, thanks for catching that, and Eran, thanks for flagging it as something that requires more discussion.) Cheers, Brian From paul.madsen@gmail.com Mon Jun 14 10:19:50 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68F1D3A69B1 for ; Mon, 14 Jun 2010 10:19:50 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nmonJG-1oflL for ; Mon, 14 Jun 2010 10:19:49 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 8880D3A688E for ; Mon, 14 Jun 2010 10:19:49 -0700 (PDT) Received: by vws9 with SMTP id 9so5514405vws.31 for ; Mon, 14 Jun 2010 10:19:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=yNqGL95SPEy7OJ/RDrHmV+LXy+IEsejrga+0jUffGUE=; b=Pks6GMOVnxHXec4hUWGEMc9lvgvxs2k9XtMA5Cq2l1wYVz/SRYNYdT8Tr26IEXGFJG B9PS0mLIMRl23meyskFnNHl21L3x3IWp/9jWC/aQi8YI7M5fdLGAWoKaRIlX+6otizUN 2zNZqbXasmJCraFftG5xeMu6mW9XLrFuCZhSU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=NubCrsjuUdnKuQCMBtSjpTy4+uYVTH1Ppi/lMNDZukblX04HcdXiRAI6+ZcqQlpmDu 07jLgNNxSzujUoENAUhLbhxOLMEK77PeR4eDMC9RRKBoSJ/qZmq1UdLZL0t2merAJknJ lCFjDeAbc48pf5ZVNRv/0m1AniiLaDVT9fPUc= Received: by 10.224.52.233 with SMTP id j41mr2428952qag.234.1276535989694; Mon, 14 Jun 2010 10:19:49 -0700 (PDT) Received: from [192.168.0.168] (CPE0022b0cb82b4-CM0012256eb4b4.cpe.net.cable.rogers.com [99.224.152.177]) by mx.google.com with ESMTPS id f34sm12222914qco.23.2010.06.14.10.19.48 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 14 Jun 2010 10:19:48 -0700 (PDT) Message-ID: <4C1664B4.80904@gmail.com> Date: Mon, 14 Jun 2010 13:19:48 -0400 From: Paul Madsen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: "OAuth WG (oauth@ietf.org)" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [OAUTH-WG] Extensibility model in 07? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2010 17:19:50 -0000 Hi Eran, you indicated last week there would be a first cut of an extensibility model in 07. Deferred to 08? Thanks From beaton@google.com Mon Jun 14 11:23:31 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EFC13A6977 for ; Mon, 14 Jun 2010 11:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.544 X-Spam-Level: X-Spam-Status: No, score=-101.544 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p5LcJEd0YG-5 for ; Mon, 14 Jun 2010 11:23:30 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id DD2D13A68D3 for ; Mon, 14 Jun 2010 11:23:28 -0700 (PDT) Received: from wpaz13.hot.corp.google.com (wpaz13.hot.corp.google.com [172.24.198.77]) by smtp-out.google.com with ESMTP id o5EINS8S024428 for ; Mon, 14 Jun 2010 11:23:28 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1276539809; bh=ajRgBnhnxNEIPdgyxKZlHCPvjqI=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=KcWEd2+teH2Gsy1eMZUUBYoOQna2HwRt8stnmxKN9legFFzCtVzOMFpYIAxV6UUIb Pqaw+QGzeUf69m2Zfpzcw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding; b=J/6W/GnI8ST/fBZohg04PjxqVqTrfP0rQJ4AimkcgGDWFryuz/ZQWYFTthiEpi/Us wI9Vba3i2S+bHpxMVcLJA== Received: from pwj4 (pwj4.prod.google.com [10.241.219.68]) by wpaz13.hot.corp.google.com with ESMTP id o5EINCGQ009005 for ; Mon, 14 Jun 2010 11:23:27 -0700 Received: by pwj4 with SMTP id 4so2736306pwj.10 for ; Mon, 14 Jun 2010 11:23:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.26.16 with SMTP id d16mr4325095wfj.318.1276539807093; Mon, 14 Jun 2010 11:23:27 -0700 (PDT) Received: by 10.142.207.21 with HTTP; Mon, 14 Jun 2010 11:23:26 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB66AC@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF76BC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3EBB66AC@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 14 Jun 2010 11:23:26 -0700 Message-ID: From: Brian Eaton To: Eran Hammer-Lahav Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Draft -07 (major rewrite) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2010 18:23:31 -0000 On Mon, Jun 14, 2010 at 9:18 AM, Eran Hammer-Lahav wr= ote: > Adding a verification code to the user-agent flow was suggested on this l= ist > and received nothing but support. It was suggested as a solution to a > Twitter use case. Once that is added in, the two flows only differ in how > the response is delivered and the presence of an access token in the > response (which currently is a MUST NOT for web-server but I don=92t know= if > this restriction is need). Yeah, this matters. If you return an access token on the web-server flow, several things break: - you can no longer rely on the client secret to authenticate the callback = URL. - you lose all hope of getting to LOA 2 with this protocol, because the access token is visible to the client. - you lose the clarity of how the web server flow is supposed to work. Bike-shed painting: The use-cases for web server and user-agent flow are also different. I'd prefer to have the spec call out different profiles for different use-cases, because it makes it much easier to figure out what a given application should be doing. During the WRAP work I argued that we didn't need a type parameter, and after looking at WRAP implementations I've changed my mind. Please leave it in. Cheers, Brian From beaton@google.com Mon Jun 14 11:27:58 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21FCB3A68D3 for ; Mon, 14 Jun 2010 11:27:58 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gr7ayL8ZbNyN for ; Mon, 14 Jun 2010 11:27:57 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 1FA333A68CC for ; Mon, 14 Jun 2010 11:27:57 -0700 (PDT) Received: from hpaq3.eem.corp.google.com (hpaq3.eem.corp.google.com [172.25.149.3]) by smtp-out.google.com with ESMTP id o5EIS04c010032 for ; Mon, 14 Jun 2010 11:28:00 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1276540080; bh=s2rOPu0ro1ob5Ic/nQoCtYf6Qf0=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=ro20DKaCtEXX91JDkHOmXOPdZvI8Fi3XDrkDK7zs4Jw76aQ7GbyirODuFRRQYkAGt Hm2eAWxRfSQLCKVhP7K1A== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding; b=PZLFte7VO+yV2MhTE6xZ2qhpNnQTWNaVrN3zwdkDOmjHx0ILniwEvVLiMhDWKofIU i8xfqgrRVriV4CJvhxKtg== Received: from pva4 (pva4.prod.google.com [10.241.209.4]) by hpaq3.eem.corp.google.com with ESMTP id o5EIRwGK008449 for ; Mon, 14 Jun 2010 11:27:58 -0700 Received: by pva4 with SMTP id 4so3221933pva.16 for ; Mon, 14 Jun 2010 11:27:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.122.4 with SMTP id u4mr4245338wfc.202.1276540077772; Mon, 14 Jun 2010 11:27:57 -0700 (PDT) Received: by 10.142.207.21 with HTTP; Mon, 14 Jun 2010 11:27:57 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF76BC@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 14 Jun 2010 11:27:57 -0700 Message-ID: From: Brian Eaton To: Andrew Arnott Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Draft -07 (major rewrite) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2010 18:27:58 -0000 On Mon, Jun 14, 2010 at 8:23 AM, Andrew Arnott wro= te: > And apparently now the user-agent flow can receive a > verification code as well as an access token?=A0 It's unclear what that's= for > or how that's used. Here's the thread where Brian Ellin proposed the verification code on the user-agent flow. http://www.ietf.org/mail-archive/web/oauth/current/msg02657.html Summary of why it's a good idea: - makes it easier to recover from compromise of refresh tokens - makes refresh token compromise less likely, because it is never passed via the browser - clear upgrade path from embeddable widgets to "server-side integrations Cheers, Brian From torsten@lodderstedt.net Mon Jun 14 11:30:25 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 464123A6974 for ; Mon, 14 Jun 2010 11:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.924 X-Spam-Level: X-Spam-Status: No, score=0.924 tagged_above=-999 required=5 tests=[AWL=-1.227, BAYES_50=0.001, HELO_EQ_DE=0.35, J_CHICKENPOX_54=0.6, J_CHICKENPOX_66=0.6, J_CHICKENPOX_83=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8JYBQI0oXFtz for ; Mon, 14 Jun 2010 11:30:22 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.42]) by core3.amsl.com (Postfix) with ESMTP id 6E9A73A68D3 for ; Mon, 14 Jun 2010 11:30:18 -0700 (PDT) Received: from p4fff0cbe.dip.t-dialin.net ([79.255.12.190] helo=[127.0.0.1]) by smtprelay04.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OOEQN-0007L6-Kn; Mon, 14 Jun 2010 20:30:19 +0200 Message-ID: <4C16753A.9050802@lodderstedt.net> Date: Mon, 14 Jun 2010 20:30:18 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <4BEBDCFB.7090503@lodderstedt.net> <255B9BB34FB7D647A506DC292726F6E11263465727@WSMSG3153V.srv.dir.telstra.com> <4BFD67CA.5040600@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3EBB66F0@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB66F0@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] in-app logout? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2010 18:30:25 -0000 Am 14.06.2010 19:10, schrieb Eran Hammer-Lahav: > Not so much text as details. > > Does revoking the refresh token also revokes any access token issued with it? > no (or optionally). It's not easy to implement in conjuction with self-contained tokens. I would prefer to use short living access tokens instead. > Do we need a way to revoke other authorization grants, such as a verification code? > I don't see a need. Verification codes should expire very quickly and are one-time use only. > Do we need a way to revoke an individual access token? > I currently don't see a need. I would prefer to use short living access tokens instead. > Does revoking means the end-user has to grant authorization again (explicitly)? Or just the refresh token and the server may issue another refresh token to the client based on some client-end-user authorization mapping? > I think both options are reasonable. regards, Torsten. > EHL > > >> -----Original Message----- >> From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] >> Sent: Wednesday, May 26, 2010 11:26 AM >> To: Eran Hammer-Lahav >> Cc: OAuth WG (oauth@ietf.org) >> Subject: Re: [OAUTH-WG] in-app logout? >> >> Hi Eran, >> >> in my perception, there is some support on the list for having a request to >> revoke refresh tokens. Will you add such a request to the specification? Do >> you need a text proposal? >> >> regards, >> Torsten. >> >> >>> IMHO this would look more like a hack than proper protocol design. We >>> need a delete/revoke operation that's the pendant to the other token >>> >> operations (i.e. >> >>> crud ops). >>> >>> Hubert >>> >>> >>> >>> On Fri, May 21, 2010 at 7:05 PM, Beau >>> >> Lebens wrote: >> >>> >>>> Could this just be implemented through support for a scope change >>>> where scope=none or revoke or something? >>>> >>>> On Friday, May 21, 2010, Lukas Rosenstock >>>> >> wrote: >> >>>> >>>>> Why not simply add this functionality to the token endpoint?The same >>>>> >> place that was used to fetch the access token first or refresh it could be used >> to revoke the same token with another request. The only requirement >> would be to define something like type=revoke. >> >>>>> I feel that is much easier than making the token a URL which supports >>>>> >> DELETE. >> >>>>> However, any mechanism will break implementations that rely on >>>>> >> minimal or no communication between authorization server and protected >> resource, because all protected resources have to be informed. >> >>>>> Regards, Lukas >>>>> >>>>> 2010/5/16 Dick Hardt >>>>> >>>>> James: An important capability of the refresh token is that it *can* be a >>>>> >> self contained token in that is not an id, but a signed token that can be >> examined and acted upon on presentation. >> >>>>> Torsten: enabling a client to revoke a refresh token looks like a useful >>>>> >> mechanism. I anticipate it will be viewed as a vitamin feature rather than a >> painkiller and will fall by the wayside unless the security conscience rally to >> have it included. >> >>>>> >>>>> -- Dick >>>>> >>>>> >>>>> On Thu, May 13, 2010 at 7:10 AM, Manger, James >>>>> >> H wrote: >> >>>>> Torsten, >>>>> >>>>> >>>>> >>>>>> What about refresh token revocation/deletion? >>>>>> >>>>>> >>>>> HTTP already has a method to do this: DELETE It just needs each >>>>> token to have a URI. >>>>> >>>>> Tokens (almost) already have URIs -- its just not immediately obvious >>>>> >> because the URI has to be built from a common token endpoint and a >> refresh_token. >> >>>>> I think it would improve the spec if refresh_token was renamed to, say, >>>>> >> token_id; and its value defined as a URI (which can be a relative URI so the >> string may not need to change at all). >> >>>>> To refresh a token you POST to the token's URI. >>>>> To delete a token you send a DELETE request to the token's URI. >>>>> >>>>> It doesn't cause major changes, but there are some benefits. >>>>> It is a more web-style design. >>>>> It leaves only 1 type of token in the spec -- an access token -- which >>>>> >> simplifies the text and aids understanding. >> >>>>> There are no arguments about length, allowed chars etc because it is a >>>>> >> URI -- a well-known type, often with native support. >> >>>>> Its obvious how to delete the token as there is a standard HTTP method >>>>> >> DELETE to apply to the token URI. >> >>>>> If a particular service supported an additional way to delete items in its >>>>> >> API (eg POST with a method=delete query parameter) that could apply to >> the OAuth part as well. >> >>>>> -- >>>>> James Manger >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> >>>>> >>>>> -- >>>>> http://lukasrosenstock.net/ >>>>> >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> OAuth mailing 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 Mon Jun 14 11:38:45 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E45863A697A for ; Mon, 14 Jun 2010 11:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.084 X-Spam-Level: X-Spam-Status: No, score=-2.084 tagged_above=-999 required=5 tests=[AWL=0.515, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id laIn1RIcj9mo for ; Mon, 14 Jun 2010 11:38:45 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id C13953A6973 for ; Mon, 14 Jun 2010 11:38:44 -0700 (PDT) Received: (qmail 25160 invoked from network); 14 Jun 2010 18:38:48 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 14 Jun 2010 18:38:48 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 14 Jun 2010 11:38:46 -0700 From: Eran Hammer-Lahav To: Brian Eaton Date: Mon, 14 Jun 2010 11:38:49 -0700 Thread-Topic: [OAUTH-WG] Draft -07 (major rewrite) Thread-Index: AcsL7rOg3MqPu4OlQfmb9F6+uitxlAAAfyVw Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB675A@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF76BC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3EBB66AC@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 \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Draft -07 (major rewrite) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2010 18:38:46 -0000 > -----Original Message----- > From: Brian Eaton [mailto:beaton@google.com] > Sent: Monday, June 14, 2010 11:23 AM > To: Eran Hammer-Lahav > Cc: Andrew Arnott; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Draft -07 (major rewrite) >=20 > On Mon, Jun 14, 2010 at 9:18 AM, Eran Hammer-Lahav > wrote: > > Adding a verification code to the user-agent flow was suggested on > > this list and received nothing but support. It was suggested as a > > solution to a Twitter use case. Once that is added in, the two flows > > only differ in how the response is delivered and the presence of an > > access token in the response (which currently is a MUST NOT for > > web-server but I don't know if this restriction is need). >=20 > Yeah, this matters. If you return an access token on the web-server flow= , > several things break: > - you can no longer rely on the client secret to authenticate the callbac= k URL. > - you lose all hope of getting to LOA 2 with this protocol, because the a= ccess > token is visible to the client. > - you lose the clarity of how the web server flow is supposed to work. Ok. No change needed. =20 > Bike-shed painting: >=20 > The use-cases for web server and user-agent flow are also different. > I'd prefer to have the spec call out different profiles for different use= -cases, > because it makes it much easier to figure out what a given application sh= ould > be doing. >=20 > During the WRAP work I argued that we didn't need a type parameter, and > after looking at WRAP implementations I've changed my mind. > Please leave it in. Which one? The type on the end-user authorization endpoint (user_agent and = web_server) or the type on the token endpoint? EHL From eran@hueniverse.com Mon Jun 14 11:39:13 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DBB83A68A7 for ; Mon, 14 Jun 2010 11:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[AWL=0.502, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qkVZ2hWx30EH for ; Mon, 14 Jun 2010 11:39:12 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id CD3263A69BD for ; Mon, 14 Jun 2010 11:39:11 -0700 (PDT) Received: (qmail 22961 invoked from network); 14 Jun 2010 18:39:16 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 14 Jun 2010 18:39:15 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 14 Jun 2010 11:39:15 -0700 From: Eran Hammer-Lahav To: Paul Madsen , "OAuth WG (oauth@ietf.org)" Date: Mon, 14 Jun 2010 11:39:18 -0700 Thread-Topic: [OAUTH-WG] Extensibility model in 07? Thread-Index: AcsL5dMTn67/aGhlQE+Py/vOV0AA3wACwX0Q Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB675B@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4C1664B4.80904@gmail.com> In-Reply-To: <4C1664B4.80904@gmail.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] Extensibility model in 07? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2010 18:39:13 -0000 Yeah. I need to finish the big rewrite before adding new stuff. I plan to g= et this done this week. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Paul Madsen > Sent: Monday, June 14, 2010 10:20 AM > To: OAuth WG (oauth@ietf.org) > Subject: [OAUTH-WG] Extensibility model in 07? >=20 > Hi Eran, you indicated last week there would be a first cut of an extensi= bility > model in 07. >=20 > Deferred to 08? >=20 > Thanks > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From torsten@lodderstedt.net Mon Jun 14 12:21:46 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9E503A68CC for ; Mon, 14 Jun 2010 12:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.204 X-Spam-Level: X-Spam-Status: No, score=-1.204 tagged_above=-999 required=5 tests=[AWL=1.045, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xrWbu3kDz5Tw for ; Mon, 14 Jun 2010 12:21:44 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.29.28]) by core3.amsl.com (Postfix) with ESMTP id 6997E3A699A for ; Mon, 14 Jun 2010 12:21:43 -0700 (PDT) Received: from p4fff0cbe.dip.t-dialin.net ([79.255.12.190] helo=[127.0.0.1]) by smtprelay03.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OOFE9-0002UI-3g; Mon, 14 Jun 2010 21:21:45 +0200 Message-ID: <4C168147.5070000@lodderstedt.net> Date: Mon, 14 Jun 2010 21:21:43 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB66F1@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB66F1@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Draft iteration frequency X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2010 19:21:46 -0000 I would prefer a frequency of once a week. regards, Torsten. Am 14.06.2010 19:14, schrieb Eran Hammer-Lahav: > I am now making daily changes to the draft. I check these changes in daily (sometimes more) to my github account [1] but I'm not clear how often do people here wants me to submit those as I-D revisions. Frequent submission makes it harder for people to read and provide feedback because there always seems to be a newer draft, but also keeps the discussion focused on IETF documents, not personal copies elsewhere. > > Preferences? > > EHL > > [1] http://github.com/theRazorBlade/draft-ietf-oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From recordond@gmail.com Mon Jun 14 13:09:25 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 058583A6876 for ; Mon, 14 Jun 2010 13:09:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[AWL=0.504, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DMixCPoyz9-6 for ; Mon, 14 Jun 2010 13:09:23 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 854653A6359 for ; Mon, 14 Jun 2010 13:09:23 -0700 (PDT) Received: by iwn41 with SMTP id 41so1591970iwn.31 for ; Mon, 14 Jun 2010 13:09:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=fk57FNsi9/s97Wj0J9nVmzFzOJga4eHRKHd/OOrO9LM=; b=U+f355z6jciBhbJ4faz1YPkBOOEqv0rq/IBKO1GGxMSYcKGG06ixCSrTJFDX/TPUxm gy1iKd+P1TXE+J+FVASZ0EGX8cujO+reBC+sEx6Xe995Gqk+UPl7ZFTZ7pvV4u8ktMVU iWND+zHE5iGtXpvs/wvw2V+J/t7D5mLk7I8AQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=XW1QCDI0FB/QlLSR5fajwfwdpUEvXu8Sm2DUhn6zj+bnkTAWjDS9NbtERPnBOk8ks4 mLzXjhzvyG9qivn41eJE4IHv4dbAehh/lL6AfXCgzFaOypn4sHU06ENwGRITn2DYOu8C R/bTMafVGtPtGuVxYiAn1tiKoX/zWCLYprs9g= MIME-Version: 1.0 Received: by 10.231.188.150 with SMTP id da22mr6129050ibb.191.1276546164489; Mon, 14 Jun 2010 13:09:24 -0700 (PDT) Received: by 10.231.192.4 with HTTP; Mon, 14 Jun 2010 13:09:24 -0700 (PDT) In-Reply-To: <4C165356.3090505@cdatazone.org> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF729E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3EAF7328@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C165356.3090505@cdatazone.org> Date: Mon, 14 Jun 2010 13:09:24 -0700 Message-ID: From: David Recordon To: Rob Richards Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Identifying OAuth 2.0 vs 1.0 requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2010 20:09:25 -0000 It's easy to detect version when calling a protected resource. In OAuth 2.0 you only have one token parameter whereas 1.0 has a variety of parameters including a signature. --David On Mon, Jun 14, 2010 at 9:05 AM, Rob Richards wro= te: > Wouldn't it make sense to require the oauth_version parameter under 2.0 f= or > resource calls so that the two versions can be distinguished? > > Rob > > Paul Lindner wrote: >> >> If you're routing requests with a load balancer it's not so trivial. >> Instead of a substring match you're talking about a regex with negative >> lookahead matching -- that's why the presence of the signature param is >> essential to distinguishing between 2.0/1.0a. >> >> On Thu, Jun 10, 2010 at 10:42 AM, Eran Hammer-Lahav > > wrote: >> >> =A0 =A0But in that case, all the other oauth_* parameters are missing. >> =A0 =A0It's trivial. >> >> =A0 =A0EHL >> >> =A0 =A0> -----Original Message----- >> =A0 =A0> From: Marius Scurtescu [mailto:mscurtescu@google.com >> =A0 =A0] >> =A0 =A0> Sent: Thursday, June 10, 2010 10:39 AM >> =A0 =A0> To: Paul Lindner >> =A0 =A0> Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org >> =A0 =A0) >> =A0 =A0> Subject: Re: [OAUTH-WG] Identifying OAuth 2.0 vs 1.0 requests >> =A0 =A0> >> =A0 =A0> I run into the same issue. In section "4.2. URI Query >> =A0 =A0Parameter", it would >> =A0 =A0> help if the parameter name, oauth_token, was different from OAu= th 1. >> =A0 =A0> >> =A0 =A0> Marius >> =A0 =A0> >> =A0 =A0> >> =A0 =A0> >> =A0 =A0> On Thu, Jun 10, 2010 at 9:41 AM, Paul Lindner > =A0 =A0> wrote: >> =A0 =A0> > I am talking about the resource server. Specifically I want t= o >> =A0 =A0be able >> =A0 =A0> > to quickly determine if an incoming request is 1.0a vs 2.0. >> =A0 =A0 And since >> =A0 =A0> > this is a library it can't make a lot of assumptions about th= e >> =A0 =A0> > specific environment it's running in. >> =A0 =A0> > At first I thought I would check the oauth_version parameter.= =A0It >> =A0 =A0> > turns out the 1.0a spec says that it is optional. =A0The only >> =A0 =A0one that >> =A0 =A0> > is required for 1.0a is oauth_signature_method. >> =A0 =A0> > Sadly we're long past time to change the spec to optimize for >> =A0 =A0this use-case. >> =A0 =A0> > =A0(It would have been better to have a parameter for oauth 2= .0 >> =A0 =A0that is >> =A0 =A0> > distinct from 1.0a) =A0At the very least this message will li= ve >> =A0 =A0on in >> =A0 =A0> > the mailing list archives -- at best we document the proper w= ay to >> =A0 =A0> > distinguish between the two versions somewhere. >> =A0 =A0> > On Thu, Jun 10, 2010 at 8:44 AM, Eran Hammer-Lahav >> =A0 =A0> > > >> =A0 =A0> > wrote: >> =A0 =A0> >> >> =A0 =A0> >> The request is very different on the resource server. On the >> =A0 =A0> >> authorization server, why would you use the same endpoint? >> =A0 =A0> >> >> =A0 =A0> >> >> =A0 =A0> >> >> =A0 =A0> >> EHL >> =A0 =A0> >> >> =A0 =A0> >> >> =A0 =A0> >> >> =A0 =A0> >> From: oauth-bounces@ietf.org >> =A0 =A0[mailto:oauth-bounces@ietf.org ] O= n >> =A0 =A0> >> Behalf Of Paul Lindner >> =A0 =A0> >> Sent: Thursday, June 10, 2010 8:24 AM >> =A0 =A0> >> To: OAuth WG (oauth@ietf.org ) >> =A0 =A0> >> Subject: [OAUTH-WG] Identifying OAuth 2.0 vs 1.0 requests >> =A0 =A0> >> >> =A0 =A0> >> >> =A0 =A0> >> >> =A0 =A0> >> Hi, >> =A0 =A0> >> >> =A0 =A0> >> >> =A0 =A0> >> >> =A0 =A0> >> As I've been working through our oauth2 implementation I've >> =A0 =A0noticed >> =A0 =A0> >> that it's not easy to disambiguate OAuth 1.0a vs 2.0 API >> =A0 =A0calls based >> =A0 =A0> >> on the request parameters alone. =A0 Based on some >> =A0 =A0investigative at the >> =A0 =A0> >> Shindig project it appears that the only standard way to to >> =A0 =A0determine >> =A0 =A0> >> 1.0a vs 2.0 is by checking for the oauth_signature_method >> =A0 =A0> parameter. =A0More info here: >> =A0 =A0> >> >> =A0 =A0> >> >> =A0 =A0> >> >> =A0 =A0> >> https://issues.apache.org/jira/browse/SHINDIG-1361 >> =A0 =A0> >> >> =A0 =A0> >> >> =A0 =A0> >> >> =A0 =A0> >> Has anyone else considered this use case? =A0How did you sol= ve it? >> =A0 =A0> >> >> =A0 =A0> >> >> =A0 =A0> > >> =A0 =A0> > _______________________________________________ >> =A0 =A0> > OAuth mailing list >> =A0 =A0> > OAuth@ietf.org >> =A0 =A0> > https://www.ietf.org/mailman/listinfo/oauth >> =A0 =A0> > >> =A0 =A0> > >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> OAuth mailing 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 lindner@inuus.com Mon Jun 14 13:46:31 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 542EB3A68E7 for ; Mon, 14 Jun 2010 13:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aI2fCRNaTicH for ; Mon, 14 Jun 2010 13:46:28 -0700 (PDT) Received: from mail-yw0-f179.google.com (mail-yw0-f179.google.com [209.85.211.179]) by core3.amsl.com (Postfix) with ESMTP id 452763A635F for ; Mon, 14 Jun 2010 13:46:27 -0700 (PDT) Received: by ywh9 with SMTP id 9so4879289ywh.17 for ; Mon, 14 Jun 2010 13:46:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.91.126.15 with SMTP id d15mr4927122agn.37.1276548384282; Mon, 14 Jun 2010 13:46:24 -0700 (PDT) Received: by 10.90.30.11 with HTTP; Mon, 14 Jun 2010 13:46:24 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF729E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3EAF7328@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C165356.3090505@cdatazone.org> Date: Mon, 14 Jun 2010 13:46:24 -0700 Message-ID: From: Paul Lindner To: David Recordon Content-Type: multipart/alternative; boundary=001485f921f2fbd76a0489039486 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Identifying OAuth 2.0 vs 1.0 requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2010 20:46:31 -0000 --001485f921f2fbd76a0489039486 Content-Type: text/plain; charset=ISO-8859-1 As stated previously the easy way to determine OAuth 1.0 vs 2.0 without using negative assertions is to check for the presence of oauth_signature_method On Mon, Jun 14, 2010 at 1:09 PM, David Recordon wrote: > It's easy to detect version when calling a protected resource. In > OAuth 2.0 you only have one token parameter whereas 1.0 has a variety > of parameters including a signature. > > --David > > > On Mon, Jun 14, 2010 at 9:05 AM, Rob Richards > wrote: > > Wouldn't it make sense to require the oauth_version parameter under 2.0 > for > > resource calls so that the two versions can be distinguished? > > > > Rob > > > > Paul Lindner wrote: > >> > >> If you're routing requests with a load balancer it's not so trivial. > >> Instead of a substring match you're talking about a regex with negative > >> lookahead matching -- that's why the presence of the signature param is > >> essential to distinguishing between 2.0/1.0a. > >> > >> On Thu, Jun 10, 2010 at 10:42 AM, Eran Hammer-Lahav < > eran@hueniverse.com > >> > wrote: > >> > >> But in that case, all the other oauth_* parameters are missing. > >> It's trivial. > >> > >> EHL > >> > >> > -----Original Message----- > >> > From: Marius Scurtescu [mailto:mscurtescu@google.com > >> ] > >> > Sent: Thursday, June 10, 2010 10:39 AM > >> > To: Paul Lindner > >> > Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org > >> ) > >> > Subject: Re: [OAUTH-WG] Identifying OAuth 2.0 vs 1.0 requests > >> > > >> > I run into the same issue. In section "4.2. URI Query > >> Parameter", it would > >> > help if the parameter name, oauth_token, was different from OAuth > 1. > >> > > >> > Marius > >> > > >> > > >> > > >> > On Thu, Jun 10, 2010 at 9:41 AM, Paul Lindner >> > wrote: > >> > > I am talking about the resource server. Specifically I want to > >> be able > >> > > to quickly determine if an incoming request is 1.0a vs 2.0. > >> And since > >> > > this is a library it can't make a lot of assumptions about the > >> > > specific environment it's running in. > >> > > At first I thought I would check the oauth_version parameter. It > >> > > turns out the 1.0a spec says that it is optional. The only > >> one that > >> > > is required for 1.0a is oauth_signature_method. > >> > > Sadly we're long past time to change the spec to optimize for > >> this use-case. > >> > > (It would have been better to have a parameter for oauth 2.0 > >> that is > >> > > distinct from 1.0a) At the very least this message will live > >> on in > >> > > the mailing list archives -- at best we document the proper way > to > >> > > distinguish between the two versions somewhere. > >> > > On Thu, Jun 10, 2010 at 8:44 AM, Eran Hammer-Lahav > >> > > > > >> > > wrote: > >> > >> > >> > >> The request is very different on the resource server. On the > >> > >> authorization server, why would you use the same endpoint? > >> > >> > >> > >> > >> > >> > >> > >> EHL > >> > >> > >> > >> > >> > >> > >> > >> From: oauth-bounces@ietf.org > >> [mailto:oauth-bounces@ietf.org ] On > >> > >> Behalf Of Paul Lindner > >> > >> Sent: Thursday, June 10, 2010 8:24 AM > >> > >> To: OAuth WG (oauth@ietf.org ) > >> > >> Subject: [OAUTH-WG] Identifying OAuth 2.0 vs 1.0 requests > >> > >> > >> > >> > >> > >> > >> > >> Hi, > >> > >> > >> > >> > >> > >> > >> > >> As I've been working through our oauth2 implementation I've > >> noticed > >> > >> that it's not easy to disambiguate OAuth 1.0a vs 2.0 API > >> calls based > >> > >> on the request parameters alone. Based on some > >> investigative at the > >> > >> Shindig project it appears that the only standard way to to > >> determine > >> > >> 1.0a vs 2.0 is by checking for the oauth_signature_method > >> > parameter. More info here: > >> > >> > >> > >> > >> > >> > >> > >> https://issues.apache.org/jira/browse/SHINDIG-1361 > >> > >> > >> > >> > >> > >> > >> > >> Has anyone else considered this use case? How did you solve it? > >> > >> > >> > >> > >> > > > >> > > _______________________________________________ > >> > > OAuth mailing 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 > > > --001485f921f2fbd76a0489039486 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable As stated previously the easy way to determine OAuth 1.0 vs 2.0 without usi= ng negative assertions is to check for the presence of oauth_signature_meth= od

On Mon, Jun 14, 2010 at 1:09 PM, Davi= d Recordon <rec= ordond@gmail.com> wrote:
It's easy to detect version when callin= g a protected resource. In
OAuth 2.0 you only have one token parameter whereas 1.0 has a variety
of parameters including a signature.

--David


On Mon, Jun 14, 2010 at 9:05 AM, Rob Richards <rrichards@cdatazone.org> wrote:
> Wouldn't it make sense to require the oauth_version parameter unde= r 2.0 for
> resource calls so that the two versions can be distinguished?
>
> Rob
>
> Paul Lindner wrote:
>>
>> If you're routing requests with a load balancer it's not s= o trivial.
>> Instead of a substring match you're talking about a regex with= negative
>> lookahead matching -- that's why the presence of the signature= param is
>> essential to distinguishing between 2.0/1.0a.
>>
>> On Thu, Jun 10, 2010 at 10:42 AM, Eran Hammer-Lahav <eran@hueniverse.com
>> <mailto:eran@hueniverse.= com>> wrote:
>>
>> =A0 =A0But in that case, all the other oauth_* parameters are miss= ing.
>> =A0 =A0It's trivial.
>>
>> =A0 =A0EHL
>>
>> =A0 =A0> -----Original Message-----
>> =A0 =A0> From: Marius Scurtescu [mailto:mscurtescu@google.com
>> =A0 =A0<mailto:mscurte= scu@google.com>]
>> =A0 =A0> Sent: Thursday, June 10, 2010 10:39 AM
>> =A0 =A0> To: Paul Lindner
>> =A0 =A0> Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org
>> =A0 =A0<mailto:oauth@ietf.org= >)
>> =A0 =A0> Subject: Re: [OAUTH-WG] Identifying OAuth 2.0 vs 1.0 r= equests
>> =A0 =A0>
>> =A0 =A0> I run into the same issue. In section "4.2. URI Q= uery
>> =A0 =A0Parameter", it would
>> =A0 =A0> help if the parameter name, oauth_token, was different= from OAuth 1.
>> =A0 =A0>
>> =A0 =A0> Marius
>> =A0 =A0>
>> =A0 =A0>
>> =A0 =A0>
>> =A0 =A0> On Thu, Jun 10, 2010 at 9:41 AM, Paul Lindner <lindner@inuus.com
>> =A0 =A0<mailto:lindner@inu= us.com>> wrote:
>> =A0 =A0> > I am talking about the resource server. Specifica= lly I want to
>> =A0 =A0be able
>> =A0 =A0> > to quickly determine if an incoming request is 1.= 0a vs 2.0.
>> =A0 =A0 And since
>> =A0 =A0> > this is a library it can't make a lot of assu= mptions about the
>> =A0 =A0> > specific environment it's running in.
>> =A0 =A0> > At first I thought I would check the oauth_versio= n parameter. =A0It
>> =A0 =A0> > turns out the 1.0a spec says that it is optional.= =A0The only
>> =A0 =A0one that
>> =A0 =A0> > is required for 1.0a is oauth_signature_method. >> =A0 =A0> > Sadly we're long past time to change the spec= to optimize for
>> =A0 =A0this use-case.
>> =A0 =A0> > =A0(It would have been better to have a parameter= for oauth 2.0
>> =A0 =A0that is
>> =A0 =A0> > distinct from 1.0a) =A0At the very least this mes= sage will live
>> =A0 =A0on in
>> =A0 =A0> > the mailing list archives -- at best we document = the proper way to
>> =A0 =A0> > distinguish between the two versions somewhere. >> =A0 =A0> > On Thu, Jun 10, 2010 at 8:44 AM, Eran Hammer-Laha= v
>> =A0 =A0> > <eran@h= ueniverse.com <mailto:eran@hu= eniverse.com>>
>> =A0 =A0> > wrote:
>> =A0 =A0> >>
>> =A0 =A0> >> The request is very different on the resource= server. On the
>> =A0 =A0> >> authorization server, why would you use the s= ame endpoint?
>> =A0 =A0> >>
>> =A0 =A0> >>
>> =A0 =A0> >>
>> =A0 =A0> >> EHL
>> =A0 =A0> >>
>> =A0 =A0> >>
>> =A0 =A0> >>
>> =A0 =A0> >> From: oauth-bounces@ietf.org <mailto:oauth-bounces@ietf.org>
>> =A0 =A0[mailto:oauth-bou= nces@ietf.org <mailto:oaut= h-bounces@ietf.org>] On
>> =A0 =A0> >> Behalf Of Paul Lindner
>> =A0 =A0> >> Sent: Thursday, June 10, 2010 8:24 AM
>> =A0 =A0> >> To: OAuth WG (oauth@ietf.org <mailto:oauth@ie= tf.org>)
>> =A0 =A0> >> Subject: [OAUTH-WG] Identifying OAuth 2.0 vs = 1.0 requests
>> =A0 =A0> >>
>> =A0 =A0> >>
>> =A0 =A0> >>
>> =A0 =A0> >> Hi,
>> =A0 =A0> >>
>> =A0 =A0> >>
>> =A0 =A0> >>
>> =A0 =A0> >> As I've been working through our oauth2 i= mplementation I've
>> =A0 =A0noticed
>> =A0 =A0> >> that it's not easy to disambiguate OAuth = 1.0a vs 2.0 API
>> =A0 =A0calls based
>> =A0 =A0> >> on the request parameters alone. =A0 Based on= some
>> =A0 =A0investigative at the
>> =A0 =A0> >> Shindig project it appears that the only stan= dard way to to
>> =A0 =A0determine
>> =A0 =A0> >> 1.0a vs 2.0 is by checking for the oauth_sign= ature_method
>> =A0 =A0> parameter. =A0More info here:
>> =A0 =A0> >>
>> =A0 =A0> >>
>> =A0 =A0> >>
>> =A0 =A0> >> https://issues.apache.org/jira/browse/S= HINDIG-1361
>> =A0 =A0> >>
>> =A0 =A0> >>
>> =A0 =A0> >>
>> =A0 =A0> >> Has anyone else considered this use case? =A0= How did you solve it?
>> =A0 =A0> >>
>> =A0 =A0> >>
>> =A0 =A0> >
>> =A0 =A0> > _______________________________________________ >> =A0 =A0> > OAuth mailing list
>> =A0 =A0> > OAuth@ietf.org<= /a> <mailto:OAuth@ietf.org>
>> =A0 =A0> > https://www.ietf.org/mailman/listinfo/oauth >> =A0 =A0> >
>> =A0 =A0> >
>>
>>
>> ------------------------------------------------------------------= ------
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--001485f921f2fbd76a0489039486-- From eran@hueniverse.com Mon Jun 14 13:56:35 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D75003A635F for ; Mon, 14 Jun 2010 13:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.091 X-Spam-Level: X-Spam-Status: No, score=0.091 tagged_above=-999 required=5 tests=[AWL=-1.710, BAYES_50=0.001, J_CHICKENPOX_54=0.6, J_CHICKENPOX_66=0.6, J_CHICKENPOX_83=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h3JmBDrlQ5z0 for ; Mon, 14 Jun 2010 13:56:34 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 5DF4E3A6984 for ; Mon, 14 Jun 2010 13:56:34 -0700 (PDT) Received: (qmail 27396 invoked from network); 14 Jun 2010 20:56:36 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 14 Jun 2010 20:56:36 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Mon, 14 Jun 2010 13:56:31 -0700 From: Eran Hammer-Lahav To: Torsten Lodderstedt Date: Mon, 14 Jun 2010 13:56:35 -0700 Thread-Topic: [OAUTH-WG] in-app logout? Thread-Index: AcsL76dIklVHVQb3TtKjiBr3sg/bNAAFB3hA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB680C@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4BEBDCFB.7090503@lodderstedt.net> <255B9BB34FB7D647A506DC292726F6E11263465727@WSMSG3153V.srv.dir.telstra.com> <4BFD67CA.5040600@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3EBB66F0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C16753A.9050802@lodderstedt.net> In-Reply-To: <4C16753A.9050802@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 \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] in-app logout? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2010 20:56:35 -0000 Since refresh token is only issued to clients capable of directly interacti= ng with the authorization server, is there a reason why the endpoint cannot= use DELETE instead of a POST with a parameter? DELETE /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded =20 grant_type=3Drefresh_token&client_id=3Ds6BhdRkqt3&client_secret=3D8eSEIpn= qmM&refresh_token=3Dn4E9O119d This looks like an elegant way of doing things. I'm not sure about using th= e token endpoint for this, but that's a separate issue. EHL > -----Original Message----- > From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > Sent: Monday, June 14, 2010 11:30 AM > To: Eran Hammer-Lahav > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] in-app logout? >=20 >=20 >=20 > Am 14.06.2010 19:10, schrieb Eran Hammer-Lahav: > > Not so much text as details. > > > > Does revoking the refresh token also revokes any access token issued wi= th > it? > > > no (or optionally). It's not easy to implement in conjuction with self- > contained tokens. I would prefer to use short living access tokens instea= d. >=20 > > Do we need a way to revoke other authorization grants, such as a > verification code? > > >=20 > I don't see a need. Verification codes should expire very quickly and are= one- > time use only. >=20 > > Do we need a way to revoke an individual access token? > > >=20 > I currently don't see a need. I would prefer to use short living access t= okens > instead. >=20 > > Does revoking means the end-user has to grant authorization again > (explicitly)? Or just the refresh token and the server may issue another > refresh token to the client based on some client-end-user authorization > mapping? > > >=20 > I think both options are reasonable. >=20 > regards, > Torsten. >=20 > > EHL > > > > > >> -----Original Message----- > >> From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > >> Sent: Wednesday, May 26, 2010 11:26 AM > >> To: Eran Hammer-Lahav > >> Cc: OAuth WG (oauth@ietf.org) > >> Subject: Re: [OAUTH-WG] in-app logout? > >> > >> Hi Eran, > >> > >> in my perception, there is some support on the list for having a > >> request to revoke refresh tokens. Will you add such a request to the > >> specification? Do you need a text proposal? > >> > >> regards, > >> Torsten. > >> > >> > >>> IMHO this would look more like a hack than proper protocol design. > >>> We need a delete/revoke operation that's the pendant to the other > >>> token > >>> > >> operations (i.e. > >> > >>> crud ops). > >>> > >>> Hubert > >>> > >>> > >>> > >>> On Fri, May 21, 2010 at 7:05 PM, Beau > >>> > >> Lebens wrote: > >> > >>> > >>>> Could this just be implemented through support for a scope change > >>>> where scope=3Dnone or revoke or something? > >>>> > >>>> On Friday, May 21, 2010, Lukas Rosenstock > >>>> > >> wrote: > >> > >>>> > >>>>> Why not simply add this functionality to the token endpoint?The > >>>>> same > >>>>> > >> place that was used to fetch the access token first or refresh it > >> could be used to revoke the same token with another request. The only > >> requirement would be to define something like type=3Drevoke. > >> > >>>>> I feel that is much easier than making the token a URL which > >>>>> supports > >>>>> > >> DELETE. > >> > >>>>> However, any mechanism will break implementations that rely on > >>>>> > >> minimal or no communication between authorization server and > >> protected resource, because all protected resources have to be informe= d. > >> > >>>>> Regards, Lukas > >>>>> > >>>>> 2010/5/16 Dick Hardt > >>>>> > >>>>> James: An important capability of the refresh token is that it > >>>>> *can* be a > >>>>> > >> self contained token in that is not an id, but a signed token that > >> can be examined and acted upon on presentation. > >> > >>>>> Torsten: enabling a client to revoke a refresh token looks like a > >>>>> useful > >>>>> > >> mechanism. I anticipate it will be viewed as a vitamin feature rather > >> than a painkiller and will fall by the wayside unless the security > >> conscience rally to have it included. > >> > >>>>> > >>>>> -- Dick > >>>>> > >>>>> > >>>>> On Thu, May 13, 2010 at 7:10 AM, Manger, James > >>>>> > >> H wrote: > >> > >>>>> Torsten, > >>>>> > >>>>> > >>>>> > >>>>>> What about refresh token revocation/deletion? > >>>>>> > >>>>>> > >>>>> HTTP already has a method to do this: DELETE It just needs each > >>>>> token to have a URI. > >>>>> > >>>>> Tokens (almost) already have URIs -- its just not immediately > >>>>> obvious > >>>>> > >> because the URI has to be built from a common token endpoint and a > >> refresh_token. > >> > >>>>> I think it would improve the spec if refresh_token was renamed to, > >>>>> say, > >>>>> > >> token_id; and its value defined as a URI (which can be a relative URI > >> so the string may not need to change at all). > >> > >>>>> To refresh a token you POST to the token's URI. > >>>>> To delete a token you send a DELETE request to the token's URI. > >>>>> > >>>>> It doesn't cause major changes, but there are some benefits. > >>>>> It is a more web-style design. > >>>>> It leaves only 1 type of token in the spec -- an access token -- > >>>>> which > >>>>> > >> simplifies the text and aids understanding. > >> > >>>>> There are no arguments about length, allowed chars etc because it > >>>>> is a > >>>>> > >> URI -- a well-known type, often with native support. > >> > >>>>> Its obvious how to delete the token as there is a standard HTTP > >>>>> method > >>>>> > >> DELETE to apply to the token URI. > >> > >>>>> If a particular service supported an additional way to delete > >>>>> items in its > >>>>> > >> API (eg POST with a method=3Ddelete query parameter) that could apply > >> to the OAuth part as well. > >> > >>>>> -- > >>>>> James Manger > >>>>> _______________________________________________ > >>>>> OAuth mailing list > >>>>> OAuth@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> OAuth mailing list > >>>>> OAuth@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> http://lukasrosenstock.net/ > >>>>> > >>>>> > >>>>> > >>>>> > >>>> _______________________________________________ > >>>> OAuth mailing 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 dick.hardt@gmail.com Mon Jun 14 14:12:04 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF7993A6933 for ; Mon, 14 Jun 2010 14:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5-eq5piecRa for ; Mon, 14 Jun 2010 14:12:03 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id 99AE93A691D for ; Mon, 14 Jun 2010 14:12:03 -0700 (PDT) Received: by pxi5 with SMTP id 5so917109pxi.31 for ; Mon, 14 Jun 2010 14:12:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=OWqHCSCGHMCXna/lp/On2VlVfxxIbuMPRQR8R4Lrkvw=; b=N6BJQaIj3bxgyPnHtBie5KuYJxorcV5zhMU/dXNVeYgFsB7RImzcPu6dnYOzqhyhZS ycHoH2r79tk/O/qsfxtgHEE85mQ/WLUsEtQelN/rBRVkhS7mZLXcQYdwcbZcPYZXjc8v JRu8ql5hDqVHSzFm60pDVHD8VlN4CjgMh5MCY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=aPE2N5pRhsXfEBPQEVKBJqbbmXOacg7lxSf0shVD+GsQ16jPYkidhNPGO9uc7y+7Me SixiMJc5w49cRPHyjvV4qi2cp0y9aPq3c03t7LgsjUV0wHNHxzlmR5QlF/Y5Ml+sDQ71 bFhevJ9RM2flgt5/Ym8oSHnBVDyGQE2r4HZZg= MIME-Version: 1.0 Received: by 10.142.74.19 with SMTP id w19mr4391369wfa.20.1276549924862; Mon, 14 Jun 2010 14:12:04 -0700 (PDT) Received: by 10.142.57.4 with HTTP; Mon, 14 Jun 2010 14:12:04 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF73EF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3EBB66E4@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 14 Jun 2010 14:12:04 -0700 Message-ID: From: Dick Hardt To: Brian Eaton Content-Type: multipart/alternative; boundary=001636d34bfecf3d32048903f0a7 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Proposal for single JSON response format X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2010 21:12:05 -0000 --001636d34bfecf3d32048903f0a7 Content-Type: text/plain; charset=ISO-8859-1 +1 (JSON in direct response, separate discussion on redirect response) On Mon, Jun 14, 2010 at 10:15 AM, Brian Eaton wrote: > On Mon, Jun 14, 2010 at 10:00 AM, Eran Hammer-Lahav > wrote: > > So far we have 16 people supporting using JSON as the only response > format > > for the token endpoint with no objections. Draft -07 reflects this > change. I am > > considering this matter closed, but if someone has a late objection, feel > free to raise it. > > > > As for using JSON in the fragment or query of the end-user authorization > > endpoint response, two people voiced specific objections to that. For > now, > > -07 contains an editorial note about that option (using JSON). I think it > is > > worth further (separate) discussion. > > Sounds good to me. > > (I completely missed that the proposal was to use JSON in redirect > URLs. Evan, thanks for catching that, and Eran, thanks for flagging > it as something that requires more discussion.) > > Cheers, > Brian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001636d34bfecf3d32048903f0a7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1 (JSON in direct response, separate discussion on redirect response)
<= br>
On Mon, Jun 14, 2010 at 10:15 AM, Brian Eaton= <beaton@google.c= om> wrote:
On Mon, Jun 14, 2010 at 1= 0:00 AM, Eran Hammer-Lahav <eran@= hueniverse.com> wrote:
> So far we have 16 people supporting using JSON as the only response fo= rmat
> for the token endpoint with no objections. Draft -07 reflects this cha= nge. I am
> considering this matter closed, but if someone has a late objection, f= eel free to raise it.
>
> As for using JSON in the fragment or query of the end-user authorizati= on
> endpoint response, two people voiced specific objections to that. For = now,
> -07 contains an editorial note about that option (using JSON). I think= it is
> worth further (separate) discussion.

Sounds good to me.

(I completely missed that the proposal was to use JSON in redirect
URLs. =A0Evan, thanks for catching that, and Eran, thanks for flagging
it as something that requires more discussion.)

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

--001636d34bfecf3d32048903f0a7-- From rrichards@cdatazone.org Mon Jun 14 14:12:33 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31F3C3A6933 for ; Mon, 14 Jun 2010 14:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c6QcAJyutiZL for ; Mon, 14 Jun 2010 14:12:29 -0700 (PDT) Received: from smtp2go.com (smtp2go.com [207.58.142.213]) by core3.amsl.com (Postfix) with ESMTP id BED043A69E3 for ; Mon, 14 Jun 2010 14:12:27 -0700 (PDT) Received: from [67.158.171.203] (helo=Rob-Richardss-MacBook-Pro.local) by smtp2go.com with esmtp (Exim 4.69) (envelope-from ) id 1OOGxJ-00029H-1k; Mon, 14 Jun 2010 21:12:29 +0000 Message-ID: <4C169B3B.80301@cdatazone.org> Date: Mon, 14 Jun 2010 17:12:27 -0400 From: Rob Richards User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Paul Lindner References: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF729E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3EAF7328@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C165356.3090505@cdatazone.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SMTP2Go-MailScanner-Information: Please contact support@smtp2go.com for more information X-SMTP2Go-MailScanner-ID: 1OOGxJ-00029H-1k X-SMTP2Go-MailScanner: Found to be clean X-SMTP2Go-MailScanner-From: rrichards@cdatazone.org Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Identifying OAuth 2.0 vs 1.0 requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2010 21:12:33 -0000 Both of those scenarios could also be bad 1.0 calls where a 400 error needs to be thrown due to missing a required parameter. So worse case is that every single parameter from a 1.0 calls needs to be checked that at least one of them exists in the call and then its still possible that it could be a bad 1.0 although it looks like 2.0. Rob Paul Lindner wrote: > As stated previously the easy way to determine OAuth 1.0 vs 2.0 > without using negative assertions is to check for the presence of > oauth_signature_method > > On Mon, Jun 14, 2010 at 1:09 PM, David Recordon > wrote: > > It's easy to detect version when calling a protected resource. In > OAuth 2.0 you only have one token parameter whereas 1.0 has a variety > of parameters including a signature. > > --David > > > On Mon, Jun 14, 2010 at 9:05 AM, Rob Richards > > wrote: > > Wouldn't it make sense to require the oauth_version parameter > under 2.0 for > > resource calls so that the two versions can be distinguished? > > > > Rob > > > > Paul Lindner wrote: > >> > >> If you're routing requests with a load balancer it's not so > trivial. > >> Instead of a substring match you're talking about a regex with > negative > >> lookahead matching -- that's why the presence of the signature > param is > >> essential to distinguishing between 2.0/1.0a. > >> > >> On Thu, Jun 10, 2010 at 10:42 AM, Eran Hammer-Lahav > > >> >> wrote: > >> > >> But in that case, all the other oauth_* parameters are missing. > >> It's trivial. > >> > >> EHL > >> > >> > -----Original Message----- > >> > From: Marius Scurtescu [mailto:mscurtescu@google.com > > >> >] > >> > Sent: Thursday, June 10, 2010 10:39 AM > >> > To: Paul Lindner > >> > Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org > > >> >) > >> > Subject: Re: [OAUTH-WG] Identifying OAuth 2.0 vs 1.0 requests > >> > > >> > I run into the same issue. In section "4.2. URI Query > >> Parameter", it would > >> > help if the parameter name, oauth_token, was different > from OAuth 1. > >> > > >> > Marius > >> > > >> > > >> > > >> > On Thu, Jun 10, 2010 at 9:41 AM, Paul Lindner > > >> >> wrote: > >> > > I am talking about the resource server. Specifically I > want to > >> be able > >> > > to quickly determine if an incoming request is 1.0a vs 2.0. > >> And since > >> > > this is a library it can't make a lot of assumptions > about the > >> > > specific environment it's running in. > >> > > At first I thought I would check the oauth_version > parameter. It > >> > > turns out the 1.0a spec says that it is optional. The only > >> one that > >> > > is required for 1.0a is oauth_signature_method. > >> > > Sadly we're long past time to change the spec to > optimize for > >> this use-case. > >> > > (It would have been better to have a parameter for > oauth 2.0 > >> that is > >> > > distinct from 1.0a) At the very least this message will > live > >> on in > >> > > the mailing list archives -- at best we document the > proper way to > >> > > distinguish between the two versions somewhere. > >> > > On Thu, Jun 10, 2010 at 8:44 AM, Eran Hammer-Lahav > >> > > > >> > >> > > wrote: > >> > >> > >> > >> The request is very different on the resource server. > On the > >> > >> authorization server, why would you use the same endpoint? > >> > >> > >> > >> > >> > >> > >> > >> EHL > >> > >> > >> > >> > >> > >> > >> > >> From: oauth-bounces@ietf.org > > > >> [mailto:oauth-bounces@ietf.org > >] On > >> > >> Behalf Of Paul Lindner > >> > >> Sent: Thursday, June 10, 2010 8:24 AM > >> > >> To: OAuth WG (oauth@ietf.org > >) > >> > >> Subject: [OAUTH-WG] Identifying OAuth 2.0 vs 1.0 requests > >> > >> > >> > >> > >> > >> > >> > >> Hi, > >> > >> > >> > >> > >> > >> > >> > >> As I've been working through our oauth2 implementation I've > >> noticed > >> > >> that it's not easy to disambiguate OAuth 1.0a vs 2.0 API > >> calls based > >> > >> on the request parameters alone. Based on some > >> investigative at the > >> > >> Shindig project it appears that the only standard way to to > >> determine > >> > >> 1.0a vs 2.0 is by checking for the oauth_signature_method > >> > parameter. More info here: > >> > >> > >> > >> > >> > >> > >> > >> https://issues.apache.org/jira/browse/SHINDIG-1361 > >> > >> > >> > >> > >> > >> > >> > >> Has anyone else considered this use case? How did you > solve it? > >> > >> > >> > >> > >> > > > >> > > _______________________________________________ > >> > > OAuth mailing list > >> > > OAuth@ietf.org > > > >> > > https://www.ietf.org/mailman/listinfo/oauth > >> > > > >> > > > >> > >> > >> > ------------------------------------------------------------------------ > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > >> > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > From cmortimore@salesforce.com Mon Jun 14 16:52:42 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AAD428C0DC for ; Mon, 14 Jun 2010 16:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.38 X-Spam-Level: X-Spam-Status: No, score=-5.38 tagged_above=-999 required=5 tests=[AWL=1.218, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4RDPGmpQZKHL for ; Mon, 14 Jun 2010 16:52:39 -0700 (PDT) Received: from exprod8og109.obsmtp.com (exprod8og109.obsmtp.com [64.18.3.98]) by core3.amsl.com (Postfix) with SMTP id CC2F53A6A05 for ; Mon, 14 Jun 2010 16:52:38 -0700 (PDT) Received: from source ([204.14.239.238]) by exprod8ob109.postini.com ([64.18.7.12]) with SMTP ID DSNKTBbAyqQTIcYvdjeYP0oF1DVB0iKo7lDr@postini.com; Mon, 14 Jun 2010 16:52:43 PDT Received: from EXSFM-MB01.internal.salesforce.com ([10.1.127.45]) by exsfm-hub3.internal.salesforce.com ([10.1.127.7]) with mapi; Mon, 14 Jun 2010 16:52:42 -0700 From: Chuck Mortimore To: "oauth@ietf.org" Date: Mon, 14 Jun 2010 16:52:40 -0700 Thread-Topic: Error Code for username/password flow Thread-Index: AcsMHKxUBO4kHqoyBkGidIsG0FQClw== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C83C0ED87055cmortimoresalesforcecom_" MIME-Version: 1.0 Subject: [OAUTH-WG] Error Code for username/password flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2010 23:52:42 -0000 --_000_C83C0ED87055cmortimoresalesforcecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable There doesn't seem to be a proper error code to use with the Username/Passw= ord flow. If the client credentials are wrong "incorrect_client_credentia= ls" is used. Nothing is specified if the end-user credentials are incorre= ct. Suggestion: "invalid_user_credentials" -cmort --_000_C83C0ED87055cmortimoresalesforcecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Error Code for username/password flow There doesn’t seem to be a proper error code to use with the Userna= me/Password flow.   If the client credentials are wrong “in= correct_client_credentials” is used.   Nothing is specified= if the end-user credentials are incorrect.    Suggestion: &= nbsp;“invalid_user_credentials”

-cmort
 --_000_C83C0ED87055cmortimoresalesforcecom_-- From eran@hueniverse.com Mon Jun 14 16:59:21 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B962E28C0DC for ; Mon, 14 Jun 2010 16:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.068 X-Spam-Level: X-Spam-Status: No, score=-2.068 tagged_above=-999 required=5 tests=[AWL=0.530, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJyhUIbA7RFV for ; Mon, 14 Jun 2010 16:59:19 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id EAA4C3A6405 for ; Mon, 14 Jun 2010 16:59:18 -0700 (PDT) Received: (qmail 30838 invoked from network); 14 Jun 2010 23:59:22 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 14 Jun 2010 23:59:22 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Mon, 14 Jun 2010 16:59:22 -0700 From: Eran Hammer-Lahav To: Chuck Mortimore , "oauth@ietf.org" Date: Mon, 14 Jun 2010 16:59:26 -0700 Thread-Topic: Error Code for username/password flow Thread-Index: AcsMHKxUBO4kHqoyBkGidIsG0FQClwAAPAdQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB6889@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_90C41DD21FB7C64BB94121FBBC2E72343B3EBB6889P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Error Code for username/password flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2010 23:59:21 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EBB6889P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Done. From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of C= huck Mortimore Sent: Monday, June 14, 2010 4:53 PM To: oauth@ietf.org Subject: [OAUTH-WG] Error Code for username/password flow There doesn't seem to be a proper error code to use with the Username/Passw= ord flow. If the client credentials are wrong "incorrect_client_credentia= ls" is used. Nothing is specified if the end-user credentials are incorre= ct. Suggestion: "invalid_user_credentials" -cmort --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EBB6889P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Error Code for username/password flow=

Done.

 

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

From: oauth-bounces@ietf.org [mailto= :oauth-bounces@ietf.org] On Behalf Of Chuck Mortimore
Sent: Monday, June 14, 2010 4:53 PM
To: oauth@ietf.org
Subject:= [OAUTH-WG] Error Code for username/password flow

=

 

= There = doesn’t seem to be a proper error code to use with the Username/Passw= ord flow.   If the client credentials are wrong “incorrect_= client_credentials” is used.   Nothing is specified if the = end-user credentials are incorrect.    Suggestion:  = 220;invalid_user_credentials”

-cmort

= --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EBB6889P3PW5EX1MB01E_-- From eran@hueniverse.com Mon Jun 14 18:54:19 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8724B3A67E7 for ; Mon, 14 Jun 2010 18:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.081 X-Spam-Level: X-Spam-Status: No, score=-2.081 tagged_above=-999 required=5 tests=[AWL=0.518, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L9YQFT8BKLHw for ; Mon, 14 Jun 2010 18:54:18 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 8E3DD3A67C0 for ; Mon, 14 Jun 2010 18:54:18 -0700 (PDT) Received: (qmail 2087 invoked from network); 15 Jun 2010 01:54:21 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 15 Jun 2010 01:54:21 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Mon, 14 Jun 2010 18:54:21 -0700 From: Eran Hammer-Lahav To: Brian Eaton , "oauth@ietf.org" Date: Mon, 14 Jun 2010 18:54:25 -0700 Thread-Topic: [OAUTH-WG] username password delegation profile Thread-Index: AcrifjhFrVKN98jDR8eFw8XMGnfJjApr2TTQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB68BD@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] username password delegation profile X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 01:54:19 -0000 How would you propose this as a generic mechanism for the token endpoint as= defined in -08 (or -07)? EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Brian Eaton > Sent: Thursday, April 22, 2010 5:45 PM > To: oauth@ietf.org > Subject: [OAUTH-WG] username password delegation profile >=20 > A couple of comments on this profile. >=20 > 1) Error URL >=20 > I noticed that there was wide consensus that returning a captcha-specific > error was not going to be useful. That matches our experience with > ClientLogin [1] - very few developers properly handle captcha. And if a > developer is sophisticated enough to handle Captchas, I would rather they > just used a web browser in the first place. >=20 > However, lots of developers do tell users to visit the URL we return in o= ur > error response. This is often sufficient to resolve whatever problems ar= e > happening with the user's account. So I'd like to see an optional "url" > parameter returned with the "invalid_credentials" error code. Clients sh= ould > instruct the user to visit that URL. >=20 > 2) Is anyone actually going to implement this flow and not return a refre= sh > token? >=20 > Cheers, > Brian >=20 > [1] http://code.google.com/apis/accounts/docs/AuthForInstalledApps.html > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From root@core3.amsl.com Mon Jun 14 19:00:01 2010 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id EF0673A67D7; Mon, 14 Jun 2010 19:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100615020001.EF0673A67D7@core3.amsl.com> Date: Mon, 14 Jun 2010 19:00:01 -0700 (PDT) Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-08.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 02:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Authentication Protocol Working Group of the IETF. Title : The OAuth 2.0 Protocol Author(s) : E. Hammer-Lahav, et al. Filename : draft-ietf-oauth-v2-08.txt Pages : 33 Date : 2010-06-14 This specification describes the OAuth 2.0 protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-oauth-v2-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-06-14185134.I-D@ietf.org> --NextPart-- From eran@hueniverse.com Mon Jun 14 19:06:13 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61F4E3A6783 for ; Mon, 14 Jun 2010 19:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.093 X-Spam-Level: X-Spam-Status: No, score=-2.093 tagged_above=-999 required=5 tests=[AWL=0.506, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xu0915qJiSns for ; Mon, 14 Jun 2010 19:06:12 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 6C4E53A6A17 for ; Mon, 14 Jun 2010 19:06:12 -0700 (PDT) Received: (qmail 5606 invoked from network); 15 Jun 2010 02:06:16 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 15 Jun 2010 02:06:16 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 14 Jun 2010 19:06:16 -0700 From: Eran Hammer-Lahav To: "oauth@ietf.org" Date: Mon, 14 Jun 2010 19:06:21 -0700 Thread-Topic: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-08.txt Thread-Index: AcsMLpowXSwJB8hNTVO+d3xiLx9oMgAAEm8Q Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB68BE@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <20100615020001.EF0673A67D7@core3.amsl.com> In-Reply-To: <20100615020001.EF0673A67D7@core3.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 Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-08.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 02:06:13 -0000 This is the second half of the big rewrite. I changed the entire introducti= on to better explain the new model, as well as cleaned up the rest of the n= ew work. This is still not a smooth specification, but I think the general = structure is starting to come through. I feel much better about the current= story line, even if it has many holes in it. My focus now is on adding in extensibility. The spec is now 33 pages! -08 o Renamed verification code to authorization code. o Revised terminology, structured section, added new terms. o Changed flows to profiles and moved to introduction. o Added support for access token rescoping. o Cleaned up client credentials section. o New introduction overview. o Added error code for invalid username and password, and renamed error= code to be more consistent. o Added access grant type parameter to token endpoint. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Internet-Drafts@ietf.org > Sent: Monday, June 14, 2010 7:00 PM > To: i-d-announce@ietf.org > Cc: oauth@ietf.org > Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-08.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Open Authentication Protocol Working Gro= up > of the IETF. >=20 >=20 > Title : The OAuth 2.0 Protocol > Author(s) : E. Hammer-Lahav, et al. > Filename : draft-ietf-oauth-v2-08.txt > Pages : 33 > Date : 2010-06-14 >=20 > This specification describes the OAuth 2.0 protocol. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-08.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the Interne= t- > Draft. From andrewarnott@gmail.com Mon Jun 14 20:31:40 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F21933A67B7 for ; Mon, 14 Jun 2010 20:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.335 X-Spam-Level: X-Spam-Status: No, score=-0.335 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-YVND15jNnU for ; Mon, 14 Jun 2010 20:31:39 -0700 (PDT) Received: from mail-yw0-f179.google.com (mail-yw0-f179.google.com [209.85.211.179]) by core3.amsl.com (Postfix) with ESMTP id 08E3F3A679C for ; Mon, 14 Jun 2010 20:31:38 -0700 (PDT) Received: by ywh9 with SMTP id 9so5190438ywh.17 for ; Mon, 14 Jun 2010 20:31:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=eKOl8MtMF922rgRj1/2fqAikUC/pRpyTpmYHB8K0AKY=; b=g+UwZGHEDdgHayx6MPzq4o/4asxPc9GzL8vXZSKjc2rOJ1JUqmEql7+jD37LDyYObh XWxsmWziZgpDPwX4CIS+Efw0yoAKA1lISPBYSUXCjvb+rG4rEMQa08cJUAeQLxqGbLEj zBQi+qCRbwrfDIqI4q5xnERRPm/zJCDsBzIcg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=qFzkl17iGSqMQfs8/VBS4/jsXJRbcHYM9kr1IHf9wxxIi3wENe/6dhuEc1ETvVFEqu dSkO+VNypLWgg3jSlqGpSTqidvUbwTxDeCtqdEAzdVY0QREgXFOAMrIXVQoZjiI0lOAK e5ZAtUVMZ2D8nRhM5pEmXFYiVmJcoGloULX28= MIME-Version: 1.0 Received: by 10.150.208.5 with SMTP id f5mr7597859ybg.271.1276572699501; Mon, 14 Jun 2010 20:31:39 -0700 (PDT) Received: by 10.151.26.19 with HTTP; Mon, 14 Jun 2010 20:31:39 -0700 (PDT) Date: Mon, 14 Jun 2010 20:31:39 -0700 Message-ID: From: Andrew Arnott To: "OAuth WG (oauth@ietf.org)" Content-Type: multipart/alternative; boundary=000e0cdf1bd448a5c40489093e67 Subject: [OAUTH-WG] Assertion flow: please add optional refresh_token in response X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 03:31:40 -0000 --000e0cdf1bd448a5c40489093e67 Content-Type: text/plain; charset=ISO-8859-1 For an application I'm building, the installed client app will have intermittent windows of time where it can obtain a (non-OAuth) assertion for user identity. During this time, it seems appropriate for it to use the assertion flow to obtain an OAuth authorization so that it can impersonate the user. So far this is just standard Assertion Flow stuff. But without a refresh_token, the app will break when the access token expires if the app doesn't have the ability at the moment (due to not being on the corporate network at the moment for example) to obtain a new assertion. Since the security model for this app would certainly allow for a refresh_token to be issued from the original OAuth authorization server exchange, this would solve it, if the spec didn't specifically ban such a parameter. Also, the user identity is asserted to the authorization server *not*through an *assertion* parameter but using Kerberos (I assume) as part of the HTTP protocol, so perhaps the spec for the assertion flow can specifically allow for assertions to be carried as part of the transport? -- 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 --000e0cdf1bd448a5c40489093e67 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable For an application I'm building, the installed client app will have int= ermittent windows of time where it can obtain a (non-OAuth) assertion for u= ser identity.=A0 During this time, it seems appropriate for it to use the a= ssertion flow to obtain an OAuth authorization so that it can impersonate t= he user.=A0 So far this is just standard Assertion Flow stuff.=A0 But witho= ut a refresh_token, the app will break when the access token expires if the= app doesn't have the ability at the moment (due to not being on the co= rporate network at the moment for example) to obtain a new assertion.=A0 Si= nce the security model for this app would certainly allow for a refresh_tok= en to be issued from the original OAuth authorization server exchange, this= would solve it, if the spec didn't specifically ban such a parameter.<= br>
Also, the user identity is asserted to the authorization server not<= /i> through an assertion parameter but using Kerberos (I assume) as = part of the HTTP protocol, so perhaps the spec for the assertion flow can s= pecifically allow for assertions to be carried as part of the transport?
--
Andrew Arnott
"I [may] not agree with what = you have to say, but I'll defend to the death your right to say it.&quo= t; - S. G. Tallentyre
--000e0cdf1bd448a5c40489093e67-- From eran@hueniverse.com Mon Jun 14 20:49:56 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6389E3A67F2 for ; Mon, 14 Jun 2010 20:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[AWL=0.495, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OB5oyxdE19cx for ; Mon, 14 Jun 2010 20:49:53 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 612F73A67B7 for ; Mon, 14 Jun 2010 20:49:53 -0700 (PDT) Received: (qmail 4075 invoked from network); 15 Jun 2010 03:49:56 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 15 Jun 2010 03:49:56 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 14 Jun 2010 20:49:56 -0700 From: Eran Hammer-Lahav To: Andrew Arnott , "OAuth WG (oauth@ietf.org)" Date: Mon, 14 Jun 2010 20:50:01 -0700 Thread-Topic: [OAUTH-WG] Assertion flow: please add optional refresh_token in response Thread-Index: AcsMO0k0AEYsZAprTKGqEKx4kSsOhQAAkqWQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB68C9@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_90C41DD21FB7C64BB94121FBBC2E72343B3EBB68C9P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Assertion flow: please add optional refresh_token in response X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 03:49:56 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EBB68C9P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable First, the spec says "SHOULD NOT issue a refresh token" which means, don't = do it unless you have to. But what stops the client from keeping the same a= ssertion and reusing it later? As for using other methods for providing an assertion, you need to be more = specific about what you have in mind. But either way, you can extend the to= ken endpoint to support other ways of providing assertions. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of A= ndrew Arnott Sent: Monday, June 14, 2010 8:32 PM To: OAuth WG (oauth@ietf.org) Subject: [OAUTH-WG] Assertion flow: please add optional refresh_token in re= sponse For an application I'm building, the installed client app will have intermi= ttent windows of time where it can obtain a (non-OAuth) assertion for user = identity. During this time, it seems appropriate for it to use the asserti= on flow to obtain an OAuth authorization so that it can impersonate the use= r. So far this is just standard Assertion Flow stuff. But without a refre= sh_token, the app will break when the access token expires if the app doesn= 't have the ability at the moment (due to not being on the corporate networ= k at the moment for example) to obtain a new assertion. Since the security= model for this app would certainly allow for a refresh_token to be issued = from the original OAuth authorization server exchange, this would solve it,= if the spec didn't specifically ban such a parameter. Also, the user identity is asserted to the authorization server not through= an assertion parameter but using Kerberos (I assume) as part of the HTTP p= rotocol, so perhaps the spec for the assertion flow can specifically allow = for assertions to be carried as part of the transport? -- 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 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EBB68C9P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable = --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EBB68C9P3PW5EX1MB01E_-- From beaton@google.com Mon Jun 14 21:02:10 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F49F3A6A1D for ; Mon, 14 Jun 2010 21:02:10 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L3XiKvWTbZYH for ; Mon, 14 Jun 2010 21:02:09 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 8A7833A6813 for ; Mon, 14 Jun 2010 21:02:09 -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 o5F429w5017663 for ; Mon, 14 Jun 2010 21:02:10 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1276574530; bh=ZLZ757EBjLRREPItQS1ZiaLDAzA=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=HbhOKCMyDfgDrjdx7vlqyqYiCWzegLSRBQ+ly6YqhCVUdcU1TX3KT/UUfX/NO8dPH Gs10XP89wGAaMXf1nLhiA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding; b=f/a6U5daDC1v3XujsxIdtz5aLM1eA/coVkpt4L5pZd/L9dkS8K1BDr4cvQm8zeQDX uDp5B3DJeg89IC3TcN6Mg== Received: from pvc22 (pvc22.prod.google.com [10.241.209.150]) by wpaz5.hot.corp.google.com with ESMTP id o5F427tk021690 for ; Mon, 14 Jun 2010 21:02:08 -0700 Received: by pvc22 with SMTP id 22so1382778pvc.1 for ; Mon, 14 Jun 2010 21:02:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.60.21 with SMTP id i21mr4638813wfa.149.1276574527352; Mon, 14 Jun 2010 21:02:07 -0700 (PDT) Received: by 10.142.207.21 with HTTP; Mon, 14 Jun 2010 21:02:07 -0700 (PDT) In-Reply-To: References: Date: Mon, 14 Jun 2010 21:02:07 -0700 Message-ID: From: Brian Eaton To: Andrew Arnott Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Assertion flow: please add optional refresh_token in response X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 04:02:10 -0000 On Mon, Jun 14, 2010 at 8:31 PM, Andrew Arnott wro= te: > For an application I'm building, the installed client app will have > intermittent windows of time where it can obtain a (non-OAuth) assertion = for > user identity.=A0 During this time, it seems appropriate for it to use th= e > assertion flow to obtain an OAuth authorization so that it can impersonat= e > the user.=A0 So far this is just standard Assertion Flow stuff.=A0 But wi= thout a > refresh_token, the app will break when the access token expires if the ap= p > doesn't have the ability at the moment (due to not being on the corporate > network at the moment for example) to obtain a new assertion.=A0 Since th= e > security model for this app would certainly allow for a refresh_token to = be > issued from the original OAuth authorization server exchange, this would > solve it, if the spec didn't specifically ban such a parameter. I think this is a different use case than the one envisioned by most people who are using the assertion flow. I'm inclined to steer different use cases to different profiles. It makes it much easier to guide deployments, for example. Cheers, Brian From James.H.Manger@team.telstra.com Mon Jun 14 21:24:01 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEC3B3A6833 for ; Mon, 14 Jun 2010 21:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.491 X-Spam-Level: * X-Spam-Status: No, score=1.491 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_40=-0.185, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qKA4oP-ke-W for ; Mon, 14 Jun 2010 21:24:00 -0700 (PDT) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by core3.amsl.com (Postfix) with ESMTP id 41EB33A67D1 for ; Mon, 14 Jun 2010 21:23:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,418,1272808800"; d="scan'208";a="4408254" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipoavi.tcif.telstra.com.au with ESMTP; 15 Jun 2010 14:24:01 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6013"; a="3192464" Received: from wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) by ipcdvi.tcif.telstra.com.au with ESMTP; 15 Jun 2010 14:24:03 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) with mapi; Tue, 15 Jun 2010 14:24:02 +1000 From: "Manger, James H" To: Eran Hammer-Lahav Date: Tue, 15 Jun 2010 14:24:01 +1000 Thread-Topic: [OAUTH-WG] in-app logout? Thread-Index: AcsL76dIklVHVQb3TtKjiBr3sg/bNAAFB3hAAA8T1QA= Message-ID: <255B9BB34FB7D647A506DC292726F6E112640B7698@WSMSG3153V.srv.dir.telstra.com> References: <4BEBDCFB.7090503@lodderstedt.net> <255B9BB34FB7D647A506DC292726F6E11263465727@WSMSG3153V.srv.dir.telstra.com> <4BFD67CA.5040600@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3EBB66F0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C16753A.9050802@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3EBB680C@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB680C@P3PW5EX1MB01.EX1.SECURESERVER.NET> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] in-app logout? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 04:24:01 -0000 PiBTaW5jZSByZWZyZXNoIHRva2VuIGlzIG9ubHkgaXNzdWVkIHRvIGNsaWVudHMgY2FwYWJsZSBv ZiBkaXJlY3RseSBpbnRlcmFjdGluZyB3aXRoIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciwgaXMg dGhlcmUgYSByZWFzb24gd2h5IHRoZSBlbmRwb2ludCBjYW5ub3QgdXNlIERFTEVURSBpbnN0ZWFk IG9mIGEgUE9TVCB3aXRoIGEgcGFyYW1ldGVyPw0KPg0KPiAgREVMRVRFIC90b2tlbiBIVFRQLzEu MQ0KPiAgSG9zdDogc2VydmVyLmV4YW1wbGUuY29tDQo+ICBDb250ZW50LVR5cGU6IGFwcGxpY2F0 aW9uL3gtd3d3LWZvcm0tdXJsZW5jb2RlZA0KPiAgDQo+ICBncmFudF90eXBlPXJlZnJlc2hfdG9r ZW4mY2xpZW50X2lkPXM2QmhkUmtxdDMmY2xpZW50X3NlY3JldD04ZVNFSXBucW1NJnJlZnJlc2hf dG9rZW49bjRFOU8xMTlkDQo+DQo+IFRoaXMgbG9va3MgbGlrZSBhbiBlbGVnYW50IHdheSBvZiBk b2luZyB0aGluZ3MuIEknbSBub3Qgc3VyZSBhYm91dCB1c2luZyB0aGUgdG9rZW4gZW5kcG9pbnQg Zm9yIHRoaXMsIGJ1dCB0aGF0J3MgYSBzZXBhcmF0ZSBpc3N1ZS4NCg0KDQpUaGUgREVMRVRFIG1l dGhvZCBkZWxldGVzIHRoZSByZXNvdXJjZSBpZGVudGlmaWVkIGJ5IHRoZSBVUkkuIEkgZG9uJ3Qg dGhpbmsgaXQgaXMgdXN1YWwgdG8gaGF2ZSBhbnkgYm9keSB3aXRoIGEgREVMRVRFLiBBbnkgaW50 ZXJtZWRpYXJpZXMgc2VlaW5nIHRoZSBERUxFVEUgd2lsbCBtYXJrIGFzIHN0YWxlIGFueSBjYWNo ZWQgcmVzcG9uc2VzIGluZGV4ZWQgYnkgdGhlIFVSSSAtLSB0aGV5IHdpbGwgbm90IGxvb2sgaW4g dGhlIGJvZHkuDQoNCkluIHNob3J0LCBhIG1vcmUgd2ViLXN0eWxlIGFwcHJvYWNoIGlzIHRvIGdp dmUgZWFjaCB0b2tlbiBpdHMgb3duIFVSSSBhbmQgREVMRVRFIHRoYXQuDQoNCiAgREVMRVRFIC90 b2tlbj9yZWZyZXNoX3Rva2VuPW40RTkwMTE5ZCBIVFRQLzEuMQ0KICBBdXRob3JpemF0aW9uOiBC QVNJQyBjelpDYUdSU2EzRjBNem80WlZORlNYQnVjVzFODQoNCi0tDQpKYW1lcyBNYW5nZXINCg0K From uidude@google.com Mon Jun 14 21:35:48 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E8813A67B6 for ; Mon, 14 Jun 2010 21:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.534 X-Spam-Level: X-Spam-Status: No, score=-107.534 tagged_above=-999 required=5 tests=[AWL=0.442, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nK6B9+cWgLCO for ; Mon, 14 Jun 2010 21:35:41 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 4575E3A6826 for ; Mon, 14 Jun 2010 21:35:41 -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 o5F4ZeT3022456 for ; Mon, 14 Jun 2010 21:35:41 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1276576541; bh=6Rqv3gkkdht1dWjHKl+n+nyJRp4=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=HCZQCyTibe+3NzY+AMmXrXBkyUG7i7IzxP22K3aXPSh5W/uLMKpr0WeRWU61UTty0 f/I6GtQZduXT33OxGcZGA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type; b=s10uaoh3hN6WRFbYkr8x2/CnCHapBW86GUhQPtDD9cQAhEs2oUUWfDi8wS5HRUigf mi6wwmQ4Vbo4ea9t8tsaw== Received: from vws9 (vws9.prod.google.com [10.241.21.137]) by kpbe16.cbf.corp.google.com with ESMTP id o5F4ZK0s004411 for ; Mon, 14 Jun 2010 21:35:40 -0700 Received: by vws9 with SMTP id 9so5928925vws.3 for ; Mon, 14 Jun 2010 21:35:39 -0700 (PDT) Received: by 10.229.248.2 with SMTP id me2mr2920176qcb.44.1276576539398; Mon, 14 Jun 2010 21:35:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.106.204 with HTTP; Mon, 14 Jun 2010 21:35:18 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB65AD@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF73EF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E11263FEC9FC@WSMSG3153V.srv.dir.telstra.com> <4A5E1C55-D589-4F25-9D45-E640BA7C833F@facebook.com> <90C41DD21FB7C64BB94121FBBC2E72343B3EBB6597@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3EBB65AD@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Evan Gilbert Date: Mon, 14 Jun 2010 21:35:18 -0700 Message-ID: To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=0016e64653fa28d4dd04890a238d Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Proposal for single JSON response format X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 04:35:48 -0000 --0016e64653fa28d4dd04890a238d Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Sun, Jun 13, 2010 at 5:55 PM, Eran Hammer-Lahav wro= te: > To be clear, you are +1 on using only JSON for server responses on the > token endpoint? > Yes, +1 on JSON responses for token endpoint. > > > EHL > > > > *From:* Evan Gilbert [mailto:uidude@google.com] > *Sent:* Sunday, June 13, 2010 11:20 AM > *To:* Eran Hammer-Lahav > *Cc:* Robert Sayre; OAuth WG (oauth@ietf.org) > > *Subject:* Re: [OAUTH-WG] Proposal for single JSON response format > > > > > > On Sun, Jun 13, 2010 at 8:18 AM, Eran Hammer-Lahav > wrote: > > Using JSON in the end-user authorization endpoint response is still > something we need to discuss. In the web server flow, it makes more sense= to > use form-encoded because the URI is processed by a typical query processo= r > (automatic in every web server). In the fragment, it is a question of > preference, and I was told that there are many benefits to using JSON. I > think Facebook uses JSON in such a way. > > > > However, there is still value in using JSON across all server responses > because it allows returning the same structured data. > > > > Can you explain the XSS hole from parsing a random JSON string? > > > > Naive processor calls: > > var href =3D document.location.href; > > var jsonBlob =3D href.substring(href.indexOf('#'), href.length) > > var userData =3D eval(jsonBlob); > > > > This code would allow executing arbitrary code by sending a user a link, > which could, for example, steal your cookies on a site. > > > > The fix is just a really complicated RegEx match - here is sample codefrom Shindig= that does this correctly - but I would worry that implementers > would do the simple thing and just eval the JSON. It also seems like a si= gn > of a design issue if the spec requires this regex. > > > > > > If all server responses are JSON, why does the client have to do > form-decoding? > > > > Redirect_uri needs to be put into a URL somehow, and the URL may have oth= er > query parameters or other content in the fragment. I'm making the assumpt= ion > that we would put this into a query parameter - otherwise we need to spec= ify > ourselves how to encode the JSON to be URL-safe and not conflict with oth= er > parameters. > > > > What simple model? Format isn=92t a model. > > Sorry, the statement about "simple model" wasn't that helpful without > context. Here's the context: > > - We currently have listed 4 named parameters that may be returned. > - Using query parameters is an obvious / clear way to return these > parameters when encoded in a URL (in the fragment, a common practice i= s to > use the same query parameter format, but after the hash). > - All modern coding environments I know of can pull out simple key / > value pairs encoded in URL parameters. Issues I've heard with URL para= meters > are all around: > > > 1. Canonicalization of parameters for signing, and > 2. Parameters that are not simple key/value pairs (i.e. how do you > encode a linefeed. > > > - The data returned on a URL should probably *not* be the same as what > you would return on the server. This is because the data is untrusted = - > evildoers can construct a URL with the wrong JSON data. > > So my preference would be to leave the redirect URI as simple key/value > pairs and actively try to discourage adding structured / complex content.= We > can use a followup call to the AS with the access token on the server sid= e > for complex data, and JSON is the right response format for this followup > call. > > > > EHL > > > > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf > Of *Evan Gilbert > *Sent:* Sunday, June 13, 2010 2:47 AM > *To:* Robert Sayre > *Cc:* OAuth WG (oauth@ietf.org) > *Subject:* Re: [OAUTH-WG] Proposal for single JSON response format > > > > -1 > > > > I disagree very strongly with this approach if I'm understanding > correctly. Let me paraphrase to make sure I understand: > > > > All responses, even those encoded in a browser URL redirect back from the > AS (redirect with verification code in the web server flow and the redire= ct > with token in the user-agent flow) will be JSON > > > This means that we will have a URL-encoded JSON blob as a form parameter > (as it has to play nicely with existing URL parameters). So the response > back in the web server flow would be: > > https://client.com/receiveVerificationCode?existingParam=3Dvalue&oauth2= =3D%7Bcode%3A'abc123'%2C+state%3A+'randomstatedata'%7D > > and the response back in the user-agent flow would be > > https://client.com/page?existingParam=3Dvalue&oauth2=3D%7Baccess_token%3A= +'accesstoken1234'%2Cexpires_in%3A3600%2Cstate%3A'randomstatedata'%7D > > > > Reasons why this is of concern: > > - Requires clients to do URL decoding *and* JSON decoding > > - Encourages unsafe JSON handling in the User-Agent flow (eval(JSON) =3D = XSS > hole) > > - Breaks the simple model we've been creating in these flows. > > > > Evan > > > > On Fri, Jun 11, 2010 at 1:51 PM, Robert Sayre wrote: > > +1 > > > On Fri, Jun 11, 2010 at 1:17 AM, Naitik Shah wrote: > > +1 > > > > On Thu, Jun 10, 2010 at 5:50 PM, Luke Shepard > wrote: > >> > >> +1 > >> > >> On Jun 10, 2010, at 5:46 PM, Manger, James H wrote: > >> > >> > +1 > >> > > >> > -- > >> > James Manger > >> > > >> > ---------- > >> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > Behalf > >> > Of Eran Hammer-Lahav > >> > Sent: Friday, 11 June 2010 6:29 AM > >> > To: OAuth WG (oauth@ietf.org) > >> > Subject: [OAUTH-WG] Proposal for single JSON response format > >> > > >> > - Support a single response format (including in the user-agent > >> > fragment) using JSON. > >> > _______________________________________________ > >> > OAuth mailing 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 > > > > > > -- > > Robert Sayre > > "I would have written a shorter letter, but I did not have the time." > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > --0016e64653fa28d4dd04890a238d Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On Sun, Jun 13, 2010 at 5:55 PM, Eran Ha= mmer-Lahav <eran@hueniverse.com> wrote:

To be clear, you are +1 = on using only JSON for server responses on the token endpoint?

Yes,=A0+1 on JSON responses for token endpoint.

= =A0

EHL

=A0

From: Evan Gilbert [mailto= :uidude@google.com]
Sent: Sunday, June 13, 2010 11:20 AM
To: Eran Hammer-Lahav=
Cc: Robert Sayre; OAuth WG (oauth@ietf.org)


Subject: Re: [OAUTH-WG] Proposal for single JSON response format=

= =A0

=A0

On Sun, Jun 13, 2010 at 8:18 AM, Eran Hammer-Lahav &= lt;eran@hueniverse= .com> wrote:

Using JSON in the end-user authorization endpoi= nt response is still something we need to discuss. In the web server flow, = it makes more sense to use form-encoded because the URI is processed by a t= ypical query processor (automatic in every web server). In the fragment, it= is a question of preference, and I was told that there are many benefits t= o using JSON. I think Facebook uses JSON in such a way.

=A0

However, there is still value in using JSON across all server responses= because it allows returning the same structured data.

=A0

Can you explain the XSS hole from parsing a random JSON string?<= /p>

=A0

= Naive processor calls:

var href =3D document.location.href;

var jsonBlob =3D href.substring(href.indexOf('#'), href.= length)

var userData =A0=3D eval(jsonBlob);

=A0

= This code would allow executing arbitrary code by sending a user a link, wh= ich could, for example, steal your cookies on a site.

=A0

The fix is just a really complicat= ed RegEx match - here is sample c= ode from Shindig that does this correctly - but I would worry that impl= ementers would do the simple thing and just eval the JSON. It also seems li= ke a sign of a design issue if the spec requires this regex.

=A0

=A0

If al= l server responses are JSON, why does the client have to do form-decoding?<= /span>

=A0

Redirect_uri needs to be put into a URL somehow, and= the URL may have other query parameters or other content in the fragment. = I'm making the assumption that we would put this into a query parameter= - otherwise we need to specify ourselves how to encode the JSON to be URL-= safe and not conflict with other parameters.

=A0

What simple model? Format is= n=92t a model.

Sorry, the statement about "simple model" wasn't that help= ful without context. Here's the context:

  • We currently have list= ed 4 named parameters that may be returned.
  • Usi= ng query parameters is an obvious / clear way to return these parameters wh= en encoded in a URL (in the fragment, a common practice is to use the same = query parameter format, but after the hash).
  • All modern coding environments I know of can=A0pull= out simple key / value pairs encoded in=A0URL parameters. Issues I've = heard with URL parameters are all around:
    1. Canonicalization of parameters for signing, and
    2. Parameters that are not simple key/value pairs (i.= e. how do you encode a linefeed.
  • The data returned on a URL should probably *not* be the same as what you wo= uld return on the server. This is because the data is untrusted - evildoers= can construct a URL with the wrong JSON data.

So my preference would be to leave the redirect URI as simple key/value pai= rs and actively try to discourage adding structured / complex content.=A0We= can use a followup call to the AS with the access token on the server side= for complex data, and JSON is the right response format for this followup = call.

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

EHL

=A0

Fr= om: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org= ] On Behalf Of Evan Gilbert
Sent: Sunday, June 13, 2010 2:47 AM
To: Robert Sayre
Cc: OAuth WG (oaut= h@ietf.org)
Subject: Re: [OAUTH-WG] Proposal for single JSON = response format

=A0

= -1=A0

=A0

I disagree very strongly with this approach if I'm un= derstanding correctly.=A0Let me paraphrase to make sure I understand:

=A0

= All responses, even those encoded in a browser URL redirect back from the A= S (redirect with verification code in the web server flow and the redirect = with token in the user-agent flow) will be JSON


This m= eans that we will have a URL-encoded JSON blob as a form parameter (as it h= as to play nicely with existing URL parameters). So the response back in th= e web server flow would be:
=A0=A0https://client.com/receiveVerificationCode?existingParam=3Dvalue&a= mp;oauth2=3D%7Bcode%3A'abc123'%2C+state%3A+'randomstatedata'= ;%7D

and the response back in the user-agent f= low would be
=A0=A0<= a href=3D"https://client.com/page?existingParam=3Dvalue&oauth2=3D%7Bacc= ess_token%3A+'accesstoken1234'%2Cexpires_in%3A3600%2Cstate%3A'r= andomstatedata'%7D" target=3D"_blank">https://client.com/page?existingP= aram=3Dvalue&oauth2=3D%7Baccess_token%3A+'accesstoken1234'%2Cex= pires_in%3A3600%2Cstate%3A'randomstatedata'%7D

=A0

= Reasons why this is of concern:

- Requ= ires clients to do URL decoding and=A0JSON decoding

- Encourages unsafe JSON handling in the User-Agent flow (eval(JSON) =3D XS= S hole)

- Breaks the simple model we&#= 39;ve been creating in these flows.

= =A0

Evan

=A0

On Fri, Jun 11, 2010 at= 1:51 PM, Robert Sayre <sayrer@gmail.com> wrote:

+1


On Fri, Jun 11, 2010 at 1:17 AM, Naitik Shah <n@daaku.org> wrote:
>= ; +1
>
> On Thu, Jun 10, 2010 at 5:50 PM, Luke Shepard <lshepard@facebook.com>= ; wrote:
>>
>> +1
>>
>> On Jun 10, 2010= , at 5:46 PM, Manger, James H wrote:
>>
>> > +1
>> >
>> > --
>&g= t; > James Manger
>> >
>> > ----------
>&g= t; > From: o= auth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
>> > Of Eran Hammer-Lahav
>> > Sent: Friday, 11 June 2= 010 6:29 AM
>> > To: OAuth WG (oauth@ietf.org)
>> > Subject: [OAUTH-WG= ] Proposal for single JSON response format
>> >
>> > - Support a single response format (includin= g in the user-agent
>> > fragment) using JSON.
>> >= _______________________________________________
>> > OAuth mai= ling list
>> > OAuth@iet= f.org
>> > https://www.ietf.org/mailman/listinfo/oauth>>
>> _______________________________________________
>> OAuth = mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth=
>
>
> _______________________________________________
>= ; OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth=
>
>

--

Robert Sayre

"I would have written a shorter = letter, but I did not have the time."

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

=A0

= =A0


--0016e64653fa28d4dd04890a238d-- From uidude@google.com Mon Jun 14 21:43:03 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1587428C0E3 for ; Mon, 14 Jun 2010 21:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.755 X-Spam-Level: X-Spam-Status: No, score=-106.755 tagged_above=-999 required=5 tests=[AWL=-0.779, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wPnad-xfW+kI for ; Mon, 14 Jun 2010 21:43:02 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 8FE2828B56A for ; Mon, 14 Jun 2010 21:42:59 -0700 (PDT) Received: from kpbe11.cbf.corp.google.com (kpbe11.cbf.corp.google.com [172.25.105.75]) by smtp-out.google.com with ESMTP id o5F4h1NP006943 for ; Mon, 14 Jun 2010 21:43:03 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1276576983; bh=S47/3Hhtvhsbn646oyHkq7ZNM6E=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=AtntuwHeGkgpO8G9W9A5Y4Y2zPx3U4Vu3kA3IZ8VYQgRF8dpVRSkLTtRNrBWRDD4U 4J0K/X7pzAQUWMViCwZLA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type; b=nbzFiwyaFKXJdjZESj0hrisYRmZAFfgiFO3Y2y0TAztd9vL8AecJxxiAhgKg/OmBX Br5CzKX59pDG6MJTuaKSw== Received: from vws3 (vws3.prod.google.com [10.241.21.131]) by kpbe11.cbf.corp.google.com with ESMTP id o5F4h0ge000461 for ; Mon, 14 Jun 2010 21:43:00 -0700 Received: by vws3 with SMTP id 3so132362vws.40 for ; Mon, 14 Jun 2010 21:43:00 -0700 (PDT) Received: by 10.229.219.209 with SMTP id hv17mr2752031qcb.186.1276576979673; Mon, 14 Jun 2010 21:42:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.106.204 with HTTP; Mon, 14 Jun 2010 21:41:05 -0700 (PDT) In-Reply-To: <1D91AEDD-E5E6-4401-8C76-53E178595AE2@gmail.com> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF73EF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E11263FEC9FC@WSMSG3153V.srv.dir.telstra.com> <4A5E1C55-D589-4F25-9D45-E640BA7C833F@facebook.com> <90C41DD21FB7C64BB94121FBBC2E72343B3EBB6597@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1D91AEDD-E5E6-4401-8C76-53E178595AE2@gmail.com> From: Evan Gilbert Date: Mon, 14 Jun 2010 21:41:05 -0700 Message-ID: To: Dick Hardt Content-Type: multipart/alternative; boundary=0016362844fa66f59504890a3dfe Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Proposal for single JSON response format X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 04:43:03 -0000 --0016362844fa66f59504890a3dfe Content-Type: text/plain; charset=ISO-8859-1 > > > If a response from the AS is untrusted, there are much bigger issues at > stake. ... or am I missing an obvious attack where random JSON would get > sent to the Client? > For the web server flow, you know the AS server you called and can reasonably trust the data. For the user agent flow, attackers can create a URL with data and send it to you. This is OK (kind of) if the data is limited to an access token - this would allow an attacker to grant you access to their protected resources, which only has problems if you accidentally send protected data in an update to that account. But if you have other parameters that need to be vouched for by the AS, then it is insecure. > > -- Dick > --0016362844fa66f59504890a3dfe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

If a response from the AS is untrust= ed, there are much bigger issues at stake. ... or am I missing an obvious a= ttack where random JSON would get sent to the Client?

For the web server flow, you know th= e AS server you called and can reasonably trust the data.

For the user agent flow, attackers can create a URL with data and s= end it to you. This is OK (kind of) if the data is limited to an access tok= en - this would allow an attacker to grant you access to their protected re= sources, which only has problems if you accidentally send protected data in= an update to that account. But if you have other parameters that need to b= e vouched for by the AS, then it is insecure.
=A0

-- Dick

--0016362844fa66f59504890a3dfe-- From dick.hardt@gmail.com Mon Jun 14 22:59:13 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80E023A67E5 for ; Mon, 14 Jun 2010 22:59:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.243 X-Spam-Level: X-Spam-Status: No, score=-2.243 tagged_above=-999 required=5 tests=[AWL=0.355, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cUw5xOFeubRN for ; Mon, 14 Jun 2010 22:59:10 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 055423A67E3 for ; Mon, 14 Jun 2010 22:59:09 -0700 (PDT) Received: by pwi8 with SMTP id 8so3553072pwi.31 for ; Mon, 14 Jun 2010 22:59:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:message-id:references:to :x-mailer; bh=9oDjpAQfMTKfKSpSaegp4Z+x7DAQNTsHPITPzF2Vrkw=; b=ovNLzZDxMw5s54tjHy0trIwKLmIB8l9fwFuJ2AmaMoGqZn3As1vevM4hwOqZaSxK+7 5yr7BJMw6oLiczqPDQlAImcidmfvGZzzxCild56wQelTcSag60uAgGjM0u6fBpBzAIHX 3ONAcdXfJNX7NyMz0w/nDjP4FbCaw8A3T2UAI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; b=MaKDjqpCvQOdMMLg6HfHq3Mf+4hwaicXlR2s8fuW7FILySkly+5oJgExabAYXcI003 xJv52xOpV4vA9gdhhF2vb7aF/JX2N8UyYxhE3QGYXYPqq+VKol1/SwiuoWUbr+SUxwIL 0ecSnFsA4b3BZhU2hkffV/vtkIHCWXChWS784= Received: by 10.115.66.33 with SMTP id t33mr5341777wak.199.1276581551254; Mon, 14 Jun 2010 22:59:11 -0700 (PDT) Received: from [192.168.1.5] (c-24-130-32-55.hsd1.ca.comcast.net [24.130.32.55]) by mx.google.com with ESMTPS id c14sm64146498waa.13.2010.06.14.22.59.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 14 Jun 2010 22:59:10 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/alternative; boundary=Apple-Mail-26--225878788 From: Dick Hardt In-Reply-To: Date: Mon, 14 Jun 2010 22:59:08 -0700 Message-Id: <4C69C07A-2D24-4872-821C-533EBB798AC0@gmail.com> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF73EF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E11263FEC9FC@WSMSG3153V.srv.dir.telstra.com> <4A5E1C55-D589-4F25-9D45-E640BA7C833F@facebook.com> <90C41DD21FB7C64BB94121FBBC2E72343B3EBB6597@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1D91AEDD-E5E6-4401-8C76-53E178595AE2@gmail.com> To: Evan Gilbert X-Mailer: Apple Mail (2.1078) Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Proposal for single JSON response format X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 05:59:13 -0000 --Apple-Mail-26--225878788 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2010-06-14, at 9:41 PM, Evan Gilbert wrote: >=20 > If a response from the AS is untrusted, there are much bigger issues = at stake. ... or am I missing an obvious attack where random JSON would = get sent to the Client? >=20 > For the web server flow, you know the AS server you called and can = reasonably trust the data. >=20 > For the user agent flow, attackers can create a URL with data and send = it to you. This is OK (kind of) if the data is limited to an access = token - this would allow an attacker to grant you access to their = protected resources, which only has problems if you accidentally send = protected data in an update to that account. But if you have other = parameters that need to be vouched for by the AS, then it is insecure. Understood. I have concerns about JSON in the user agent flow. My = original JSON proposal was using JSON in the response for direct calls = only. -- Dick --Apple-Mail-26--225878788 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On 2010-06-14, at 9:41 PM, Evan Gilbert wrote:


If a response from the AS is untrusted, there are much bigger issues at stake. ... or am I missing an obvious attack where random JSON would get sent to the Client?

For the web server flow, you know the AS server you called and can reasonably trust the data.

For the user agent flow, attackers can create a URL with data and send it to you. This is OK (kind of) if the data is limited to an access token - this would allow an attacker to grant you access to their protected resources, which only has problems if you accidentally send protected data in an update to that account. But if you have other parameters that need to be vouched for by the AS, then it is insecure.

Understood. I have concerns about JSON in the user agent flow. My original JSON proposal was using JSON in the response for direct calls only.

-- Dick

--Apple-Mail-26--225878788-- From dick.hardt@gmail.com Mon Jun 14 23:07:03 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5D5B3A67E5 for ; Mon, 14 Jun 2010 23:07:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[AWL=0.311, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XN0MpZNI-jpX for ; Mon, 14 Jun 2010 23:07:02 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id 7C6EE3A6862 for ; Mon, 14 Jun 2010 23:07:02 -0700 (PDT) Received: by pxi5 with SMTP id 5so1112288pxi.31 for ; Mon, 14 Jun 2010 23:07:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=mDj/+QxL4nsqjnMAQm2e7pgqKZ/W89lFnhDcgqA9PEs=; b=wKm9LCKh3kO8e3Cirep9hLVOJtO+G0D4wGblPEjxAeirCBApaonVDiVmg80hP06uf0 SsgOK2ym5wPLOSaWQp2VbsmFBJlG/Via1s9cQA9n+ZE8rJR8X9JraVl4CwkvqMXcbYda W4oYZkhlHHraOBiwGCUKJtqM4ahQowULyMMJE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=mxDd0by3pz9M+O284joPsfKUvrYDzw24esTjfGiDDuFbUaUDahom+6Zl6DtNmcXfj2 ha6p7QwsiaiFd3OPjlTV927yeII9D2A4XjRd8sV2j9ZPvwgbQX922lqrXVUdMvOEeBLP rmrk1+VziVs2BR4EZCmkarTj/JLraQev/KvUs= Received: by 10.140.180.20 with SMTP id c20mr5376446rvf.76.1276581619574; Mon, 14 Jun 2010 23:00:19 -0700 (PDT) Received: from [192.168.1.5] (c-24-130-32-55.hsd1.ca.comcast.net [24.130.32.55]) by mx.google.com with ESMTPS id o38sm5475097rvp.2.2010.06.14.23.00.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 14 Jun 2010 23:00:18 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Dick Hardt In-Reply-To: Date: Mon, 14 Jun 2010 23:00:16 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7F00C2CF-E57F-4341-BBA4-7B03B69277D6@gmail.com> References: To: Brian Eaton X-Mailer: Apple Mail (2.1078) Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Assertion flow: please add optional refresh_token in response X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 06:07:03 -0000 +1 On 2010-06-14, at 9:02 PM, Brian Eaton wrote: > On Mon, Jun 14, 2010 at 8:31 PM, Andrew Arnott = wrote: >> For an application I'm building, the installed client app will have >> intermittent windows of time where it can obtain a (non-OAuth) = assertion for >> user identity. During this time, it seems appropriate for it to use = the >> assertion flow to obtain an OAuth authorization so that it can = impersonate >> the user. So far this is just standard Assertion Flow stuff. But = without a >> refresh_token, the app will break when the access token expires if = the app >> doesn't have the ability at the moment (due to not being on the = corporate >> network at the moment for example) to obtain a new assertion. Since = the >> security model for this app would certainly allow for a refresh_token = to be >> issued from the original OAuth authorization server exchange, this = would >> solve it, if the spec didn't specifically ban such a parameter. >=20 > I think this is a different use case than the one envisioned by most > people who are using the assertion flow. >=20 > I'm inclined to steer different use cases to different profiles. It > makes it much easier to guide deployments, for example. >=20 > Cheers, > Brian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Mon Jun 14 23:34:59 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A19733A6867 for ; Mon, 14 Jun 2010 23:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.815 X-Spam-Level: X-Spam-Status: No, score=-0.815 tagged_above=-999 required=5 tests=[AWL=-0.816, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w47vyMlsIj9u for ; Mon, 14 Jun 2010 23:34:56 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id A8A9B3A6809 for ; Mon, 14 Jun 2010 23:34:56 -0700 (PDT) Received: (qmail 19337 invoked from network); 15 Jun 2010 06:34:59 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 15 Jun 2010 06:34:59 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 14 Jun 2010 23:34:59 -0700 From: Eran Hammer-Lahav To: "OAuth WG (oauth@ietf.org)" Date: Mon, 14 Jun 2010 23:35:02 -0700 Thread-Topic: OAuth meeting notes on -05 (with updates) Thread-Index: AcsMLfi0k1bL/UTuTyKlbQqO9cCDCg== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB68D9@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [OAUTH-WG] OAuth meeting notes on -05 (with updates) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 06:34:59 -0000 X-List-Received-Date: Tue, 15 Jun 2010 06:34:59 -0000 RHVyaW5nIHRoZSBPQXV0aCBXRyBpbnRlcmltIG1lZXRpbmcsIHRoZSBncm91cCBzcGVudCBhIGNv bnNpZGVyYWJsZSBhbW91bnQgb2YgdGltZSBnb2luZyBvdmVyIGRyYWZ0IC0wNSBhbmQgbGlzdGlu ZyBpc3N1ZXMgd2l0aCB0aGUgdGV4dCBhbmQgcHJvdG9jb2wuIFNpbmNlIHRoZSBkcmFmdCBpcyBu b3cgc2lnbmlmaWNhbnRseSBkaWZmZXJlbnQsIEkgd2FudCB0byBnbyBvdmVyIHRoaXMgYW5kIGlk ZW50aWZ5IHRoZSBpc3N1ZXMgcmVzb2x2ZWQgYW5kIHRob3NlIHN0aWxsIG9wZW4gKGJlZm9yZSBp dCBpcyB0b28gbGF0ZSkuDQoNClRoZXNlIGNvbW1lbnRzIGFyZSBiYXNlZCBvbiBCcmlhbiBFYXRv bidzIGRldGFpbGVkIG5vdGVzICh0aGFua3MhKSB3aXRoIG15IGVkaXRzLiBJIHJlbW92ZWQgY29t bWVudHMgdGhhdCB3ZXJlIG5vdCBhY3Rpb25hYmxlLiBJIGtlcHQgdGhlIG5hbWVzIG5leHQgdG8g Y29tbWVudHMgd2hlcmUgYWRkaXRpb25hbCBjbGFyaWZpY2F0aW9ucyBhcmUgbmVlZGVkLiBJZiB0 aGUgbm90ZXMgYXJlIHdyb25nLCBibGFtZSBtZSBmb3IgbWVzc2luZyB3aXRoIHRoZSBCcmlhbidz IGNvcHkuDQoNCkFjdGlvbiBpdGVtcyBhcmUgbWFya2VkIHdpdGggKioqLg0KDQpPdmVyYWxsLCBJ IHRoaW5rIGJ5IC0wOSB3ZSB3aWxsIGJlIGRvbmUgd2l0aCBtb3N0IG9mIHRoZSBjb21tZW50cyAo cmVhZHkgZm9yIGFub3RoZXIgYmF0Y2gpLg0KDQpFSEwNCg0KLS0tDQoNCj4gSW50cm9kdWN0aW9u Og0KPg0KPiAtIEFkZCBwdXJwb3NlcyAvIHVzZSBjYXNlcw0KPiAtIERlc2NyaWJlIGhvdyBpdCBy ZWxhdGVzIHRvIG90aGVyIGF1dGhlbnRpY2F0aW9uIHNjaGVtZXMgKE9wZW5JRCwgSFRUUCBBdXRo KQ0KPiAtIE1vdmUgcmVxdWlyZW1lbnRzIG91dCBvZiB0aGUgaW50cm9kdWN0aW9uDQo+IC0gRGVz Y3JpYmUgZ29hbHMgYW5kIHBvc3NpYmlsaXRpZXMNCj4gLSBDbGFyaWZ5IHRoYXQgdGhlIGxpc3Rl ZCByZXF1aXJlbWVudHMgYXJlIG5vdCB0aGUgb25seSBvbmVzDQoNCkknbSBnZW5lcmFsbHkgaGFw cHkgd2l0aCB0aGUgY3VycmVudCBvdXRsaW5lIGZvciB0aGUgaW50cm9kdWN0aW9uLiBUaG9zZSBs b29raW5nIHRvIGFkZHJlc3MgdGhlc2UgcG9pbnRzIHNob3VsZCBzdWJtaXQgdGV4dCBwcm9wb3Nh bHMuDQoNCj4gVGVybWlub2xvZ3k6DQo+DQo+IC0gRGVmaW5lIGNsaWVudCBzZWNyZXQNCg0KQ2xp ZW50IHNlY3JldCBpc24ndCBhIHRlcm0gYnV0IGEgZGV0YWlsIG9mIHRoZSBjbGllbnQgYXV0aGVu dGljYXRpb24gcHJvY2VzcywgZXNwZWNpYWxseSB3aXRoIHRoZSB3YXkgaXQgaXMgZGVmaW5lZCBu b3cuDQoNCj4gLSBEZXNjcmliZSByZWxhdGlvbnNoaXAgYmV0d2VlbiB0ZXJtcw0KDQpUaGUgc2Vj dGlvbiBoYXMgYmVlbiByZXN0cnVjdHVyZWQgdG8gYWRkIHR3byBsZXZlbHMgb2YgdGVybXMgdG8g c2hvdyByZWxhdGlvbnNoaXBzLg0KDQo+IC0gQWRkIHZlcmlmaWNhdGlvbiBjb2RlDQoNClRoZSB2 ZXJpZmljYXRpb24gY29kZSB3YXMgcmVuYW1lZCB0byBhdXRob3JpemF0aW9uIGNvZGUgYW5kIGFk ZGVkLg0KDQo+IC0gUmVtb3ZlIHRlcm1pbm9sb2d5IHJlZmVyZW5jZXMgdG8gSFRUUCB0ZXJtcw0K DQpSZW1vdmVkIHJlbGlhbmNlIG9uIEhUVFAgdGVybWlub2xvZ3kuDQoNCj4gLSBBZGQgY3J5cHRv Z3JhcGhpYyB0ZXJtcw0KPiAtIFVzZXIgdGhlIHRlcm0gJ2NhcGFiaWxpdHknIHdoZW4gdGFsa2lu ZyBhYm91dCBiZWFyZXIgdG9rZW5zDQoNClNpbmNlIHRoZSBzaWduYXR1cmUgYW5kIGNyeXB0b2dy YXBoeSB3YXMgcmVtb3ZlZCwgdGhlc2UgY29tbWVudHMgYXJlIG5vIGxvbmdlciByZWxldmFudCBm b3IgdGhpcyBkcmFmdC4NCg0KPiBPdmVydmlldzoNCj4NCj4gLSBEb2VzIG5vdCByZWxhdGVkIHRv IHRoZSBpbnRyb2R1Y3Rpb24gKGNvbmZ1c2luZykNCg0KVGhlIG92ZXJ2aWV3IHNlY3Rpb24gd2Fz IHdyaXR0ZW4gZnJvbSBzY3JhdGNoIHNvIGhvcGVmdWxseSBpdCBpcyBsZXNzIGNvbmZ1c2luZy4N Cg0KPiAtIFN0YW5kYXJkaXphdGlvbiBvZiB0b2tlbnMgc2hvdWxkIGJlIGNhbGxlZCBvdXQgYXMg ZGVmaW5lZCBlbHNld2hlcmUNCj4gLSBFeHBsYWluIHRoYXQgdGhlIHNlcGFyYXRpb24gYmV0d2Vl biB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYW5kIHJlc291cmNlIHNlcnZlciBpcyBvdXQgb2Yg c2NvcGUNCg0KQm90aCB3aWxsIGJlIGNsYXJpZmllZCBpbiAtMDkuDQoNCj4gLSBGbG93IGdyb3Vw aW5nIGlzIGNvbmZ1c2luZw0KDQpTaW5jZSB0aGUgZmxvd3MgaGF2ZSBiZWVuIGluY29ycG9yYXRl ZCBpbnRvIHRoZSBpbnRyb2R1Y3Rpb24sIGFuZCB0aGUgZ3JvdXBpbmcgcmVtb3ZlZCwgdGhlIGNv bmZ1c2lvbiBzaG91bGQgYmUgcmVzb2x2ZWQuDQoNCj4gMy4yIEVuZC11c2VyIGVuZHBvaW50Og0K Pg0KPiAtIFJlbmFtZSAnZW5kLXVzZXIgZW5kcG9pbnQnIHRvICdhcHByb3ZhbCB1cmwnDQoNClJl bmFtZWQgdG8gJ2VuZC11c2VyIGF1dGhvcml6YXRpb24gZW5kcG9pbnQnLg0KDQo+IC0gTm8gbWFu ZGF0b3J5IHRvIGltcGxlbWVudCBsYW5ndWFnZSAtIGludGVyb3AgcHJvYmxlbSAoUGV0ZXIgU3Qu IEFuZHJlKQ0KDQoqKiogUGxlYXNlIGNsYXJpZnkgd2hhdCBzaG91bGQgYmUgcmVxdWlyZWQuDQoN Cj4gLSBEb2VzIG5vdCBtZW50aW9uIHVzZXIgaWRlbnRpdHkgKGhvdyB0byB2ZXJpZnkpDQoNClVz ZXIgaWRlbnRpdHkgaXMgb3V0IG9mIHNjb3BlLiBTaG91bGQgYmUgYWRkcmVzc2VkIGJ5IHRoZSBw cm9wb3NlZCBPcGVuSUQgQ29ubmVjdCB3b3JrLg0KDQo+IC0gV2hlbiB1c2luZyBUTFMsIG1ha2Ug c3VyZSBpdCdzIHNlcnZlciBhdXRoZW50aWNhdGlvbiwgbm90IGNsaWVudCBjZXJ0aWZpY2F0ZXMg KEV2ZSBNYWxlcikNCg0KKioqIFBsZWFzZSBwcm9wb3NlIGxhbmd1YWdlLg0KDQo+IC0gJ3VzZXIt dXJpJyBhdHRyaWJ1dGUgaXMgdG9vIGV4cGVyaW1lbnRhbCB0byBiZSBpbmNsdWRlZA0KDQpNb3Zl ZCB0byBkaXNjb3ZlcnkgZHJhZnQuDQoNCj4gLSBFeHBsYWluIHRoYXQgdGhlIGVuZC11c2VyIGVu ZHBvaW50IGlzIG9ubHkgcmVsZXZhbnQgdG8gc29tZSBmbG93cw0KDQpJIHRoaW5rIC0wOCBtYWtl cyB0aGlzIGNsZWFyLg0KDQo+IC0gU2hvdWxkIHN0YW5kYXJkaXplIGV4aXN0aW5nIHNlcnZpY2Ug cHJvdmlkZXIgc3BlY2lmaWMgcGFyYW1ldGVycyBmb3IgVUksIGUuZy4gbGFuZ3VhZ2UsIGRpc3Bs YXkgdHlwZSwgdXNlciBoaW50DQoNClB1Ymxpc2hlZCBpbiBhIHNlcGFyYXRlIFVYIGRyYWZ0Lg0K DQo+IDMuMyBUb2tlbiBlbmRwb2ludDoNCj4NCj4gLSBGaXJzdCBzZW50ZW5jZSAoIkFmdGVyIG9i dGFpbmluZyBhdXRob3JpemF0aW9uIGZyb20gdGhlIHJlc291cmNlIG93bmVyIikgaXMgbm90IHRy dWUgZm9yIGFsbCBmbG93cw0KDQpJIHRoaW5rIHRoZSBzYW1lIGlzc3VlIGV4aXN0cyBpbiAtMDgg YnV0IEknbSBub3Qgc3VyZSBob3cgdG8gYWRkcmVzcyBpdC4gSXMgaXQgcmVhbGx5IGEgcHJvYmxl bT8NCg0KPiAtIE1heWJlIGNoYW5nZSBuYW1lIHRvICdUb2tlbiBpc3N1aW5nIGVuZHBvaW50Jw0K DQpJIHRoaW5rIHRva2VuIGVuZHBvaW50IGlzIG5pY2UgYW5kIHNob3J0Lg0KDQo+IC0gTVVTVCB1 c2UgU1NMPw0KDQpDaGFuZ2VkIHRvICJTZXJ2ZXJzIE1VU1Qgc3VwcG9ydCBUTFMgMS4yIiBhbmQg bWF5IHN1cHBvcnQgb3RoZXIgc3R1ZmYgKGVxdWFsbHkgc3Ryb25nKSBhcyB3ZWxsLg0KDQo+IC0g TWFuZGF0ZSBQT1NUPw0KDQpZZXMuIE90aGVyd2lzZSBzZWNyZXRzIGxlYWsgaW50byBsb2cgZmls ZXMuDQoNCj4gMy4zLjEgQ2xpZW50IEF1dGhlbnRpY2F0aW9uOg0KPg0KPiAtIE5lZWQgbmV3IHRl eHQgZm9yIGNlcnRpZmljYXRlIGF1dGhlbnRpY2F0aW9uDQo+IC0gTmVlZCBtb3JlIGZsZXhpYmxl IGxhbmd1YWdlDQoNClRoZSBsYXRlc3QgZHJhZnQgZml4ZXMgdGhpcyBieSBtb3ZpbmcgdGhlIGNs aWVudCBhdXRoZW50aWNhdGlvbiBvdXQgb2YgdGhlIGVuZHBvaW50cyBhbmQgaW50byBpdHMgb3du IHNlY3Rpb24uIEluIGFkZGl0aW9uLCB0aGUgY2xpZW50IGlkZW50aWZpZXIgYW5kIHNlY3JldCBh cmUgZ2l2ZW4gYSBuYW1lIChiYXNpYyBjbGllbnQgY3JlZGVudGlhbHMpIHRvIG1ha2UgaXQgZWFz aWVyIHRvIHNwZWNpZnkgb3RoZXIgd2F5cyB0byBhdXRoZW50aWNhdGUgdGhlIGNsaWVudC4NCg0K PiAzLjMuMiBSZXNwb25zZSBGb3JtYXQ6DQo+DQo+IC0gRG8gd2UgbmVlZCBzbyBtYW55IGZvcm1h dHM/DQo+IC0gQXJlIGFsbCBmb3JtYXRzIG5lZWRlZCBvbiBib3RoIHNpZGVzPw0KDQpTb2x2ZWQg YnkgdXNpbmcganVzdCBKU09OIGZvciB0b2tlbiBlbmRwb2ludCByZXNwb25zZXMuDQoNCj4gLSBJ cyBuby1zdG9yZSBlbm91Z2ggb2YgYSBjYWNoZS1jb250cm9sIGhlYWRlcj8gKENodWNrIE1vcnRp bW9yZSkNCg0KKioqIE5vIGlkZWEuIElzIGl0Pw0KDQo+IDMuMy4yLjEgQWNjZXNzIFRva2VuIFJl c3BvbnNlOg0KPg0KPiAtIERlZmluZSBzY29wZSBvbmNlLCBpbmNsdWRlIGJ5IHJlZmVyZW5jZQ0K DQpEb24ndCBldmVuIG5lZWQgdG8gcmVmZXJlbmNlIGFueW1vcmUuIERlZmluZWQgaW4gYSBzaW5n bGUgcGxhY2UuDQoNCj4gLSBOZWVkIOKAnHNjb3Bl4oCdIGV4YW1wbGUgKEhhbm5lcykNCg0KKioq IEl0IGlzIGhhcmQgdG8gcHJvdmlkZSBzY29wZSBleGFtcGxlcy4gQXJlIHRoZXJlIGFueSBzY29w ZXMgY29tbW9uIGluIG1vcmUgdGhhbiBvbmUgT0F1dGggMS4wIGltcGxlbWVudGF0aW9uPw0KDQo+ IC0gU2NvcGUgaXMgdW5kZXJzcGVjaWZpZWQNCg0KSXQgaXMgYXMgc3BlY2lmaWVkIGFzIHdlIGhh dmUgY29uc2Vuc3VzIGZvciAoZXZlbiB0aGlzIHdhcyBwYWluZnVsKS4NCg0KPiAtIEF1dGhvcml6 YXRpb24gc2VydmVyIE1VU1QgaG9ub3IgY2xpZW50IHJlcXVlc3QgZm9yIHRva2VuIHNlY3JldD8N Cg0KU2luY2UgdGhpcyBpcyBtb3ZlZCB0byBhbiBleHRlbnNpb24sIHRoZSBhbnN3ZXIgaXMgbm8u DQoNCj4gLSBTZW1hbnRpY3Mgb2Yg4oCcZXhwaXJlc19pbuKAnSBhcmUgdW5kZXJzcGVjaWZpZWQN Cg0KQWRkZWQgZXhhbXBsZSBpbiAtMDkuDQoNCj4gMy4zLjIuMiBFcnJvciByZXNwb25zZToNCj4N Cj4gLSBEYXRhIGZvcm1hdCBuZWVkcyB0byBiZSBpbiBzeW5jIGFjcm9zcyBlbnRpcmUgc3BlYw0K DQpOb3cgdXNlcyBKU09OIGxpa2UgYSBzdWNjZXNzZnVsIHJlc3BvbnNlLg0KDQo+IC0gQWRkIGRl YnVnZ2luZyBtZXNzYWdlIGZpZWxkIHRvIEpTT04NCg0KRGVidWdnaW5nIGlzIG91dCBvZiBzY29w ZSwgYnV0IGZlZWwgZnJlZSB0byB3cml0ZSBhIHByb3Bvc2FsLg0KDQo+IC0gUHJlZGVmaW5lZCBs aXN0IG9mIGVycm9yIHJlc3BvbnNlcz8NCg0KTmV3IHNlY3Rpb24gYWRkZWQgaW4gLTA3LiBTdGls bCBuZWVkcyB0byBhZGQgdGV4dCB0byBkZXNjcmliZSBlYWNoIGVycm9yIG1lc3NhZ2UsIGFzIHdl bGwgYXMgbWFrZSB0aGUgbGlzdCBjb21wbGV0ZS4NCg0KPiAzLjQgRmxvdyBQYXJhbWV0ZXJzOg0K Pg0KPiAtIE1vcmUgb24gZXJyb3IgaGFuZGxpbmc/IChQZXRlciBTdC4gQW5kcmUpDQoNCioqKiBO b3Qgc3VyZSB3aGF0IHRoaXMgaXMgYWJvdXQuDQoNCj4gMy41IFVzZXItQWdlbnQgRmxvdzoNCj4N Cj4gLSBJZiByZWZyZXNoIHRva2VuIGxlYWtzLCB5b3UgY2Fu4oCZdCByZWNvdmVyLiDCoENoYW5n aW5nIGNsaWVudCBzZWNyZXQgaXMgbm90IGVub3VnaC4NCg0KTm8gbG9uZ2VyIGlzc3VpbmcgcmVm cmVzaCB0b2tlbiBpbiB1c2VyLWFnZW50IGZsb3cuDQoNCj4gLSBDYW4gd2UgY2hhbmdlIG9yZGVy IG9mIHVzZXItYWdlbnQgYW5kIHdlYiBhcHAgZmxvdyBpbiBzcGVjPw0KDQpEb25lLg0KDQo+IC0g V1JBUCB3ZWIgc2VydmVyIGZsb3cgd2FzIG1vcmUgc2VjdXJlIGZvciByaWNoLWNsaWVudCBhcHBz LCBiZWNhdXNlIHdlYiBzaXRlcyBjYW5ub3QgcHJldGVuZCB0byBiZSByaWNoIGNsaWVudHMuIMKg VXNlci1BZ2VudCBmbG93IGRvZXMgbm90IGFsbG93IHRoaXMuIChTYXJhaCBGYXVsa25lcikNCg0K KioqIFBsZWFzZSBzdGFydCBhIG5ldyB0aHJlYWQgdG8gZGlzY3Vzcy4NCg0KPiAtIFdoZXJlIGRv IHdlIGhhbmRsZSBjdXN0b20gcHJvdG9jb2wgc2NoZW1lcyBpbiByZWRpcmVjdCBVUklzPw0KDQoq KiogQ3VycmVudGx5IG1lbnRpb25lZCBpbiBuYXRpdmUgYXBwbGljYXRpb24gc2VjdGlvbi4gTmVl ZCBndWlkYW5jZSBmcm9tIElFU0cgb24gaG93IHRvIGhhbmRsZSB0aGlzIHNvIGl0IHdpbGwgbm90 IGJlY29tZSBhIGJsb2NraW5nIGlzc3VlLg0KDQo+IC0gTW92ZSBpbnN0YWxsZWQgYXBwbGljYXRp b25zIHRvIGEgc2VwYXJhdGUgc2VjdGlvbg0KDQpEb25lLg0KDQo+IC0gTmVlZCB0byBnaXZlIGlu c3RhbGxlZCBhcHAgZGV2ZWxvcGVycyBhIHdheSB0byBzcGVjaWZ5IGRldmljZSBuYW1lIChCcmlh biBFYXRvbikNCg0KKioqIFBsZWFzZSBwcm9wb3NlIHRleHQuDQoNCj4gLSBDYW7CoG1vYmlsZSBk ZXZlbG9wZXJzIHVzZSBIVFRQIFVSTCBkaXNjb3ZlcnkgZnJvbSBzbGlkZSBkZWNrIGluc3RlYWQ/ IChCaWxsIEtlZW5hbikNCg0KKioqIE5lZWQgY2xhcmlmaWNhdGlvbi4NCg0KPiAtIEV4cGxhaW4g aG93IHRvIGF1dGhlbnRpY2F0ZSB0aGUgY2xpZW50Lg0KIA0KSSB0aGluayB0aGUgbmV3IHRleHQg aXMgcHJldHR5IGNsZWFyLCB1c2luZyBhIHJlZmVyZW5jZSB0byB0aGUgY2xpZW50IGF1dGhlbnRp Y2F0aW9uIHNlY3Rpb24uDQoNCj4gMy41LjEgQ2xpZW50IFJlcXVlc3RzIEF1dGhvcml6YXRpb246 DQo+DQo+IC0gV2hhdCBpZiBtYWxpY2lvdXMgYWN0b3IgKGVpdGhlciBhIHVzZXIgb3Ig4oCcbWFu IGluIHRoZSBicm93c2Vy4oCdKSB0YW1wZXJzIHdpdGgg4oCcc2NvcGXigJ0gb3Ig4oCcc3RhdGXi gJ0gcGFyYW1ldGVyPyAoRXZlIE1hbGVyKQ0KDQpTaW5jZSB0aGUgZW5kLXVzZXIgZ2V0cyB0byBh dXRob3JpemUgdGhlIHJlcXVlc3QsIHNjb3BlIHRlbXBlcmluZyBzaG91bGRuJ3QgYmUgYSBwcm9i bGVtLiBBcyBmb3Igc3RhdGUsIEknbSBub3Qgc3VyZS4NCg0KPiAtIFNob3VsZCB3ZSBhZGQgYW4g ZXh0ZW5zaW9uIHNvIHRoYXQgdXNlcnMgY2FuIHNlbGYtaWRlbnRpZnkgdGhlaXIgZGV2aWNlPyAo QmlsbCBTbWl0aCkNCg0KKioqIFBsZWFzZSBwcm9wb3NlIHRleHQgb3Igc3RhcnQgYSBkaXNjdXNz aW9uLg0KDQo+IC0gQXV0aG9yaXphdGlvbiBzZXJ2ZXJzIE1BWSByZXN0cmljdCB0aGUgcmVkaXJl Y3Rpb24gVVJJIHRvIG5vdCBpbmNsdWRlIGENCj4gcXVlcnkgY29tcG9uZW50LiBUaGlzIHdpbGwg YnJlYWsgUEhQIGNsaWVudHMNCg0KVGhpcyBpcyBwYXJ0IG9mIHRoZSB1bmRlcnNwZWNpZmllZCBt YXRjaGluZyBydWxlcy4gSSdsbCBkcm9wIGl0IGZvciBub3cuDQoNCj4gMy41LjEuMSBFbmQtdXNl ciBncmFudHMgYXV0aG9yaXphdGlvbjoNCj4NCj4gLSBzZWVtcyBvZGQgdGhhdCBjbGllbnQgaXMg cmVxdWVzdGluZyB0aGUgdG9rZW4gc2VjcmV0Lg0KPiAtIHdoYXQgaGFwcGVucyBpZiBzZXJ2ZXIg ZG9lc27igJl0IHdhbnQgdG8gaXNzdWUgdG9rZW4gc2VjcmV0Pw0KDQpSZW1vdmVkLiBTdGlsbCBh biBvcGVuIHF1ZXN0aW9uIGZvciB0aGUgc2lnbmF0dXJlIHNwZWMuDQoNCj4gLSBzaG91bGQgd2Ug bWFrZSBleGFtcGxlIGh0dHBzPw0KDQpJIGRvbid0IHRoaW5rIHRoaXMgaXMgbmVjZXNzYXJ5IHNp bmNlIHRoZSBmcmFnbWVudCBpcyBub3QgdHJhbnNtaXR0ZWQuDQoNCj4gMy41LjEuMiBFbmQtdXNl ciBkZW5pZXMgYXV0aG9yaXphdGlvbjoNCj4NCj4gLSBNb3JlIGVycm9yIGNvZGVzIG5lZWRlZCAo U2FyYWggRmF1bGtuZXIgYW5kIE1hcml1cyBTY3VydGVzY3UpDQoNCioqKiBQbGVhc2UgcHJvdmlk ZSB0ZXh0Lg0KDQo+IC0gSW1tZWRpYXRlIG1vZGUgZmFpbHVyZSBuZWVkcyBhbiBlcnJvciBjb2Rl DQoNClJlbW92ZWQuIE5vdGVkIGZvciB3aGVuIHRoZSBwYXJhbWV0ZXIgYXBwZWFycyBvbiBhbm90 aGVyIGRyYWZ0Lg0KDQo+IDMuNS4yIENsaWVudCBleHRyYWN0cyBhY2Nlc3MgdG9rZW46DQo+DQo+ IC0gQ2FuIHdlIHRlbGwgdXNlci1hZ2VudHMgbm90IHRvIHNlbmQgZnJhZ21lbnQgaW4gSFRUUCBy ZXF1ZXN0PyDCoElFIGRvZXMgdGhpcw0KPiBpbiBjZXJ0YWluIGNpcmN1bXN0YW5jZXMuDQoNCkhU VFAgdGVsbHMgdGhhdC4gSXQgd2FzIG1hZGUgbW9yZSBleHBsaWNpdCBpbiB0aGUgbmV3IEhUVFBi aXMgd29yay4gQmV5b25kIHRoYXQsIG5vdCBzdXJlIHdoYXQgd2UgY2FuIGRvLg0KDQo+IDMuNi4x IENsaWVudCBSZXF1ZXN0cyBBdXRob3JpemF0aW9uOg0KPg0KPiAtIHJlZGlyZWN0X3VyaSB2YWxp ZGF0aW9uIHN0cmF0ZWd5IHNob3VsZCBiZSBkZXNjcmliZWQgb25jZSBpbiB0aGUgc3BlYywgYW5k IHRoZW4gaW5jbHVkZWQgYnkgcmVmZXJlbmNlLg0KDQpEb25lLg0KDQo+IC0gU29tZSBvZiB0aGUg cmVxdWlyZWQgcGFyYW1ldGVycyBkb27igJl0IG1ha2Ugc2Vuc2UgaWYgYXV0aGVudGljYXRpb24g b2YgdXNlciBpcyBvdXQgb2YgYmFuZC4gKEV2ZSBNYWxlcikNCg0KVGhlIG9ubHkgcmVxdWlyZWQg cGFyYW1ldGVyIHRoZXJlIHdlcmUgJ2NsaWVudF9pZCcsICd0eXBlJywgYW5kICdyZWRpcmVjdF91 cmknLiBXaGljaCBvbmUgYXJlIHlvdSByZWZlcnJpbmcgdG8/DQoNCj4gMy42LjEuMSAtIEVuZC11 c2VyIGdyYW50cyBhdXRob3JpemF0aW9uOg0KPg0KPiAtIFdoYXQgZG9lcyB0aGUgdmVyaWZpY2F0 aW9uIGNvZGUgcHJvdmlkZT8NCg0KSSB0aGluayB0aGUgbmV3IHRleHQgZXhwbGFpbnMgdGhpcyAo cGFydCBvZiB0aGUgYWJzdHJhY3Rpb24gbGF5ZXIgcHJvdmlkZWQgYnkgdGhlIGFjY2VzcyBncmFu dCkuIExldCBtZSBrbm93IGlmIGl0IHN0aWxsIG5lZWRzIHRvIGJlIGNsYXJpZmllZC4NCg0KPiAt IEhvdyBkbyBwZW9wbGUga2VlcCB2ZXJpZmljYXRpb24gY29kZSBmcm9tIGxlYWtpbmcgaW4gcmVm ZXJyZXIgaGVhZGVyPyAoU2FyYWggRmF1bGtuZXIpDQoNCioqKiBJcyB0aGlzIGFuIGlzc3VlPyBD YW4geW91IHN0YXJ0IGEgdGhyZWFkIHRvIGRpc2N1c3M/DQoNCj4gLSBTaG91bGQgd2UgZGVmaW5l IHRpbWUtbGltaXQgZm9yIHZlcmlmaWNhdGlvbiBjb2RlPyDCoDUgbWludXRlcz8gKFBldGVyIFN0 LiBBbmRyZSkNCg0KKioqIE9wZW4gaXNzdWUuDQoNCj4gLSBTcGVjaWZ5IHRoYXQgdmVyaWZpY2F0 aW9uIGNvZGUgc2hvdWxkIGJlIHVzZWQgb25seSBvbmNlDQoNCk1hZGUgZXZlbiBjbGVhcmVyIGlu IC0wOS4NCg0KPiAzLjYuMiAtIENsaWVudCByZXF1ZXN0cyBhY2Nlc3MgdG9rZW46DQo+DQo+IC0g c2hvdWxkIG1lbnRpb24gaHR0cHMNCg0KRG9uZS4NCg0KW0RldmljZSBmbG93IGZlZWRiYWNrIHJl bW92ZWRdDQoNCj4gMy44IC0gVXNlcm5hbWUgYW5kIHBhc3N3b3JkIGZsb3c6DQo+DQo+IC0gbmVl ZCB0byByZXR1cm4gZXJyb3IgVVJMIGZyb20gdGhpcyBmbG93LCBzbyB0aGF0IHVzZXJzIGNhbiBn ZXQgdGhlaXIgYWNjb3VudCB1bmJsb2NrZWQgaWYgdGhleSBhcmUgb24gdGhlIHNhbWUgSVAgcmFu Z2UgYXMgYSBib3RuZXQgKEJyaWFuIEVhdG9uKQ0KDQoqKiogUGxlYXNlIHN1Z2dlc3QgdGV4dC4N Cg0KPiAzLjEwIC0gQXNzZXJ0aW9uIEZsb3c6DQo+DQo+IC0gd2UgbmVlZCBhbiBleGFtcGxlDQoN CkRvbmUuDQoNCj4gLSBUd28gZm9ybWF0IHBhcmFtZXRlcnMNCg0KRml4ZWQuDQoNCj4gNCAtIFJl ZnJlc2ggVG9rZW46DQo+DQo+IC0gc2hvdWxkIHdlIGFsd2F5IHRlbGwgY2xpZW50cyB0byB1c2Ug YSBzZWNyZXQsIGUuZy4g4oCcYW5vbnltb3Vz4oCdIG9yIOKAnG9wZW5zZWNyZXTigJ0/IMKgQWJz ZW50IHNlY3JldCBtaWdodCBiZSBjb25mdXNpbmc/IChCcmlhbiBFYXRvbikNCg0KKioqIFBsZWFz ZSBjbGFyaWZ5Lg0KDQo+IC0gU2hvdWxkIHdlIGFsbG93IGRvd24tc2NvcGluZyBvbiB0aGlzIGVu ZHBvaW50Pw0KDQotMDggYWRkcyBzdXBwb3J0IGZvciBkb3duLXNjb3BpbmcuDQoNCj4gLSBTY29w ZSBuZWVkcyB0byBiZSBmaWd1cmVkIG91dCB0aHJvdWdoIGVudGlyZSBmbG93IChFdmUgTWFsZXIp DQoNCioqKiAtMDggdHJpZXMgdG8gY2xlYW4gdXAgc2NvcGUgaGFuZGxpbmcuIFBsZWFzZSByZXZp ZXcuDQoNCj4gNSAtIEFjY2Vzc2luZyBhIHByb3RlY3RlZCByZXNvdXJjZToNCj4NCj4gLSBObyBj bGVhciBlcnJvciBwYXRoDQoNCk5vdGVkLiBUbyBiZSBhZGRyZXNzZWQgaW4gLTA5Lg0KDQo+IC0g U2hvdWxkIHRoZSBhdXRoZW50aWNhdGlvbiBzY2hlbWUgbmFtZSBiZSBjYWxsZWQgJ1Rva2VuJz8N Cg0KSSB0aGluayBzby4gVGhvc2Ugd2hvIGRpc2FncmVlIGFyZSB3ZWxjb21lIHRvIHN0YXJ0IGEg ZGlzY3Vzc2lvbi4NCg0KPiAtIENhbiB3ZSBzYXkg4oCcYmVhcmVyIHRva2Vuc+KAnSBNVVNUIE5P VCBiZSBzZW50IG92ZXIgc2VjdXJlIGNoYW5uZWxzPyAoSmltIEZlbnRvbikNCg0KSSB3b3VsZCBs aWtlIHRoYXQgYnV0IGNvbnNlbnN1cyB3YXMgdGhhdCBTSE9VTEQgTk9UIGlzIHRoZSBzdHJvbmdl c3Qgd2UgY2FuIHNwZWNpZnkuDQoNCj4gLSBDYW4gd2Ugd3JpdGUgYSBzcGVjIHRoYXQgcmVmbGVj dHMgc2VjdXJpdHkgcmVhbGl0eSAtIHBlb3BsZSBkbyBzZW5kIGJlYXJlciB0b2tlbnMgb3ZlciBI VFRQIGNvbm5lY3Rpb25zDQoNCldlIGRpZCA6LSgNCg0KPiAtIENhbiB3ZSBzYXkgTVVTVCBOT1Qg c2VuZCBiZWFyZXIgdG9rZW5zIHRvIHVuZmFtaWxpYXIgc2l0ZXM/DQoNCkRvbmUgaW4gLTA5Lg0K DQo+IC0gSXMg4oCcdW5mYW1pbGlhcuKAnSB3ZWxsLWRlZmluZWQ/DQoNCkkgdGhpbmsgaXQgaXMg aW4gdGhlIGNvbnRleHQgb2YgdGhlIHNwZWMgLSBub3QgaGFyZGNvZGVkIGludG8gdGhlIGNsaWVu dC4NCg0KPiAtIENhbiB3ZSBoYXZlIGEgc2FtZS1vcmlnaW4gcG9saWN5Pw0KDQpUaGlzIG5lZWRz IHRvIGJlIGFkZHJlc3NlZCBpbiB0aGUgZGlzY292ZXJ5IHNwZWMuIEphbWVzJyBwcm9wb3NlICdz aXRlcycgcGFyYW1ldGVyIGlzIG9uZSBhcHByb2FjaC4NCg0KPiA1LjIgLSBCZWFyZXIgVG9rZW4g UmVxdWVzdHM6DQo+DQo+IC0gV2Ugc2hvdWxkIGRyb3AgcmVhbG0sIGl0IGhhcyBubyBtZWFuaW5n ZnVsIHNlbWFudGljcyBoZXJlDQoNCioqKiBJIHdpbGwgZmxvYXQgdGhpcyBwYXN0IHRoZSBIVFRQ IGZvbGtzIHRvIGdhZ2UgdGhlaXIgcmVhY3Rpb24uDQoNCj4gNi4xIC0gV1dXLUF1dGhlbnRpY2F0 ZSBSZXNwb25zZSBoZWFkZXI6DQo+DQo+IC0gd2hhdCBhYm91dCByZXNvdXJjZXMgdGhhdCByZXR1 cm4gcHVibGljIGRhdGEgaWYgcmVxdWVzdCBpcyB1bmF1dGhlbnRpY2F0ZWQ/IFBPU1QgdnMgR0VU IG1pZ2h0IGhhdmUgZGlmZmVyZW50IHNlY3VyaXR5IHBvbGljeS4NCg0KKioqIE5lZWQgdG8gbG9v ayBpbnRvIHRoaXMuDQoNCj4gNi4xLjEuIC0gZGVzY3JpYmluZyB0aGUgV1dXLUF1dGhlbnRpY2F0 ZSByZXNwb25zZSBoZWFkZXINCj4NCj4gLSBEaXNjb3ZlcnkgbmVlZGVkIGZvciB2YXJpb3VzIGVs ZW1lbnRzDQoNClllcy4gVGhhdCdzIGZvciB0aGUgZGlzY292ZXJ5IGRyYWZ0Lg0KDQo= From eran@hueniverse.com Mon Jun 14 23:56:53 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E6D53A681F for ; Mon, 14 Jun 2010 23:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.797 X-Spam-Level: X-Spam-Status: No, score=-0.797 tagged_above=-999 required=5 tests=[AWL=-0.799, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id biyVwer3sBmI for ; Mon, 14 Jun 2010 23:56:52 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id ECA423A659C for ; Mon, 14 Jun 2010 23:56:50 -0700 (PDT) Received: (qmail 9233 invoked from network); 15 Jun 2010 06:56:54 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 15 Jun 2010 06:56:53 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 14 Jun 2010 23:56:54 -0700 From: Eran Hammer-Lahav To: Lisa Dusseault , oauth Date: Mon, 14 Jun 2010 23:56:58 -0700 Thread-Topic: [OAUTH-WG] Assertion flow and token bootstrapping Thread-Index: AcsCeZuWf+1QUumuS2KElnRLeYFGvwJ3iQ8w Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB68E0@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_90C41DD21FB7C64BB94121FBBC2E72343B3EBB68E0P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Assertion flow and token bootstrapping X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 06:56:53 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EBB68E0P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As long as: - You can provide a URI identifier for the assertion format you are going t= o use, and - The authorization server can do something useful with the assertion provi= ded and decide if it should grant an access token Then sure, you can use the assertion flow for utilizing any other trust fra= mework for obtaining an access token. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of L= isa Dusseault Sent: Wednesday, June 02, 2010 10:33 AM To: oauth Subject: [OAUTH-WG] Assertion flow and token bootstrapping I've been trying to understand the use case for the assertion flow (http://= tools.ietf.org/html/draft-ietf-oauth-v2-05#section-3.10) . Conversely, I h= ave a use case for bootstrapping, and I'm trying to understand if the asser= tion flow is the right flow for that use case. The bootstrapping use case I have in mind is to allow a client to interact = with a related set of services by bootstrapping from client secret to an ac= cess token, and then from that access token to other access tokens. For ex= ample, in a "login" interaction the client would get a generic access token= . Later, to use various services -- access to personal data, access to fri= ends' data, attempts to do uploads -- the client would ask the security tok= en server for access to new resources by URI, and if access was granted, re= ceive new access tokens which could be used on those services. The client = secret is not reused very often, and policy is centralized. This seems similar to other use cases being discussed and so it's possible = my main point of confusion is trying to tie this to the assertion flow inst= ead of something else. The assertion flow has the right number of parties involved, and it could c= ertainly be hacked/extended to do bootstrapping: instead of the client secr= et, the general session access token could be used, and the "assertion" fie= ld can contain anything including the URI of the service that the client no= w wants. However I wondered if something less generic could make this more= interoperable. Any thoughts? Thanks, Lisa --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EBB68E0P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As long a= s:

 

- You can provide a URI identifier for the= assertion format you are going to use, and

- The authorization server can do something useful with= the assertion provided and decide if it should grant an access token<= /o:p>

 

Then sure, you can use the assertion flow for util= izing any other trust framework for obtaining an access token.

 

EHL

 

From:= oau= th-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Lis= a Dusseault
Sent: Wednesday, June 02, 2010 10:33 AM
To:= oauth
Subject: [OAUTH-WG] Assertion flow and token bootstrapping=

 


I've been trying to understand the use case for t= he assertion flow (http://tools.ietf.org/html/draft-ietf-oauth-v2-05#sectio= n-3.10) .  Conversely, I have a use case for bootstrapping, and I'= m trying to understand if the assertion flow is the right flow for that use= case. 

The bootstrapping use case I have in mind is to allow = a client to interact with a related set of services by bootstrapping from c= lient secret to an access token, and then from that access token to other a= ccess tokens.  For example, in a "login" interaction the cli= ent would get a generic access token.  Later, to use various services = -- access to personal data, access to friends' data, attempts to do uploads= -- the client would ask the security token server for access to new resour= ces by URI, and if access was granted, receive new access tokens which coul= d be used on those services.  The client secret is not reused very oft= en, and policy is centralized. 

This seems similar to other us= e cases being discussed and so it's possible my main point of confusion is = trying to tie this to the assertion flow instead of something else.
The assertion flow has the right number of parties involved, and it could = certainly be hacked/extended to do bootstrapping: instead of the client sec= ret, the general session access token could be used, and the "assertio= n" field can contain anything including the URI of the service that th= e client now wants.  However I wondered if something less generic coul= d make this more interoperable.

Any thoughts?

Thanks,
Lis= a

= --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EBB68E0P3PW5EX1MB01E_-- From torsten@lodderstedt.net Mon Jun 14 23:57:12 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13D123A659C for ; Mon, 14 Jun 2010 23:57:12 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aXwJUibjibNS for ; Mon, 14 Jun 2010 23:57:11 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.35]) by core3.amsl.com (Postfix) with ESMTP id 163D63A6867 for ; Mon, 14 Jun 2010 23:57:11 -0700 (PDT) Received: from [80.187.148.14] (helo=[10.135.145.183]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1OOQ5B-00050N-Kg; Tue, 15 Jun 2010 08:57:13 +0200 References: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB68D9@P3PW5EX1MB01.EX1.SECURESERVER.NET> Message-Id: From: Torsten Lodderstedt To: Eran Hammer-Lahav In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB68D9@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: multipart/alternative; boundary=Apple-Mail-7--222419395 Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7E18) Mime-Version: 1.0 (iPhone Mail 7E18) Date: Tue, 15 Jun 2010 08:56:46 +0200 X-Df-Sender: 141509 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] OAuth meeting notes on -05 (with updates) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 06:57:12 -0000 --Apple-Mail-7--222419395 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit > - Explain that the separation between the authorization server and > resource server is out of scope Why is this out of scope? I consider this a major improvement over Oauth 1.0. regards, Torsten. Am 15.06.2010 um 08:35 schrieb Eran Hammer-Lahav : > - Explain that the separation between the authorization server and > resource server is out of scope --Apple-Mail-7--222419395 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

- Explain that the = separation between the authorization server and resource server is out = of scope

Why is this out of scope? I = consider this a major improvement over Oauth 1.0.

regards,
Torsten.  


Am 15.06.2010 = um 08:35 schrieb Eran Hammer-Lahav <eran@hueniverse.com>:

- Explain that the separation between the = authorization server and resource server is out of = scope
= --Apple-Mail-7--222419395-- From eran@hueniverse.com Tue Jun 15 00:02:12 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1115D3A6860 for ; Tue, 15 Jun 2010 00:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.08 X-Spam-Level: X-Spam-Status: No, score=-2.08 tagged_above=-999 required=5 tests=[AWL=0.518, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EjtfiD6YYXrp for ; Tue, 15 Jun 2010 00:02:07 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 3794C3A6862 for ; Tue, 15 Jun 2010 00:02:07 -0700 (PDT) Received: (qmail 9611 invoked from network); 15 Jun 2010 07:02:11 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 15 Jun 2010 07:02:11 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 15 Jun 2010 00:02:11 -0700 From: Eran Hammer-Lahav To: Andrew Arnott , "OAuth WG (oauth@ietf.org)" Date: Tue, 15 Jun 2010 00:02:17 -0700 Thread-Topic: [OAUTH-WG] Definition of XML response format Thread-Index: AcsD5VEE571s7DS7Tea7mCIwXSjM5AIczq1g Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB68E1@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_90C41DD21FB7C64BB94121FBBC2E72343B3EBB68E1P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Definition of XML response format X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 07:02:12 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EBB68E1P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Since XML was dropped, if you feel strongly about this, please submit a new= I-D extending the spec to allow XML format responses. Don't worry about ho= w to extend it, just add parameters or whatever for now. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of A= ndrew Arnott Sent: Friday, June 04, 2010 5:56 AM To: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Definition of XML response format In the absence of anyone else volunteering an XML format, what would you sa= y to this as a proposal (because the implementation of which happens to be = simple for me): some access token some refresh token 235298298 So the main points here is: 1. no namespace 2. root tag is called "root" 3. each parameter is an element 4. each element has a type parameter that is either string, number, or ob= ject to assist the deserializer to understnad how to cast the contents. We may axe #4. In fact we may want to switch all the elements to attribute= s because it's slightly more compact which might help small devices. -- 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 Mon, May 31, 2010 at 9:12 AM, Andrew Arnott > wrote: Where is the definition of how a auth server response in XML format should = look? At the least we need an XML namespace and root node name. -- 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 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EBB68E1P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Since XML= was dropped, if you feel strongly about this, please submit a new I-D exte= nding the spec to allow XML format responses. Don’t worry about how t= o extend it, just add parameters or whatever for now.

=

 

EHL

 

From: oauth-bounces@= ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Andrew Arnott<= br>Sent: Friday, June 04, 2010 5:56 AM
To: OAuth WG (oauth= @ietf.org)
Subject: Re: [OAUTH-WG] Definition of XML response for= mat

 =

In the absence of anyone else volunteering an XML = format, what would you say to this as a proposal (because the implementatio= n of which happens to be simple for me):

<root type=3D"objec= t">
   <access_token type=3D"string">s= ome access token</access_token>
   <refresh_token typ= e=3D"string">some refresh token</refresh_token>
 = ;  <expires_in type=3D"number">235298298</expires_i= n>
</root>

So the main points here is:

  • no namespace=
  • root tag is called "root"
  • each parameter is an element
  • each element has a type param= eter that is either string, number, or object to assist the deserializer to= understnad how to cast the contents.

    • We may axe #4.  In fact we may want= to switch all the elements to attributes because it's slightly more compac= t which might help small devices.

    --
    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 Mon, May 31, 2010 at 9:12 AM, Andrew Arnott &l= t;andrewarnott@gmail.com> = wrote:

    Where is the definition of how a = auth server response in XML format should look?  At the least we need = an XML namespace and root node name.

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

     

    = --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EBB68E1P3PW5EX1MB01E_-- From eran@hueniverse.com Tue Jun 15 00:13:41 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9ECAD3A6867 for ; Tue, 15 Jun 2010 00:13:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.091 X-Spam-Level: X-Spam-Status: No, score=-2.091 tagged_above=-999 required=5 tests=[AWL=0.507, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M4D1Sjsmsirh for ; Tue, 15 Jun 2010 00:13:40 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 5385E3A69A8 for ; Tue, 15 Jun 2010 00:13:40 -0700 (PDT) Received: (qmail 19120 invoked from network); 15 Jun 2010 07:13:44 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 15 Jun 2010 07:13:44 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 15 Jun 2010 00:13:44 -0700 From: Eran Hammer-Lahav To: Andrew Arnott , "OAuth WG (oauth@ietf.org)" Date: Tue, 15 Jun 2010 00:13:50 -0700 Thread-Topic: [OAUTH-WG] User agent flow missing optional scope parameter in response? Thread-Index: AcsGZXbkwkYSNVxiTNCApDLQ67JxgwF9NMkw Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB68E7@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_90C41DD21FB7C64BB94121FBBC2E72343B3EBB68E7P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] User agent flow missing optional scope parameter in response? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 07:13:41 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EBB68E7P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Added in -09. From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of A= ndrew Arnott Sent: Monday, June 07, 2010 8:39 AM To: OAuth WG (oauth@ietf.org) Subject: [OAUTH-WG] User agent flow missing optional scope parameter in res= ponse? The web server flow includes an optional scope parameter in a success respo= nse. The user agent flow seems to be missing that. If a single auth serve= r supports both flows, and actually leverages the capability in the web ser= ver flow to change the set of granted scopes from the requested ones by sen= ding a new scope value, it will be unable to do so for user-agent clients. Is this intended? -- 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 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EBB68E7P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Added in = -09.

     

    From: oauth-bounces@ietf.org= [mailto:oauth-bounces@ietf.org] On Behalf Of Andrew Arnott
    Se= nt: Monday, June 07, 2010 8:39 AM
    To: OAuth WG (oauth@ietf.or= g)
    Subject: [OAUTH-WG] User agent flow missing optional scope par= ameter in response?

    <= o:p> 

    The web server flow includes = an optional scope parameter in a success response.  The user agent flo= w seems to be missing that.  If a single auth server supports both flo= ws, and actually leverages the capability in the web server flow to change = the set of granted scopes from the requested ones by sending a new scope va= lue, it will be unable to do so for user-agent clients.

    Is this inte= nded?
    --
    Andrew Arnott
    &= quot;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

     

    = --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EBB68E7P3PW5EX1MB01E_-- From eran@hueniverse.com Tue Jun 15 00:16:47 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 279B33A69A8 for ; Tue, 15 Jun 2010 00:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[AWL=0.497, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SsMBWrr8LFrZ for ; Tue, 15 Jun 2010 00:16:46 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 36EEF3A686E for ; Tue, 15 Jun 2010 00:16:46 -0700 (PDT) Received: (qmail 11881 invoked from network); 15 Jun 2010 07:16:50 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 15 Jun 2010 07:16:50 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Tue, 15 Jun 2010 00:16:51 -0700 From: Eran Hammer-Lahav To: Torsten Lodderstedt Date: Tue, 15 Jun 2010 00:16:56 -0700 Thread-Topic: [OAUTH-WG] OAuth meeting notes on -05 (with updates) Thread-Index: AcsMV/7gjq1VfnrsSO+UKF60cMEnQQAArMFA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB68E8@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB68D9@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_90C41DD21FB7C64BB94121FBBC2E72343B3EBB68E8P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] OAuth meeting notes on -05 (with updates) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 07:16:47 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EBB68E8P3PW5EX1MB01E_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SG93IHRoZXkgY29tbXVuaWNhdGUgaXMgb3V0IG9mIHNjb3BlLg0KDQpFSEwNCg0KRnJvbTogVG9y c3RlbiBMb2RkZXJzdGVkdCBbbWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0XQ0KU2VudDog TW9uZGF5LCBKdW5lIDE0LCAyMDEwIDExOjU3IFBNDQpUbzogRXJhbiBIYW1tZXItTGFoYXYNCkNj OiBPQXV0aCBXRyAob2F1dGhAaWV0Zi5vcmcpDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBPQXV0 aCBtZWV0aW5nIG5vdGVzIG9uIC0wNSAod2l0aCB1cGRhdGVzKQ0KDQoNCg0KLSBFeHBsYWluIHRo YXQgdGhlIHNlcGFyYXRpb24gYmV0d2VlbiB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYW5kIHJl c291cmNlIHNlcnZlciBpcyBvdXQgb2Ygc2NvcGUNCg0KV2h5IGlzIHRoaXMgb3V0IG9mIHNjb3Bl PyBJIGNvbnNpZGVyIHRoaXMgYSBtYWpvciBpbXByb3ZlbWVudCBvdmVyIE9hdXRoIDEuMC4NCg0K DQpyZWdhcmRzLA0KVG9yc3Rlbi4NCg0KDQpBbSAxNS4wNi4yMDEwIHVtIDA4OjM1IHNjaHJpZWIg RXJhbiBIYW1tZXItTGFoYXYgPGVyYW5AaHVlbml2ZXJzZS5jb208bWFpbHRvOmVyYW5AaHVlbml2 ZXJzZS5jb20+PjoNCi0gRXhwbGFpbiB0aGF0IHRoZSBzZXBhcmF0aW9uIGJldHdlZW4gdGhlIGF1 dGhvcml6YXRpb24gc2VydmVyIGFuZCByZXNvdXJjZSBzZXJ2ZXIgaXMgb3V0IG9mIHNjb3BlDQo= --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EBB68E8P3PW5EX1MB01E_ 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 IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uYXBwbGUtc3R5bGUt c3Bhbg0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1zdHlsZS1zcGFuO30NCnNwYW4uRW1haWxTdHls ZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4w aW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBM aXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxMDEzNzk4MTc0Ow0K CW1zby1saXN0LXRlbXBsYXRlLWlkczoxMTgxNDk0NDg4O30NCkBsaXN0IGwwOmxldmVsMQ0KCXtt c28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtdGFi LXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjEuNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGww OmxldmVsNQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7 bXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC10 YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6NC4w aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3Qg bDENCgl7bXNvLWxpc3QtaWQ6MTY0MDQ1NjM3NTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MjA2 ODU4ODIwO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206 MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT48L2hlYWQ+PGJvZHkgYmdjb2xvcj13aGl0ZSBsYW5nPUVOLVVTIGxpbms9Ymx1ZSB2 bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7Y29sb3I6IzFGNDk3RCc+SG93IHRoZXkgY29tbXVuaWNhdGUgaXMgb3V0IG9mIHNjb3Bl LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7Y29sb3I6IzFGNDk3RCc+RUhMPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQnPjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4nPjxw IGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPiBUb3Jz dGVuIExvZGRlcnN0ZWR0IFttYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXRdIDxicj48Yj5T ZW50OjwvYj4gTW9uZGF5LCBKdW5lIDE0LCAyMDEwIDExOjU3IFBNPGJyPjxiPlRvOjwvYj4gRXJh biBIYW1tZXItTGFoYXY8YnI+PGI+Q2M6PC9iPiBPQXV0aCBXRyAob2F1dGhAaWV0Zi5vcmcpPGJy PjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBPQXV0aCBtZWV0aW5nIG5vdGVzIG9uIC0w NSAod2l0aCB1cGRhdGVzKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFz cz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PGJyPjxicj48c3BhbiBjbGFzcz1hcHBsZS1zdHlsZS1zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTEuNXB0Jz48bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjVwdCc+LSBFeHBsYWluIHRoYXQgdGhlIHNlcGFy YXRpb24gYmV0d2VlbiB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYW5kIHJlc291cmNlIHNlcnZl ciBpcyBvdXQgb2Ygc2NvcGU8L3NwYW4+PG86cD48L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS41cHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gY2xhc3M9YXBwbGUtc3R5bGUt c3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjVwdCc+V2h5IGlzIHRoaXMgb3V0IG9mIHNj b3BlPyBJIGNvbnNpZGVyIHRoaXMgYSBtYWpvciBpbXByb3ZlbWVudCBvdmVyIE9hdXRoIDEuMC48 L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuNXB0Jz48YnI+PGJyPjwvc3Bhbj48bzpwPjwvbzpw PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBjbGFzcz1hcHBsZS1zdHls ZS1zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuNXB0Jz5yZWdhcmRzLDwvc3Bhbj48L3Nw YW4+PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gY2xh c3M9YXBwbGUtc3R5bGUtc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjVwdCc+VG9yc3Rl bi4gJm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjVwdCc+PGJy Pjxicj48L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz48YnI+QW0gMTUuMDYuMjAxMCB1bSAwODozNSBz Y2hyaWViIEVyYW4gSGFtbWVyLUxhaGF2ICZsdDs8YSBocmVmPSJtYWlsdG86ZXJhbkBodWVuaXZl cnNlLmNvbSI+ZXJhbkBodWVuaXZlcnNlLmNvbTwvYT4mZ3Q7OjxvOnA+PC9vOnA+PC9wPjwvZGl2 PjxibG9ja3F1b3RlIHN0eWxlPSdtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQn PjxwIGNsYXNzPU1zb05vcm1hbD4tIEV4cGxhaW4gdGhhdCB0aGUgc2VwYXJhdGlvbiBiZXR3ZWVu IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhbmQgcmVzb3VyY2Ugc2VydmVyIGlzIG91dCBvZiBz Y29wZTxvOnA+PC9vOnA+PC9wPjwvYmxvY2txdW90ZT48L2Rpdj48L2Rpdj48L2JvZHk+PC9odG1s Pg== --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EBB68E8P3PW5EX1MB01E_-- From eran@hueniverse.com Tue Jun 15 00:19:26 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B145E3A69A8 for ; Tue, 15 Jun 2010 00:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.111 X-Spam-Level: X-Spam-Status: No, score=-2.111 tagged_above=-999 required=5 tests=[AWL=0.488, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGQL42TUjlsr for ; Tue, 15 Jun 2010 00:19:25 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 98DAE3A6A2E for ; Tue, 15 Jun 2010 00:19:24 -0700 (PDT) Received: (qmail 12161 invoked from network); 15 Jun 2010 07:19:04 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 15 Jun 2010 07:19:04 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 15 Jun 2010 00:19:04 -0700 From: Eran Hammer-Lahav To: Marius Scurtescu , OAuth WG Date: Tue, 15 Jun 2010 00:19:10 -0700 Thread-Topic: [OAUTH-WG] OAuth 2 for Native Apps Thread-Index: AcsGd1zAJXebCkHnSVO1s+f4/MoI0AF46DqA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB68E9@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 2 for Native Apps X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 07:19:26 -0000 Please turn this into a text proposal for section 1.4.3 in -08. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Marius Scurtescu > Sent: Monday, June 07, 2010 12:26 PM > To: OAuth WG > Subject: [OAUTH-WG] OAuth 2 for Native Apps >=20 > Hi, >=20 > I attached a document that summaries how native applications can use > OAuth 2. >=20 > Feedback more than welcome, especially if you have experience with native > apps and OAuth. >=20 > The current Web Server and Device flows need small changes and > clarifications in order to properly support native apps, I will start a s= eparate > thread on that. >=20 > Marius From torsten@lodderstedt.net Tue Jun 15 00:31:34 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44D073A686E for ; Tue, 15 Jun 2010 00:31:34 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zlabjxbrS728 for ; Tue, 15 Jun 2010 00:31:33 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.35]) by core3.amsl.com (Postfix) with ESMTP id E18F73A676A for ; Tue, 15 Jun 2010 00:31:32 -0700 (PDT) Received: from [88.128.85.193] (helo=[10.135.145.183]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1OOQcR-0000iH-Mj; Tue, 15 Jun 2010 09:31:35 +0200 References: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB68D9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3EBB68E8@P3PW5EX1MB01.EX1.SECURESERVER.NET> Message-Id: From: Torsten Lodderstedt To: Eran Hammer-Lahav In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB68E8@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: multipart/alternative; boundary=Apple-Mail-16--220357560 Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7E18) Mime-Version: 1.0 (iPhone Mail 7E18) Date: Tue, 15 Jun 2010 09:31:08 +0200 X-Df-Sender: 141509 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] OAuth meeting notes on -05 (with updates) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 07:31:34 -0000 --Apple-Mail-16--220357560 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit ok, understood. Am 15.06.2010 um 09:16 schrieb Eran Hammer-Lahav : > How they communicate is out of scope. > > > > EHL > > > > From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > Sent: Monday, June 14, 2010 11:57 PM > To: Eran Hammer-Lahav > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] OAuth meeting notes on -05 (with updates) > > > > > > > - Explain that the separation between the authorization server and > resource server is out of scope > > > > Why is this out of scope? I consider this a major improvement over > Oauth 1.0. > > > > > regards, > > Torsten. > > > > Am 15.06.2010 um 08:35 schrieb Eran Hammer-Lahav > : > > - Explain that the separation between the authorization server and > resource server is out of scope --Apple-Mail-16--220357560 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
    ok, = understood.



    Am 15.06.2010 um 09:16 schrieb = Eran Hammer-Lahav <eran@hueniverse.com>:

    How they communicate is out of = scope.

     

    EHL

     

    From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] =
    Sent: Monday, June 14, 2010 11:57 PM
    To: Eran = Hammer-Lahav
    Cc: OAuth WG (oauth@ietf.org)
    Subject: = Re: [OAUTH-WG] OAuth meeting notes on -05 (with = updates)

     



    - Explain that the = separation between the authorization server and resource server is out = of scope

     

    Why is this out of scope? I consider this a = major improvement over Oauth = 1.0.



    regards,

    Torsten.  


    Am 15.06.2010 um = 08:35 schrieb Eran Hammer-Lahav <eran@hueniverse.com>:<= /o:p>

    - = Explain that the separation between the authorization server and = resource server is out of = scope

    = --Apple-Mail-16--220357560-- From Axel.Nennker@telekom.de Tue Jun 15 06:12:21 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7F0A3A681E for ; Tue, 15 Jun 2010 06:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PnM9NGrQY2bQ for ; Tue, 15 Jun 2010 06:12:19 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by core3.amsl.com (Postfix) with ESMTP id 9D8CC3A693E for ; Tue, 15 Jun 2010 06:12:17 -0700 (PDT) Received: from s4de9jsaano.mgb.telekom.de (HELO S4DE9JSAANO.ost.t-com.de) ([10.125.177.105]) by tcmail81.telekom.de with ESMTP; 15 Jun 2010 15:12:15 +0200 Received: from S4DE9JSAAID.ost.t-com.de ([10.125.177.169]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Jun 2010 15:12:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Jun 2010 15:10:03 +0200 Message-ID: <98B37F7D0484184B9DBDCC44B6C8EDA304C07971@S4DE9JSAAID.ost.t-com.de> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB68D9@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: expires_in RE: [OAUTH-WG] OAuth meeting notes on -05 (with updates) Thread-Index: AcsMLfi0k1bL/UTuTyKlbQqO9cCDCgAW+JpA References: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB68D9@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: To: , X-OriginalArrivalTime: 15 Jun 2010 13:12:15.0416 (UTC) FILETIME=[5FE79B80:01CB0C8C] Subject: [OAUTH-WG] expires_in RE: OAuth meeting notes on -05 (with updates) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 13:12:21 -0000 =20 During the meeting we had a (short) discussion about the expires_in = parameter. I propose to change it to a notonorafter parameter with a GMT/UTC date = as value. If the time slew between server is bigger or nearly equal to the life = time of the expires_in value than the token receiver has no chance to = detect that the token is dead on arrival. Or we could keep the name expires_in but change the value from a = relative unit (seconds) to a absolute one (Date) -Axel expires_in OPTIONAL. The duration in seconds of the access token = lifetime. notonorafter OPTIONAL. Specifies the time instant at which the assertion = has expired in universal time coordinates. Example notonorafter=3D"2007-08-21T08:18:50.605Z" -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf = Of Eran Hammer-Lahav Sent: Tuesday, June 15, 2010 8:35 AM To: OAuth WG (oauth@ietf.org) Subject: [OAUTH-WG] OAuth meeting notes on -05 (with updates) During the OAuth WG interim meeting, the group spent a considerable = amount of time going over draft -05 and listing issues with the text and = protocol. Since the draft is now significantly different, I want to go = over this and identify the issues resolved and those still open (before = it is too late). These comments are based on Brian Eaton's detailed notes (thanks!) with = my edits. I removed comments that were not actionable. I kept the names = next to comments where additional clarifications are needed. If the = notes are wrong, blame me for messing with the Brian's copy. Action items are marked with ***. Overall, I think by -09 we will be done with most of the comments (ready = for another batch). EHL --- > Introduction: > > - Add purposes / use cases > - Describe how it relates to other authentication schemes (OpenID, = HTTP Auth) > - Move requirements out of the introduction > - Describe goals and possibilities > - Clarify that the listed requirements are not the only ones I'm generally happy with the current outline for the introduction. Those = looking to address these points should submit text proposals. > Terminology: > > - Define client secret Client secret isn't a term but a detail of the client authentication = process, especially with the way it is defined now. > - Describe relationship between terms The section has been restructured to add two levels of terms to show = relationships. > - Add verification code The verification code was renamed to authorization code and added. > - Remove terminology references to HTTP terms Removed reliance on HTTP terminology. > - Add cryptographic terms > - User the term 'capability' when talking about bearer tokens Since the signature and cryptography was removed, these comments are no = longer relevant for this draft. > Overview: > > - Does not related to the introduction (confusing) The overview section was written from scratch so hopefully it is less = confusing. > - Standardization of tokens should be called out as defined elsewhere > - Explain that the separation between the authorization server and = resource server is out of scope Both will be clarified in -09. > - Flow grouping is confusing Since the flows have been incorporated into the introduction, and the = grouping removed, the confusion should be resolved. > 3.2 End-user endpoint: > > - Rename 'end-user endpoint' to 'approval url' Renamed to 'end-user authorization endpoint'. > - No mandatory to implement language - interop problem (Peter St. = Andre) *** Please clarify what should be required. > - Does not mention user identity (how to verify) User identity is out of scope. Should be addressed by the proposed = OpenID Connect work. > - When using TLS, make sure it's server authentication, not client = certificates (Eve Maler) *** Please propose language. > - 'user-uri' attribute is too experimental to be included Moved to discovery draft. > - Explain that the end-user endpoint is only relevant to some flows I think -08 makes this clear. > - Should standardize existing service provider specific parameters for = UI, e.g. language, display type, user hint Published in a separate UX draft. > 3.3 Token endpoint: > > - First sentence ("After obtaining authorization from the resource = owner") is not true for all flows I think the same issue exists in -08 but I'm not sure how to address it. = Is it really a problem? > - Maybe change name to 'Token issuing endpoint' I think token endpoint is nice and short. > - MUST use SSL? Changed to "Servers MUST support TLS 1.2" and may support other stuff = (equally strong) as well. > - Mandate POST? Yes. Otherwise secrets leak into log files. > 3.3.1 Client Authentication: > > - Need new text for certificate authentication > - Need more flexible language The latest draft fixes this by moving the client authentication out of = the endpoints and into its own section. In addition, the client = identifier and secret are given a name (basic client credentials) to = make it easier to specify other ways to authenticate the client. > 3.3.2 Response Format: > > - Do we need so many formats? > - Are all formats needed on both sides? Solved by using just JSON for token endpoint responses. > - Is no-store enough of a cache-control header? (Chuck Mortimore) *** No idea. Is it? > 3.3.2.1 Access Token Response: > > - Define scope once, include by reference Don't even need to reference anymore. Defined in a single place. > - Need "scope" example (Hannes) *** It is hard to provide scope examples. Are there any scopes common in = more than one OAuth 1.0 implementation? > - Scope is underspecified It is as specified as we have consensus for (even this was painful). > - Authorization server MUST honor client request for token secret? Since this is moved to an extension, the answer is no. > - Semantics of "expires_in" are underspecified Added example in -09. > 3.3.2.2 Error response: > > - Data format needs to be in sync across entire spec Now uses JSON like a successful response. > - Add debugging message field to JSON Debugging is out of scope, but feel free to write a proposal. > - Predefined list of error responses? New section added in -07. Still needs to add text to describe each error = message, as well as make the list complete. > 3.4 Flow Parameters: > > - More on error handling? (Peter St. Andre) *** Not sure what this is about. > 3.5 User-Agent Flow: > > - If refresh token leaks, you can't recover. =A0Changing client secret = is not enough. No longer issuing refresh token in user-agent flow. > - Can we change order of user-agent and web app flow in spec? Done. > - WRAP web server flow was more secure for rich-client apps, because = web sites cannot pretend to be rich clients. =A0User-Agent flow does not = allow this. (Sarah Faulkner) *** Please start a new thread to discuss. > - Where do we handle custom protocol schemes in redirect URIs? *** Currently mentioned in native application section. Need guidance = from IESG on how to handle this so it will not become a blocking issue. > - Move installed applications to a separate section Done. > - Need to give installed app developers a way to specify device name = (Brian Eaton) *** Please propose text. > - Can=A0mobile developers use HTTP URL discovery from slide deck = instead? (Bill Keenan) *** Need clarification. > - Explain how to authenticate the client. =20 I think the new text is pretty clear, using a reference to the client = authentication section. > 3.5.1 Client Requests Authorization: > > - What if malicious actor (either a user or "man in the browser") = tampers with "scope" or "state" parameter? (Eve Maler) Since the end-user gets to authorize the request, scope tempering = shouldn't be a problem. As for state, I'm not sure. > - Should we add an extension so that users can self-identify their = device? (Bill Smith) *** Please propose text or start a discussion. > - Authorization servers MAY restrict the redirection URI to not = include a > query component. This will break PHP clients This is part of the underspecified matching rules. I'll drop it for now. > 3.5.1.1 End-user grants authorization: > > - seems odd that client is requesting the token secret. > - what happens if server doesn't want to issue token secret? Removed. Still an open question for the signature spec. > - should we make example https? I don't think this is necessary since the fragment is not transmitted. > 3.5.1.2 End-user denies authorization: > > - More error codes needed (Sarah Faulkner and Marius Scurtescu) *** Please provide text. > - Immediate mode failure needs an error code Removed. Noted for when the parameter appears on another draft. > 3.5.2 Client extracts access token: > > - Can we tell user-agents not to send fragment in HTTP request? =A0IE = does this > in certain circumstances. HTTP tells that. It was made more explicit in the new HTTPbis work. = Beyond that, not sure what we can do. > 3.6.1 Client Requests Authorization: > > - redirect_uri validation strategy should be described once in the = spec, and then included by reference. Done. > - Some of the required parameters don't make sense if authentication = of user is out of band. (Eve Maler) The only required parameter there were 'client_id', 'type', and = 'redirect_uri'. Which one are you referring to? > 3.6.1.1 - End-user grants authorization: > > - What does the verification code provide? I think the new text explains this (part of the abstraction layer = provided by the access grant). Let me know if it still needs to be = clarified. > - How do people keep verification code from leaking in referrer = header? (Sarah Faulkner) *** Is this an issue? Can you start a thread to discuss? > - Should we define time-limit for verification code? =A05 minutes? = (Peter St. Andre) *** Open issue. > - Specify that verification code should be used only once Made even clearer in -09. > 3.6.2 - Client requests access token: > > - should mention https Done. [Device flow feedback removed] > 3.8 - Username and password flow: > > - need to return error URL from this flow, so that users can get their = account unblocked if they are on the same IP range as a botnet (Brian = Eaton) *** Please suggest text. > 3.10 - Assertion Flow: > > - we need an example Done. > - Two format parameters Fixed. > 4 - Refresh Token: > > - should we alway tell clients to use a secret, e.g. "anonymous" or = "opensecret"? =A0Absent secret might be confusing? (Brian Eaton) *** Please clarify. > - Should we allow down-scoping on this endpoint? -08 adds support for down-scoping. > - Scope needs to be figured out through entire flow (Eve Maler) *** -08 tries to clean up scope handling. Please review. > 5 - Accessing a protected resource: > > - No clear error path Noted. To be addressed in -09. > - Should the authentication scheme name be called 'Token'? I think so. Those who disagree are welcome to start a discussion. > - Can we say "bearer tokens" MUST NOT be sent over secure channels? = (Jim Fenton) I would like that but consensus was that SHOULD NOT is the strongest we = can specify. > - Can we write a spec that reflects security reality - people do send = bearer tokens over HTTP connections We did :-( > - Can we say MUST NOT send bearer tokens to unfamiliar sites? Done in -09. > - Is "unfamiliar" well-defined? I think it is in the context of the spec - not hardcoded into the = client. > - Can we have a same-origin policy? This needs to be addressed in the discovery spec. James' propose 'sites' = parameter is one approach. > 5.2 - Bearer Token Requests: > > - We should drop realm, it has no meaningful semantics here *** I will float this past the HTTP folks to gage their reaction. > 6.1 - WWW-Authenticate Response header: > > - what about resources that return public data if request is = unauthenticated? POST vs GET might have different security policy. *** Need to look into this. > 6.1.1. - describing the WWW-Authenticate response header > > - Discovery needed for various elements Yes. That's for the discovery draft. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From andrewarnott@gmail.com Tue Jun 15 06:55:59 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D97523A67D6 for ; Tue, 15 Jun 2010 06:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.431 X-Spam-Level: X-Spam-Status: No, score=-0.431 tagged_above=-999 required=5 tests=[AWL=-0.433, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mid4Bt8wituM for ; Tue, 15 Jun 2010 06:55:59 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id D63A83A67D4 for ; Tue, 15 Jun 2010 06:55:58 -0700 (PDT) Received: by gwj16 with SMTP id 16so3343906gwj.31 for ; Tue, 15 Jun 2010 06:56:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=CT7JCxR8kl2AqMaT7qUCcgFzbzmuLFRybIZLwW+RfE4=; b=BCnKMsy6iptOIwyekU0Qjrf/9Q554ofXY63fCQ/oFQMgu5m2RH/1egN+MAauudC3JH eeLkX/CUSuEGQfLA9ryALK+aIwvd/Y0J9C1mUay6OBlW7ROwxpZsgvcIhyMHXd2M8J26 a209YD+aVOWf0Y/WxL3eOri/8kciXLlhqWtQQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=ji7ADlZIsTepcFtQpDu5+WczwtB67bi9vKdmME+XYLNFjBl3+5EWi0w6AZ9lwHa6C9 I7WUm3lTXANCrdc8XYW2LWTCXAyv3hWNHbfiON0Z+9x1CLXHHncBAmrv3jysyWcQEDXU fq+cZuQhfwDOFXej5Xzdt6fAQeE6VtlxHxwng= MIME-Version: 1.0 Received: by 10.150.94.6 with SMTP id r6mr8579153ybb.306.1276610159373; Tue, 15 Jun 2010 06:55:59 -0700 (PDT) Received: by 10.151.26.19 with HTTP; Tue, 15 Jun 2010 06:55:58 -0700 (PDT) Date: Tue, 15 Jun 2010 06:55:58 -0700 Message-ID: From: Andrew Arnott To: "OAuth WG (oauth@ietf.org)" Content-Type: multipart/alternative; boundary=000e0cd6e7e611271c048911f724 Subject: [OAUTH-WG] Clarification on whether arguments can contain empty values X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 13:55:59 -0000 --000e0cd6e7e611271c048911f724 Content-Type: text/plain; charset=ISO-8859-1 Can we get some clarification into the spec as to whether optional parameters can be present but empty? Particularly parameters such as tokens that obviously cannot be meaningful when having an empty value. This was a muddy issue in the OpenID spec, where some implementations would include empty parameters rather than just omitting them, breaking other implementations that would expect that if the parameter is present it ought to have a meaningful value. My own vote: parameters must have valid values (non-empty) if they are present, unless they are opaque strings (like client state) that the remote party doesn't have to do anything but imitate back anyway. -- 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 --000e0cd6e7e611271c048911f724 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Can we get some clarification into the spec as to whether optional paramete= rs can be present but empty?=A0 Particularly parameters such as tokens that= obviously cannot be meaningful when having an empty value.=A0 This was a m= uddy issue in the OpenID spec, where some implementations would include emp= ty parameters rather than just omitting them, breaking other implementation= s that would expect that if the parameter is present it ought to have a mea= ningful value.

    My own vote: parameters must have valid values (non-empty) if they are = present, unless they are opaque strings (like client state) that the remote= party doesn't have to do anything but imitate back anyway.

    --
    Andrew Arnott
    "I [may] not agree with what you have to say, b= ut I'll defend to the death your right to say it." - S. G. Tallent= yre
    --000e0cd6e7e611271c048911f724-- From andrewarnott@gmail.com Tue Jun 15 06:58:45 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 035CA28C11B for ; Tue, 15 Jun 2010 06:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.525 X-Spam-Level: X-Spam-Status: No, score=-1.525 tagged_above=-999 required=5 tests=[AWL=1.073, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-CXi0D1S2He for ; Tue, 15 Jun 2010 06:58:44 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id DA0C73A67D6 for ; Tue, 15 Jun 2010 06:58:43 -0700 (PDT) Received: by gyh4 with SMTP id 4so3340157gyh.31 for ; Tue, 15 Jun 2010 06:58:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=PDfHoC3rBx53/eVq8mRwcCIVKv/dZnga5c+pdFElbgA=; b=ErppFtxw286cmWmsvUWwCfQer64hewKWqpBIBq4i27vITt78lBaULb5ooh+e9QhCB9 l0ZuA3iBUFwQMDeIYoxEhQrWiOzknmF4jo5MEMMyuim9Er7O3Lw69Vn3SJf8r0Brb3jm 7Sx10F/TYvoJPT7mF5MpBR60WB3B+b5bSwLdo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=sP1Jv8qIfLggVTjePgWXjVlAJi0XYSLcwu49EuuvI1IEPcJ8AzY0eZpDknTWZGydjm 0qdMpBDbiZ9ynjN8bDU+OqHr9pIW2nf8kC6V4KbbQ4ylGIJzptd25l1HCsx9X3UjoS9x kw2H/IKoFGKe27QxmknSf0IVx3qEzJ6YPEcEw= MIME-Version: 1.0 Received: by 10.150.167.22 with SMTP id p22mr8560231ybe.382.1276610325392; Tue, 15 Jun 2010 06:58:45 -0700 (PDT) Received: by 10.151.26.19 with HTTP; Tue, 15 Jun 2010 06:58:45 -0700 (PDT) In-Reply-To: <7F00C2CF-E57F-4341-BBA4-7B03B69277D6@gmail.com> References: <7F00C2CF-E57F-4341-BBA4-7B03B69277D6@gmail.com> Date: Tue, 15 Jun 2010 06:58:45 -0700 Message-ID: From: Andrew Arnott To: Dick Hardt Content-Type: multipart/alternative; boundary=000e0cd5c4b0f62d5c04891200c4 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Assertion flow: please add optional refresh_token in response X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 13:58:45 -0000 --000e0cd5c4b0f62d5c04891200c4 Content-Type: text/plain; charset=ISO-8859-1 Well it's easy enough for me to just make up a profile that follows rules I set. But since I don't think this need will be unique to myself, would you like me to write up a spec somewhere? (I've never written an IETF spec before) -- 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 Mon, Jun 14, 2010 at 11:00 PM, Dick Hardt wrote: > +1 > > On 2010-06-14, at 9:02 PM, Brian Eaton wrote: > > > On Mon, Jun 14, 2010 at 8:31 PM, Andrew Arnott > wrote: > >> For an application I'm building, the installed client app will have > >> intermittent windows of time where it can obtain a (non-OAuth) assertion > for > >> user identity. During this time, it seems appropriate for it to use the > >> assertion flow to obtain an OAuth authorization so that it can > impersonate > >> the user. So far this is just standard Assertion Flow stuff. But > without a > >> refresh_token, the app will break when the access token expires if the > app > >> doesn't have the ability at the moment (due to not being on the > corporate > >> network at the moment for example) to obtain a new assertion. Since the > >> security model for this app would certainly allow for a refresh_token to > be > >> issued from the original OAuth authorization server exchange, this would > >> solve it, if the spec didn't specifically ban such a parameter. > > > > I think this is a different use case than the one envisioned by most > > people who are using the assertion flow. > > > > I'm inclined to steer different use cases to different profiles. It > > makes it much easier to guide deployments, for example. > > > > Cheers, > > Brian > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > --000e0cd5c4b0f62d5c04891200c4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Well it's easy enough for me to just make up a profile that follows rul= es I set.=A0 But since I don't think this need will be unique to myself= , would you like me to write up a spec somewhere? (I've never written a= n IETF spec before)
    --
    Andrew Arnott
    "I [may] not agree with what you have to say, b= ut I'll defend to the death your right to say it." - S. G. Tallent= yre


    On Mon, Jun 14, 2010 at 11:00 PM, Dick H= ardt <dick.har= dt@gmail.com> wrote:
    +1

    On 2010-06-14, at 9:02 PM, Brian Eaton wrote:

    > On Mon, Jun 14, 2010 at 8:31 PM, Andrew Arnott <andrewarnott@gmail.com> wrote:
    >> For an application I'm building, the installed client app will= have
    >> intermittent windows of time where it can obtain a (non-OAuth) ass= ertion for
    >> user identity. =A0During this time, it seems appropriate for it to= use the
    >> assertion flow to obtain an OAuth authorization so that it can imp= ersonate
    >> the user. =A0So far this is just standard Assertion Flow stuff. = =A0But without a
    >> refresh_token, the app will break when the access token expires if= the app
    >> doesn't have the ability at the moment (due to not being on th= e corporate
    >> network at the moment for example) to obtain a new assertion. =A0S= ince the
    >> security model for this app would certainly allow for a refresh_to= ken to be
    >> issued from the original OAuth authorization server exchange, this= would
    >> solve it, if the spec didn't specifically ban such a parameter= .
    >
    > I think this is a different use case than the one envisioned by most > people who are using the assertion flow.
    >
    > I'm inclined to steer different use cases to different profiles. = =A0It
    > makes it much easier to guide deployments, for example.
    >
    > Cheers,
    > Brian
    > _______________________________________________
    > OAuth mailing list
    > OAuth@ietf.org
    > https://www.ietf.org/mailman/listinfo/oauth


    --000e0cd5c4b0f62d5c04891200c4-- From andrewarnott@gmail.com Tue Jun 15 07:03:23 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51F0C3A6A6D for ; Tue, 15 Jun 2010 07:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.632 X-Spam-Level: X-Spam-Status: No, score=-1.632 tagged_above=-999 required=5 tests=[AWL=0.966, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UcDpYpCZ8h1Y for ; Tue, 15 Jun 2010 07:03:21 -0700 (PDT) Received: from mail-yw0-f193.google.com (mail-yw0-f193.google.com [209.85.211.193]) by core3.amsl.com (Postfix) with ESMTP id 998083A6801 for ; Tue, 15 Jun 2010 07:03:21 -0700 (PDT) Received: by ywh31 with SMTP id 31so3784107ywh.20 for ; Tue, 15 Jun 2010 07:03:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=zn1CaDW8TNCzuszQ1qAdaHzhdZbxNPrx1E9W1naASyQ=; b=FJbuCwBxYXvZ7ogMtF3p+dvFTNzp9rNSF8zVB8VGYhst0W86GwUMMjI9j7Xx/5j4uu WBgRCKlLAi+we0X77fEkM868LzGAOvakRRLHPjzMsnMbZFsaN7FHYZiyhxN4d8w/joNs KSnz26hkJWzz8HARP7De0d4imwcj/WYBnXFoY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=XfNY1RGK2z9gmenahgpZfdJaLEGly2zQyJ4rpfF4J4IYfCfHmuzRSTVlPlyQEF9VI9 kx1hfC1gQlYZYlHynTdScgOj1d3X04SY4eumDlKVKQ8sQBhlPN213y/GhjiHQZJ98R23 uP1w567a79LD3nITFluCzI1D2My6WAkv8EmNs= MIME-Version: 1.0 Received: by 10.151.59.13 with SMTP id m13mr8178853ybk.250.1276610599784; Tue, 15 Jun 2010 07:03:19 -0700 (PDT) Received: by 10.151.26.19 with HTTP; Tue, 15 Jun 2010 07:03:19 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB68C9@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB68C9@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Tue, 15 Jun 2010 07:03:19 -0700 Message-ID: From: Andrew Arnott To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=00151750e27e5110e40489121146 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Assertion flow: please add optional refresh_token in response X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 14:03:23 -0000 --00151750e27e5110e40489121146 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable In this case, the assertion the client starts with is from Windows authentication, and the assertion is obtained from an Active Directory server that is inaccessible unless the client app is running on a computer currently connected to the corporate network. I imagine that assertion has a limited lifetime, and the client doesn't have access to it anyway since i= t is added to the HTTP request by the platform, and is a challenge-response based protocol and therefore cannot be replayed later. So sure, I can read "SHOULD NOT" as a recommendation and do it anyway (usin= g the standard parameter name refresh_token). The assertion itself being a challenge-response type thing in the transport itself, this profile seems t= o apply even less unless it can be worded to say the assertion can be found elsewhere. (there's precedence for this in the spec that talks about how client credentials can be found in any of multiple places but must only be found in ONE of them). Let me know what you think. If I need to invent my own profile I guess I can do that. -- 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 Mon, Jun 14, 2010 at 8:50 PM, Eran Hammer-Lahav wro= te: > First, the spec says =93SHOULD NOT issue a refresh token=94 which means, = don=92t > do it unless you have to. But what stops the client from keeping the same > assertion and reusing it later? > > > > As for using other methods for providing an assertion, you need to be mor= e > specific about what you have in mind. But either way, you can extend the > token endpoint to support other ways of providing assertions. > > > > EHL > > > > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf > Of *Andrew Arnott > *Sent:* Monday, June 14, 2010 8:32 PM > *To:* OAuth WG (oauth@ietf.org) > *Subject:* [OAUTH-WG] Assertion flow: please add optional refresh_token i= n > response > > > > For an application I'm building, the installed client app will have > intermittent windows of time where it can obtain a (non-OAuth) assertion = for > user identity. During this time, it seems appropriate for it to use the > assertion flow to obtain an OAuth authorization so that it can impersonat= e > the user. So far this is just standard Assertion Flow stuff. But withou= t a > refresh_token, the app will break when the access token expires if the ap= p > doesn't have the ability at the moment (due to not being on the corporate > network at the moment for example) to obtain a new assertion. Since the > security model for this app would certainly allow for a refresh_token to = be > issued from the original OAuth authorization server exchange, this would > solve it, if the spec didn't specifically ban such a parameter. > > Also, the user identity is asserted to the authorization server *not*thro= ugh an > *assertion* parameter but using Kerberos (I assume) as part of the HTTP > protocol, so perhaps the spec for the assertion flow can specifically all= ow > for assertions to be carried as part of the transport? > > -- > 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 > --00151750e27e5110e40489121146 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable In this case, the assertion the client starts with is from Windows authenti= cation, and the assertion is obtained from an Active Directory server that = is inaccessible unless the client app is running on a computer currently co= nnected to the corporate network.=A0 I imagine that assertion has a limited= lifetime, and the client doesn't have access to it anyway since it is = added to the HTTP request by the platform, and is a challenge-response base= d protocol and therefore cannot be replayed later.

    So sure, I can read "SHOULD NOT" as a recommendation and do i= t anyway (using the standard parameter name refresh_token).=A0 The assertio= n itself being a challenge-response type thing in the transport itself, thi= s profile seems to apply even less unless it can be worded to say the asser= tion can be found elsewhere. (there's precedence for this in the spec t= hat talks about how client credentials can be found in any of multiple plac= es but must only be found in ONE of them).

    Let me know what you think.=A0 If I need to invent my own profile I gue= ss I can do that.
    --
    Andrew Arnott
    "I [may] not= agree with what you have to say, but I'll defend to the death your rig= ht to say it." - S. G. Tallentyre


    On Mon, Jun 14, 2010 at 8:50 PM, Eran Ha= mmer-Lahav <era= n@hueniverse.com> wrote:

    First, the sp= ec says =93SHOULD NOT issue a refresh token=94 which means, don=92t do it u= nless you have to. But what stops the client from keeping the same assertio= n and reusing it later?

    =A0

    As for using other methods for providing an asser= tion, you need to be more specific about what you have in mind. But either = way, you can extend the token endpoint to support other ways of providing a= ssertions.

    =A0

    EHL

    =A0

    From:= oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Be= half Of Andrew Arnott
    Sent: Monday, June 14, 2010 8:32 PM
    To: OAuth WG (oauth@ietf.org)
    Subj= ect: [OAUTH-WG] Assertion flow: please add optional refresh_token in re= sponse

    =A0

    For an application I'm building, the installed = client app will have intermittent windows of time where it can obtain a (no= n-OAuth) assertion for user identity.=A0 During this time, it seems appropr= iate for it to use the assertion flow to obtain an OAuth authorization so t= hat it can impersonate the user.=A0 So far this is just standard Assertion = Flow stuff.=A0 But without a refresh_token, the app will break when the acc= ess token expires if the app doesn't have the ability at the moment (du= e to not being on the corporate network at the moment for example) to obtai= n a new assertion.=A0 Since the security model for this app would certainly= allow for a refresh_token to be issued from the original OAuth authorizati= on server exchange, this would solve it, if the spec didn't specificall= y ban such a parameter.

    Also, the user identity is asserted to the authorization server not<= /i> through an assertion parameter but using Kerberos (I assume) as = part of the HTTP protocol, so perhaps the spec for the assertion flow can s= pecifically allow for assertions to be carried as part of the transport?
    --
    Andrew Arnott
    "I [may] not agree with what = you have to say, but I'll defend to the death your right to say it.&quo= t; - S. G. Tallentyre


    --00151750e27e5110e40489121146-- From andrewarnott@gmail.com Tue Jun 15 07:03:53 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99AC63A6801 for ; Tue, 15 Jun 2010 07:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.623 X-Spam-Level: X-Spam-Status: No, score=-1.623 tagged_above=-999 required=5 tests=[AWL=0.975, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7hkd2DewMFTc for ; Tue, 15 Jun 2010 07:03:52 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 4D18528C12B for ; Tue, 15 Jun 2010 07:03:52 -0700 (PDT) Received: by gwj16 with SMTP id 16so3352231gwj.31 for ; Tue, 15 Jun 2010 07:03:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=xdrxsazkQRXTQD4k9VYoRScW7qQHNUvWCBM0cV+cPR4=; b=HMdcArwxxPc7vfEsHYF84rW46JJRd794bRIxXTvqrd4fq4GJocXGada5/MLrYA2Mbn 1lmkjA87eSzcSt+OQ0b7m+EHw9bIpamMMGFaDQr3Vb8Vz/Uh7JYxUy64kGHp9LKPOKQP Et6ifQ0+r7rlmpYMAsew6gzczGzaDSi3zGWgk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=SovK08hpJv/RXE32xNUTCS5Z5i/Yjh37zOsmyprgWwWpXtniEPwF55StOvs1kronAM PH+qFX4gudaTi/xB57MnkvyRtvUB3iNyGzPEDyGBzRU+dLNTsB7Pj3EHbPrs9eIsdMe5 rh7bmLIoX3hSzp434uIZbMp1uQnP71ElCboOA= MIME-Version: 1.0 Received: by 10.150.160.14 with SMTP id i14mr8312485ybe.144.1276610633523; Tue, 15 Jun 2010 07:03:53 -0700 (PDT) Received: by 10.151.26.19 with HTTP; Tue, 15 Jun 2010 07:03:53 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB68E1@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB68E1@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Tue, 15 Jun 2010 07:03:53 -0700 Message-ID: From: Andrew Arnott To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=000e0cd7551654002a048912132c Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Definition of XML response format X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 14:03:53 -0000 --000e0cd7551654002a048912132c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Nope. I'm happy to see it dropped. -- 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, Jun 15, 2010 at 12:02 AM, Eran Hammer-Lahav wr= ote: > Since XML was dropped, if you feel strongly about this, please submit a n= ew > I-D extending the spec to allow XML format responses. Don=92t worry about= how > to extend it, just add parameters or whatever for now. > > > > EHL > > > > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf > Of *Andrew Arnott > *Sent:* Friday, June 04, 2010 5:56 AM > *To:* OAuth WG (oauth@ietf.org) > > *Subject:* Re: [OAUTH-WG] Definition of XML response format > > > > In the absence of anyone else volunteering an XML format, what would you > say to this as a proposal (because the implementation of which happens to= be > simple for me): > > > > some access token > some refresh token > 235298298 > > > So the main points here is: > > 1. no namespace > 2. root tag is called "root" > 3. each parameter is an element > 4. each element has a type parameter that is either string, number, or > object to assist the deserializer to understnad how to cast the conten= ts. > > We may axe #4. In fact we may want to switch all the elements to > attributes because it's slightly more compact which might help small > devices. > > -- > 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 Mon, May 31, 2010 at 9:12 AM, Andrew Arnott > wrote: > > Where is the definition of how a auth server response in XML format shoul= d > look? At the least we need an XML namespace and root node name. > > -- > 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 > > > --000e0cd7551654002a048912132c Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Nope.=A0 I'm happy to see it dropped.
    --
    Andrew Arn= ott
    "I [may] not agree with what you have to say, but I'll defe= nd to the death your right to say it." - S. G. Tallentyre


    On Tue, Jun 15, 2010 at 12:02 AM, Eran H= ammer-Lahav <er= an@hueniverse.com> wrote:

    Since XML was= dropped, if you feel strongly about this, please submit a new I-D extendin= g the spec to allow XML format responses. Don=92t worry about how to extend= it, just add parameters or whatever for now.

    =A0

    EHL

    =A0

    From:= oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Be= half Of Andrew Arnott
    Sent: Friday, June 04, 2010 5:56 AM
    To: OAuth WG (oauth@ietf.org)


    Subject: Re: [OAUTH-WG] Definition of XML response forma= t

    =A0

    In the absence of anyone else volunteering an XML format, what would you s= ay to this as a proposal (because the implementation of which happens to be= simple for me):



    <root type=3D"object"= ;>
    =A0=A0 <access_token type=3D"string">some access t= oken</access_token>
    =A0=A0 <refresh_token type=3D"string&q= uot;>some refresh token</refresh_token>
    =A0=A0 <expires_in type=3D"number">235298298</expires_in= >
    </root>

    So the main points here is:
    1. no namespace
    2. root tag is called "root"
    3. each parameter is an element
    4. eac= h element has a type parameter that is either string, number, or object to = assist the deserializer to understnad how to cast the contents.

    We may axe #4.= =A0 In fact we may want to switch all the elements to attributes because it= 's slightly more compact which might help small devices.

    --
    Andrew Arnott
    "I [may] not agree with what you have to say, b= ut I'll defend to the death your right to say it." - S. G. Tallent= yre

    On Mon, May 31, 2010 at 9:12 AM,= Andrew Arnott <andrewarnott@gmail.com> wrote:

    Where is the definition of how a auth server respons= e in XML format should look?=A0 At the least we need an XML namespace and r= oot node name.

    --
    Andrew Arnott
    "I [may] not agree with what you have to say, b= ut I'll defend to the death your right to say it." - S. G. Tallent= yre

    =A0

    <= /div>

    --000e0cd7551654002a048912132c-- From dick.hardt@gmail.com Tue Jun 15 07:11:59 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57DED3A67D6 for ; Tue, 15 Jun 2010 07:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.322 X-Spam-Level: X-Spam-Status: No, score=-2.322 tagged_above=-999 required=5 tests=[AWL=0.276, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cwCjR1LfuSPT for ; Tue, 15 Jun 2010 07:11:57 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 913C93A6801 for ; Tue, 15 Jun 2010 07:11:57 -0700 (PDT) Received: by pwi8 with SMTP id 8so3758180pwi.31 for ; Tue, 15 Jun 2010 07:11:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:message-id:references:to :x-mailer; bh=qhv54YccMlGhSpt79gT51uCaAcW2NpQtMjjPMZ1/m2Q=; b=yBaWYLgEa9Fe7xkYFHcttwaNFGBiOcHttJYNj/UwNCa/08pHLGCPaTlqEb1jrKB/rX 5Vorjb/CoLWKYBwsxC8LZ9PjoL/TVdIzr1Xl88+wpdKjGQP6azRvsklNFNJWmLcFX7AR 4X/yfSVRZl2lnrZEAp4rzdX4zzJOkeQYuXobg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; b=mMi9Da0kkauP2BZKA/YN2o8qTu7yFRWCc93K8LSRTOesqHkdyLukNXeVyCADZ2D5h2 NoJ/NWSeYnVOqb6QfPXY/k6t0jNiIAAWHsCbJhCAG2DPgQPmTwUCkNwYrJb0QkN/OKmC 7mjk+1K6W7Yc91JwYS74ADkukdFn5bKCUapAo= Received: by 10.115.65.14 with SMTP id s14mr5754014wak.209.1276610756301; Tue, 15 Jun 2010 07:05:56 -0700 (PDT) Received: from [192.168.1.5] ([24.130.32.55]) by mx.google.com with ESMTPS id a23sm68700808wam.14.2010.06.15.07.05.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 15 Jun 2010 07:05:54 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/alternative; boundary=Apple-Mail-3--196673897 From: Dick Hardt In-Reply-To: Date: Tue, 15 Jun 2010 07:05:53 -0700 Message-Id: <035D0E28-4518-4C28-9744-E90EA4E22395@gmail.com> References: <7F00C2CF-E57F-4341-BBA4-7B03B69277D6@gmail.com> To: Andrew Arnott X-Mailer: Apple Mail (2.1078) Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Assertion flow: please add optional refresh_token in response X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 14:12:00 -0000 --Apple-Mail-3--196673897 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Why can the client app access the AS to get an access token but not the = corporate network to get a new assertion? How does the client app get the assertion to begin with? How did = delegation from the user happen? Would you elaborate more on the use case so that we can understand the = full trust model? The assertion flow was intended for autonomous clients rather than user = delegation -- hence Brian's response and mine that this is a different = flow if the access token is for user delegation. -- Dick On 2010-06-15, at 6:58 AM, Andrew Arnott wrote: > Well it's easy enough for me to just make up a profile that follows = rules I set. But since I don't think this need will be unique to = myself, would you like me to write up a spec somewhere? (I've never = written an IETF spec before) > -- > 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 >=20 >=20 > On Mon, Jun 14, 2010 at 11:00 PM, Dick Hardt = wrote: > +1 >=20 > On 2010-06-14, at 9:02 PM, Brian Eaton wrote: >=20 > > On Mon, Jun 14, 2010 at 8:31 PM, Andrew Arnott = wrote: > >> For an application I'm building, the installed client app will have > >> intermittent windows of time where it can obtain a (non-OAuth) = assertion for > >> user identity. During this time, it seems appropriate for it to = use the > >> assertion flow to obtain an OAuth authorization so that it can = impersonate > >> the user. So far this is just standard Assertion Flow stuff. But = without a > >> refresh_token, the app will break when the access token expires if = the app > >> doesn't have the ability at the moment (due to not being on the = corporate > >> network at the moment for example) to obtain a new assertion. = Since the > >> security model for this app would certainly allow for a = refresh_token to be > >> issued from the original OAuth authorization server exchange, this = would > >> solve it, if the spec didn't specifically ban such a parameter. > > > > I think this is a different use case than the one envisioned by most > > people who are using the assertion flow. > > > > I'm inclined to steer different use cases to different profiles. It > > makes it much easier to guide deployments, for example. > > > > Cheers, > > Brian > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 --Apple-Mail-3--196673897 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Why = can the client app access the AS to get an access token but not the = corporate network to get a new assertion?

    How does = the client app get the assertion to begin with? How did delegation from = the user happen?

    Would you elaborate more on = the use case so that we can understand the full trust = model?

    The assertion flow was intended for = autonomous clients rather than user delegation -- hence Brian's response = and mine that this is a different flow if the access token is for user = delegation.

    -- = Dick

    On 2010-06-15, at 6:58 AM, = Andrew Arnott wrote:

    Well it's = easy enough for me to just make up a profile that follows rules I = set.  But since I don't think this need will be unique to myself, = would you like me to write up a spec somewhere? (I've never written an = IETF spec before)
    --
    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 Mon, Jun 14, 2010 at 11:00 PM, = Dick Hardt <dick.hardt@gmail.com> = wrote:
    +1

    On 2010-06-14, at 9:02 PM, Brian Eaton wrote:

    > On Mon, Jun 14, 2010 at 8:31 PM, Andrew Arnott <andrewarnott@gmail.com> = wrote:
    >> For an application I'm building, the installed client app will = have
    >> intermittent windows of time where it can obtain a (non-OAuth) = assertion for
    >> user identity.  During this time, it seems appropriate for = it to use the
    >> assertion flow to obtain an OAuth authorization so that it can = impersonate
    >> the user.  So far this is just standard Assertion Flow = stuff.  But without a
    >> refresh_token, the app will break when the access token expires = if the app
    >> doesn't have the ability at the moment (due to not being on the = corporate
    >> network at the moment for example) to obtain a new assertion. =  Since the
    >> security model for this app would certainly allow for a = refresh_token to be
    >> issued from the original OAuth authorization server exchange, = this would
    >> solve it, if the spec didn't specifically ban such a = parameter.
    >
    > I think this is a different use case than the one envisioned by = most
    > people who are using the assertion flow.
    >
    > I'm inclined to steer different use cases to different profiles. =  It
    > makes it much easier to guide deployments, for example.
    >
    > Cheers,
    > Brian
    > _______________________________________________
    > OAuth mailing list
    > OAuth@ietf.org
    > https://www.ietf.org/mailman/listinfo/oauth



    = --Apple-Mail-3--196673897-- From dick.hardt@gmail.com Tue Jun 15 07:12:43 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06BFA3A67D6 for ; Tue, 15 Jun 2010 07:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CUsYu0YG-e59 for ; Tue, 15 Jun 2010 07:12:40 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 573323A6916 for ; Tue, 15 Jun 2010 07:12:40 -0700 (PDT) Received: by pwi8 with SMTP id 8so3758575pwi.31 for ; Tue, 15 Jun 2010 07:12:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:message-id:references:to :x-mailer; bh=HH9ABKaqqZg+7ddvo2E/R8GHYLv3VIBsBoARHBj51RM=; b=KJcQosfTwY9uUFA9BiUCcj6gyWWG4UEtOBrW2eNcVeJzvXIS/iOvUdfKopnuiAjYI7 GvOBXXQ8qfsmRPtmn6BjQ7LM7+YPXpCAJqdih3c55WMczxmAz0Yn+vO21GfkSyGMu/Ax zPg7Oh6wR2DEneVlBY8Ded/JUkiWxpIvle5CI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; b=XfqePvbTfI8x2j4Y5ofIOZKeCY+lFF1Nd/8vbheJJ/zmZ+uu2QSmli06/NrAKHcvzo LfscHkla/+4mPVJCVmKvzOpJ9RhDJlxxBX+zR89FpWHXOVrQQDGg2L/RtTT7FduffhR+ NqhOn+gQOT2SwFs3ocPJZfHd6IylRsfqKA/lE= Received: by 10.141.2.14 with SMTP id e14mr5780621rvi.115.1276611161988; Tue, 15 Jun 2010 07:12:41 -0700 (PDT) Received: from [192.168.1.5] ([24.130.32.55]) by mx.google.com with ESMTPS id g14sm5865290rvb.13.2010.06.15.07.12.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 15 Jun 2010 07:12:41 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/alternative; boundary=Apple-Mail-4--196267615 From: Dick Hardt In-Reply-To: Date: Tue, 15 Jun 2010 07:12:39 -0700 Message-Id: References: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB68C9@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Andrew Arnott X-Mailer: Apple Mail (2.1078) Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Assertion flow: please add optional refresh_token in response X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 14:12:43 -0000 --Apple-Mail-4--196267615 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Are you envisioning the client makes a call to AD to get an assertion = where the call is automagically authenticated as the user by NTLM?=20 What do you envision being the relationship between the AS and AD? What = authority does the AS have? How long is the refresh token valid for? I think you have an interesting use case here, but it would be useful to = step back and describe how the client got to the point you are = envisioning per my last email. -- Dick On 2010-06-15, at 7:03 AM, Andrew Arnott wrote: > In this case, the assertion the client starts with is from Windows = authentication, and the assertion is obtained from an Active Directory = server that is inaccessible unless the client app is running on a = computer currently connected to the corporate network. I imagine that = assertion has a limited lifetime, and the client doesn't have access to = it anyway since it is added to the HTTP request by the platform, and is = a challenge-response based protocol and therefore cannot be replayed = later. >=20 > So sure, I can read "SHOULD NOT" as a recommendation and do it anyway = (using the standard parameter name refresh_token). The assertion itself = being a challenge-response type thing in the transport itself, this = profile seems to apply even less unless it can be worded to say the = assertion can be found elsewhere. (there's precedence for this in the = spec that talks about how client credentials can be found in any of = multiple places but must only be found in ONE of them). >=20 > Let me know what you think. If I need to invent my own profile I = guess I can do that. > -- > 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 >=20 >=20 > On Mon, Jun 14, 2010 at 8:50 PM, Eran Hammer-Lahav = wrote: > First, the spec says =93SHOULD NOT issue a refresh token=94 which = means, don=92t do it unless you have to. But what stops the client from = keeping the same assertion and reusing it later? >=20 > =20 > As for using other methods for providing an assertion, you need to be = more specific about what you have in mind. But either way, you can = extend the token endpoint to support other ways of providing assertions. >=20 > =20 > EHL >=20 > =20 > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf = Of Andrew Arnott > Sent: Monday, June 14, 2010 8:32 PM > To: OAuth WG (oauth@ietf.org) > Subject: [OAUTH-WG] Assertion flow: please add optional refresh_token = in response >=20 > =20 > For an application I'm building, the installed client app will have = intermittent windows of time where it can obtain a (non-OAuth) assertion = for user identity. During this time, it seems appropriate for it to use = the assertion flow to obtain an OAuth authorization so that it can = impersonate the user. So far this is just standard Assertion Flow = stuff. But without a refresh_token, the app will break when the access = token expires if the app doesn't have the ability at the moment (due to = not being on the corporate network at the moment for example) to obtain = a new assertion. Since the security model for this app would certainly = allow for a refresh_token to be issued from the original OAuth = authorization server exchange, this would solve it, if the spec didn't = specifically ban such a parameter. >=20 > Also, the user identity is asserted to the authorization server not = through an assertion parameter but using Kerberos (I assume) as part of = the HTTP protocol, so perhaps the spec for the assertion flow can = specifically allow for assertions to be carried as part of the = transport? >=20 > -- > 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 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-4--196267615 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
    In this case, the assertion the client starts with is from = Windows authentication, and the assertion is obtained from an Active = Directory server that is inaccessible unless the client app is running = on a computer currently connected to the corporate network.  I = imagine that assertion has a limited lifetime, and the client doesn't = have access to it anyway since it is added to the HTTP request by the = platform, and is a challenge-response based protocol and therefore = cannot be replayed later.

    So sure, I can read "SHOULD NOT" as a recommendation and do it = anyway (using the standard parameter name refresh_token).  The = assertion itself being a challenge-response type thing in the transport = itself, this profile seems to apply even less unless it can be worded to = say the assertion can be found elsewhere. (there's precedence for this = in the spec that talks about how client credentials can be found in any = of multiple places but must only be found in ONE of them).

    Let me know what you think.  If I need to invent my own profile = I guess I can do that.
    --
    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 Mon, Jun 14, 2010 at 8:50 PM, Eran = Hammer-Lahav <eran@hueniverse.com> = wrote:

    First, the spec says =93SHOULD NOT issue a refresh token=94 which = means, don=92t do it unless you have to. But what stops the client from = keeping the same assertion and reusing it later?

     

    As for using other = methods for providing an assertion, you need to be more specific about = what you have in mind. But either way, you can extend the token endpoint = to support other ways of providing assertions.

     

    EHL

     

    From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Andrew = Arnott
    Sent: Monday, June 14, 2010 8:32 PM
    To: OAuth WG (oauth@ietf.org)
    Subject: [OAUTH-WG] = Assertion flow: please add optional refresh_token in response

     

    For an = application I'm building, the installed client app will have = intermittent windows of time where it can obtain a (non-OAuth) assertion = for user identity.  During this time, it seems appropriate for it = to use the assertion flow to obtain an OAuth authorization so that it = can impersonate the user.  So far this is just standard Assertion = Flow stuff.  But without a refresh_token, the app will break when = the access token expires if the app doesn't have the ability at the = moment (due to not being on the corporate network at the moment for = example) to obtain a new assertion.  Since the security model for = this app would certainly allow for a refresh_token to be issued from the = original OAuth authorization server exchange, this would solve it, if = the spec didn't specifically ban such a parameter.

    Also, the user identity is asserted to the authorization server = not through an assertion parameter but using Kerberos (I = assume) as part of the HTTP protocol, so perhaps the spec for the = assertion flow can specifically allow for assertions to be carried as = part of the transport?

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

    = --Apple-Mail-4--196267615-- From andrewarnott@gmail.com Tue Jun 15 08:19:16 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95C4A28C123 for ; Tue, 15 Jun 2010 08:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.518 X-Spam-Level: X-Spam-Status: No, score=-0.518 tagged_above=-999 required=5 tests=[AWL=-0.520, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v7D2hkL06yUW for ; Tue, 15 Jun 2010 08:19:15 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 988FD3A6820 for ; Tue, 15 Jun 2010 08:19:14 -0700 (PDT) Received: by gwj16 with SMTP id 16so3431012gwj.31 for ; Tue, 15 Jun 2010 08:19:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=jTnw42lPtq4fJkR05JWH2zN82M/Y5rbt2dibTPnXv5s=; b=RzAifFpgel9cGOiba+9oB6QxgNozlcZYJ/5qKwellR+Y6RPf/QJPjSoz7UMZIDoSXG pVEj/3FWmOLwFnT6ltATKEc8OYTxxvOOUcIlslIsZSfcaxbOsNvNc7TyMcoaxubu+LUM l0YLCGIAPwknLZVuTvd6dlN5/KrDPztwBROho= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Y5HZXahR+6Xb32TINSutDIkMA5pUtK62cDObrCRcwvswsOWxUzPDZyWzYa+PfEbUJb iVeD0+tNJtKsX22jYs5GSanrc4D5yyTckzD0ekkaea0IBqwZyXWPiGNmpMUvqHHRx/m1 kXqppGwzPvopatQM13ZTeZBc5NDaFyH9TjLwU= MIME-Version: 1.0 Received: by 10.150.246.23 with SMTP id t23mr8353470ybh.331.1276615156099; Tue, 15 Jun 2010 08:19:16 -0700 (PDT) Received: by 10.151.26.19 with HTTP; Tue, 15 Jun 2010 08:19:16 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB68C9@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Tue, 15 Jun 2010 08:19:16 -0700 Message-ID: From: Andrew Arnott To: Dick Hardt Content-Type: multipart/alternative; boundary=000e0cd6c8dee4ea4804891320cd Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Assertion flow: please add optional refresh_token in response X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 15:19:16 -0000 --000e0cd6c8dee4ea4804891320cd Content-Type: text/plain; charset=ISO-8859-1 Hi Dick, Responses inline. On Tue, Jun 15, 2010 at 7:12 AM, Dick Hardt wrote: > Why can the client app access the AS to get an access token but not the > corporate network to get a new assertion? > The corporate network where the AD lives is behind a firewall, whereas the AS is on the public Internet. So when the client is on the public Internet, the AD is not available but the AS is. Also, the resource server is on the public Internet (probably obvious). How does the client app get the assertion to begin with? How did delegation > from the user happen? > There are two possible scenarios here, which I will outline and inject the steps in each scenario: 1. The client app is initially launched while on the corporate network 1. The client sends an HTTP request to *an *endpoint on a *corpnet *AS(1) (directly -- not through a browser), which sniffs the request for NTLM credentials (or however Windows auth does it) and if present immediately responds with an authorization code (a.k.a. verification code) rather than prompting the user for permission. This is considered reasonable in this application because the client is already running on a trusted machine and the privacy ramifications are minimal. 2. The client app exchanges the authorization code for a refresh token and an access token at the AS(2) token endpoint, which lies outside the corporate firewall, and can thereby refresh access tokens when the client is off corpnet. 3. All resource requests use an OAuth access token to gain access. 2. The client app is initially launched *off* the corporate network. 1. This just uses the standard user agent or web server flows, including prompting the user for authorization. > Would you elaborate more on the use case so that we can understand the full > trust model? > Perhaps my description above covers this question. I'll just add that the goal is to make the authorization process as painless (or altogether absent from the user's point of view) as possible. We're also considering providing customized app downloads to each user based on the Windows auth user that downloads the .zip file, such that the client app includes a file containing the authorization code encoded for that particular user. > The assertion flow was intended for autonomous clients rather than user > delegation -- hence Brian's response and mine that this is a different flow > if the access token is for user delegation. > That makes sense. > > Are you envisioning the client makes a call to AD to get an assertion where > the call is automagically authenticated as the user by NTLM? > Perhaps my scenarios above clarified this. My client never explicitly calls AD though. Whether that happens implicitly by the Windows platform, I don't know. What do you envision being the relationship between the AS and AD? What > authority does the AS have? How long is the refresh token valid for? > The refresh token would be valid until the user logged into the AS (or RS perhaps) to revoke it. The AD is altogether unaware of the AS, but the AS trusts the AD to have authenticated the user and trusts the AD assertion. --000e0cd6c8dee4ea4804891320cd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Dick,

    Responses inline.

    On Tue, Jun 15, 2010 at 7:12 AM, Dick Hardt <dick.hardt@gmail.com> w= rote:
    Why can the client app access the AS to get an ac= cess token but not the=20 corporate network to get a new assertion?

    = The corporate network where the AD lives is behind a firewall, whereas the = AS is on the public Internet.=A0 So when the client is on the public Intern= et, the AD is not available but the AS is.=A0 Also, the resource server is = on the public Internet (probably obvious).

    How does=20 the client app get the assertion to begin with? How did delegation from=20 the user happen?

    There are two p= ossible scenarios here, which I will outline and inject the steps in each s= cenario:
    1. The client app is initially launched while on the corpo= rate network
      1. The client sends an HTTP request to an endpoint on a corp= net AS(1) (directly -- not through a browser), which sniffs the request= for NTLM credentials (or however Windows auth does it) and if present imme= diately responds with an authorization code (a.k.a. verification code) rath= er than prompting the user for permission.=A0 This is considered reasonable= in this application because the client is already running on a trusted mac= hine and the privacy ramifications are minimal.
      2. The client app exchanges the authorization code for a refresh toke= n and an access token at the AS(2) token endpoint, which lies outside the c= orporate firewall, and can thereby refresh access tokens when the client is= off corpnet.
      3. All resource requests use an OAuth access token to gain access.
    2. The client app is initially launched off the corporat= e network.
      1. This just uses the standard user agent or web server= flows, including prompting the user for authorization.

    Would yo= u elaborate more on=20 the use case so that we can understand the full trust model?

    Perhaps my description above covers this question.= =A0 I'll just add that the goal is to make the authorization process as= painless (or altogether absent from the user's point of view) as possi= ble.=A0 We're also considering providing customized app downloads to ea= ch user based on the Windows auth user that downloads the .zip file, such t= hat the client app includes a file containing the authorization code encode= d for that particular user.


    The assertion flow was intended for autonomous clients rather than user=20 delegation -- hence Brian's response and mine that this is a different= =20 flow if the access token is for user delegation.

    That makes sense.
    =A0
    =A0
    Are you envisioning th= e client makes a call to AD to get an assertion where the call is automagic= ally authenticated as the user by NTLM?=A0

    Perhaps my scenarios above clarified this. My c= lient never explicitly calls AD though.=A0 Whether that happens implicitly = by the Windows platform, I don't know.

    What do you envision = being the relationship between the AS and AD? What authority does the AS ha= ve? How long is the refresh token valid for?

    The refresh token would be valid until the user logged into the AS (or = RS perhaps) to revoke it. The AD is altogether unaware of the AS, but the A= S trusts the AD to have authenticated the user and trusts the AD assertion.=
    --000e0cd6c8dee4ea4804891320cd-- From andrewarnott@gmail.com Tue Jun 15 08:26:49 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D90BE3A6935 for ; Tue, 15 Jun 2010 08:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.431 X-Spam-Level: X-Spam-Status: No, score=-0.431 tagged_above=-999 required=5 tests=[AWL=-0.433, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y3SwGSw3v19r for ; Tue, 15 Jun 2010 08:26:49 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id D5D723A67EA for ; Tue, 15 Jun 2010 08:26:48 -0700 (PDT) Received: by gwj16 with SMTP id 16so3438747gwj.31 for ; Tue, 15 Jun 2010 08:26:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=gYDIIAoln4TPgMd0RIddwAImou5syK2B/8+FuXJ2kQ0=; b=omzmy3wbkxuIqbIAdW1gGULAnbp+SCV2KnahGaO6psTXKUpPiODyOnNKTZhhWYu/Yp BHjHPXfrvNDMM2cCesrNTs32W7LbICe0zC77lW4eRp2Uz/DRHeHaVB70zExbymR7zv0V spF5fh881yGzrmzLb1WCurvZAS+vuypSG2xjo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=srqQiRGQJXd5NTW6tweFvHEXzHVBwZIcXDMw9XoZgru+EBpEhkd2jZVOPhxsQjHNzS qVGFI4mylIXr7z5lSQDD3qRc77mEpCgG3a4fuKLCGlDDz3rXSnWTF42OB0Uq8VScIsLF WgPl70m96F3eygaunffXsElombmhie7H6nM+w= MIME-Version: 1.0 Received: by 10.150.244.1 with SMTP id r1mr8568316ybh.374.1276615158770; Tue, 15 Jun 2010 08:19:18 -0700 (PDT) Received: by 10.151.26.19 with HTTP; Tue, 15 Jun 2010 08:19:18 -0700 (PDT) Date: Tue, 15 Jun 2010 08:19:18 -0700 Message-ID: From: Andrew Arnott To: "OAuth WG (oauth@ietf.org)" Content-Type: multipart/alternative; boundary=000e0cd343ac0dac03048913217d Subject: [OAUTH-WG] On the ease of writing an authorization server X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 15:26:50 -0000 --000e0cd343ac0dac03048913217d Content-Type: text/plain; charset=ISO-8859-1 I've read a few comments on this DL that a primary goal is that writing an OAuth 2.0 client should be very easy. I think we're doing well here. I know this ease for the client necessarily comes at the expense of some complexity on the server. As has also been pointed out recently (by Eran, I believe) the AS' job is considerably more complex now than it was in OAuth 1.0. While overall this *may* be a win, it also seems optimized for the few large service providers that are driving the spec (Facebook, Twitter, etc.). They definitely have the resources and understanding that a large investment in security is important. But as more web sites across the Internet drop using user passwords in favor of federated identity and/or OpenID-type protocols, the only way these sites can delegate access to user data will be to use a protocol like OAuth 2.0 since user passwords will no longer apply. Therefore *very *many web sites will become OAuth 2.0 resource servers, and likely given their size and requirements will be their on authorization server as well. Now we have a complex server-side protocol that may be "too" complex for the average-sized web site to implement correctly and confidently. So my $0.02 here is that we try to keep the AS side simple as well where possible. And invite responses from others. -- 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 --000e0cd343ac0dac03048913217d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I've read a few comments on this DL that a primary goal is that writing= an OAuth 2.0 client should be very easy.=A0 I think we're doing well h= ere.=A0 I know this ease for the client necessarily comes at the expense of= some complexity on the server.=A0 As has also been pointed out recently (b= y Eran, I believe) the AS' job is considerably more complex now than it= was in OAuth 1.0.=A0

    While overall this may be a win, it also seems optimized for the= few large service providers that are driving the spec (Facebook, Twitter, = etc.).=A0 They definitely have the resources and understanding that a large= investment in security is important.=A0 But as more web sites across the I= nternet drop using user passwords in favor of federated identity and/or Ope= nID-type protocols, the only way these sites can delegate access to user da= ta will be to use a protocol like OAuth 2.0 since user passwords will no lo= nger apply.=A0 Therefore very many web sites will become OAuth 2.0 r= esource servers, and likely given their size and requirements will be their= on authorization server as well.=A0 Now we have a complex server-side prot= ocol that may be "too" complex for the average-sized web site to = implement correctly and confidently.=A0

    So my $0.02 here is that we try to keep the AS side simple as well wher= e possible.=A0 And invite responses from others.

    --Andrew Arnott
    "I [may] not agree with what you have to say, but I&= #39;ll defend to the death your right to say it." - S. G. Tallentyre --000e0cd343ac0dac03048913217d-- From gffletch@aol.com Tue Jun 15 08:40:23 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBF633A6989 for ; Tue, 15 Jun 2010 08:40:22 -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=-0.975, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RGWDknOXmbQJ for ; Tue, 15 Jun 2010 08:40:21 -0700 (PDT) Received: from imr-mb01.mx.aol.com (imr-mb01.mx.aol.com [64.12.207.164]) by core3.amsl.com (Postfix) with ESMTP id F2B873A699F for ; Tue, 15 Jun 2010 08:40:20 -0700 (PDT) Received: from mtaout-db02.r1000.mx.aol.com (mtaout-db02.r1000.mx.aol.com [172.29.51.194]) by imr-mb01.mx.aol.com (8.14.1/8.14.1) with ESMTP id o5FFdpoq008017; Tue, 15 Jun 2010 11:40:06 -0400 Received: from palantir.local (unknown [10.181.183.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-db02.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id CF166E000235; Tue, 15 Jun 2010 11:40:04 -0400 (EDT) Message-ID: <4C179ED4.1060303@aol.com> Date: Tue, 15 Jun 2010 11:40:04 -0400 From: George Fletcher Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Andrew Arnott References: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB68C9@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080507090404020701090908" x-aol-global-disposition: G X-AOL-SCOLL-SCORE: 0:2:448699072:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d33c24c179ed42bba X-AOL-IP: 10.181.183.108 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Assertion flow: please add optional refresh_token in response X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 15:40:23 -0000 This is a multi-part message in MIME format. --------------080507090404020701090908 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit To me, the use case described is more similar to the "Username and Password flow" but where the user credentials are NOT username & password. Should we have two "user credential" flows? (1) Username and Password and (2) assertion/token? I can see it being useful to have a "user credential" flow that allows for other means of verifying the user identity than just username and password. Otherwise, I think the semantics of the flow should be the same. Thoughts? Thanks, George On 6/15/10 11:19 AM, Andrew Arnott wrote: > Hi Dick, > > Responses inline. > > On Tue, Jun 15, 2010 at 7:12 AM, Dick Hardt > wrote: > > Why can the client app access the AS to get an access token but > not the corporate network to get a new assertion? > > > The corporate network where the AD lives is behind a firewall, whereas > the AS is on the public Internet. So when the client is on the public > Internet, the AD is not available but the AS is. Also, the resource > server is on the public Internet (probably obvious). > > How does the client app get the assertion to begin with? How did > delegation from the user happen? > > > There are two possible scenarios here, which I will outline and inject > the steps in each scenario: > > 1. The client app is initially launched while on the corporate network > 1. The client sends an HTTP request to /an /endpoint on a > /corpnet /AS(1) (directly -- not through a browser), which > sniffs the request for NTLM credentials (or however > Windows auth does it) and if present immediately responds > with an authorization code (a.k.a. verification code) > rather than prompting the user for permission. This is > considered reasonable in this application because the > client is already running on a trusted machine and the > privacy ramifications are minimal. > 2. The client app exchanges the authorization code for a > refresh token and an access token at the AS(2) token > endpoint, which lies outside the corporate firewall, and > can thereby refresh access tokens when the client is off > corpnet. > 3. All resource requests use an OAuth access token to gain > access. > 2. The client app is initially launched /off/ the corporate network. > 1. This just uses the standard user agent or web server > flows, including prompting the user for authorization. > > > Would you elaborate more on the use case so that we can understand > the full trust model? > > > Perhaps my description above covers this question. I'll just add that > the goal is to make the authorization process as painless (or > altogether absent from the user's point of view) as possible. We're > also considering providing customized app downloads to each user based > on the Windows auth user that downloads the .zip file, such that the > client app includes a file containing the authorization code encoded > for that particular user. > > > The assertion flow was intended for autonomous clients rather than > user delegation -- hence Brian's response and mine that this is a > different flow if the access token is for user delegation. > > > That makes sense. > > Are you envisioning the client makes a call to AD to get an > assertion where the call is automagically authenticated as the > user by NTLM? > > > Perhaps my scenarios above clarified this. My client never explicitly > calls AD though. Whether that happens implicitly by the Windows > platform, I don't know. > > What do you envision being the relationship between the AS and AD? > What authority does the AS have? How long is the refresh token > valid for? > > > The refresh token would be valid until the user logged into the AS (or > RS perhaps) to revoke it. The AD is altogether unaware of the AS, but > the AS trusts the AD to have authenticated the user and trusts the AD > assertion. > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------080507090404020701090908 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit To me, the use case described is more similar to the "Username and Password flow" but where the user credentials are NOT username & password. Should we have two "user credential" flows? (1) Username and Password and (2) assertion/token? I can see it being useful to have a "user credential" flow that allows for other means of verifying the user identity than just username and password. Otherwise, I think the semantics of the flow should be the same.

    Thoughts?

    Thanks,
    George

    On 6/15/10 11:19 AM, Andrew Arnott wrote:
    Hi Dick,

    Responses inline.

    On Tue, Jun 15, 2010 at 7:12 AM, Dick Hardt <dick.hardt@gmail.com> wrote:
    Why can the client app access the AS to get an access token but not the corporate network to get a new assertion?

    The corporate network where the AD lives is behind a firewall, whereas the AS is on the public Internet.  So when the client is on the public Internet, the AD is not available but the AS is.  Also, the resource server is on the public Internet (probably obvious).

    How does the client app get the assertion to begin with? How did delegation from the user happen?

    There are two possible scenarios here, which I will outline and inject the steps in each scenario:
    1. The client app is initially launched while on the corporate network
      1. The client sends an HTTP request to an endpoint on a corpnet AS(1) (directly -- not through a browser), which sniffs the request for NTLM credentials (or however Windows auth does it) and if present immediately responds with an authorization code (a.k.a. verification code) rather than prompting the user for permission.  This is considered reasonable in this application because the client is already running on a trusted machine and the privacy ramifications are minimal.
      2. The client app exchanges the authorization code for a refresh token and an access token at the AS(2) token endpoint, which lies outside the corporate firewall, and can thereby refresh access tokens when the client is off corpnet.
      3. All resource requests use an OAuth access token to gain access.
    2. The client app is initially launched off the corporate network.
      1. This just uses the standard user agent or web server flows, including prompting the user for authorization.

    Would you elaborate more on the use case so that we can understand the full trust model?

    Perhaps my description above covers this question.  I'll just add that the goal is to make the authorization process as painless (or altogether absent from the user's point of view) as possible.  We're also considering providing customized app downloads to each user based on the Windows auth user that downloads the .zip file, such that the client app includes a file containing the authorization code encoded for that particular user.


    The assertion flow was intended for autonomous clients rather than user delegation -- hence Brian's response and mine that this is a different flow if the access token is for user delegation.

    That makes sense.
     
     
    Are you envisioning the client makes a call to AD to get an assertion where the call is automagically authenticated as the user by NTLM? 

    Perhaps my scenarios above clarified this. My client never explicitly calls AD though.  Whether that happens implicitly by the Windows platform, I don't know.

    What do you envision being the relationship between the AS and AD? What authority does the AS have? How long is the refresh token valid for?

    The refresh token would be valid until the user logged into the AS (or RS perhaps) to revoke it. The AD is altogether unaware of the AS, but the AS trusts the AD to have authenticated the user and trusts the AD assertion. 
    
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
    --------------080507090404020701090908-- From recordond@gmail.com Tue Jun 15 08:51:04 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AC2C3A68A5 for ; Tue, 15 Jun 2010 08:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.128 X-Spam-Level: X-Spam-Status: No, score=-2.128 tagged_above=-999 required=5 tests=[AWL=0.471, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W8g4qIPabAXx for ; Tue, 15 Jun 2010 08:50:58 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 920D63A68BF for ; Tue, 15 Jun 2010 08:50:58 -0700 (PDT) Received: by iwn36 with SMTP id 36so642238iwn.31 for ; Tue, 15 Jun 2010 08:50:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=wZ6Nnx8y0Jxa7zQmEMVXahJzhXbsAgXT6hhpuKoqvGA=; b=V5ufiL0lA7/+bL0VUV+djDNzGKk0Y+2qQ6NGvp9SHq3itanMjXud+hhyQkZXf5swPO jDn3Pybc5Om7Pi/DNk1J6k9cT9gJC8oUar5b2383wHwYpGD3bj5XbfAE3KJxgFP9wAxe uem9gKS0t87eENtTfpBrKrfU2YlDH95oatG78= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=OjtqOcCgqmVoq7rqs4t3V5+/hLSRE7NaU5comYHYC8EprxvXsTEnos4DGKn/T6ZGYA FMXiDJzkgK25pYhIdw3KKxvhTcRXRFEALG7fb5eW1xuK9pM+FgL+rHyLIlcyOMYKSolv 0VovbZ/iRisOWCU0vdKBNcKHEo2t+zQJD2VyU= MIME-Version: 1.0 Received: by 10.231.145.85 with SMTP id c21mr8278228ibv.104.1276617059261; Tue, 15 Jun 2010 08:50:59 -0700 (PDT) Received: by 10.231.192.4 with HTTP; Tue, 15 Jun 2010 08:50:59 -0700 (PDT) In-Reply-To: <98B37F7D0484184B9DBDCC44B6C8EDA304C07971@S4DE9JSAAID.ost.t-com.de> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB68D9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <98B37F7D0484184B9DBDCC44B6C8EDA304C07971@S4DE9JSAAID.ost.t-com.de> Date: Tue, 15 Jun 2010 08:50:59 -0700 Message-ID: From: David Recordon To: Axel.Nennker@telekom.de Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] expires_in RE: OAuth meeting notes on -05 (with updates) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 15:51:04 -0000 Hey Axel, We had previously decided (I can try to dig up the link) that relative times will be easier for client developers. It means no timezone handling but being able to store the expiration as time() + expires_in. No, it's not going to be perfect to the second but the AS could always send an expires_in that is 5? seconds shorter than reality. --David On Tue, Jun 15, 2010 at 6:10 AM, wrote: > > During the meeting we had a (short) discussion about the expires_in param= eter. > I propose to change it to a notonorafter parameter with a GMT/UTC date as= value. > If the time slew between server is bigger or nearly equal to the life tim= e of the expires_in value than the token receiver has no chance to detect t= hat the token is dead on arrival. > Or we could keep the name expires_in but change the value from a relative= unit (seconds) to a absolute one (Date) > > -Axel > > expires_in > =A0 =A0 =A0 =A0 OPTIONAL. =A0The duration in seconds of the access token = lifetime. > > notonorafter > =A0 =A0 =A0 =A0 OPTIONAL. =A0Specifies the time instant at which the asse= rtion has expired in universal time coordinates. > > Example > =A0 =A0 =A0 =A0notonorafter=3D"2007-08-21T08:18:50.605Z" > > > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of= Eran Hammer-Lahav > Sent: Tuesday, June 15, 2010 8:35 AM > To: OAuth WG (oauth@ietf.org) > Subject: [OAUTH-WG] OAuth meeting notes on -05 (with updates) > > During the OAuth WG interim meeting, the group spent a considerable amoun= t of time going over draft -05 and listing issues with the text and protoco= l. Since the draft is now significantly different, I want to go over this a= nd identify the issues resolved and those still open (before it is too late= ). > > These comments are based on Brian Eaton's detailed notes (thanks!) with m= y edits. I removed comments that were not actionable. I kept the names next= to comments where additional clarifications are needed. If the notes are w= rong, blame me for messing with the Brian's copy. > > Action items are marked with ***. > > Overall, I think by -09 we will be done with most of the comments (ready = for another batch). > > EHL > > --- > >> Introduction: >> >> - Add purposes / use cases >> - Describe how it relates to other authentication schemes (OpenID, HTTP = Auth) >> - Move requirements out of the introduction >> - Describe goals and possibilities >> - Clarify that the listed requirements are not the only ones > > I'm generally happy with the current outline for the introduction. Those = looking to address these points should submit text proposals. > >> Terminology: >> >> - Define client secret > > Client secret isn't a term but a detail of the client authentication proc= ess, especially with the way it is defined now. > >> - Describe relationship between terms > > The section has been restructured to add two levels of terms to show rela= tionships. > >> - Add verification code > > The verification code was renamed to authorization code and added. > >> - Remove terminology references to HTTP terms > > Removed reliance on HTTP terminology. > >> - Add cryptographic terms >> - User the term 'capability' when talking about bearer tokens > > Since the signature and cryptography was removed, these comments are no l= onger relevant for this draft. > >> Overview: >> >> - Does not related to the introduction (confusing) > > The overview section was written from scratch so hopefully it is less con= fusing. > >> - Standardization of tokens should be called out as defined elsewhere >> - Explain that the separation between the authorization server and resou= rce server is out of scope > > Both will be clarified in -09. > >> - Flow grouping is confusing > > Since the flows have been incorporated into the introduction, and the gro= uping removed, the confusion should be resolved. > >> 3.2 End-user endpoint: >> >> - Rename 'end-user endpoint' to 'approval url' > > Renamed to 'end-user authorization endpoint'. > >> - No mandatory to implement language - interop problem (Peter St. Andre) > > *** Please clarify what should be required. > >> - Does not mention user identity (how to verify) > > User identity is out of scope. Should be addressed by the proposed OpenID= Connect work. > >> - When using TLS, make sure it's server authentication, not client certi= ficates (Eve Maler) > > *** Please propose language. > >> - 'user-uri' attribute is too experimental to be included > > Moved to discovery draft. > >> - Explain that the end-user endpoint is only relevant to some flows > > I think -08 makes this clear. > >> - Should standardize existing service provider specific parameters for U= I, e.g. language, display type, user hint > > Published in a separate UX draft. > >> 3.3 Token endpoint: >> >> - First sentence ("After obtaining authorization from the resource owner= ") is not true for all flows > > I think the same issue exists in -08 but I'm not sure how to address it. = Is it really a problem? > >> - Maybe change name to 'Token issuing endpoint' > > I think token endpoint is nice and short. > >> - MUST use SSL? > > Changed to "Servers MUST support TLS 1.2" and may support other stuff (eq= ually strong) as well. > >> - Mandate POST? > > Yes. Otherwise secrets leak into log files. > >> 3.3.1 Client Authentication: >> >> - Need new text for certificate authentication >> - Need more flexible language > > The latest draft fixes this by moving the client authentication out of th= e endpoints and into its own section. In addition, the client identifier an= d secret are given a name (basic client credentials) to make it easier to s= pecify other ways to authenticate the client. > >> 3.3.2 Response Format: >> >> - Do we need so many formats? >> - Are all formats needed on both sides? > > Solved by using just JSON for token endpoint responses. > >> - Is no-store enough of a cache-control header? (Chuck Mortimore) > > *** No idea. Is it? > >> 3.3.2.1 Access Token Response: >> >> - Define scope once, include by reference > > Don't even need to reference anymore. Defined in a single place. > >> - Need "scope" example (Hannes) > > *** It is hard to provide scope examples. Are there any scopes common in = more than one OAuth 1.0 implementation? > >> - Scope is underspecified > > It is as specified as we have consensus for (even this was painful). > >> - Authorization server MUST honor client request for token secret? > > Since this is moved to an extension, the answer is no. > >> - Semantics of "expires_in" are underspecified > > Added example in -09. > >> 3.3.2.2 Error response: >> >> - Data format needs to be in sync across entire spec > > Now uses JSON like a successful response. > >> - Add debugging message field to JSON > > Debugging is out of scope, but feel free to write a proposal. > >> - Predefined list of error responses? > > New section added in -07. Still needs to add text to describe each error = message, as well as make the list complete. > >> 3.4 Flow Parameters: >> >> - More on error handling? (Peter St. Andre) > > *** Not sure what this is about. > >> 3.5 User-Agent Flow: >> >> - If refresh token leaks, you can't recover. =A0Changing client secret i= s not enough. > > No longer issuing refresh token in user-agent flow. > >> - Can we change order of user-agent and web app flow in spec? > > Done. > >> - WRAP web server flow was more secure for rich-client apps, because web= sites cannot pretend to be rich clients. =A0User-Agent flow does not allow= this. (Sarah Faulkner) > > *** Please start a new thread to discuss. > >> - Where do we handle custom protocol schemes in redirect URIs? > > *** Currently mentioned in native application section. Need guidance from= IESG on how to handle this so it will not become a blocking issue. > >> - Move installed applications to a separate section > > Done. > >> - Need to give installed app developers a way to specify device name (Br= ian Eaton) > > *** Please propose text. > >> - Can=A0mobile developers use HTTP URL discovery from slide deck instead= ? (Bill Keenan) > > *** Need clarification. > >> - Explain how to authenticate the client. > > I think the new text is pretty clear, using a reference to the client aut= hentication section. > >> 3.5.1 Client Requests Authorization: >> >> - What if malicious actor (either a user or "man in the browser") tamper= s with "scope" or "state" parameter? (Eve Maler) > > Since the end-user gets to authorize the request, scope tempering shouldn= 't be a problem. As for state, I'm not sure. > >> - Should we add an extension so that users can self-identify their devic= e? (Bill Smith) > > *** Please propose text or start a discussion. > >> - Authorization servers MAY restrict the redirection URI to not include = a >> query component. This will break PHP clients > > This is part of the underspecified matching rules. I'll drop it for now. > >> 3.5.1.1 End-user grants authorization: >> >> - seems odd that client is requesting the token secret. >> - what happens if server doesn't want to issue token secret? > > Removed. Still an open question for the signature spec. > >> - should we make example https? > > I don't think this is necessary since the fragment is not transmitted. > >> 3.5.1.2 End-user denies authorization: >> >> - More error codes needed (Sarah Faulkner and Marius Scurtescu) > > *** Please provide text. > >> - Immediate mode failure needs an error code > > Removed. Noted for when the parameter appears on another draft. > >> 3.5.2 Client extracts access token: >> >> - Can we tell user-agents not to send fragment in HTTP request? =A0IE do= es this >> in certain circumstances. > > HTTP tells that. It was made more explicit in the new HTTPbis work. Beyon= d that, not sure what we can do. > >> 3.6.1 Client Requests Authorization: >> >> - redirect_uri validation strategy should be described once in the spec,= and then included by reference. > > Done. > >> - Some of the required parameters don't make sense if authentication of = user is out of band. (Eve Maler) > > The only required parameter there were 'client_id', 'type', and 'redirect= _uri'. Which one are you referring to? > >> 3.6.1.1 - End-user grants authorization: >> >> - What does the verification code provide? > > I think the new text explains this (part of the abstraction layer provide= d by the access grant). Let me know if it still needs to be clarified. > >> - How do people keep verification code from leaking in referrer header? = (Sarah Faulkner) > > *** Is this an issue? Can you start a thread to discuss? > >> - Should we define time-limit for verification code? =A05 minutes? (Pete= r St. Andre) > > *** Open issue. > >> - Specify that verification code should be used only once > > Made even clearer in -09. > >> 3.6.2 - Client requests access token: >> >> - should mention https > > Done. > > [Device flow feedback removed] > >> 3.8 - Username and password flow: >> >> - need to return error URL from this flow, so that users can get their a= ccount unblocked if they are on the same IP range as a botnet (Brian Eaton) > > *** Please suggest text. > >> 3.10 - Assertion Flow: >> >> - we need an example > > Done. > >> - Two format parameters > > Fixed. > >> 4 - Refresh Token: >> >> - should we alway tell clients to use a secret, e.g. "anonymous" or "ope= nsecret"? =A0Absent secret might be confusing? (Brian Eaton) > > *** Please clarify. > >> - Should we allow down-scoping on this endpoint? > > -08 adds support for down-scoping. > >> - Scope needs to be figured out through entire flow (Eve Maler) > > *** -08 tries to clean up scope handling. Please review. > >> 5 - Accessing a protected resource: >> >> - No clear error path > > Noted. To be addressed in -09. > >> - Should the authentication scheme name be called 'Token'? > > I think so. Those who disagree are welcome to start a discussion. > >> - Can we say "bearer tokens" MUST NOT be sent over secure channels? (Jim= Fenton) > > I would like that but consensus was that SHOULD NOT is the strongest we c= an specify. > >> - Can we write a spec that reflects security reality - people do send be= arer tokens over HTTP connections > > We did :-( > >> - Can we say MUST NOT send bearer tokens to unfamiliar sites? > > Done in -09. > >> - Is "unfamiliar" well-defined? > > I think it is in the context of the spec - not hardcoded into the client. > >> - Can we have a same-origin policy? > > This needs to be addressed in the discovery spec. James' propose 'sites' = parameter is one approach. > >> 5.2 - Bearer Token Requests: >> >> - We should drop realm, it has no meaningful semantics here > > *** I will float this past the HTTP folks to gage their reaction. > >> 6.1 - WWW-Authenticate Response header: >> >> - what about resources that return public data if request is unauthentic= ated? POST vs GET might have different security policy. > > *** Need to look into this. > >> 6.1.1. - describing the WWW-Authenticate response header >> >> - Discovery needed for various elements > > Yes. That's for the discovery draft. > > _______________________________________________ > OAuth mailing 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 recordond@gmail.com Tue Jun 15 08:53:14 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 053343A68BA for ; Tue, 15 Jun 2010 08:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.413 X-Spam-Level: X-Spam-Status: No, score=-1.413 tagged_above=-999 required=5 tests=[AWL=-0.303, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 698kFfVEahhO for ; Tue, 15 Jun 2010 08:53:13 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 033793A68A5 for ; Tue, 15 Jun 2010 08:53:12 -0700 (PDT) Received: by vws9 with SMTP id 9so6892080vws.31 for ; Tue, 15 Jun 2010 08:53:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=9WeV4N38jfyLFM+99VqTnffnsnTdsFBkrw9qmXenZvY=; b=MTOLu5MSYCXstBfEYxrZqwFbc+wYVqQlemxWHjGGuavUY/YNWBj6G7oeDfMil5XvIe uCdKoO3pxFPDKevwL+3B53RuzcHwWUZhcxZjafMi+ktnAh1f+X9jvWwhsKcYCNsJTsC8 akTnSVXrbdFixbb8IbdjM18fV7dcJF74ow/RE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=qmLVD7CbFH+yp4sFcDA81f59bq9WpY8gtN1R9dfzaXVJLpfUMRPtxlIpL2L1R/4isr RMcTw7JAlxu8XCYczwim6U8NTYUtl0jgIRCACSFh6uiQx9gFSJjPOYJG9pkpNDwPbLym SO6+7pnwHwuUywIt+8SmDm9C9yBgNiZj6lpBU= MIME-Version: 1.0 Received: by 10.224.46.228 with SMTP id k36mr3482870qaf.192.1276617188613; Tue, 15 Jun 2010 08:53:08 -0700 (PDT) Received: by 10.231.192.4 with HTTP; Tue, 15 Jun 2010 08:53:08 -0700 (PDT) In-Reply-To: References: Date: Tue, 15 Jun 2010 08:53:08 -0700 Message-ID: From: David Recordon To: Andrew Arnott Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] On the ease of writing an authorization server X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 15:53:14 -0000 I frame this goal a little differently. When there is a decision about where to place needed complexity, we should place as little as possible of it on the client. This means that the AS is more complex, but I think that is the correct decision. --David On Tue, Jun 15, 2010 at 8:19 AM, Andrew Arnott wro= te: > I've read a few comments on this DL that a primary goal is that writing a= n > OAuth 2.0 client should be very easy.=A0 I think we're doing well here.= =A0 I > know this ease for the client necessarily comes at the expense of some > complexity on the server.=A0 As has also been pointed out recently (by Er= an, I > believe) the AS' job is considerably more complex now than it was in OAut= h > 1.0. > > While overall this may be a win, it also seems optimized for the few larg= e > service providers that are driving the spec (Facebook, Twitter, etc.).=A0= They > definitely have the resources and understanding that a large investment i= n > security is important.=A0 But as more web sites across the Internet drop = using > user passwords in favor of federated identity and/or OpenID-type protocol= s, > the only way these sites can delegate access to user data will be to use = a > protocol like OAuth 2.0 since user passwords will no longer apply. > Therefore very many web sites will become OAuth 2.0 resource servers, and > likely given their size and requirements will be their on authorization > server as well.=A0 Now we have a complex server-side protocol that may be > "too" complex for the average-sized web site to implement correctly and > confidently. > > So my $0.02 here is that we try to keep the AS side simple as well where > possible.=A0 And invite responses from others. > > -- > 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 > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From torsten@lodderstedt.net Tue Jun 15 08:54:47 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C84B28C101 for ; Tue, 15 Jun 2010 08:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.948 X-Spam-Level: X-Spam-Status: No, score=-0.948 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XMPjrKxoEXj6 for ; Tue, 15 Jun 2010 08:54:45 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.40]) by core3.amsl.com (Postfix) with ESMTP id 5D54828C12C for ; Tue, 15 Jun 2010 08:54:45 -0700 (PDT) Received: from [80.187.100.231] (helo=[10.170.218.214]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1OOYTM-0002U1-Gj; Tue, 15 Jun 2010 17:54:48 +0200 References: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB68C9@P3PW5EX1MB01.EX1.SECURESERVER.NET> Message-Id: <55E1F9D6-71EC-40CE-8103-790E823B8D58@lodderstedt.net> From: Torsten Lodderstedt To: Andrew Arnott In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-35--190179003 Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7E18) Mime-Version: 1.0 (iPhone Mail 7E18) Date: Tue, 15 Jun 2010 17:54:05 +0200 X-Df-Sender: 141509 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Assertion flow: please add optional refresh_token in response X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 15:54:47 -0000 --Apple-Mail-35--190179003 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Wouldn't it be an alternative solution, if the AS first tries to authenticate the user using SPNEGO within the Web Server flow? This should work in the inhouse scenario. If it fails, it can fall back to username/password auth.. Thoughts? regards, Torsten. Am 15.06.2010 um 17:19 schrieb Andrew Arnott : > Hi Dick, > > Responses inline. > > On Tue, Jun 15, 2010 at 7:12 AM, Dick Hardt > wrote: > Why can the client app access the AS to get an access token but not > the corporate network to get a new assertion? > > The corporate network where the AD lives is behind a firewall, > whereas the AS is on the public Internet. So when the client is on > the public Internet, the AD is not available but the AS is. Also, > the resource server is on the public Internet (probably obvious). > > How does the client app get the assertion to begin with? How did > delegation from the user happen? > > There are two possible scenarios here, which I will outline and > inject the steps in each scenario: > The client app is initially launched while on the corporate network > The client sends an HTTP request to an endpoint on a corpnet AS(1) > (directly -- not through a browser), which sniffs the request for > NTLM credentials (or however Windows auth does it) and if present > immediately responds with an authorization code (a.k.a. verification > code) rather than prompting the user for permission. This is > considered reasonable in this application because the client is > already running on a trusted machine and the privacy ramifications > are minimal. > The client app exchanges the authorization code for a refresh token > and an access token at the AS(2) token endpoint, which lies outside > the corporate firewall, and can thereby refresh access tokens when > the client is off corpnet. > All resource requests use an OAuth access token to gain access. > The client app is initially launched off the corporate network. > This just uses the standard user agent or web server flows, > including prompting the user for authorization. > > Would you elaborate more on the use case so that we can understand > the full trust model? > > Perhaps my description above covers this question. I'll just add > that the goal is to make the authorization process as painless (or > altogether absent from the user's point of view) as possible. We're > also considering providing customized app downloads to each user > based on the Windows auth user that downloads the .zip file, such > that the client app includes a file containing the authorization > code encoded for that particular user. > > > The assertion flow was intended for autonomous clients rather than > user delegation -- hence Brian's response and mine that this is a > different flow if the access token is for user delegation. > > That makes sense. > > > Are you envisioning the client makes a call to AD to get an > assertion where the call is automagically authenticated as the user > by NTLM? > > Perhaps my scenarios above clarified this. My client never > explicitly calls AD though. Whether that happens implicitly by the > Windows platform, I don't know. > > What do you envision being the relationship between the AS and AD? > What authority does the AS have? How long is the refresh token valid > for? > > The refresh token would be valid until the user logged into the AS > (or RS perhaps) to revoke it. The AD is altogether unaware of the > AS, but the AS trusts the AD to have authenticated the user and > trusts the AD assertion. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-35--190179003 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
    Wouldn't it be an alternative solution, if the AS first tries to authenticate the user using SPNEGO within the Web Server flow? This should work in the inhouse scenario. If it fails, it can fall back to username/password auth..

    Thoughts?

    regards,
    Torsten. 



    Am 15.06.2010 um 17:19 schrieb Andrew Arnott <andrewarnott@gmail.com>:

    Hi Dick,

    Responses inline.

    On Tue, Jun 15, 2010 at 7:12 AM, Dick Hardt <dick.hardt@gmail.com> wrote:
    Why can the client app access the AS to get an access token but not the corporate network to get a new assertion?

    The corporate network where the AD lives is behind a firewall, whereas the AS is on the public Internet.  So when the client is on the public Internet, the AD is not available but the AS is.  Also, the resource server is on the public Internet (probably obvious).

    How does the client app get the assertion to begin with? How did delegation from the user happen?

    There are two possible scenarios here, which I will outline and inject the steps in each scenario:
    1. The client app is initially launched while on the corporate network
      1. The client sends an HTTP request to an endpoint on a corpnet AS(1) (directly -- not through a browser), which sniffs the request for NTLM credentials (or however Windows auth does it) and if present immediately responds with an authorization code (a.k.a. verification code) rather than prompting the user for permission.  This is considered reasonable in this application because the client is already running on a trusted machine and the privacy ramifications are minimal.
      2. The client app exchanges the authorization code for a refresh token and an access token at the AS(2) token endpoint, which lies outside the corporate firewall, and can thereby refresh access tokens when the client is off corpnet.
      3. All resource requests use an OAuth access token to gain access.
    2. The client app is initially launched off the corporate network.
      1. This just uses the standard user agent or web server flows, including prompting the user for authorization.

    Would you elaborate more on the use case so that we can understand the full trust model?

    Perhaps my description above covers this question.  I'll just add that the goal is to make the authorization process as painless (or altogether absent from the user's point of view) as possible.  We're also considering providing customized app downloads to each user based on the Windows auth user that downloads the .zip file, such that the client app includes a file containing the authorization code encoded for that particular user.


    The assertion flow was intended for autonomous clients rather than user delegation -- hence Brian's response and mine that this is a different flow if the access token is for user delegation.

    That makes sense.
     
     
    Are you envisioning the client makes a call to AD to get an assertion where the call is automagically authenticated as the user by NTLM? 

    Perhaps my scenarios above clarified this. My client never explicitly calls AD though.  Whether that happens implicitly by the Windows platform, I don't know.

    What do you envision being the relationship between the AS and AD? What authority does the AS have? How long is the refresh token valid for?

    The refresh token would be valid until the user logged into the AS (or RS perhaps) to revoke it. The AD is altogether unaware of the AS, but the AS trusts the AD to have authenticated the user and trusts the AD assertion.
    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth
    --Apple-Mail-35--190179003-- From jricher@mitre.org Tue Jun 15 09:12:48 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D68F3A69B2 for ; Tue, 15 Jun 2010 09:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.476 X-Spam-Level: X-Spam-Status: No, score=-4.476 tagged_above=-999 required=5 tests=[AWL=-0.291, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S00td7dRBjhZ for ; Tue, 15 Jun 2010 09:12:47 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 59A493A6979 for ; Tue, 15 Jun 2010 09:12:47 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o5FGCpH2001088 for ; Tue, 15 Jun 2010 12:12:51 -0400 Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o5FGCo2d001079; Tue, 15 Jun 2010 12:12:50 -0400 Received: from [129.83.50.65] (129.83.50.65) by imchub2.MITRE.ORG (129.83.29.74) with Microsoft SMTP Server id 8.2.254.0; Tue, 15 Jun 2010 12:12:50 -0400 From: Justin Richer To: "Manger, James H" In-Reply-To: <255B9BB34FB7D647A506DC292726F6E112640B7698@WSMSG3153V.srv.dir.telstra.com> References: <4BEBDCFB.7090503@lodderstedt.net> <255B9BB34FB7D647A506DC292726F6E11263465727@WSMSG3153V.srv.dir.telstra.com> <4BFD67CA.5040600@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3EBB66F0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C16753A.9050802@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3EBB680C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E112640B7698@WSMSG3153V.srv.dir.telstra.com> Content-Type: text/plain; charset="UTF-8" Date: Tue, 15 Jun 2010 12:12:50 -0400 Message-ID: <1276618370.10716.47.camel@localhost.localdomain> MIME-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] in-app logout? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 16:12:49 -0000 This is exactly my contention with using DELETE: it's specified[1] as deleting the resource identified by the URI, and it's not meant as way to determine intended action in a higher-level API. Like PUT, it's there for using HTTP as a uri-addressable document store. I'm also not convinced it's going to be as well-supported across client libraries as GET and POST will be, but I can't confirm that in practice as I don't remember ever using the DELETE method by hand. I'm also not in favor of requiring all tokens be URL-addressable. I'd much rather see us use a separate delete/revoke method. Perhaps in parallel with how the rescope is written in -08 (which structure I'm mostly happy with, btw) we can have an optional argument that says "please trash this token". Also, it seems we should be able to revoke both refresh and access tokens by presenting them to the token endpoint. I can see this kind of API call as something that some providers are going to offer anyway, so it should be part of OAuth so that everyone does it the same way. This may be another candidate for "just throw it in an extension", but we seem to be collecting quite a few of those lately. :) -- Justin [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html On Tue, 2010-06-15 at 00:24 -0400, Manger, James H wrote: > > Since refresh token is only issued to clients capable of directly interacting with the authorization server, is there a reason why the endpoint cannot use DELETE instead of a POST with a parameter? > > > > DELETE /token HTTP/1.1 > > Host: server.example.com > > Content-Type: application/x-www-form-urlencoded > > > > grant_type=refresh_token&client_id=s6BhdRkqt3&client_secret=8eSEIpnqmM&refresh_token=n4E9O119d > > > > This looks like an elegant way of doing things. I'm not sure about using the token endpoint for this, but that's a separate issue. > > > The DELETE method deletes the resource identified by the URI. I don't think it is usual to have any body with a DELETE. Any intermediaries seeing the DELETE will mark as stale any cached responses indexed by the URI -- they will not look in the body. > > In short, a more web-style approach is to give each token its own URI and DELETE that. > > DELETE /token?refresh_token=n4E90119d HTTP/1.1 > Authorization: BASIC czZCaGRSa3F0Mzo4ZVNFSXBucW1N > > -- > James Manger > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From Axel.Nennker@telekom.de Tue Jun 15 09:28:18 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 716DA3A69CE for ; Tue, 15 Jun 2010 09:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y60C92RrUxx3 for ; Tue, 15 Jun 2010 09:28:16 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by core3.amsl.com (Postfix) with ESMTP id 1EDD83A69BF for ; Tue, 15 Jun 2010 09:28:15 -0700 (PDT) Received: from s4de9jsaanm.mgb.telekom.de (HELO S4DE9JSAANM.ost.t-com.de) ([10.125.177.122]) by tcmail81.telekom.de with ESMTP; 15 Jun 2010 18:28:12 +0200 Received: from S4DE9JSAAID.ost.t-com.de ([10.125.177.169]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Jun 2010 18:28:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Jun 2010 18:28:09 +0200 Message-ID: <98B37F7D0484184B9DBDCC44B6C8EDA304C07AAB@S4DE9JSAAID.ost.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] expires_in RE: OAuth meeting notes on -05 (with updates) Thread-Index: AcsMoo3yiSV7x4qUTnuPvVYlGg+KbgABM8dQ References: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB68D9@P3PW5EX1MB01.EX1.SECURESERVER.NET><98B37F7D0484184B9DBDCC44B6C8EDA304C07971@S4DE9JSAAID.ost.t-com.de> From: To: X-OriginalArrivalTime: 15 Jun 2010 16:28:11.0834 (UTC) FILETIME=[BF46A1A0:01CB0CA7] Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] expires_in RE: OAuth meeting notes on -05 (with updates) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 16:28:18 -0000 That killer argument again. I allways tend to overestimate the skills of = the developer. Thanks.=20 -Axel -----Original Message----- From: David Recordon [mailto:recordond@gmail.com]=20 Sent: Tuesday, June 15, 2010 5:51 PM To: Nennker, Axel Cc: eran@hueniverse.com; oauth@ietf.org Subject: Re: [OAUTH-WG] expires_in RE: OAuth meeting notes on -05 (with = updates) Hey Axel, We had previously decided (I can try to dig up the link) that relative times will be easier for client developers. It means no timezone handling but being able to store the expiration as time() + expires_in. No, it's not going to be perfect to the second but the AS could always send an expires_in that is 5? seconds shorter than reality. --David On Tue, Jun 15, 2010 at 6:10 AM, wrote: > > During the meeting we had a (short) discussion about the expires_in = parameter. > I propose to change it to a notonorafter parameter with a GMT/UTC date = as value. > If the time slew between server is bigger or nearly equal to the life = time of the expires_in value than the token receiver has no chance to = detect that the token is dead on arrival. > Or we could keep the name expires_in but change the value from a = relative unit (seconds) to a absolute one (Date) > > -Axel > > expires_in > =A0 =A0 =A0 =A0 OPTIONAL. =A0The duration in seconds of the access = token lifetime. > > notonorafter > =A0 =A0 =A0 =A0 OPTIONAL. =A0Specifies the time instant at which the = assertion has expired in universal time coordinates. > > Example > =A0 =A0 =A0 =A0notonorafter=3D"2007-08-21T08:18:50.605Z" > > > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf = Of Eran Hammer-Lahav > Sent: Tuesday, June 15, 2010 8:35 AM > To: OAuth WG (oauth@ietf.org) > Subject: [OAUTH-WG] OAuth meeting notes on -05 (with updates) > > During the OAuth WG interim meeting, the group spent a considerable = amount of time going over draft -05 and listing issues with the text and = protocol. Since the draft is now significantly different, I want to go = over this and identify the issues resolved and those still open (before = it is too late). > > These comments are based on Brian Eaton's detailed notes (thanks!) = with my edits. I removed comments that were not actionable. I kept the = names next to comments where additional clarifications are needed. If = the notes are wrong, blame me for messing with the Brian's copy. > > Action items are marked with ***. > > Overall, I think by -09 we will be done with most of the comments = (ready for another batch). > > EHL > > --- > >> Introduction: >> >> - Add purposes / use cases >> - Describe how it relates to other authentication schemes (OpenID, = HTTP Auth) >> - Move requirements out of the introduction >> - Describe goals and possibilities >> - Clarify that the listed requirements are not the only ones > > I'm generally happy with the current outline for the introduction. = Those looking to address these points should submit text proposals. > >> Terminology: >> >> - Define client secret > > Client secret isn't a term but a detail of the client authentication = process, especially with the way it is defined now. > >> - Describe relationship between terms > > The section has been restructured to add two levels of terms to show = relationships. > >> - Add verification code > > The verification code was renamed to authorization code and added. > >> - Remove terminology references to HTTP terms > > Removed reliance on HTTP terminology. > >> - Add cryptographic terms >> - User the term 'capability' when talking about bearer tokens > > Since the signature and cryptography was removed, these comments are = no longer relevant for this draft. > >> Overview: >> >> - Does not related to the introduction (confusing) > > The overview section was written from scratch so hopefully it is less = confusing. > >> - Standardization of tokens should be called out as defined elsewhere >> - Explain that the separation between the authorization server and = resource server is out of scope > > Both will be clarified in -09. > >> - Flow grouping is confusing > > Since the flows have been incorporated into the introduction, and the = grouping removed, the confusion should be resolved. > >> 3.2 End-user endpoint: >> >> - Rename 'end-user endpoint' to 'approval url' > > Renamed to 'end-user authorization endpoint'. > >> - No mandatory to implement language - interop problem (Peter St. = Andre) > > *** Please clarify what should be required. > >> - Does not mention user identity (how to verify) > > User identity is out of scope. Should be addressed by the proposed = OpenID Connect work. > >> - When using TLS, make sure it's server authentication, not client = certificates (Eve Maler) > > *** Please propose language. > >> - 'user-uri' attribute is too experimental to be included > > Moved to discovery draft. > >> - Explain that the end-user endpoint is only relevant to some flows > > I think -08 makes this clear. > >> - Should standardize existing service provider specific parameters = for UI, e.g. language, display type, user hint > > Published in a separate UX draft. > >> 3.3 Token endpoint: >> >> - First sentence ("After obtaining authorization from the resource = owner") is not true for all flows > > I think the same issue exists in -08 but I'm not sure how to address = it. Is it really a problem? > >> - Maybe change name to 'Token issuing endpoint' > > I think token endpoint is nice and short. > >> - MUST use SSL? > > Changed to "Servers MUST support TLS 1.2" and may support other stuff = (equally strong) as well. > >> - Mandate POST? > > Yes. Otherwise secrets leak into log files. > >> 3.3.1 Client Authentication: >> >> - Need new text for certificate authentication >> - Need more flexible language > > The latest draft fixes this by moving the client authentication out of = the endpoints and into its own section. In addition, the client = identifier and secret are given a name (basic client credentials) to = make it easier to specify other ways to authenticate the client. > >> 3.3.2 Response Format: >> >> - Do we need so many formats? >> - Are all formats needed on both sides? > > Solved by using just JSON for token endpoint responses. > >> - Is no-store enough of a cache-control header? (Chuck Mortimore) > > *** No idea. Is it? > >> 3.3.2.1 Access Token Response: >> >> - Define scope once, include by reference > > Don't even need to reference anymore. Defined in a single place. > >> - Need "scope" example (Hannes) > > *** It is hard to provide scope examples. Are there any scopes common = in more than one OAuth 1.0 implementation? > >> - Scope is underspecified > > It is as specified as we have consensus for (even this was painful). > >> - Authorization server MUST honor client request for token secret? > > Since this is moved to an extension, the answer is no. > >> - Semantics of "expires_in" are underspecified > > Added example in -09. > >> 3.3.2.2 Error response: >> >> - Data format needs to be in sync across entire spec > > Now uses JSON like a successful response. > >> - Add debugging message field to JSON > > Debugging is out of scope, but feel free to write a proposal. > >> - Predefined list of error responses? > > New section added in -07. Still needs to add text to describe each = error message, as well as make the list complete. > >> 3.4 Flow Parameters: >> >> - More on error handling? (Peter St. Andre) > > *** Not sure what this is about. > >> 3.5 User-Agent Flow: >> >> - If refresh token leaks, you can't recover. =A0Changing client = secret is not enough. > > No longer issuing refresh token in user-agent flow. > >> - Can we change order of user-agent and web app flow in spec? > > Done. > >> - WRAP web server flow was more secure for rich-client apps, because = web sites cannot pretend to be rich clients. =A0User-Agent flow does not = allow this. (Sarah Faulkner) > > *** Please start a new thread to discuss. > >> - Where do we handle custom protocol schemes in redirect URIs? > > *** Currently mentioned in native application section. Need guidance = from IESG on how to handle this so it will not become a blocking issue. > >> - Move installed applications to a separate section > > Done. > >> - Need to give installed app developers a way to specify device name = (Brian Eaton) > > *** Please propose text. > >> - Can=A0mobile developers use HTTP URL discovery from slide deck = instead? (Bill Keenan) > > *** Need clarification. > >> - Explain how to authenticate the client. > > I think the new text is pretty clear, using a reference to the client = authentication section. > >> 3.5.1 Client Requests Authorization: >> >> - What if malicious actor (either a user or "man in the browser") = tampers with "scope" or "state" parameter? (Eve Maler) > > Since the end-user gets to authorize the request, scope tempering = shouldn't be a problem. As for state, I'm not sure. > >> - Should we add an extension so that users can self-identify their = device? (Bill Smith) > > *** Please propose text or start a discussion. > >> - Authorization servers MAY restrict the redirection URI to not = include a >> query component. This will break PHP clients > > This is part of the underspecified matching rules. I'll drop it for = now. > >> 3.5.1.1 End-user grants authorization: >> >> - seems odd that client is requesting the token secret. >> - what happens if server doesn't want to issue token secret? > > Removed. Still an open question for the signature spec. > >> - should we make example https? > > I don't think this is necessary since the fragment is not transmitted. > >> 3.5.1.2 End-user denies authorization: >> >> - More error codes needed (Sarah Faulkner and Marius Scurtescu) > > *** Please provide text. > >> - Immediate mode failure needs an error code > > Removed. Noted for when the parameter appears on another draft. > >> 3.5.2 Client extracts access token: >> >> - Can we tell user-agents not to send fragment in HTTP request? =A0IE = does this >> in certain circumstances. > > HTTP tells that. It was made more explicit in the new HTTPbis work. = Beyond that, not sure what we can do. > >> 3.6.1 Client Requests Authorization: >> >> - redirect_uri validation strategy should be described once in the = spec, and then included by reference. > > Done. > >> - Some of the required parameters don't make sense if authentication = of user is out of band. (Eve Maler) > > The only required parameter there were 'client_id', 'type', and = 'redirect_uri'. Which one are you referring to? > >> 3.6.1.1 - End-user grants authorization: >> >> - What does the verification code provide? > > I think the new text explains this (part of the abstraction layer = provided by the access grant). Let me know if it still needs to be = clarified. > >> - How do people keep verification code from leaking in referrer = header? (Sarah Faulkner) > > *** Is this an issue? Can you start a thread to discuss? > >> - Should we define time-limit for verification code? =A05 minutes? = (Peter St. Andre) > > *** Open issue. > >> - Specify that verification code should be used only once > > Made even clearer in -09. > >> 3.6.2 - Client requests access token: >> >> - should mention https > > Done. > > [Device flow feedback removed] > >> 3.8 - Username and password flow: >> >> - need to return error URL from this flow, so that users can get = their account unblocked if they are on the same IP range as a botnet = (Brian Eaton) > > *** Please suggest text. > >> 3.10 - Assertion Flow: >> >> - we need an example > > Done. > >> - Two format parameters > > Fixed. > >> 4 - Refresh Token: >> >> - should we alway tell clients to use a secret, e.g. "anonymous" or = "opensecret"? =A0Absent secret might be confusing? (Brian Eaton) > > *** Please clarify. > >> - Should we allow down-scoping on this endpoint? > > -08 adds support for down-scoping. > >> - Scope needs to be figured out through entire flow (Eve Maler) > > *** -08 tries to clean up scope handling. Please review. > >> 5 - Accessing a protected resource: >> >> - No clear error path > > Noted. To be addressed in -09. > >> - Should the authentication scheme name be called 'Token'? > > I think so. Those who disagree are welcome to start a discussion. > >> - Can we say "bearer tokens" MUST NOT be sent over secure channels? = (Jim Fenton) > > I would like that but consensus was that SHOULD NOT is the strongest = we can specify. > >> - Can we write a spec that reflects security reality - people do send = bearer tokens over HTTP connections > > We did :-( > >> - Can we say MUST NOT send bearer tokens to unfamiliar sites? > > Done in -09. > >> - Is "unfamiliar" well-defined? > > I think it is in the context of the spec - not hardcoded into the = client. > >> - Can we have a same-origin policy? > > This needs to be addressed in the discovery spec. James' propose = 'sites' parameter is one approach. > >> 5.2 - Bearer Token Requests: >> >> - We should drop realm, it has no meaningful semantics here > > *** I will float this past the HTTP folks to gage their reaction. > >> 6.1 - WWW-Authenticate Response header: >> >> - what about resources that return public data if request is = unauthenticated? POST vs GET might have different security policy. > > *** Need to look into this. > >> 6.1.1. - describing the WWW-Authenticate response header >> >> - Discovery needed for various elements > > Yes. That's for the discovery draft. > > _______________________________________________ > OAuth mailing 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 Tue Jun 15 09:43:47 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 627443A6B0B for ; Tue, 15 Jun 2010 09:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[AWL=0.478, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zh3Sws-IXlLS for ; Tue, 15 Jun 2010 09:43:46 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 65A273A6B0D for ; Tue, 15 Jun 2010 09:43:46 -0700 (PDT) Received: (qmail 20934 invoked from network); 15 Jun 2010 16:43:50 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 15 Jun 2010 16:43:50 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 15 Jun 2010 09:43:42 -0700 From: Eran Hammer-Lahav To: Andrew Arnott , "OAuth WG (oauth@ietf.org)" Date: Tue, 15 Jun 2010 09:43:48 -0700 Thread-Topic: [OAUTH-WG] Clarification on whether arguments can contain empty values Thread-Index: AcsMkoMxR+TvUkakS568T9Sy44f9VwAF1ZSQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB6A36@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_90C41DD21FB7C64BB94121FBBC2E72343B3EBB6A36P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Clarification on whether arguments can contain empty values X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 16:43:47 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EBB6A36P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The best way to address this is to write more resilient servers. Servers sh= ould accept empty optional parameters. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of A= ndrew Arnott Sent: Tuesday, June 15, 2010 6:56 AM To: OAuth WG (oauth@ietf.org) Subject: [OAUTH-WG] Clarification on whether arguments can contain empty va= lues Can we get some clarification into the spec as to whether optional paramete= rs can be present but empty? Particularly parameters such as tokens that o= bviously cannot be meaningful when having an empty value. This was a muddy= issue in the OpenID spec, where some implementations would include empty p= arameters rather than just omitting them, breaking other implementations th= at would expect that if the parameter is present it ought to have a meaning= ful value. My own vote: parameters must have valid values (non-empty) if they are pres= ent, unless they are opaque strings (like client state) that the remote par= ty doesn't have to do anything but imitate back anyway. -- 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 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EBB6A36P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    The best = way to address this is to write more resilient servers. Servers should acce= pt empty optional parameters.

     

    EHL<= /span>

     

    From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Andrew Arnott
    Sent: Tuesday,= June 15, 2010 6:56 AM
    To: OAuth WG (oauth@ietf.org)
    Subjec= t: [OAUTH-WG] Clarification on whether arguments can contain empty valu= es

     <= /p>

    Can we get some clarification into the spec as to w= hether optional parameters can be present but empty?  Particularly par= ameters such as tokens that obviously cannot be meaningful when having an e= mpty value.  This was a muddy issue in the OpenID spec, where some imp= lementations would include empty parameters rather than just omitting them,= breaking other implementations that would expect that if the parameter is = present it ought to have a meaningful value.

    My own vote: parameters= must have valid values (non-empty) if they are present, unless they are op= aque strings (like client state) that the remote party doesn't have to do a= nything but imitate back anyway.

    --
    Andrew Arnott
    = "I [may] not agree with what you have to say, but I'll defend to the d= eath your right to say it." - S. G. Tallentyre

    = --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EBB6A36P3PW5EX1MB01E_-- From wmills@yahoo-inc.com Tue Jun 15 09:49:41 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FB773A6A2F for ; Tue, 15 Jun 2010 09:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.289 X-Spam-Level: X-Spam-Status: No, score=-16.289 tagged_above=-999 required=5 tests=[AWL=0.976, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lBIdJ-q5PKzm for ; Tue, 15 Jun 2010 09:49:39 -0700 (PDT) Received: from mrout2-b.corp.re1.yahoo.com (mrout2-b.corp.re1.yahoo.com [69.147.107.21]) by core3.amsl.com (Postfix) with ESMTP id D58763A6B1D for ; Tue, 15 Jun 2010 09:49:34 -0700 (PDT) Received: from SNV-EXBH01.ds.corp.yahoo.com (snv-exbh01.ds.corp.yahoo.com [207.126.227.249]) by mrout2-b.corp.re1.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o5FGmPNe026169; Tue, 15 Jun 2010 09:48:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:x-mimeole:content-class:mime-version: content-type:content-transfer-encoding:subject:date:message-id: in-reply-to:x-ms-has-attach:x-ms-tnef-correlator:thread-topic: thread-index:references:from:to:x-originalarrivaltime; b=JSNdUPLRKOOb+lbtzp4ZHc1giJwsPVmXE/w1CvE4vtSGVm5CJ3kYlKy427BA2f3s Received: from SNV-EXVS08.ds.corp.yahoo.com ([207.126.227.8]) by SNV-EXBH01.ds.corp.yahoo.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Jun 2010 09:48:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Jun 2010 09:48:24 -0700 Message-ID: <012AB2B223CB3F4BB846962876F4721705795D02@SNV-EXVS08.ds.corp.yahoo.com> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB68D9@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] OAuth meeting notes on -05 (with updates) Thread-Index: AcsMLfi0k1bL/UTuTyKlbQqO9cCDCgAfFVjQ References: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB68D9@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: "William Mills" To: "Eran Hammer-Lahav" , X-OriginalArrivalTime: 15 Jun 2010 16:48:25.0571 (UTC) FILETIME=[92B83330:01CB0CAA] Subject: Re: [OAUTH-WG] OAuth meeting notes on -05 (with updates) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 16:49:41 -0000 Recordon had a fantastic idea at the interim meeting, using G Wave for = comments on the draft, which would have been far superior to the = whiteboard. Perhaps when your ready for another major round of comments = the text version can get posted to a wave and folks can annotate. -bill=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]=20 > On Behalf Of Eran Hammer-Lahav > Sent: Monday, June 14, 2010 11:35 PM > To: OAuth WG (oauth@ietf.org) > Subject: [OAUTH-WG] OAuth meeting notes on -05 (with updates) >=20 > During the OAuth WG interim meeting, the group spent a=20 > considerable amount of time going over draft -05 and listing=20 > issues with the text and protocol. Since the draft is now=20 > significantly different, I want to go over this and identify=20 > the issues resolved and those still open (before it is too late). >=20 > These comments are based on Brian Eaton's detailed notes=20 > (thanks!) with my edits. I removed comments that were not=20 > actionable. I kept the names next to comments where=20 > additional clarifications are needed. If the notes are wrong,=20 > blame me for messing with the Brian's copy. >=20 > Action items are marked with ***. >=20 > Overall, I think by -09 we will be done with most of the=20 > comments (ready for another batch). >=20 > EHL >=20 > --- >=20 > > Introduction: > > > > - Add purposes / use cases > > - Describe how it relates to other authentication schemes (OpenID,=20 > > HTTP Auth) > > - Move requirements out of the introduction > > - Describe goals and possibilities > > - Clarify that the listed requirements are not the only ones >=20 > I'm generally happy with the current outline for the=20 > introduction. Those looking to address these points should=20 > submit text proposals. >=20 > > Terminology: > > > > - Define client secret >=20 > Client secret isn't a term but a detail of the client=20 > authentication process, especially with the way it is defined now. >=20 > > - Describe relationship between terms >=20 > The section has been restructured to add two levels of terms=20 > to show relationships. >=20 > > - Add verification code >=20 > The verification code was renamed to authorization code and added. >=20 > > - Remove terminology references to HTTP terms >=20 > Removed reliance on HTTP terminology. >=20 > > - Add cryptographic terms > > - User the term 'capability' when talking about bearer tokens >=20 > Since the signature and cryptography was removed, these=20 > comments are no longer relevant for this draft. >=20 > > Overview: > > > > - Does not related to the introduction (confusing) >=20 > The overview section was written from scratch so hopefully it=20 > is less confusing. >=20 > > - Standardization of tokens should be called out as defined=20 > elsewhere > > - Explain that the separation between the authorization server and=20 > > resource server is out of scope >=20 > Both will be clarified in -09. >=20 > > - Flow grouping is confusing >=20 > Since the flows have been incorporated into the introduction,=20 > and the grouping removed, the confusion should be resolved. >=20 > > 3.2 End-user endpoint: > > > > - Rename 'end-user endpoint' to 'approval url' >=20 > Renamed to 'end-user authorization endpoint'. >=20 > > - No mandatory to implement language - interop problem (Peter St.=20 > > Andre) >=20 > *** Please clarify what should be required. >=20 > > - Does not mention user identity (how to verify) >=20 > User identity is out of scope. Should be addressed by the=20 > proposed OpenID Connect work. >=20 > > - When using TLS, make sure it's server authentication, not client=20 > > certificates (Eve Maler) >=20 > *** Please propose language. >=20 > > - 'user-uri' attribute is too experimental to be included >=20 > Moved to discovery draft. >=20 > > - Explain that the end-user endpoint is only relevant to some flows >=20 > I think -08 makes this clear. >=20 > > - Should standardize existing service provider specific=20 > parameters for=20 > > UI, e.g. language, display type, user hint >=20 > Published in a separate UX draft. >=20 > > 3.3 Token endpoint: > > > > - First sentence ("After obtaining authorization from the resource=20 > > owner") is not true for all flows >=20 > I think the same issue exists in -08 but I'm not sure how to=20 > address it. Is it really a problem? >=20 > > - Maybe change name to 'Token issuing endpoint' >=20 > I think token endpoint is nice and short. >=20 > > - MUST use SSL? >=20 > Changed to "Servers MUST support TLS 1.2" and may support=20 > other stuff (equally strong) as well. >=20 > > - Mandate POST? >=20 > Yes. Otherwise secrets leak into log files. >=20 > > 3.3.1 Client Authentication: > > > > - Need new text for certificate authentication > > - Need more flexible language >=20 > The latest draft fixes this by moving the client=20 > authentication out of the endpoints and into its own section.=20 > In addition, the client identifier and secret are given a=20 > name (basic client credentials) to make it easier to specify=20 > other ways to authenticate the client. >=20 > > 3.3.2 Response Format: > > > > - Do we need so many formats? > > - Are all formats needed on both sides? >=20 > Solved by using just JSON for token endpoint responses. >=20 > > - Is no-store enough of a cache-control header? (Chuck Mortimore) >=20 > *** No idea. Is it? >=20 > > 3.3.2.1 Access Token Response: > > > > - Define scope once, include by reference >=20 > Don't even need to reference anymore. Defined in a single place. >=20 > > - Need "scope" example (Hannes) >=20 > *** It is hard to provide scope examples. Are there any=20 > scopes common in more than one OAuth 1.0 implementation? >=20 > > - Scope is underspecified >=20 > It is as specified as we have consensus for (even this was painful). >=20 > > - Authorization server MUST honor client request for token secret? >=20 > Since this is moved to an extension, the answer is no. >=20 > > - Semantics of "expires_in" are underspecified >=20 > Added example in -09. >=20 > > 3.3.2.2 Error response: > > > > - Data format needs to be in sync across entire spec >=20 > Now uses JSON like a successful response. >=20 > > - Add debugging message field to JSON >=20 > Debugging is out of scope, but feel free to write a proposal. >=20 > > - Predefined list of error responses? >=20 > New section added in -07. Still needs to add text to describe=20 > each error message, as well as make the list complete. >=20 > > 3.4 Flow Parameters: > > > > - More on error handling? (Peter St. Andre) >=20 > *** Not sure what this is about. >=20 > > 3.5 User-Agent Flow: > > > > - If refresh token leaks, you can't recover. =A0Changing=20 > client secret is not enough. >=20 > No longer issuing refresh token in user-agent flow. >=20 > > - Can we change order of user-agent and web app flow in spec? >=20 > Done. >=20 > > - WRAP web server flow was more secure for rich-client=20 > apps, because=20 > > web sites cannot pretend to be rich clients. =A0User-Agent=20 > flow does not=20 > > allow this. (Sarah Faulkner) >=20 > *** Please start a new thread to discuss. >=20 > > - Where do we handle custom protocol schemes in redirect URIs? >=20 > *** Currently mentioned in native application section. Need=20 > guidance from IESG on how to handle this so it will not=20 > become a blocking issue. >=20 > > - Move installed applications to a separate section >=20 > Done. >=20 > > - Need to give installed app developers a way to specify=20 > device name=20 > > (Brian Eaton) >=20 > *** Please propose text. >=20 > > - Can=A0mobile developers use HTTP URL discovery from slide deck=20 > > instead? (Bill Keenan) >=20 > *** Need clarification. >=20 > > - Explain how to authenticate the client. > =20 > I think the new text is pretty clear, using a reference to=20 > the client authentication section. >=20 > > 3.5.1 Client Requests Authorization: > > > > - What if malicious actor (either a user or "man in the browser")=20 > > tampers with "scope" or "state" parameter? (Eve Maler) >=20 > Since the end-user gets to authorize the request, scope=20 > tempering shouldn't be a problem. As for state, I'm not sure. >=20 > > - Should we add an extension so that users can self-identify their=20 > > device? (Bill Smith) >=20 > *** Please propose text or start a discussion. >=20 > > - Authorization servers MAY restrict the redirection URI to not=20 > > include a query component. This will break PHP clients >=20 > This is part of the underspecified matching rules. I'll drop=20 > it for now. >=20 > > 3.5.1.1 End-user grants authorization: > > > > - seems odd that client is requesting the token secret. > > - what happens if server doesn't want to issue token secret? >=20 > Removed. Still an open question for the signature spec. >=20 > > - should we make example https? >=20 > I don't think this is necessary since the fragment is not transmitted. >=20 > > 3.5.1.2 End-user denies authorization: > > > > - More error codes needed (Sarah Faulkner and Marius Scurtescu) >=20 > *** Please provide text. >=20 > > - Immediate mode failure needs an error code >=20 > Removed. Noted for when the parameter appears on another draft. >=20 > > 3.5.2 Client extracts access token: > > > > - Can we tell user-agents not to send fragment in HTTP request? = =A0IE=20 > > does this in certain circumstances. >=20 > HTTP tells that. It was made more explicit in the new HTTPbis=20 > work. Beyond that, not sure what we can do. >=20 > > 3.6.1 Client Requests Authorization: > > > > - redirect_uri validation strategy should be described once=20 > in the spec, and then included by reference. >=20 > Done. >=20 > > - Some of the required parameters don't make sense if=20 > authentication=20 > > of user is out of band. (Eve Maler) >=20 > The only required parameter there were 'client_id', 'type',=20 > and 'redirect_uri'. Which one are you referring to? >=20 > > 3.6.1.1 - End-user grants authorization: > > > > - What does the verification code provide? >=20 > I think the new text explains this (part of the abstraction=20 > layer provided by the access grant). Let me know if it still=20 > needs to be clarified. >=20 > > - How do people keep verification code from leaking in referrer=20 > > header? (Sarah Faulkner) >=20 > *** Is this an issue? Can you start a thread to discuss? >=20 > > - Should we define time-limit for verification code? =A05 minutes?=20 > > (Peter St. Andre) >=20 > *** Open issue. >=20 > > - Specify that verification code should be used only once >=20 > Made even clearer in -09. >=20 > > 3.6.2 - Client requests access token: > > > > - should mention https >=20 > Done. >=20 > [Device flow feedback removed] >=20 > > 3.8 - Username and password flow: > > > > - need to return error URL from this flow, so that users=20 > can get their=20 > > account unblocked if they are on the same IP range as a=20 > botnet (Brian=20 > > Eaton) >=20 > *** Please suggest text. >=20 > > 3.10 - Assertion Flow: > > > > - we need an example >=20 > Done. >=20 > > - Two format parameters >=20 > Fixed. >=20 > > 4 - Refresh Token: > > > > - should we alway tell clients to use a secret, e.g. "anonymous" or=20 > > "opensecret"? =A0Absent secret might be confusing? (Brian Eaton) >=20 > *** Please clarify. >=20 > > - Should we allow down-scoping on this endpoint? >=20 > -08 adds support for down-scoping. >=20 > > - Scope needs to be figured out through entire flow (Eve Maler) >=20 > *** -08 tries to clean up scope handling. Please review. >=20 > > 5 - Accessing a protected resource: > > > > - No clear error path >=20 > Noted. To be addressed in -09. >=20 > > - Should the authentication scheme name be called 'Token'? >=20 > I think so. Those who disagree are welcome to start a discussion. >=20 > > - Can we say "bearer tokens" MUST NOT be sent over secure channels?=20 > > (Jim Fenton) >=20 > I would like that but consensus was that SHOULD NOT is the=20 > strongest we can specify. >=20 > > - Can we write a spec that reflects security reality -=20 > people do send=20 > > bearer tokens over HTTP connections >=20 > We did :-( >=20 > > - Can we say MUST NOT send bearer tokens to unfamiliar sites? >=20 > Done in -09. >=20 > > - Is "unfamiliar" well-defined? >=20 > I think it is in the context of the spec - not hardcoded into=20 > the client. >=20 > > - Can we have a same-origin policy? >=20 > This needs to be addressed in the discovery spec. James'=20 > propose 'sites' parameter is one approach. >=20 > > 5.2 - Bearer Token Requests: > > > > - We should drop realm, it has no meaningful semantics here >=20 > *** I will float this past the HTTP folks to gage their reaction. >=20 > > 6.1 - WWW-Authenticate Response header: > > > > - what about resources that return public data if request=20 > is unauthenticated? POST vs GET might have different security policy. >=20 > *** Need to look into this. >=20 > > 6.1.1. - describing the WWW-Authenticate response header > > > > - Discovery needed for various elements >=20 > Yes. That's for the discovery draft. >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 From eran@hueniverse.com Tue Jun 15 09:50:32 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A82943A6A40 for ; Tue, 15 Jun 2010 09:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.385 X-Spam-Level: X-Spam-Status: No, score=-1.385 tagged_above=-999 required=5 tests=[AWL=-0.276, BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hLlvsvDHaoDG for ; Tue, 15 Jun 2010 09:50:28 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 0BECD3A6A2F for ; Tue, 15 Jun 2010 09:50:28 -0700 (PDT) Received: (qmail 11852 invoked from network); 15 Jun 2010 16:50:32 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 15 Jun 2010 16:50:32 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 15 Jun 2010 09:50:19 -0700 From: Eran Hammer-Lahav To: Andrew Arnott , "OAuth WG (oauth@ietf.org)" Date: Tue, 15 Jun 2010 09:50:25 -0700 Thread-Topic: [OAUTH-WG] On the ease of writing an authorization server Thread-Index: AcsMnzGhGPgqP8nWS9y/f1h3cO7wAgAC3dWA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB6A3D@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_90C41DD21FB7C64BB94121FBBC2E72343B3EBB6A3DP3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] On the ease of writing an authorization server X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 16:50:32 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EBB6A3DP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If the current draft is too hard for server developers to implement correct= ly, they should probably hire someone more capable. Server side development= of a security protocol isn't something I'd like to see done by people with= out the proper experience. Once we have the security consideration section,= this will become even more complex. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of A= ndrew Arnott Sent: Tuesday, June 15, 2010 8:19 AM To: OAuth WG (oauth@ietf.org) Subject: [OAUTH-WG] On the ease of writing an authorization server I've read a few comments on this DL that a primary goal is that writing an = OAuth 2.0 client should be very easy. I think we're doing well here. I kn= ow this ease for the client necessarily comes at the expense of some comple= xity on the server. As has also been pointed out recently (by Eran, I beli= eve) the AS' job is considerably more complex now than it was in OAuth 1.0. While overall this may be a win, it also seems optimized for the few large = service providers that are driving the spec (Facebook, Twitter, etc.). The= y definitely have the resources and understanding that a large investment i= n security is important. But as more web sites across the Internet drop us= ing user passwords in favor of federated identity and/or OpenID-type protoc= ols, the only way these sites can delegate access to user data will be to u= se a protocol like OAuth 2.0 since user passwords will no longer apply. Th= erefore very many web sites will become OAuth 2.0 resource servers, and lik= ely given their size and requirements will be their on authorization server= as well. Now we have a complex server-side protocol that may be "too" com= plex for the average-sized web site to implement correctly and confidently. So my $0.02 here is that we try to keep the AS side simple as well where po= ssible. And invite responses from others. -- 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 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EBB6A3DP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    If the cu= rrent draft is too hard for server developers to implement correctly, they = should probably hire someone more capable. Server side development of a sec= urity protocol isn’t something I’d like to see done by people w= ithout the proper experience. Once we have the security consideration secti= on, this will become even more complex.

     

    EHL<= o:p>

     

    From: oauth-bounces@ietf.org [mai= lto:oauth-bounces@ietf.org] On Behalf Of Andrew Arnott
    Sent: Tuesday, June 15, 2010 8:19 AM
    To: OAuth WG (oauth@ietf.org)Subject: [OAUTH-WG] On the ease of writing an authorization server=

     

    I've read a few comments on this DL that a primary go= al is that writing an OAuth 2.0 client should be very easy.  I think w= e're doing well here.  I know this ease for the client necessarily com= es at the expense of some complexity on the server.  As has also been = pointed out recently (by Eran, I believe) the AS' job is considerably more = complex now than it was in OAuth 1.0. 

    While overall this m= ay be a win, it also seems optimized for the few large service provider= s that are driving the spec (Facebook, Twitter, etc.).  They definitel= y have the resources and understanding that a large investment in security = is important.  But as more web sites across the Internet drop using us= er passwords in favor of federated identity and/or OpenID-type protocols, t= he only way these sites can delegate access to user data will be to use a p= rotocol like OAuth 2.0 since user passwords will no longer apply.  The= refore very many web sites will become OAuth 2.0 resource servers, a= nd likely given their size and requirements will be their on authorization = server as well.  Now we have a complex server-side protocol that may b= e "too" complex for the average-sized web site to implement corre= ctly and confidently. 

    So my $0.02 here is that we try to keep= the AS side simple as well where possible.  And invite responses from= others.

    --
    Andrew Arnott
    "I [may] not agree = with what you have to say, but I'll defend to the death your right to say i= t." - S. G. Tallentyre

    = --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EBB6A3DP3PW5EX1MB01E_-- From eran@hueniverse.com Tue Jun 15 09:55:14 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 261273A69E6 for ; Tue, 15 Jun 2010 09:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.124 X-Spam-Level: X-Spam-Status: No, score=-2.124 tagged_above=-999 required=5 tests=[AWL=0.475, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QBhDpn3udaCZ for ; Tue, 15 Jun 2010 09:55:12 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 223073A6AF1 for ; Tue, 15 Jun 2010 09:40:43 -0700 (PDT) Received: (qmail 5804 invoked from network); 15 Jun 2010 16:40:46 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 15 Jun 2010 16:40:46 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 15 Jun 2010 09:40:39 -0700 From: Eran Hammer-Lahav To: "Axel.Nennker@telekom.de" , "oauth@ietf.org" Date: Tue, 15 Jun 2010 09:40:46 -0700 Thread-Topic: expires_in RE: [OAUTH-WG] OAuth meeting notes on -05 (with updates) Thread-Index: AcsMLfi0k1bL/UTuTyKlbQqO9cCDCgAW+JpAAAfc6SA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB6A31@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB68D9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <98B37F7D0484184B9DBDCC44B6C8EDA304C07971@S4DE9JSAAID.ost.t-com.de> In-Reply-To: <98B37F7D0484184B9DBDCC44B6C8EDA304C07971@S4DE9JSAAID.ost.t-com.de> 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] expires_in RE: OAuth meeting notes on -05 (with updates) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 16:55:14 -0000 I prefer to keep this as seconds. In most cases, this will be good enough a= nd will not require any clock sync. Servers should not issue tokens with du= rations that are too short and likely to expire during processing. If clock= sync is requires, the client can use the server's Date response header fie= ld to figure out the absolute expiration time. EHL > -----Original Message----- > From: Axel.Nennker@telekom.de [mailto:Axel.Nennker@telekom.de] > Sent: Tuesday, June 15, 2010 6:10 AM > To: Eran Hammer-Lahav; oauth@ietf.org > Subject: expires_in RE: [OAUTH-WG] OAuth meeting notes on -05 (with > updates) >=20 >=20 > During the meeting we had a (short) discussion about the expires_in > parameter. > I propose to change it to a notonorafter parameter with a GMT/UTC date as > value. > If the time slew between server is bigger or nearly equal to the life tim= e of > the expires_in value than the token receiver has no chance to detect that > the token is dead on arrival. > Or we could keep the name expires_in but change the value from a relative > unit (seconds) to a absolute one (Date) >=20 > -Axel >=20 > expires_in > OPTIONAL. The duration in seconds of the access token lifetime. >=20 > notonorafter > OPTIONAL. Specifies the time instant at which the assertion has= expired > in universal time coordinates. >=20 > Example > notonorafter=3D"2007-08-21T08:18:50.605Z" >=20 >=20 >=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Eran Hammer-Lahav > Sent: Tuesday, June 15, 2010 8:35 AM > To: OAuth WG (oauth@ietf.org) > Subject: [OAUTH-WG] OAuth meeting notes on -05 (with updates) >=20 > During the OAuth WG interim meeting, the group spent a considerable > amount of time going over draft -05 and listing issues with the text and > protocol. Since the draft is now significantly different, I want to go ov= er this > and identify the issues resolved and those still open (before it is too l= ate). >=20 > These comments are based on Brian Eaton's detailed notes (thanks!) with m= y > edits. I removed comments that were not actionable. I kept the names next > to comments where additional clarifications are needed. If the notes are > wrong, blame me for messing with the Brian's copy. >=20 > Action items are marked with ***. >=20 > Overall, I think by -09 we will be done with most of the comments (ready = for > another batch). >=20 > EHL >=20 > --- >=20 > > Introduction: > > > > - Add purposes / use cases > > - Describe how it relates to other authentication schemes (OpenID, > > HTTP Auth) > > - Move requirements out of the introduction > > - Describe goals and possibilities > > - Clarify that the listed requirements are not the only ones >=20 > I'm generally happy with the current outline for the introduction. Those > looking to address these points should submit text proposals. >=20 > > Terminology: > > > > - Define client secret >=20 > Client secret isn't a term but a detail of the client authentication proc= ess, > especially with the way it is defined now. >=20 > > - Describe relationship between terms >=20 > The section has been restructured to add two levels of terms to show > relationships. >=20 > > - Add verification code >=20 > The verification code was renamed to authorization code and added. >=20 > > - Remove terminology references to HTTP terms >=20 > Removed reliance on HTTP terminology. >=20 > > - Add cryptographic terms > > - User the term 'capability' when talking about bearer tokens >=20 > Since the signature and cryptography was removed, these comments are no > longer relevant for this draft. >=20 > > Overview: > > > > - Does not related to the introduction (confusing) >=20 > The overview section was written from scratch so hopefully it is less > confusing. >=20 > > - Standardization of tokens should be called out as defined elsewhere > > - Explain that the separation between the authorization server and > > resource server is out of scope >=20 > Both will be clarified in -09. >=20 > > - Flow grouping is confusing >=20 > Since the flows have been incorporated into the introduction, and the > grouping removed, the confusion should be resolved. >=20 > > 3.2 End-user endpoint: > > > > - Rename 'end-user endpoint' to 'approval url' >=20 > Renamed to 'end-user authorization endpoint'. >=20 > > - No mandatory to implement language - interop problem (Peter St. > > Andre) >=20 > *** Please clarify what should be required. >=20 > > - Does not mention user identity (how to verify) >=20 > User identity is out of scope. Should be addressed by the proposed OpenID > Connect work. >=20 > > - When using TLS, make sure it's server authentication, not client > > certificates (Eve Maler) >=20 > *** Please propose language. >=20 > > - 'user-uri' attribute is too experimental to be included >=20 > Moved to discovery draft. >=20 > > - Explain that the end-user endpoint is only relevant to some flows >=20 > I think -08 makes this clear. >=20 > > - Should standardize existing service provider specific parameters for > > UI, e.g. language, display type, user hint >=20 > Published in a separate UX draft. >=20 > > 3.3 Token endpoint: > > > > - First sentence ("After obtaining authorization from the resource > > owner") is not true for all flows >=20 > I think the same issue exists in -08 but I'm not sure how to address it. = Is it > really a problem? >=20 > > - Maybe change name to 'Token issuing endpoint' >=20 > I think token endpoint is nice and short. >=20 > > - MUST use SSL? >=20 > Changed to "Servers MUST support TLS 1.2" and may support other stuff > (equally strong) as well. >=20 > > - Mandate POST? >=20 > Yes. Otherwise secrets leak into log files. >=20 > > 3.3.1 Client Authentication: > > > > - Need new text for certificate authentication > > - Need more flexible language >=20 > The latest draft fixes this by moving the client authentication out of th= e > endpoints and into its own section. In addition, the client identifier an= d > secret are given a name (basic client credentials) to make it easier to s= pecify > other ways to authenticate the client. >=20 > > 3.3.2 Response Format: > > > > - Do we need so many formats? > > - Are all formats needed on both sides? >=20 > Solved by using just JSON for token endpoint responses. >=20 > > - Is no-store enough of a cache-control header? (Chuck Mortimore) >=20 > *** No idea. Is it? >=20 > > 3.3.2.1 Access Token Response: > > > > - Define scope once, include by reference >=20 > Don't even need to reference anymore. Defined in a single place. >=20 > > - Need "scope" example (Hannes) >=20 > *** It is hard to provide scope examples. Are there any scopes common in > more than one OAuth 1.0 implementation? >=20 > > - Scope is underspecified >=20 > It is as specified as we have consensus for (even this was painful). >=20 > > - Authorization server MUST honor client request for token secret? >=20 > Since this is moved to an extension, the answer is no. >=20 > > - Semantics of "expires_in" are underspecified >=20 > Added example in -09. >=20 > > 3.3.2.2 Error response: > > > > - Data format needs to be in sync across entire spec >=20 > Now uses JSON like a successful response. >=20 > > - Add debugging message field to JSON >=20 > Debugging is out of scope, but feel free to write a proposal. >=20 > > - Predefined list of error responses? >=20 > New section added in -07. Still needs to add text to describe each error > message, as well as make the list complete. >=20 > > 3.4 Flow Parameters: > > > > - More on error handling? (Peter St. Andre) >=20 > *** Not sure what this is about. >=20 > > 3.5 User-Agent Flow: > > > > - If refresh token leaks, you can't recover. =A0Changing client secret = is not > enough. >=20 > No longer issuing refresh token in user-agent flow. >=20 > > - Can we change order of user-agent and web app flow in spec? >=20 > Done. >=20 > > - WRAP web server flow was more secure for rich-client apps, because > > web sites cannot pretend to be rich clients. =A0User-Agent flow does no= t > > allow this. (Sarah Faulkner) >=20 > *** Please start a new thread to discuss. >=20 > > - Where do we handle custom protocol schemes in redirect URIs? >=20 > *** Currently mentioned in native application section. Need guidance from > IESG on how to handle this so it will not become a blocking issue. >=20 > > - Move installed applications to a separate section >=20 > Done. >=20 > > - Need to give installed app developers a way to specify device name > > (Brian Eaton) >=20 > *** Please propose text. >=20 > > - Can=A0mobile developers use HTTP URL discovery from slide deck > > instead? (Bill Keenan) >=20 > *** Need clarification. >=20 > > - Explain how to authenticate the client. >=20 > I think the new text is pretty clear, using a reference to the client > authentication section. >=20 > > 3.5.1 Client Requests Authorization: > > > > - What if malicious actor (either a user or "man in the browser") > > tampers with "scope" or "state" parameter? (Eve Maler) >=20 > Since the end-user gets to authorize the request, scope tempering shouldn= 't > be a problem. As for state, I'm not sure. >=20 > > - Should we add an extension so that users can self-identify their > > device? (Bill Smith) >=20 > *** Please propose text or start a discussion. >=20 > > - Authorization servers MAY restrict the redirection URI to not > > include a query component. This will break PHP clients >=20 > This is part of the underspecified matching rules. I'll drop it for now. >=20 > > 3.5.1.1 End-user grants authorization: > > > > - seems odd that client is requesting the token secret. > > - what happens if server doesn't want to issue token secret? >=20 > Removed. Still an open question for the signature spec. >=20 > > - should we make example https? >=20 > I don't think this is necessary since the fragment is not transmitted. >=20 > > 3.5.1.2 End-user denies authorization: > > > > - More error codes needed (Sarah Faulkner and Marius Scurtescu) >=20 > *** Please provide text. >=20 > > - Immediate mode failure needs an error code >=20 > Removed. Noted for when the parameter appears on another draft. >=20 > > 3.5.2 Client extracts access token: > > > > - Can we tell user-agents not to send fragment in HTTP request? =A0IE > > does this in certain circumstances. >=20 > HTTP tells that. It was made more explicit in the new HTTPbis work. Beyon= d > that, not sure what we can do. >=20 > > 3.6.1 Client Requests Authorization: > > > > - redirect_uri validation strategy should be described once in the spec= , and > then included by reference. >=20 > Done. >=20 > > - Some of the required parameters don't make sense if authentication > > of user is out of band. (Eve Maler) >=20 > The only required parameter there were 'client_id', 'type', and 'redirect= _uri'. > Which one are you referring to? >=20 > > 3.6.1.1 - End-user grants authorization: > > > > - What does the verification code provide? >=20 > I think the new text explains this (part of the abstraction layer provide= d by > the access grant). Let me know if it still needs to be clarified. >=20 > > - How do people keep verification code from leaking in referrer > > header? (Sarah Faulkner) >=20 > *** Is this an issue? Can you start a thread to discuss? >=20 > > - Should we define time-limit for verification code? =A05 minutes? > > (Peter St. Andre) >=20 > *** Open issue. >=20 > > - Specify that verification code should be used only once >=20 > Made even clearer in -09. >=20 > > 3.6.2 - Client requests access token: > > > > - should mention https >=20 > Done. >=20 > [Device flow feedback removed] >=20 > > 3.8 - Username and password flow: > > > > - need to return error URL from this flow, so that users can get their > > account unblocked if they are on the same IP range as a botnet (Brian > > Eaton) >=20 > *** Please suggest text. >=20 > > 3.10 - Assertion Flow: > > > > - we need an example >=20 > Done. >=20 > > - Two format parameters >=20 > Fixed. >=20 > > 4 - Refresh Token: > > > > - should we alway tell clients to use a secret, e.g. "anonymous" or > > "opensecret"? =A0Absent secret might be confusing? (Brian Eaton) >=20 > *** Please clarify. >=20 > > - Should we allow down-scoping on this endpoint? >=20 > -08 adds support for down-scoping. >=20 > > - Scope needs to be figured out through entire flow (Eve Maler) >=20 > *** -08 tries to clean up scope handling. Please review. >=20 > > 5 - Accessing a protected resource: > > > > - No clear error path >=20 > Noted. To be addressed in -09. >=20 > > - Should the authentication scheme name be called 'Token'? >=20 > I think so. Those who disagree are welcome to start a discussion. >=20 > > - Can we say "bearer tokens" MUST NOT be sent over secure channels? > > (Jim Fenton) >=20 > I would like that but consensus was that SHOULD NOT is the strongest we c= an > specify. >=20 > > - Can we write a spec that reflects security reality - people do send > > bearer tokens over HTTP connections >=20 > We did :-( >=20 > > - Can we say MUST NOT send bearer tokens to unfamiliar sites? >=20 > Done in -09. >=20 > > - Is "unfamiliar" well-defined? >=20 > I think it is in the context of the spec - not hardcoded into the client. >=20 > > - Can we have a same-origin policy? >=20 > This needs to be addressed in the discovery spec. James' propose 'sites' > parameter is one approach. >=20 > > 5.2 - Bearer Token Requests: > > > > - We should drop realm, it has no meaningful semantics here >=20 > *** I will float this past the HTTP folks to gage their reaction. >=20 > > 6.1 - WWW-Authenticate Response header: > > > > - what about resources that return public data if request is > unauthenticated? POST vs GET might have different security policy. >=20 > *** Need to look into this. >=20 > > 6.1.1. - describing the WWW-Authenticate response header > > > > - Discovery needed for various elements >=20 > Yes. That's for the discovery draft. >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From wmills@yahoo-inc.com Tue Jun 15 09:55:55 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BE413A68FB for ; Tue, 15 Jun 2010 09:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.781 X-Spam-Level: X-Spam-Status: No, score=-16.781 tagged_above=-999 required=5 tests=[AWL=0.817, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJ1SYy4884ra for ; Tue, 15 Jun 2010 09:55:54 -0700 (PDT) Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) by core3.amsl.com (Postfix) with ESMTP id 421D23A6A9B for ; Tue, 15 Jun 2010 09:34:01 -0700 (PDT) Received: from SNV-EXBH01.ds.corp.yahoo.com (snv-exbh01.ds.corp.yahoo.com [207.126.227.249]) by mrout3.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o5FGX2rQ093597; Tue, 15 Jun 2010 09:33:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:x-mimeole:content-class:mime-version: content-type:subject:date:message-id:in-reply-to:x-ms-has-attach: x-ms-tnef-correlator:thread-topic:thread-index:references:from:to:return-path:x-originalarrivaltime; b=K2imDBBwcbxNdTz5BRKeXxWiHbv/ccFG5OA3NFi4HjDCFAKpAQCSQBe/FB9pGDB2 Received: from SNV-EXVS08.ds.corp.yahoo.com ([207.126.227.8]) by SNV-EXBH01.ds.corp.yahoo.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Jun 2010 09:33:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB0CA8.6C07809C" Date: Tue, 15 Jun 2010 09:33:00 -0700 Message-ID: <012AB2B223CB3F4BB846962876F4721705795CF9@SNV-EXVS08.ds.corp.yahoo.com> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB68E1@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] Definition of XML response format Thread-Index: AcsD5VEE571s7DS7Tea7mCIwXSjM5AIczq1gABPvFsA= References: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB68E1@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: "William Mills" To: "Eran Hammer-Lahav" , "Andrew Arnott" , X-OriginalArrivalTime: 15 Jun 2010 16:33:02.0341 (UTC) FILETIME=[6C6E7B50:01CB0CA8] Subject: Re: [OAUTH-WG] Definition of XML response format X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 16:55:55 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB0CA8.6C07809C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Why use CDATA? Why not just use unary tags with all the data in attributes? =20 From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Andrew Arnott Sent: Friday, June 04, 2010 5:56 AM To: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Definition of XML response format =20 In the absence of anyone else volunteering an XML format, what would you say to this as a proposal (because the implementation of which happens to be simple for me): =09 some access token some refresh token 235298298 =09 So the main points here is: 1. no namespace=20 2. root tag is called "root"=20 3. each parameter is an element=20 4. each element has a type parameter that is either string, number, or object to assist the deserializer to understnad how to cast the contents. We may axe #4. In fact we may want to switch all the elements to attributes because it's slightly more compact which might help small devices. =09 -- 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 =09 =09 On Mon, May 31, 2010 at 9:12 AM, Andrew Arnott wrote: Where is the definition of how a auth server response in XML format should look? At the least we need an XML namespace and root node name. =09 -- 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 =20 ------_=_NextPart_001_01CB0CA8.6C07809C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    Why use CDATA?  Why not just use unary tags = with all the=20 data in attributes?

     

    From:=20 oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of = Andrew Arnott
    Sent: Friday, June 04, 2010 5:56 = AM
    To:=20 OAuth WG (oauth@ietf.org)
    Subject: Re: [OAUTH-WG] Definition = of XML=20 response format

     

    In the absence of anyone else volunteering an XML = format,=20 what would you say to this as a proposal (because the implementation = of which=20 happens to be simple for me):

    <root=20 type=3D"object">
       <access_token = type=3D"string">some=20 access token</access_token>
       <refresh_token=20 type=3D"string">some refresh = token</refresh_token>
      =20 <expires_in=20 = type=3D"number">235298298</expires_in>
    </root>

    S= o the=20 main points here is:

      no namespace root tag is called "root" each parameter is an element each element has a type parameter that is either = string,=20 number, or object to assist the deserializer to understnad how to = cast the=20 contents.

    We may axe = #4.  In fact we=20 may want to switch all the elements to attributes because it's = slightly more=20 compact which might help small devices.

    --
    Andrew=20 Arnott
    "I [may] not agree with what you have to say, but I'll = defend to the=20 death your right to say it." - S. G. Tallentyre

    On Mon, May 31, 2010 at 9:12 AM, Andrew Arnott = <andrewarnott@gmail.com>=20 wrote:

    Where is the definition of how a auth server = response in=20 XML format should look?  At the least we need an XML namespace = and root=20 node name.

    --
    Andrew=20 Arnott
    "I [may] not agree with what you have to say, but I'll = defend to the=20 death your right to say it." - S. G. = Tallentyre

     

    ------_=_NextPart_001_01CB0CA8.6C07809C-- From andrewarnott@gmail.com Tue Jun 15 09:55:56 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4351B3A6A96 for ; Tue, 15 Jun 2010 09:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.669 X-Spam-Level: X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kso9xeCQEcWo for ; Tue, 15 Jun 2010 09:55:54 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 4DD4A3A6AF8 for ; Tue, 15 Jun 2010 09:40:58 -0700 (PDT) Received: by gwj16 with SMTP id 16so3515533gwj.31 for ; Tue, 15 Jun 2010 09:40:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=A0TTYcBvYCUpf40ZyOnrS/2Hq4QFeld7IV5ruF3Nv5o=; b=moduYGVqbjS8UWCM7shrWomcuymsf+xNFqQCGdCEsgD+sJKXibHuxJGrnoUHgvlO8l +fAOpDnjRtbPh10AhLq6ctpfHycOPQM8R7tkyMEoCz2GztU/HzIrxj7LZx0FDHCfY4/1 ILPAgfISR2SHT70X4Ld61TMy0Vo/Fz/Ioq/EE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=MOSIACKmdTf//dF4lqGfY/9uKA1RdERjWNIvOzM9jjLOqnRr3DQoMhLOEFwbJ953TO nKSul1Av5EMAlBSNw2vrSbKVH86ByFGZaSTHtVIl9DagxXYXs+d+ezS5pt3aoPryPW1u OQA/IsWf/d5wbAnfeuyjg8s2SWfapN2+LFCCE= MIME-Version: 1.0 Received: by 10.150.55.33 with SMTP id d33mr9254271yba.58.1276620057748; Tue, 15 Jun 2010 09:40:57 -0700 (PDT) Received: by 10.151.26.19 with HTTP; Tue, 15 Jun 2010 09:40:57 -0700 (PDT) In-Reply-To: References: Date: Tue, 15 Jun 2010 09:40:57 -0700 Message-ID: From: Andrew Arnott To: David Recordon Content-Type: multipart/alternative; boundary=000e0cd7096c0e23ff048914454a Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] On the ease of writing an authorization server X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 16:55:56 -0000 --000e0cd7096c0e23ff048914454a Content-Type: text/plain; charset=ISO-8859-1 Thanks, David. Just to clarify, I think it is the right decision as well. But I just wanted to voice that I think we should simplify the AS where possible (i.e. where it doesn't sacrifice legitimate scenarios or simplicity on the client). As a great example of good work being done here, removing the access token secrets was a great move IMO. I wouldn't have liked it a few months ago, but since it was among the more complex areas of the spec, hard to get right, and no one was planning to use it (from the sound of it) moving it to an extension spec makes tons of sense. -- 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, Jun 15, 2010 at 8:53 AM, David Recordon wrote: > I frame this goal a little differently. When there is a decision about > where to place needed complexity, we should place as little as > possible of it on the client. This means that the AS is more complex, > but I think that is the correct decision. > > --David > > > On Tue, Jun 15, 2010 at 8:19 AM, Andrew Arnott > wrote: > > I've read a few comments on this DL that a primary goal is that writing > an > > OAuth 2.0 client should be very easy. I think we're doing well here. I > > know this ease for the client necessarily comes at the expense of some > > complexity on the server. As has also been pointed out recently (by > Eran, I > > believe) the AS' job is considerably more complex now than it was in > OAuth > > 1.0. > > > > While overall this may be a win, it also seems optimized for the few > large > > service providers that are driving the spec (Facebook, Twitter, etc.). > They > > definitely have the resources and understanding that a large investment > in > > security is important. But as more web sites across the Internet drop > using > > user passwords in favor of federated identity and/or OpenID-type > protocols, > > the only way these sites can delegate access to user data will be to use > a > > protocol like OAuth 2.0 since user passwords will no longer apply. > > Therefore very many web sites will become OAuth 2.0 resource servers, and > > likely given their size and requirements will be their on authorization > > server as well. Now we have a complex server-side protocol that may be > > "too" complex for the average-sized web site to implement correctly and > > confidently. > > > > So my $0.02 here is that we try to keep the AS side simple as well where > > possible. And invite responses from others. > > > > -- > > 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 > > > > > --000e0cd7096c0e23ff048914454a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks, David.=A0 Just to clarify, I think it is the right decision as well= .=A0 But I just wanted to voice that I think we should simplify the AS wher= e possible (i.e. where it doesn't sacrifice legitimate scenarios or sim= plicity on the client).

    As a great example of good work being done here, removing the access to= ken secrets was a great move IMO.=A0 I wouldn't have liked it a few mon= ths ago, but since it was among the more complex areas of the spec, hard to= get right, and no one was planning to use it (from the sound of it) moving= it to an extension spec makes tons of sense.

    --
    Andrew Arnott
    "I [may] not agree with what = you have to say, but I'll defend to the death your right to say it.&quo= t; - S. G. Tallentyre


    On Tue, Jun 15, 2010 at 8:53 AM, David R= ecordon <record= ond@gmail.com> wrote:
    I frame this goal a little differently. When there is a decision about
    where to place needed complexity, we should place as little as
    possible of it on the client. This means that the AS is more complex,
    but I think that is the correct decision.

    --David


    On Tue, Jun 15, 2010 at 8:19 AM, Andrew Arnott <andrewarnott@gmail.com> wrote:
    > I've read a few comments on this DL that a primary goal is that wr= iting an
    > OAuth 2.0 client should be very easy.=A0 I think we're doing well = here.=A0 I
    > know this ease for the client necessarily comes at the expense of some=
    > complexity on the server.=A0 As has also been pointed out recently (by= Eran, I
    > believe) the AS' job is considerably more complex now than it was = in OAuth
    > 1.0.
    >
    > While overall this may be a win, it also seems optimized for the few l= arge
    > service providers that are driving the spec (Facebook, Twitter, etc.).= =A0 They
    > definitely have the resources and understanding that a large investmen= t in
    > security is important.=A0 But as more web sites across the Internet dr= op using
    > user passwords in favor of federated identity and/or OpenID-type proto= cols,
    > the only way these sites can delegate access to user data will be to u= se a
    > protocol like OAuth 2.0 since user passwords will no longer apply.
    > Therefore very many web sites will become OAuth 2.0 resource servers, = and
    > likely given their size and requirements will be their on authorizatio= n
    > server as well.=A0 Now we have a complex server-side protocol that may= be
    > "too" complex for the average-sized web site to implement co= rrectly and
    > confidently.
    >
    > So my $0.02 here is that we try to keep the AS side simple as well whe= re
    > possible.=A0 And invite responses from others.
    >
    > --
    > 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
    >
    >

    --000e0cd7096c0e23ff048914454a-- From eran@hueniverse.com Tue Jun 15 09:55:58 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CC253A6A96 for ; Tue, 15 Jun 2010 09:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.133 X-Spam-Level: X-Spam-Status: No, score=-2.133 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0dyEW+-lbYMu for ; Tue, 15 Jun 2010 09:55:57 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id E45023A6A40 for ; Tue, 15 Jun 2010 09:55:05 -0700 (PDT) Received: (qmail 4071 invoked from network); 15 Jun 2010 16:55:10 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 15 Jun 2010 16:55:10 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Tue, 15 Jun 2010 09:55:06 -0700 From: Eran Hammer-Lahav To: Andrew Arnott Date: Tue, 15 Jun 2010 09:55:11 -0700 Thread-Topic: [OAUTH-WG] Clarification on whether arguments can contain empty values Thread-Index: AcsMqqGFHerCdO31SRC/4fscm8A5iwAANf0g Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB6A49@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB6A36@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_90C41DD21FB7C64BB94121FBBC2E72343B3EBB6A49P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Clarification on whether arguments can contain empty values X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 16:55:58 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EBB6A49P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I added: Parameters sent without a value MUST be treated as if they were omitted f= rom the request. This should cover it. EHL From: Andrew Arnott [mailto:andrewarnott@gmail.com] Sent: Tuesday, June 15, 2010 9:49 AM To: Eran Hammer-Lahav Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Clarification on whether arguments can contain empt= y values Thanks, Eran. I can live with that. Do you think it would be a good idea to state in the spec that parameter va= lues may be empty? For instance for this one: expires_in OPTIONAL. The duration in seconds of the access token lifetime if an access= token is included. Maybe I'm taking it to literally, but I read this to include "if the parame= ter is present, its value WILL be an integer". But if somewhere in the spe= c it said "all optional parameters may be present but empty", then that def= eats by incorrect interpretation. Again, I can live with an email from you, but it might help other implement= ors who come along next year to get it right the first time if they're remi= nded in the spec that parameter values may be empty. At least it would hav= e helped me a few years ago in the OpenID spec. :) -- 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, Jun 15, 2010 at 9:43 AM, Eran Hammer-Lahav > wrote: The best way to address this is to write more resilient servers. Servers sh= ould accept empty optional parameters. EHL From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Andrew Arnott Sent: Tuesday, June 15, 2010 6:56 AM To: OAuth WG (oauth@ietf.org) Subject: [OAUTH-WG] Clarification on whether arguments can contain empty va= lues Can we get some clarification into the spec as to whether optional paramete= rs can be present but empty? Particularly parameters such as tokens that o= bviously cannot be meaningful when having an empty value. This was a muddy= issue in the OpenID spec, where some implementations would include empty p= arameters rather than just omitting them, breaking other implementations th= at would expect that if the parameter is present it ought to have a meaning= ful value. My own vote: parameters must have valid values (non-empty) if they are pres= ent, unless they are opaque strings (like client state) that the remote par= ty doesn't have to do anything but imitate back anyway. -- 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 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EBB6A49P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    I added:<= o:p>

     

      Parameters sent without a value MUST = be treated as if they were omitted from the request.

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

    This should cover it.

     

    EHL

     

     

    <= p class=3DMsoNormal>From: Andrew Arnott [mailto:andrewarnott@gmail.com]
    <= b>Sent:     Tuesday, June 15, 2010 9:49 AM
    To: Eran Hammer-Lahav<= br>Cc: OAuth WG (oauth@ietf.org)
    Subject: Re: [OAUTH-WG] C= larification on whether arguments can contain empty values

     

    Thanks, Eran.  I can live with that.

    Do you think it would= be a good idea to state in the spec that parameter values may be empty?&nb= sp; For instance for this one:

    expires_i= n

    OPTIONAL. T= he duration in seconds of the access token lifetime if an access token is i= ncluded.

    = Maybe I'm taking it to literally, but I read this to include "if the p= arameter is present, its value WILL be an integer".  But if somew= here in the spec it said "all optional parameters may be present but e= mpty", then that defeats by incorrect interpretation.

    Again, I = can live with an email from you, but it might help other implementors who c= ome along next year to get it right the first time if they're reminded in t= he spec that parameter values may be empty.  At least it would have he= lped me a few years ago in the OpenID spec. :)
    --
    Andrew = Arnott
    "I [may] not agree with what you have to say, but I'll defen= d to the death your right to say it." - S. G. Tallentyre

    <= /o:p>

    On Tue, Jun 15, 2010 at 9:43 AM, Eran Ha= mmer-Lahav <eran@hueniverse.com> wrote:

    The best way to address this is to write more resilient se= rvers. Servers should accept empty optional parameters.

     <= /o:p>

    EHL

     

    F= rom: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.or= g] On Behalf Of Andrew Arnott
    Sent: Tuesday, June 15, = 2010 6:56 AM
    To: OAuth WG (oauth@ietf.org)
    Subject: [OAUTH-WG] Clarificati= on on whether arguments can contain empty values

     

    Can we get some clarifi= cation into the spec as to whether optional parameters can be present but e= mpty?  Particularly parameters such as tokens that obviously cannot be= meaningful when having an empty value.  This was a muddy issue in the= OpenID spec, where some implementations would include empty parameters rat= her than just omitting them, breaking other implementations that would expe= ct that if the parameter is present it ought to have a meaningful value.
    My own vote: parameters must have valid values (non-empty) if they are= present, unless they are opaque strings (like client state) that the remot= e party doesn't have to do anything but imitate back anyway.

    --
    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. Tall= entyre

     

    = --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EBB6A49P3PW5EX1MB01E_-- From eran@hueniverse.com Tue Jun 15 09:56:30 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7946F3A68F3 for ; Tue, 15 Jun 2010 09:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.141 X-Spam-Level: X-Spam-Status: No, score=-2.141 tagged_above=-999 required=5 tests=[AWL=0.458, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LCWQz08CqfML for ; Tue, 15 Jun 2010 09:56:28 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id B4A3E3A68F8 for ; Tue, 15 Jun 2010 09:56:28 -0700 (PDT) Received: (qmail 16733 invoked from network); 15 Jun 2010 16:56:33 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 15 Jun 2010 16:56:32 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Tue, 15 Jun 2010 09:56:24 -0700 From: Eran Hammer-Lahav To: William Mills , "oauth@ietf.org" Date: Tue, 15 Jun 2010 09:56:30 -0700 Thread-Topic: [OAUTH-WG] OAuth meeting notes on -05 (with updates) Thread-Index: AcsMLfi0k1bL/UTuTyKlbQqO9cCDCgAfFVjQAABSOvA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB6A4B@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB68D9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <012AB2B223CB3F4BB846962876F4721705795D02@SNV-EXVS08.ds.corp.yahoo.com> In-Reply-To: <012AB2B223CB3F4BB846962876F4721705795D02@SNV-EXVS08.ds.corp.yahoo.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] OAuth meeting notes on -05 (with updates) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 16:56:30 -0000 No thanks. I much prefer posts on this list. I would be best if people didn't sent one= email with a long list of issues, but instead posted each issue separately= to help manage the discussion. EHL > -----Original Message----- > From: William Mills [mailto:wmills@yahoo-inc.com] > Sent: Tuesday, June 15, 2010 9:48 AM > To: Eran Hammer-Lahav; oauth@ietf.org > Subject: RE: [OAUTH-WG] OAuth meeting notes on -05 (with updates) >=20 > Recordon had a fantastic idea at the interim meeting, using G Wave for > comments on the draft, which would have been far superior to the > whiteboard. Perhaps when your ready for another major round of > comments the text version can get posted to a wave and folks can annotate= . >=20 > -bill >=20 > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > Of Eran Hammer-Lahav > > Sent: Monday, June 14, 2010 11:35 PM > > To: OAuth WG (oauth@ietf.org) > > Subject: [OAUTH-WG] OAuth meeting notes on -05 (with updates) > > > > During the OAuth WG interim meeting, the group spent a considerable > > amount of time going over draft -05 and listing issues with the text > > and protocol. Since the draft is now significantly different, I want > > to go over this and identify the issues resolved and those still open > > (before it is too late). > > > > These comments are based on Brian Eaton's detailed notes > > (thanks!) with my edits. I removed comments that were not actionable. > > I kept the names next to comments where additional clarifications are > > needed. If the notes are wrong, blame me for messing with the Brian's > > copy. > > > > Action items are marked with ***. > > > > Overall, I think by -09 we will be done with most of the comments > > (ready for another batch). > > > > EHL > > > > --- > > > > > Introduction: > > > > > > - Add purposes / use cases > > > - Describe how it relates to other authentication schemes (OpenID, > > > HTTP Auth) > > > - Move requirements out of the introduction > > > - Describe goals and possibilities > > > - Clarify that the listed requirements are not the only ones > > > > I'm generally happy with the current outline for the introduction. > > Those looking to address these points should submit text proposals. > > > > > Terminology: > > > > > > - Define client secret > > > > Client secret isn't a term but a detail of the client authentication > > process, especially with the way it is defined now. > > > > > - Describe relationship between terms > > > > The section has been restructured to add two levels of terms to show > > relationships. > > > > > - Add verification code > > > > The verification code was renamed to authorization code and added. > > > > > - Remove terminology references to HTTP terms > > > > Removed reliance on HTTP terminology. > > > > > - Add cryptographic terms > > > - User the term 'capability' when talking about bearer tokens > > > > Since the signature and cryptography was removed, these comments are > > no longer relevant for this draft. > > > > > Overview: > > > > > > - Does not related to the introduction (confusing) > > > > The overview section was written from scratch so hopefully it is less > > confusing. > > > > > - Standardization of tokens should be called out as defined > > elsewhere > > > - Explain that the separation between the authorization server and > > > resource server is out of scope > > > > Both will be clarified in -09. > > > > > - Flow grouping is confusing > > > > Since the flows have been incorporated into the introduction, and the > > grouping removed, the confusion should be resolved. > > > > > 3.2 End-user endpoint: > > > > > > - Rename 'end-user endpoint' to 'approval url' > > > > Renamed to 'end-user authorization endpoint'. > > > > > - No mandatory to implement language - interop problem (Peter St. > > > Andre) > > > > *** Please clarify what should be required. > > > > > - Does not mention user identity (how to verify) > > > > User identity is out of scope. Should be addressed by the proposed > > OpenID Connect work. > > > > > - When using TLS, make sure it's server authentication, not client > > > certificates (Eve Maler) > > > > *** Please propose language. > > > > > - 'user-uri' attribute is too experimental to be included > > > > Moved to discovery draft. > > > > > - Explain that the end-user endpoint is only relevant to some flows > > > > I think -08 makes this clear. > > > > > - Should standardize existing service provider specific > > parameters for > > > UI, e.g. language, display type, user hint > > > > Published in a separate UX draft. > > > > > 3.3 Token endpoint: > > > > > > - First sentence ("After obtaining authorization from the resource > > > owner") is not true for all flows > > > > I think the same issue exists in -08 but I'm not sure how to address > > it. Is it really a problem? > > > > > - Maybe change name to 'Token issuing endpoint' > > > > I think token endpoint is nice and short. > > > > > - MUST use SSL? > > > > Changed to "Servers MUST support TLS 1.2" and may support other stuff > > (equally strong) as well. > > > > > - Mandate POST? > > > > Yes. Otherwise secrets leak into log files. > > > > > 3.3.1 Client Authentication: > > > > > > - Need new text for certificate authentication > > > - Need more flexible language > > > > The latest draft fixes this by moving the client authentication out of > > the endpoints and into its own section. > > In addition, the client identifier and secret are given a name (basic > > client credentials) to make it easier to specify other ways to > > authenticate the client. > > > > > 3.3.2 Response Format: > > > > > > - Do we need so many formats? > > > - Are all formats needed on both sides? > > > > Solved by using just JSON for token endpoint responses. > > > > > - Is no-store enough of a cache-control header? (Chuck Mortimore) > > > > *** No idea. Is it? > > > > > 3.3.2.1 Access Token Response: > > > > > > - Define scope once, include by reference > > > > Don't even need to reference anymore. Defined in a single place. > > > > > - Need "scope" example (Hannes) > > > > *** It is hard to provide scope examples. Are there any scopes common > > in more than one OAuth 1.0 implementation? > > > > > - Scope is underspecified > > > > It is as specified as we have consensus for (even this was painful). > > > > > - Authorization server MUST honor client request for token secret? > > > > Since this is moved to an extension, the answer is no. > > > > > - Semantics of "expires_in" are underspecified > > > > Added example in -09. > > > > > 3.3.2.2 Error response: > > > > > > - Data format needs to be in sync across entire spec > > > > Now uses JSON like a successful response. > > > > > - Add debugging message field to JSON > > > > Debugging is out of scope, but feel free to write a proposal. > > > > > - Predefined list of error responses? > > > > New section added in -07. Still needs to add text to describe each > > error message, as well as make the list complete. > > > > > 3.4 Flow Parameters: > > > > > > - More on error handling? (Peter St. Andre) > > > > *** Not sure what this is about. > > > > > 3.5 User-Agent Flow: > > > > > > - If refresh token leaks, you can't recover. =A0Changing > > client secret is not enough. > > > > No longer issuing refresh token in user-agent flow. > > > > > - Can we change order of user-agent and web app flow in spec? > > > > Done. > > > > > - WRAP web server flow was more secure for rich-client > > apps, because > > > web sites cannot pretend to be rich clients. =A0User-Agent > > flow does not > > > allow this. (Sarah Faulkner) > > > > *** Please start a new thread to discuss. > > > > > - Where do we handle custom protocol schemes in redirect URIs? > > > > *** Currently mentioned in native application section. Need guidance > > from IESG on how to handle this so it will not become a blocking > > issue. > > > > > - Move installed applications to a separate section > > > > Done. > > > > > - Need to give installed app developers a way to specify > > device name > > > (Brian Eaton) > > > > *** Please propose text. > > > > > - Can=A0mobile developers use HTTP URL discovery from slide deck > > > instead? (Bill Keenan) > > > > *** Need clarification. > > > > > - Explain how to authenticate the client. > > > > I think the new text is pretty clear, using a reference to the client > > authentication section. > > > > > 3.5.1 Client Requests Authorization: > > > > > > - What if malicious actor (either a user or "man in the browser") > > > tampers with "scope" or "state" parameter? (Eve Maler) > > > > Since the end-user gets to authorize the request, scope tempering > > shouldn't be a problem. As for state, I'm not sure. > > > > > - Should we add an extension so that users can self-identify their > > > device? (Bill Smith) > > > > *** Please propose text or start a discussion. > > > > > - Authorization servers MAY restrict the redirection URI to not > > > include a query component. This will break PHP clients > > > > This is part of the underspecified matching rules. I'll drop it for > > now. > > > > > 3.5.1.1 End-user grants authorization: > > > > > > - seems odd that client is requesting the token secret. > > > - what happens if server doesn't want to issue token secret? > > > > Removed. Still an open question for the signature spec. > > > > > - should we make example https? > > > > I don't think this is necessary since the fragment is not transmitted. > > > > > 3.5.1.2 End-user denies authorization: > > > > > > - More error codes needed (Sarah Faulkner and Marius Scurtescu) > > > > *** Please provide text. > > > > > - Immediate mode failure needs an error code > > > > Removed. Noted for when the parameter appears on another draft. > > > > > 3.5.2 Client extracts access token: > > > > > > - Can we tell user-agents not to send fragment in HTTP request? =A0IE > > > does this in certain circumstances. > > > > HTTP tells that. It was made more explicit in the new HTTPbis work. > > Beyond that, not sure what we can do. > > > > > 3.6.1 Client Requests Authorization: > > > > > > - redirect_uri validation strategy should be described once > > in the spec, and then included by reference. > > > > Done. > > > > > - Some of the required parameters don't make sense if > > authentication > > > of user is out of band. (Eve Maler) > > > > The only required parameter there were 'client_id', 'type', and > > 'redirect_uri'. Which one are you referring to? > > > > > 3.6.1.1 - End-user grants authorization: > > > > > > - What does the verification code provide? > > > > I think the new text explains this (part of the abstraction layer > > provided by the access grant). Let me know if it still needs to be > > clarified. > > > > > - How do people keep verification code from leaking in referrer > > > header? (Sarah Faulkner) > > > > *** Is this an issue? Can you start a thread to discuss? > > > > > - Should we define time-limit for verification code? =A05 minutes? > > > (Peter St. Andre) > > > > *** Open issue. > > > > > - Specify that verification code should be used only once > > > > Made even clearer in -09. > > > > > 3.6.2 - Client requests access token: > > > > > > - should mention https > > > > Done. > > > > [Device flow feedback removed] > > > > > 3.8 - Username and password flow: > > > > > > - need to return error URL from this flow, so that users > > can get their > > > account unblocked if they are on the same IP range as a > > botnet (Brian > > > Eaton) > > > > *** Please suggest text. > > > > > 3.10 - Assertion Flow: > > > > > > - we need an example > > > > Done. > > > > > - Two format parameters > > > > Fixed. > > > > > 4 - Refresh Token: > > > > > > - should we alway tell clients to use a secret, e.g. "anonymous" or > > > "opensecret"? =A0Absent secret might be confusing? (Brian Eaton) > > > > *** Please clarify. > > > > > - Should we allow down-scoping on this endpoint? > > > > -08 adds support for down-scoping. > > > > > - Scope needs to be figured out through entire flow (Eve Maler) > > > > *** -08 tries to clean up scope handling. Please review. > > > > > 5 - Accessing a protected resource: > > > > > > - No clear error path > > > > Noted. To be addressed in -09. > > > > > - Should the authentication scheme name be called 'Token'? > > > > I think so. Those who disagree are welcome to start a discussion. > > > > > - Can we say "bearer tokens" MUST NOT be sent over secure channels? > > > (Jim Fenton) > > > > I would like that but consensus was that SHOULD NOT is the strongest > > we can specify. > > > > > - Can we write a spec that reflects security reality - > > people do send > > > bearer tokens over HTTP connections > > > > We did :-( > > > > > - Can we say MUST NOT send bearer tokens to unfamiliar sites? > > > > Done in -09. > > > > > - Is "unfamiliar" well-defined? > > > > I think it is in the context of the spec - not hardcoded into the > > client. > > > > > - Can we have a same-origin policy? > > > > This needs to be addressed in the discovery spec. James' > > propose 'sites' parameter is one approach. > > > > > 5.2 - Bearer Token Requests: > > > > > > - We should drop realm, it has no meaningful semantics here > > > > *** I will float this past the HTTP folks to gage their reaction. > > > > > 6.1 - WWW-Authenticate Response header: > > > > > > - what about resources that return public data if request > > is unauthenticated? POST vs GET might have different security policy. > > > > *** Need to look into this. > > > > > 6.1.1. - describing the WWW-Authenticate response header > > > > > > - Discovery needed for various elements > > > > Yes. That's for the discovery draft. > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > From andrewarnott@gmail.com Tue Jun 15 09:56:52 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D6E93A68F8 for ; Tue, 15 Jun 2010 09:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.786 X-Spam-Level: X-Spam-Status: No, score=-1.786 tagged_above=-999 required=5 tests=[AWL=0.812, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KzEFGE0DAK1Q for ; Tue, 15 Jun 2010 09:56:51 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id F3E9B3A68F3 for ; Tue, 15 Jun 2010 09:56:50 -0700 (PDT) Received: by gwj16 with SMTP id 16so3531569gwj.31 for ; Tue, 15 Jun 2010 09:56:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=b+jQ6zO6EMXealBHGJrmHYvRfjtMGmyKYTRcEs7/pVw=; b=ElVCKGrxjkecWliktb32rQX9Y4PPGE9nf62X2PpnuV84vyOPFRaGYHoeLcL/Wvqg0M n0+KdkRI3WYMOksk6tjxEH7poo0EBix1bDh+38hZf3oXKJDYYpcILe2YQbSRNbgj2cIp zOb3I71FRj0yRrEFROU/wf0hHMCCJ2XgPdzPo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=KkRY5sFk6VL5v/mLqU6/K6CJZ82x1yIiD4ygifZcof2soDitifuI/gldFdFrjnFktK 4c25TESqblegJte2ze6v3DtNUNkja1ov5GNb7luZU1+1mxKzc40QJHaA7dMPGV8mQW2p eJZIAfxsqWMgebFb7IG32KIZSSNZQBHtIEYaU= MIME-Version: 1.0 Received: by 10.150.94.6 with SMTP id r6mr8838950ybb.306.1276620525504; Tue, 15 Jun 2010 09:48:45 -0700 (PDT) Received: by 10.151.26.19 with HTTP; Tue, 15 Jun 2010 09:48:45 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB6A36@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB6A36@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Tue, 15 Jun 2010 09:48:45 -0700 Message-ID: From: Andrew Arnott To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=000e0cd6e7e6ef899104891460ff Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Clarification on whether arguments can contain empty values X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 16:56:52 -0000 --000e0cd6e7e6ef899104891460ff Content-Type: text/plain; charset=ISO-8859-1 Thanks, Eran. I can live with that. Do you think it would be a good idea to state in the spec that parameter values may be empty? For instance for this one: expires_in OPTIONAL. The duration in seconds of the access token lifetime if an access token is included. Maybe I'm taking it to literally, but I read this to include "if the parameter is present, its value WILL be an integer". But if somewhere in the spec it said "all optional parameters may be present but empty", then that defeats by incorrect interpretation. Again, I can live with an email from you, but it might help other implementors who come along next year to get it right the first time if they're reminded in the spec that parameter values may be empty. At least it would have helped me a few years ago in the OpenID spec. :) -- 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, Jun 15, 2010 at 9:43 AM, Eran Hammer-Lahav wrote: > The best way to address this is to write more resilient servers. Servers > should accept empty optional parameters. > > > > EHL > > > > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf > Of *Andrew Arnott > *Sent:* Tuesday, June 15, 2010 6:56 AM > *To:* OAuth WG (oauth@ietf.org) > *Subject:* [OAUTH-WG] Clarification on whether arguments can contain empty > values > > > > Can we get some clarification into the spec as to whether optional > parameters can be present but empty? Particularly parameters such as tokens > that obviously cannot be meaningful when having an empty value. This was a > muddy issue in the OpenID spec, where some implementations would include > empty parameters rather than just omitting them, breaking other > implementations that would expect that if the parameter is present it ought > to have a meaningful value. > > My own vote: parameters must have valid values (non-empty) if they are > present, unless they are opaque strings (like client state) that the remote > party doesn't have to do anything but imitate back anyway. > > -- > 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 > --000e0cd6e7e6ef899104891460ff Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks, Eran.=A0 I can live with that.

    Do you think it would be a go= od idea to state in the spec that parameter values may be empty?=A0 For ins= tance for this one:
    expires_in
    =20 OPTIONAL. The duration in seconds of the access token=20 lifetime if an access token is included.
    Maybe I'm taking it to literall= y, but I read this to include "if the parameter is present, its value = WILL be an integer".=A0 But if somewhere in the spec it said "all= optional parameters may be present but empty", then that defeats by i= ncorrect interpretation.

    Again, I can live with an email from you, but it might help other imple= mentors who come along next year to get it right the first time if they'= ;re reminded in the spec that parameter values may be empty.=A0 At least it= would have helped me a few years ago in the OpenID spec. :)
    --
    Andrew Arnott
    "I [may] not agree with what you have to say, b= ut I'll defend to the death your right to say it." - S. G. Tallent= yre


    On Tue, Jun 15, 2010 at 9:43 AM, Eran Ha= mmer-Lahav <era= n@hueniverse.com> wrote:

    The best way = to address this is to write more resilient servers. Servers should accept e= mpty optional parameters.

    =A0

    EHL

    =A0

    From:= oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Be= half Of Andrew Arnott
    Sent: Tuesday, June 15, 2010 6:56 AM
    To: OAuth WG (oauth@ietf.org)
    Subj= ect: [OAUTH-WG] Clarification on whether arguments can contain empty va= lues

    =A0

    Can we get some clarification into the spec as to w= hether optional parameters can be present but empty?=A0 Particularly parame= ters such as tokens that obviously cannot be meaningful when having an empt= y value.=A0 This was a muddy issue in the OpenID spec, where some implement= ations would include empty parameters rather than just omitting them, break= ing other implementations that would expect that if the parameter is presen= t it ought to have a meaningful value.

    My own vote: parameters must have valid values (non-empty) if they are = present, unless they are opaque strings (like client state) that the remote= party doesn't have to do anything but imitate back anyway.

    --
    Andrew Arnott
    "I [may] not agree with what you have to say, b= ut I'll defend to the death your right to say it." - S. G. Tallent= yre


    --000e0cd6e7e6ef899104891460ff-- From kris.selden@gmail.com Tue Jun 15 09:58:01 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 312FB3A68F8 for ; Tue, 15 Jun 2010 09:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MFliYIVozcw1 for ; Tue, 15 Jun 2010 09:58:00 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id E400D3A68F3 for ; Tue, 15 Jun 2010 09:57:59 -0700 (PDT) Received: by gwj16 with SMTP id 16so3532667gwj.31 for ; Tue, 15 Jun 2010 09:58:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:message-id:references:to :x-mailer; bh=tfkMFHVStb2AkfXDYy27+i8QmuTn8Ih2g7OMLvjjVgQ=; b=oT/CQSzQzDp+P/UOdrJcG52COyya67Cetxn9GGQIw8KbjAxPk/LP1OaaFLKVPo2ayT JxBpboTnnp+h8jHJALnKNufEDYClecerE6wz1LXGFpYBREMQL/7uxX+CXcmz2lehMSdi V93lPlv2jaDlsFc5VsxRSPZScCxn6yZCE1ua0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; b=qkVRUkL73m6G/bXxrcSLNzLFqbRHXwnx4ZlRSsLyrOaNkSMUMz0WBG3cGEN7EqVt5e Sw3xlOwrHqWld6LSik8OYqP641EXsJVIZS52mIigFCLTHW253Sh1OA3aKfHrU9KjY3ta tQQKi3GabdLkPxKEEHvx4NdBuZdhK6jhYwuHw= Received: by 10.150.170.17 with SMTP id s17mr8724007ybe.410.1276621081617; Tue, 15 Jun 2010 09:58:01 -0700 (PDT) Received: from [10.210.5.175] ([74.94.67.45]) by mx.google.com with ESMTPS id j4sm40607334ybe.44.2010.06.15.09.57.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 15 Jun 2010 09:57:58 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/alternative; boundary=Apple-Mail-2--186365249 From: Kris Selden In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB68E1@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Tue, 15 Jun 2010 09:57:41 -0700 Message-Id: <9523A9A4-69F1-4AA8-B720-E2686951CB59@gmail.com> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB68E1@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1078) Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Definition of XML response format X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 16:58:01 -0000 --Apple-Mail-2--186365249 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 In order to do that On Jun 15, 2010, at 12:02 AM, Eran Hammer-Lahav wrote: > Since XML was dropped, if you feel strongly about this, please submit = a new I-D extending the spec to allow XML format responses. Don=92t = worry about how to extend it, just add parameters or whatever for now. > =20 > EHL > =20 > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf = Of Andrew Arnott > Sent: Friday, June 04, 2010 5:56 AM > To: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Definition of XML response format > =20 > In the absence of anyone else volunteering an XML format, what would = you say to this as a proposal (because the implementation of which = happens to be simple for me): >=20 > > some access token > some refresh token > 235298298 > >=20 > So the main points here is: > no namespace > root tag is called "root" > each parameter is an element > each element has a type parameter that is either string, number, or = object to assist the deserializer to understnad how to cast the = contents. > We may axe #4. In fact we may want to switch all the elements to = attributes because it's slightly more compact which might help small = devices. >=20 > -- > 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 >=20 >=20 > On Mon, May 31, 2010 at 9:12 AM, Andrew Arnott = wrote: > Where is the definition of how a auth server response in XML format = should look? At the least we need an XML namespace and root node name. >=20 > -- > 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 > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-2--186365249 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 In order to do that
    On Jun 15, 2010, = at 12:02 AM, Eran Hammer-Lahav wrote:

    Since XML was dropped, if you feel strongly about = this, please submit a new I-D extending the spec to allow XML format = responses. Don=92t worry about how to extend it, just add parameters or = whatever for now.
     oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.or= g] On Behalf = Of Andrew = Arnott
    Sent: Friday, June 04, 2010 5:56 = AM
    To: OAuth = WG (     Re: [OAUTH-WG] Definition = of XML response format
    1. no namespace
    2. root tag is called "root"
    3. each parameter is an element
    4. each element has a type parameter that is = either string, number, or object to assist the deserializer to = understnad how to cast the contents.

    We may axe #4.  In fact we may want to = switch all the elements to attributes because it's slightly more compact = which might help small devices.

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

    Subject: Re: [OAUTH-WG] Definition of XML response format X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 17:28:35 -0000 --Apple-Mail-1--184513257 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Sorry about the partial message, hit send by accident. ------ In order to do that well it would be nice if some further restrictions = were imposed on extending rather than responses can be any valid JSON = doc. In JSON, keys can be any string, so you can not use them as tags = or attribute names in XML. Any XML extension spec if it wanted to = support other extensions would just be a generic JSON to XML conversion = which will look verbose and ugly. Maybe the spec on extending OAuth 2 should explicitly restrict the = allowed characters in JSON keys, avoid mixing types in arrays, etc. = Just to keep it simple but still take advantage of the JSON structure. Otherwise an XML extension will look something like: scopes http://example.com http://foo.com ... While I do think it is weird for example to need a JSON parser to read = an authenticated ATOM feed and also think it is pointless now to support = XML as an alternative format in an OAuth 2 protected API =96 I'm cool = with JSON only. -Kris On Jun 15, 2010, at 12:02 AM, Eran Hammer-Lahav wrote: > Since XML was dropped, if you feel strongly about this, please submit = a new I-D extending the spec to allow XML format responses. Don=92t = worry about how to extend it, just add parameters or whatever for now. > =20 > EHL > =20 > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf = Of Andrew Arnott > Sent: Friday, June 04, 2010 5:56 AM > To: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Definition of XML response format > =20 > In the absence of anyone else volunteering an XML format, what would = you say to this as a proposal (because the implementation of which = happens to be simple for me): >=20 > > some access token > some refresh token > 235298298 > >=20 > So the main points here is: > no namespace > root tag is called "root" > each parameter is an element > each element has a type parameter that is either string, number, or = object to assist the deserializer to understnad how to cast the = contents. > We may axe #4. In fact we may want to switch all the elements to = attributes because it's slightly more compact which might help small = devices. >=20 > -- > 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 >=20 >=20 > On Mon, May 31, 2010 at 9:12 AM, Andrew Arnott = wrote: > Where is the definition of how a auth server response in XML format = should look? At the least we need an XML namespace and root node name. >=20 > -- > 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 > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-1--184513257 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Sorry about the partial message, hit send by = accident.
    ------

    In order to do that well it = would be nice if some further restrictions were imposed on extending = rather than responses can be any valid JSON doc.  In JSON, keys can = be any string, so you can not use them as tags or attribute names in = XML.  Any XML extension spec if it wanted to support other = extensions would just be a generic JSON to XML conversion which will = look verbose and ugly.

    Maybe the spec on = extending OAuth 2 should explicitly restrict the allowed characters in = JSON keys, avoid mixing types in arrays, etc.  Just to keep it = simple but still take advantage of the JSON = structure.

    Otherwise an XML extension will look = something like:
    <object>
    = <member>
    = <key>scopes</key>
         =     = <value type=3D"array">
    = <element = type=3D"string">http://example.com</element>
    = <element = type=3D"string">http://foo.com</element>
    = </value>
    </member>
    = ...
    </object>

    While I do = think it is weird for example to need a JSON parser to read an = authenticated ATOM feed and also think it is pointless now to support = XML as an alternative format in an OAuth 2 protected API =96 I'm = cool with JSON = only.

    -Kris

    On Jun 15, = 2010, at 12:02 AM, Eran Hammer-Lahav wrote:

    Since XML was dropped, if you feel strongly about = this, please submit a new I-D extending the spec to allow XML format = responses. Don=92t worry about how to extend it, just add parameters or = whatever for now.
    1. no namespace
    2. root tag is called "root"
    3. each parameter is an element
    4. each element has a type parameter that is = either string, number, or object to assist the deserializer to = understnad how to cast the contents.

    We may axe #4.  In fact we may want to = switch all the elements to attributes because it's slightly more compact = which might help small devices.

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

    Subject: Re: [OAUTH-WG] Assertion flow: please add optional refresh_token in response X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 22:35:45 -0000 On Tue, Jun 15, 2010 at 8:54 AM, Torsten Lodderstedt wrote: > Wouldn't it be an alternative solution, if the AS first tries to > authenticate the user using SPNEGO within the Web Server flow? This should > work in the inhouse scenario. If it fails, it can fall back to > username/password auth.. This would let you skip password entry, but I think you'd still require user confirmation to grant the access. From mscurtescu@google.com Tue Jun 15 16:19:03 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D8523A69C3 for ; Tue, 15 Jun 2010 16:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.131 X-Spam-Level: X-Spam-Status: No, score=-105.131 tagged_above=-999 required=5 tests=[AWL=0.846, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P1AmYVXY287Q for ; Tue, 15 Jun 2010 16:19:02 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 160DC3A68DF for ; Tue, 15 Jun 2010 16:19:01 -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 o5FNJ5YF012114 for ; Tue, 15 Jun 2010 16:19:06 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1276643946; bh=8AStiJwpc44Zfp0mM4Ty9sxalzw=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=C7dPlbnnLC+GZHnHInR9VNEQ8TSDEASXQTJVTy85ouiz2RIPMoqaw5WJ1d+p0s7uB WYoqDPVkIlmrXUigFnrFQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=wZVnvn/10ANtUSDqcxaUUhQVOmg2GAnH9662UQOtAdj/TnDgD8JxL2DcA9y3yxpfJ drNVp2ub0AaDuMQ+dxnAQ== Received: from gwb17 (gwb17.prod.google.com [10.200.2.17]) by kpbe16.cbf.corp.google.com with ESMTP id o5FNJ4u2016200 for ; Tue, 15 Jun 2010 16:19:05 -0700 Received: by gwb17 with SMTP id 17so4122105gwb.7 for ; Tue, 15 Jun 2010 16:19:04 -0700 (PDT) Received: by 10.101.143.19 with SMTP id v19mr6554537ann.125.1276643944150; Tue, 15 Jun 2010 16:19:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.189.37 with HTTP; Tue, 15 Jun 2010 16:18:44 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB66AC@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF76BC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3EBB66AC@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu Date: Tue, 15 Jun 2010 16:18:44 -0700 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Draft -07 (major rewrite) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 23:19:03 -0000 On Mon, Jun 14, 2010 at 9:18 AM, Eran Hammer-Lahav wrote: > Adding a verification code to the user-agent flow was suggested on this list > and received nothing but support. It was suggested as a solution to a > Twitter use case. I think it would be good to see a detailed use case where this is really needed and the previous Web Server and/or User-Agent flows could not do. A Java-Script client can use the Web Server flow to grab a verification code and then either swap it or pass it down to the client server. Marius From eran@hueniverse.com Tue Jun 15 17:05:36 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F7323A6A6F for ; Tue, 15 Jun 2010 17:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9GmRT1tV2EU2 for ; Tue, 15 Jun 2010 17:05:35 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id CA2D73A6A0E for ; Tue, 15 Jun 2010 17:05:35 -0700 (PDT) Received: (qmail 1520 invoked from network); 16 Jun 2010 00:05:37 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 16 Jun 2010 00:05:37 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 15 Jun 2010 17:05:37 -0700 From: Eran Hammer-Lahav To: Marius Scurtescu Date: Tue, 15 Jun 2010 17:05:27 -0700 Thread-Topic: [OAUTH-WG] Draft -07 (major rewrite) Thread-Index: AcsM4Sm2byIw1hrySIOhtXh4RjARVwABkNpA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB6C15@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF76BC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3EBB66AC@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 \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Draft -07 (major rewrite) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2010 00:05:36 -0000 It gives you a hybrid solution. The user-agent client doesn't not need to k= eep the client secret, but can still move the authorization code to its ser= ver component to obtain a longer lasting refresh token. It also allows the = server to manage the two tokens using different policies (the one obtained = using the user-agent flow directly and the one obtained using an authentica= ted client call on the server). EHL -----Original Message----- From: Marius Scurtescu [mailto:mscurtescu@google.com]=20 Sent: Tuesday, June 15, 2010 4:19 PM To: Eran Hammer-Lahav Cc: Andrew Arnott; OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Draft -07 (major rewrite) On Mon, Jun 14, 2010 at 9:18 AM, Eran Hammer-Lahav wr= ote: > Adding a verification code to the user-agent flow was suggested on=20 > this list and received nothing but support. It was suggested as a=20 > solution to a Twitter use case. I think it would be good to see a detailed use case where this is really ne= eded and the previous Web Server and/or User-Agent flows could not do. A Java-Script client can use the Web Server flow to grab a verification cod= e and then either swap it or pass it down to the client server. Marius From mscurtescu@google.com Tue Jun 15 17:24:10 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A09463A6A7D for ; Tue, 15 Jun 2010 17:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.215 X-Spam-Level: X-Spam-Status: No, score=-105.215 tagged_above=-999 required=5 tests=[AWL=0.762, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yCMRu89NHdeX for ; Tue, 15 Jun 2010 17:24:09 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id BB2CC3A6A81 for ; Tue, 15 Jun 2010 17:24:09 -0700 (PDT) Received: from hpaq6.eem.corp.google.com (hpaq6.eem.corp.google.com [172.25.149.6]) by smtp-out.google.com with ESMTP id o5G0OBYK030439 for ; Tue, 15 Jun 2010 17:24:11 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1276647851; bh=cr4B3LNdmlvPlFZ/NUt3CEkTUQs=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=XIqwGHKGW0Ek3tp3zTYyFw2+bU6f46Pjg2uiKaKWwjGTYiO6ZaWHhCJEmeY6Q1doR QLV6mEK7yrXwCptoob3aw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding:x-system-of-record; b=EqL5t1+rl9lWSSQvXmWHldeFjyTv0Ekq6ZhNpj8L0ouBKnr6OCkIxRUZrdBQBGoN/ BayIBGcSdFK85VS3LWq+g== Received: from ywh6 (ywh6.prod.google.com [10.192.8.6]) by hpaq6.eem.corp.google.com with ESMTP id o5G0O96D017208 for ; Tue, 15 Jun 2010 17:24:10 -0700 Received: by ywh6 with SMTP id 6so4178883ywh.16 for ; Tue, 15 Jun 2010 17:24:09 -0700 (PDT) Received: by 10.101.133.9 with SMTP id k9mr6742206ann.43.1276647849258; Tue, 15 Jun 2010 17:24:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.189.37 with HTTP; Tue, 15 Jun 2010 17:23:49 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB6C15@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF76BC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3EBB66AC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3EBB6C15@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu Date: Tue, 15 Jun 2010 17:23:49 -0700 Message-ID: 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 \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Draft -07 (major rewrite) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2010 00:24:10 -0000 On Tue, Jun 15, 2010 at 5:05 PM, Eran Hammer-Lahav wr= ote: > It gives you a hybrid solution. The user-agent client doesn't not need to= keep the client secret, but can still move the authorization code to its s= erver component to obtain a longer lasting refresh token. It also allows th= e server to manage the two tokens using different policies (the one obtaine= d using the user-agent flow directly and the one obtained using an authenti= cated client call on the server). OK, but why cannot this be done with the Web Server profile? The JavaScript client can start the Web Server profile and at the end it gets an authorization code (as a query parameter as opposed to fragment) which it can pass to the its server... Marius > > EHL > > -----Original Message----- > From: Marius Scurtescu [mailto:mscurtescu@google.com] > Sent: Tuesday, June 15, 2010 4:19 PM > To: Eran Hammer-Lahav > Cc: Andrew Arnott; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Draft -07 (major rewrite) > > On Mon, Jun 14, 2010 at 9:18 AM, Eran Hammer-Lahav = wrote: >> Adding a verification code to the user-agent flow was suggested on >> this list and received nothing but support. It was suggested as a >> solution to a Twitter use case. > > I think it would be good to see a detailed use case where this is really = needed and the previous Web Server and/or User-Agent flows could not do. > > A Java-Script client can use the Web Server flow to grab a verification c= ode and then either swap it or pass it down to the client server. > > Marius > From eran@hueniverse.com Tue Jun 15 17:34:43 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C9D03A6A8E for ; Tue, 15 Jun 2010 17:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.157 X-Spam-Level: X-Spam-Status: No, score=-2.157 tagged_above=-999 required=5 tests=[AWL=0.442, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ybOcAv4sUECq for ; Tue, 15 Jun 2010 17:34:42 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 573E83A6A7F for ; Tue, 15 Jun 2010 17:34:42 -0700 (PDT) Received: (qmail 30804 invoked from network); 16 Jun 2010 00:34:47 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 16 Jun 2010 00:34:47 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 15 Jun 2010 17:34:47 -0700 From: Eran Hammer-Lahav To: Marius Scurtescu Date: Tue, 15 Jun 2010 17:34:36 -0700 Thread-Topic: [OAUTH-WG] Draft -07 (major rewrite) Thread-Index: AcsM6kFlqPHSulqwRFSYxgRBa/oAKAAAU8/A Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB6C1C@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF76BC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3EBB66AC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3EBB6C15@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 \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Draft -07 (major rewrite) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2010 00:34:43 -0000 Because that defeats the point of having two different access tokens, one i= ssued with a client secret and the other without. It also requires the JS c= lient to interact a lot more with the server part and wait for responses (n= o needed when it just sends over the authorization code). EHL -----Original Message----- From: Marius Scurtescu [mailto:mscurtescu@google.com]=20 Sent: Tuesday, June 15, 2010 5:24 PM To: Eran Hammer-Lahav Cc: Andrew Arnott; OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Draft -07 (major rewrite) On Tue, Jun 15, 2010 at 5:05 PM, Eran Hammer-Lahav wr= ote: > It gives you a hybrid solution. The user-agent client doesn't not need to= keep the client secret, but can still move the authorization code to its s= erver component to obtain a longer lasting refresh token. It also allows th= e server to manage the two tokens using different policies (the one obtaine= d using the user-agent flow directly and the one obtained using an authenti= cated client call on the server). OK, but why cannot this be done with the Web Server profile? The JavaScript= client can start the Web Server profile and at the end it gets an authoriz= ation code (as a query parameter as opposed to fragment) which it can pass to the its server... Marius > > EHL > > -----Original Message----- > From: Marius Scurtescu [mailto:mscurtescu@google.com] > Sent: Tuesday, June 15, 2010 4:19 PM > To: Eran Hammer-Lahav > Cc: Andrew Arnott; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Draft -07 (major rewrite) > > On Mon, Jun 14, 2010 at 9:18 AM, Eran Hammer-Lahav = wrote: >> Adding a verification code to the user-agent flow was suggested on=20 >> this list and received nothing but support. It was suggested as a=20 >> solution to a Twitter use case. > > I think it would be good to see a detailed use case where this is really = needed and the previous Web Server and/or User-Agent flows could not do. > > A Java-Script client can use the Web Server flow to grab a verification c= ode and then either swap it or pass it down to the client server. > > Marius > From mscurtescu@google.com Tue Jun 15 18:04:53 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EA5D3A68CD for ; Tue, 15 Jun 2010 18:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.285 X-Spam-Level: X-Spam-Status: No, score=-105.285 tagged_above=-999 required=5 tests=[AWL=0.693, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eS52UPdGBLoJ for ; Tue, 15 Jun 2010 18:04:52 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id E4C4E3A6A8A for ; Tue, 15 Jun 2010 18:04:51 -0700 (PDT) Received: from hpaq2.eem.corp.google.com (hpaq2.eem.corp.google.com [172.25.149.2]) by smtp-out.google.com with ESMTP id o5G14sCj014273 for ; Tue, 15 Jun 2010 18:04:55 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1276650295; bh=A1M9pMFT7onflCY9My9X0bn59SQ=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=ZDKNut5yScy8Yjb4+AF3GaoFdrD/Xoh/ef8QNydDEWTdTksqCo+1QxccbqTv7Ek0T DHnlFDiX33+aTrb5lw1bw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding:x-system-of-record; b=VUQXXSxu/pFKR67xBUb6dIH1r/r4RS1rxGRJSMBMCC7UpG52AioVTzyzRar0EjQVG dP03t0oAciUCtEC64ikpw== Received: from ywh37 (ywh37.prod.google.com [10.192.8.37]) by hpaq2.eem.corp.google.com with ESMTP id o5G14qYe010790 for ; Tue, 15 Jun 2010 18:04:53 -0700 Received: by ywh37 with SMTP id 37so4091279ywh.2 for ; Tue, 15 Jun 2010 18:04:52 -0700 (PDT) Received: by 10.101.200.6 with SMTP id c6mr6933896anq.234.1276650292220; Tue, 15 Jun 2010 18:04:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.189.37 with HTTP; Tue, 15 Jun 2010 18:04:32 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB6C1C@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF76BC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3EBB66AC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3EBB6C15@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3EBB6C1C@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu Date: Tue, 15 Jun 2010 18:04:32 -0700 Message-ID: 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 \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Draft -07 (major rewrite) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2010 01:04:53 -0000 On Tue, Jun 15, 2010 at 5:34 PM, Eran Hammer-Lahav wr= ote: > Because that defeats the point of having two different access tokens, one= issued with a client secret and the other without. If the authorization code is passed by the JavaScript client to the client server, then the client server can use its secret if it has one. Access token with client secret can be issued. If the authorization code is swapped directly by the JavaScript client then it is clear that there is no secret (based on both client id and the fact that no secret is sent), access token with no client secret is issued. Where does Web Server vs User-Agent make a difference? > It also requires the JS client to interact a lot more with the server par= t and wait for responses (no needed when it just sends over the authorizati= on code). Maybe, but it would be good to see in detail such a case. When does the JavaScript interact a lot more and why? Marius > > EHL > > -----Original Message----- > From: Marius Scurtescu [mailto:mscurtescu@google.com] > Sent: Tuesday, June 15, 2010 5:24 PM > To: Eran Hammer-Lahav > Cc: Andrew Arnott; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Draft -07 (major rewrite) > > On Tue, Jun 15, 2010 at 5:05 PM, Eran Hammer-Lahav = wrote: >> It gives you a hybrid solution. The user-agent client doesn't not need t= o keep the client secret, but can still move the authorization code to its = server component to obtain a longer lasting refresh token. It also allows t= he server to manage the two tokens using different policies (the one obtain= ed using the user-agent flow directly and the one obtained using an authent= icated client call on the server). > > OK, but why cannot this be done with the Web Server profile? The JavaScri= pt client can start the Web Server profile and at the end it gets an author= ization code (as a query parameter as opposed to > fragment) which it can pass to the its server... > > > Marius > >> >> EHL >> >> -----Original Message----- >> From: Marius Scurtescu [mailto:mscurtescu@google.com] >> Sent: Tuesday, June 15, 2010 4:19 PM >> To: Eran Hammer-Lahav >> Cc: Andrew Arnott; OAuth WG (oauth@ietf.org) >> Subject: Re: [OAUTH-WG] Draft -07 (major rewrite) >> >> On Mon, Jun 14, 2010 at 9:18 AM, Eran Hammer-Lahav = wrote: >>> Adding a verification code to the user-agent flow was suggested on >>> this list and received nothing but support. It was suggested as a >>> solution to a Twitter use case. >> >> I think it would be good to see a detailed use case where this is really= needed and the previous Web Server and/or User-Agent flows could not do. >> >> A Java-Script client can use the Web Server flow to grab a verification = code and then either swap it or pass it down to the client server. >> >> Marius >> > From mscurtescu@google.com Tue Jun 15 18:21:02 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EEB83A67CF for ; Tue, 15 Jun 2010 18:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.463 X-Spam-Level: X-Spam-Status: No, score=-101.463 tagged_above=-999 required=5 tests=[AWL=0.514, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wkSkD06ljSBW for ; Tue, 15 Jun 2010 18:20:59 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 1B02F3A659A for ; Tue, 15 Jun 2010 18:20:56 -0700 (PDT) Received: from hpaq6.eem.corp.google.com (hpaq6.eem.corp.google.com [172.25.149.6]) by smtp-out.google.com with ESMTP id o5G1L0rc026252 for ; Tue, 15 Jun 2010 18:21:00 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1276651260; bh=wF03EqZkKRlC5IubauW7PZGZblM=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=A0XUiuvGO5IDoVCO2QJnqRDBrRZfa6/YuuHBuFqWbIY6PWlUY/7tHzvibL/lFJAad IizJofSiqFsSNXxjoIGzA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding:x-system-of-record; b=M4SVU4VgNIpVFB/RNT4iIhzvF3sBf8n1pGZFLn7U3xlh4/2VDblhXmBBxiH/VxH3h DfK/mo1EozR9uFByLf3rA== Received: from gyf1 (gyf1.prod.google.com [10.243.50.65]) by hpaq6.eem.corp.google.com with ESMTP id o5G1Kwf2029783 for ; Tue, 15 Jun 2010 18:20:59 -0700 Received: by gyf1 with SMTP id 1so4337072gyf.21 for ; Tue, 15 Jun 2010 18:20:58 -0700 (PDT) Received: by 10.101.131.40 with SMTP id i40mr6942293ann.49.1276651258225; Tue, 15 Jun 2010 18:20:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.189.37 with HTTP; Tue, 15 Jun 2010 18:20:38 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB68BE@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <20100615020001.EF0673A67D7@core3.amsl.com> <90C41DD21FB7C64BB94121FBBC2E72343B3EBB68BE@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu Date: Tue, 15 Jun 2010 18:20:38 -0700 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-08.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2010 01:21:02 -0000 A few small corrections: - section "1.3. Overview": "exchange that access grant" =3D> "exchange the access grant" ? - section "1.4.2. User-Agent", step (C) and also section "3.1. Authorization Server Response": the authorization code is optionally returned in the user_agent profile, but it is not clear when this is done; even if an authz server issues these codes with User-Agent I don't think it will be done on every single request, an extra request parameter may be needed to ask for a code (I think the original request for this feature did specify such a parameter) - section "1.4.3. Native Application": "incapable of receiving callback requests from the server", in most cases this is not true, native apps can specify a callback URL (custom scheme, locally running web server, local HTML file, helper web app) - section "4. Obtaining an Access Token": "The token endpoint URI MAY include a query component, which must be retained when adding additional query parameters.", in this case there is no need to add any query parameters, the request is executed as a POST. Thanks, Marius On Mon, Jun 14, 2010 at 7:06 PM, Eran Hammer-Lahav wr= ote: > This is the second half of the big rewrite. I changed the entire introduc= tion to better explain the new model, as well as cleaned up the rest of the= new work. This is still not a smooth specification, but I think the genera= l structure is starting to come through. I feel much better about the curre= nt story line, even if it has many holes in it. > > My focus now is on adding in extensibility. > > The spec is now 33 pages! > > =A0 -08 > > =A0 o =A0Renamed verification code to authorization code. > =A0 o =A0Revised terminology, structured section, added new terms. > =A0 o =A0Changed flows to profiles and moved to introduction. > =A0 o =A0Added support for access token rescoping. > =A0 o =A0Cleaned up client credentials section. > =A0 o =A0New introduction overview. > =A0 o =A0Added error code for invalid username and password, and renamed = error code to be more consistent. > =A0 o =A0Added access grant type parameter to token endpoint. > > EHL > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Internet-Drafts@ietf.org >> Sent: Monday, June 14, 2010 7:00 PM >> To: i-d-announce@ietf.org >> Cc: oauth@ietf.org >> Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-08.txt >> >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >> This draft is a work item of the Open Authentication Protocol Working Gr= oup >> of the IETF. >> >> >> =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : The OAuth 2.0 Protocol >> =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : E. Hammer-Lahav, et al. >> =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-oauth-v2-08.txt >> =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 33 >> =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2010-06-14 >> >> This specification describes the OAuth 2.0 protocol. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-08.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the Intern= et- >> Draft. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From sakimura@gmail.com Tue Jun 15 18:26:51 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AE4C3A659A for ; Tue, 15 Jun 2010 18:26:51 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1VYuRF8pW3L5 for ; Tue, 15 Jun 2010 18:26:49 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 7F71A3A6A91 for ; Tue, 15 Jun 2010 18:26:49 -0700 (PDT) Received: by wya21 with SMTP id 21so1615015wya.31 for ; Tue, 15 Jun 2010 18:26:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=QNfzG+p9YI8BpGXOQI+Ai0hL38r9DU4M0861kJqTGII=; b=waispUGs4EzZ6h2rZmpKfoBr4wH18fi2dc5pXyX/79A9unh1s1ZLIxee2b7RvhS7NH ZjD61NP/QmDyssMfVhIkQF/PrLBd93XsdqR3jCief1v+oWUMzPQqyiJe/uOtIYchwgHK mAvAamr8O87jtWmQSuQj1Tvy+LGHwYutswnQw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=R/0cIGu6H38n24HJ3aMvmI1Cigyl5g/7TluFthQy8Bpkqve1l+srektty/G4N8vb5v NXxy9b2q4t5KGBb/jtDHfVqi285dThV8TAu3NxNodnaxQt3sk6NhZT0TAtUUQw14k48/ FDD+/uIVsmi5lG8mlG+qpUQVR2RvhJebzdSKQ= MIME-Version: 1.0 Received: by 10.216.188.203 with SMTP id a53mr4365559wen.22.1276651610607; Tue, 15 Jun 2010 18:26:50 -0700 (PDT) Received: by 10.216.85.138 with HTTP; Tue, 15 Jun 2010 18:26:50 -0700 (PDT) Date: Wed, 16 Jun 2010 10:26:50 +0900 Message-ID: From: Nat Sakimura To: oauth Content-Type: text/plain; charset=ISO-8859-1 Subject: [OAUTH-WG] 4.2 Access Token Response in draft 8 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2010 01:26:51 -0000 It is my understanding that access token response may contain other parameters than what is stated there. Sometimes, mutually understanding server and client may want to exchange other parameters on top of it and is legitimate, IMHO. Is this understanding correct? -- Nat Sakimura (=nat) http://www.sakimura.org/en/ http://twitter.com/_nat_en From eran@hueniverse.com Tue Jun 15 19:52:41 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4430F3A6A17 for ; Tue, 15 Jun 2010 19:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=0.434, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vftPbE+hLYo9 for ; Tue, 15 Jun 2010 19:52:39 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id C54103A6783 for ; Tue, 15 Jun 2010 19:52:39 -0700 (PDT) Received: (qmail 26794 invoked from network); 16 Jun 2010 02:52:44 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 16 Jun 2010 02:52:43 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Tue, 15 Jun 2010 19:52:43 -0700 From: Eran Hammer-Lahav To: Nat Sakimura , oauth Date: Tue, 15 Jun 2010 19:52:33 -0700 Thread-Topic: [OAUTH-WG] 4.2 Access Token Response in draft 8 Thread-Index: AcsM8wQOI+7R2Q8mSlWhYLFEQ+YyuwAC9yig Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB6C2E@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] 4.2 Access Token Response in draft 8 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2010 02:52:41 -0000 There is nothing in the spec to prevent other parameters. There will be spe= cific methods to extend the protocol. EHL -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of N= at Sakimura Sent: Tuesday, June 15, 2010 6:27 PM To: oauth Subject: [OAUTH-WG] 4.2 Access Token Response in draft 8 It is my understanding that access token response may contain other paramet= ers than what is stated there. Sometimes, mutually understanding server and client may want to exchange ot= her parameters on top of it and is legitimate, IMHO. Is this understanding correct? -- Nat Sakimura (=3Dnat) http://www.sakimura.org/en/ http://twitter.com/_nat_en _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From sakimura@gmail.com Tue Jun 15 20:07:25 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B1B13A677C for ; Tue, 15 Jun 2010 20:07:25 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M45vaHgfTeL1 for ; Tue, 15 Jun 2010 20:07:24 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 563AD3A66B4 for ; Tue, 15 Jun 2010 20:07:24 -0700 (PDT) Received: by pvh1 with SMTP id 1so1456824pvh.31 for ; Tue, 15 Jun 2010 20:07:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:x-mailer :mime-version:subject:date:cc; bh=wO2GzZS8wvrQKE4x5/UEFMr2actzKty+6G/f3vNHCDA=; b=WhSHu+gmfAwR7rjHncnd30tzOUwXhcnEt94idC9IV5BekQnznfAhvAJkCPlGZ0ck7x AztXr2tsbTozY9KFvIYB8bPAQ4+8yTuV7CDOu/fktB85EZArCkXamFnAJ8q3HzdgYSEK d8WEjDJP9LFOmxz/FbukbQPo8aT8QiYGgfsR4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:x-mailer:mime-version:subject:date:cc; b=CbhzoTsWAhjs8m0H8y/qUOR9MKPJRDiI6cB3JMAHqXvoV66FMOm9lPYltzLSHNR/xE XS8QjGp5jD3i4nUS3r+ebWXQmxeke2xK2A4ehNGWmzWBYMJ40jJTfVvbrxKRs7zEa2P+ P3/3j826sd2dgK06yos8gGSY8O7BAff3X8CVc= Received: by 10.141.188.4 with SMTP id q4mr6519133rvp.147.1276657646302; Tue, 15 Jun 2010 20:07:26 -0700 (PDT) Received: from [126.234.177.25] (pw126234177025.20.tss.panda-world.ne.jp [126.234.177.25]) by mx.google.com with ESMTPS id q10sm6472642rvp.20.2010.06.15.20.07.22 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 15 Jun 2010 20:07:24 -0700 (PDT) References: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB6C2E@P3PW5EX1MB01.EX1.SECURESERVER.NET> Message-Id: From: Nat To: Eran Hammer-Lahav In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB6C2E@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7E18) Mime-Version: 1.0 (iPhone Mail 7E18) Date: Wed, 16 Jun 2010 12:07:44 +0900 Cc: oauth Subject: Re: [OAUTH-WG] 4.2 Access Token Response in draft 8 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2010 03:07:25 -0000 I am looking forward to the extension mechanism. Is it coming in draft 10? =nat @ Tokyo via iPhone On 2010/06/16, at 11:52, Eran Hammer-Lahav wrote: > There is nothing in the spec to prevent other parameters. There will > be specific methods to extend the protocol. > > EHL > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > Behalf Of Nat Sakimura > Sent: Tuesday, June 15, 2010 6:27 PM > To: oauth > Subject: [OAUTH-WG] 4.2 Access Token Response in draft 8 > > It is my understanding that access token response may contain other > parameters than what is stated there. > Sometimes, mutually understanding server and client may want to > exchange other parameters on top of it and is legitimate, IMHO. > > Is this understanding correct? > > > -- > Nat Sakimura (=nat) > http://www.sakimura.org/en/ > http://twitter.com/_nat_en > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Tue Jun 15 20:27:37 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B516A3A67AD for ; Tue, 15 Jun 2010 20:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[AWL=0.427, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U34PrnWrdMdu for ; Tue, 15 Jun 2010 20:27:36 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 7854A3A66B4 for ; Tue, 15 Jun 2010 20:27:36 -0700 (PDT) Received: (qmail 13185 invoked from network); 16 Jun 2010 03:27:40 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 16 Jun 2010 03:27:39 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 15 Jun 2010 20:27:39 -0700 From: Eran Hammer-Lahav To: Nat Date: Tue, 15 Jun 2010 20:27:28 -0700 Thread-Topic: [OAUTH-WG] 4.2 Access Token Response in draft 8 Thread-Index: AcsNAQ1JFLJCPPnqTQapIsz8Ve3E0wAAsinw Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB6C32@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB6C2E@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 Subject: Re: [OAUTH-WG] 4.2 Access Token Response in draft 8 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2010 03:27:37 -0000 -09 -----Original Message----- From: Nat [mailto:sakimura@gmail.com]=20 Sent: Tuesday, June 15, 2010 8:08 PM To: Eran Hammer-Lahav Cc: oauth Subject: Re: [OAUTH-WG] 4.2 Access Token Response in draft 8 I am looking forward to the extension mechanism. Is it coming in draft 10? =3Dnat @ Tokyo via iPhone On 2010/06/16, at 11:52, Eran Hammer-Lahav wrote: > There is nothing in the spec to prevent other parameters. There will=20 > be specific methods to extend the protocol. > > EHL > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf=20 > Of Nat Sakimura > Sent: Tuesday, June 15, 2010 6:27 PM > To: oauth > Subject: [OAUTH-WG] 4.2 Access Token Response in draft 8 > > It is my understanding that access token response may contain other=20 > parameters than what is stated there. > Sometimes, mutually understanding server and client may want to=20 > exchange other parameters on top of it and is legitimate, IMHO. > > Is this understanding correct? > > > -- > Nat Sakimura (=3Dnat) > http://www.sakimura.org/en/ > http://twitter.com/_nat_en > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From recordond@gmail.com Tue Jun 15 23:06:24 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 438C33A6AA8 for ; Tue, 15 Jun 2010 23:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[AWL=-0.841, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ENbWdOhTDUUH for ; Tue, 15 Jun 2010 23:06:23 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 094933A67CC for ; Tue, 15 Jun 2010 23:06:22 -0700 (PDT) Received: by iwn36 with SMTP id 36so1332580iwn.31 for ; Tue, 15 Jun 2010 23:06:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=zFG2FFQUyxx6Mdim9Bnf7IPl7VYO12UjruFVuoS1ffc=; b=wJxfj+4Wvvy1TYj8d0jninkBenZQQEy/2IBfFvd3cCfaIcFeto8bHzTAFEOjh4DUS8 lOlSKXgGCVJ+vWH/EntptIjT5g3pJkSLcW1ONrFVwUHYRNDBlGShvUX4VBDsj1gOIDxv r0aluVGskqmlh7j+lkIgJtZWhVim9Df1L5SL0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=NzGOgp35QpAGHDTDJEt2IsCvIHRU4nL/hLEIiXIPtIHpInD2RLaqjuOvvkgD6h/gs3 w54I0zBREcTsKtEML1U8xo5Hd/m7v5tStguWAm7+61EbDgIV3xGRnBMgTE9Kx4PFiBE6 jftcG/vWd80alFLRnOR+gL6peT/gQkmShQ0Yk= MIME-Version: 1.0 Received: by 10.231.49.6 with SMTP id t6mr8190736ibf.144.1276668384464; Tue, 15 Jun 2010 23:06:24 -0700 (PDT) Received: by 10.231.192.4 with HTTP; Tue, 15 Jun 2010 23:06:24 -0700 (PDT) In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B4502B29B75@FIESEXC015.nsn-intra.net> References: <3D3C75174CB95F42AD6BCC56E5555B4502B29B75@FIESEXC015.nsn-intra.net> Date: Tue, 15 Jun 2010 23:06:24 -0700 Message-ID: From: David Recordon To: "Tschofenig, Hannes (NSN - FI/Espoo)" Content-Type: text/plain; charset=ISO-8859-1 Cc: OAuth WG Subject: Re: [OAUTH-WG] Planning for upcoming IETF meeting X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2010 06:06:24 -0000 Hey Hannes, Thanks! While I realize that the meeting lasts for the full week, I'll have a hard time being in the Netherlands for over two week days. I don't know what other people's schedules look like, but I'm guessing that a fewer number of longer time blocks will be more useful than shorter blocks spread out across the entire week. I made a poll to see what day(s) people are planning to be at the meeting in Maastricht. (If you're not planning to come, please still respond to the poll but just don't check any of the days.) http://www.doodle.com/t593i5yc76furdt6 Thanks, --David On Mon, Jun 14, 2010 at 7:13 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > Hi all, > > Those who attended the last IETF meeting noticed that the actual working > group slots are quite short (around 2 hours). The feedback I got was > that this does not leave us with enough time to get work done. I > understand that argument and acknowledge that not everyone wants to > attend a punch of other working group (even though I believe it would be > useful todo so) and therefore staying the entire week does not make a > lot of sense either. Traveling to a remote location for a 2 hour meeting > then does not sound super efficient. > > The plan I had discussed with Blaine is the following: Once the final > IETF meeting agenda is available we will pick time slots all over the > week (one every day). I will organize a room and we can get together to > discuss open issues until we reach a point where we need to dig into the > details (often requiring text to be written). Writing such text > contributions will then happen afterwards so that we can continue our > discussion during the next slot. > > This will hopefully help us to get some open issues investigated in > detail and to have text proposals available. The official working group > meeting slot would be used to summarize the work on the text proposals > and to get input from the larger community. > > Thoughts? > > Ciao > Hannes & Blaine > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From Hannes.Tschofenig@gmx.net Wed Jun 16 03:35:21 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90F053A6B19 for ; Wed, 16 Jun 2010 03:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q3Rwu3xSkBd7 for ; Wed, 16 Jun 2010 03:35:20 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 9E0753A6A3A for ; Wed, 16 Jun 2010 03:35:19 -0700 (PDT) Received: (qmail invoked by alias); 16 Jun 2010 10:35:22 -0000 Received: from unknown (EHLO [10.255.136.187]) [192.100.123.77] by mail.gmx.net (mp018) with SMTP; 16 Jun 2010 12:35:22 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/Bqj4PUW3BCl4HZRP4EvH33LwCINnjybwuN8+h/c RUACYYyGWfy7kO Message-ID: <4C18A900.8090609@gmx.net> Date: Wed, 16 Jun 2010 13:35:44 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: David Recordon References: <3D3C75174CB95F42AD6BCC56E5555B4502B29B75@FIESEXC015.nsn-intra.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , OAuth WG Subject: Re: [OAUTH-WG] Planning for upcoming IETF meeting X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2010 10:35:21 -0000 Hi David, a poll sounds like a good idea. But maybe it would be useful to start it when the final agenda is distributed to know when the actual working group meeting takes place. According to http://www.ietf.org/meeting/cutoff-dates-2010.html#IETF78 the final agenda will be available on the 2nd July. Ciao Hannes David Recordon wrote: > Hey Hannes, > Thanks! While I realize that the meeting lasts for the full week, I'll > have a hard time being in the Netherlands for over two week days. I > don't know what other people's schedules look like, but I'm guessing > that a fewer number of longer time blocks will be more useful than > shorter blocks spread out across the entire week. > > I made a poll to see what day(s) people are planning to be at the > meeting in Maastricht. (If you're not planning to come, please still > respond to the poll but just don't check any of the days.) > > http://www.doodle.com/t593i5yc76furdt6 > > Thanks, > --David > > > On Mon, Jun 14, 2010 at 7:13 AM, Tschofenig, Hannes (NSN - FI/Espoo) > wrote: > >> Hi all, >> >> Those who attended the last IETF meeting noticed that the actual working >> group slots are quite short (around 2 hours). The feedback I got was >> that this does not leave us with enough time to get work done. I >> understand that argument and acknowledge that not everyone wants to >> attend a punch of other working group (even though I believe it would be >> useful todo so) and therefore staying the entire week does not make a >> lot of sense either. Traveling to a remote location for a 2 hour meeting >> then does not sound super efficient. >> >> The plan I had discussed with Blaine is the following: Once the final >> IETF meeting agenda is available we will pick time slots all over the >> week (one every day). I will organize a room and we can get together to >> discuss open issues until we reach a point where we need to dig into the >> details (often requiring text to be written). Writing such text >> contributions will then happen afterwards so that we can continue our >> discussion during the next slot. >> >> This will hopefully help us to get some open issues investigated in >> detail and to have text proposals available. The official working group >> meeting slot would be used to summarize the work on the text proposals >> and to get input from the larger community. >> >> Thoughts? >> >> Ciao >> Hannes & Blaine >> _______________________________________________ >> OAuth mailing 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 bcampbell@pingidentity.com Wed Jun 16 07:39:35 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 787373A6B33 for ; Wed, 16 Jun 2010 07:39:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.377 X-Spam-Level: X-Spam-Status: No, score=-3.377 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fnd9BxV55C8b for ; Wed, 16 Jun 2010 07:39:32 -0700 (PDT) Received: from na3sys009aog108.obsmtp.com (na3sys009aog108.obsmtp.com [74.125.149.199]) by core3.amsl.com (Postfix) with SMTP id 705A43A6A6A for ; Wed, 16 Jun 2010 07:39:32 -0700 (PDT) Received: from source ([209.85.212.51]) by na3sys009aob108.postini.com ([74.125.148.12]) with SMTP ID DSNKTBjiKFI0HeAiu6TE/Z7V9AfJV0PTjtxQ@postini.com; Wed, 16 Jun 2010 07:39:37 PDT Received: by vws6 with SMTP id 6so419569vws.24 for ; Wed, 16 Jun 2010 07:39:36 -0700 (PDT) Received: by 10.224.96.97 with SMTP id g33mr4451336qan.372.1276699176117; Wed, 16 Jun 2010 07:39:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.11.1 with HTTP; Wed, 16 Jun 2010 07:39:02 -0700 (PDT) From: Brian Campbell Date: Wed, 16 Jun 2010 08:39:02 -0600 Message-ID: To: oauth Content-Type: text/plain; charset=ISO-8859-1 Subject: [OAUTH-WG] -08 nit X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2010 14:39:35 -0000 Noticed some awkward wording on page 6 - the last sentence of step (a) describing the authorization request, "When cannot be avoided, the client interacts ..." From eran@hueniverse.com Wed Jun 16 07:45:48 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DB6D3A6B3E for ; Wed, 16 Jun 2010 07:45:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.179 X-Spam-Level: X-Spam-Status: No, score=-2.179 tagged_above=-999 required=5 tests=[AWL=0.420, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sWxo4TqOLYuk for ; Wed, 16 Jun 2010 07:45:47 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 353B03A6B3D for ; Wed, 16 Jun 2010 07:45:47 -0700 (PDT) Received: (qmail 29530 invoked from network); 16 Jun 2010 14:45:51 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 16 Jun 2010 14:45:51 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 16 Jun 2010 07:45:51 -0700 From: Eran Hammer-Lahav To: Brian Campbell , oauth Date: Wed, 16 Jun 2010 07:45:43 -0700 Thread-Topic: [OAUTH-WG] -08 nit Thread-Index: AcsNYcPjQ1itaoc2Qcik8DAED5Q7FwAAM6pg Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB6CD7@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] -08 nit X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2010 14:45:48 -0000 Please suggest new text. EHL -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of B= rian Campbell Sent: Wednesday, June 16, 2010 7:39 AM To: oauth Subject: [OAUTH-WG] -08 nit Noticed some awkward wording on page 6 - the last sentence of step (a) desc= ribing the authorization request, "When cannot be avoided, the client inter= acts ..." _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From bcampbell@pingidentity.com Wed Jun 16 07:54:12 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79BE03A691A for ; Wed, 16 Jun 2010 07:54:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.677 X-Spam-Level: X-Spam-Status: No, score=-4.677 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z2GZSTbBUFSm for ; Wed, 16 Jun 2010 07:54:11 -0700 (PDT) Received: from na3sys009aog103.obsmtp.com (na3sys009aog103.obsmtp.com [74.125.149.71]) by core3.amsl.com (Postfix) with SMTP id 76D5C3A68ED for ; Wed, 16 Jun 2010 07:54:11 -0700 (PDT) Received: from source ([209.85.212.44]) by na3sys009aob103.postini.com ([74.125.148.12]) with SMTP ID DSNKTBjlmFaIozz10POHjeAnA6XyJwVCWdGX@postini.com; Wed, 16 Jun 2010 07:54:16 PDT Received: by mail-vw0-f44.google.com with SMTP id 9so10225743vws.17 for ; Wed, 16 Jun 2010 07:54:16 -0700 (PDT) Received: by 10.224.79.38 with SMTP id n38mr4420641qak.204.1276700055505; Wed, 16 Jun 2010 07:54:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.11.1 with HTTP; Wed, 16 Jun 2010 07:53:42 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB6CD7@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB6CD7@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Brian Campbell Date: Wed, 16 Jun 2010 08:53:42 -0600 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Cc: oauth Subject: Re: [OAUTH-WG] -08 nit X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2010 14:54:12 -0000 Sorry, I was hoping you already knew what it was supposed to say and had just omitted a word or two :) Perhaps "When cannot be avoided, ..." should be, "When it cannot be avoided,..." or "When a direct request for authorization cannot be avoided, ..." On Wed, Jun 16, 2010 at 8:45 AM, Eran Hammer-Lahav wrote: > Please suggest new text. > > EHL > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Brian Campbell > Sent: Wednesday, June 16, 2010 7:39 AM > To: oauth > Subject: [OAUTH-WG] -08 nit > > Noticed some awkward wording on page 6 - the last sentence of step (a) describing the authorization request, "When cannot be avoided, the client interacts ..." > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From breno.demedeiros@gmail.com Wed Jun 16 08:17:23 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 256B33A6A63 for ; Wed, 16 Jun 2010 08:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eD7Etw4Ex8FS for ; Wed, 16 Jun 2010 08:17:18 -0700 (PDT) Received: from mail-yw0-f179.google.com (mail-yw0-f179.google.com [209.85.211.179]) by core3.amsl.com (Postfix) with ESMTP id 233663A6801 for ; Wed, 16 Jun 2010 08:17:17 -0700 (PDT) Received: by ywh9 with SMTP id 9so6777100ywh.17 for ; Wed, 16 Jun 2010 08:17:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:received :in-reply-to:references:date:message-id:subject:from:to:cc :content-type; bh=DzHvOhGB5lAkZPflFolbcBxMwPyNQtAu+T08vLbvdsE=; b=DjkRIbWpBiorHhxawxPlmZ0egU6liBJX8/jsexj4x/7Hny5sEc1PsBGTgPDufPCKWr oNu4vMVJcSwqga9wlH9fXRVgh15cjUtYSAa/J54F8j+2c3P3lqGO5MSP8jn00UkRujGD Z/2TjY38ExlOmIYDWujUF0I5gHOrZs0uV3U6I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=hDQmKPK944QcpCG3iGG69KRBagFO+aVtoA9Omu9dacLea5ZVVCsIc7uzbridzZk+hz /5buZX2aDsi3vvNRY9C9VUMgOlStO8t+pNRKGIqii5p2ebWiN4l8bE0wE7NSJYCsl9NI A+oBUiUd/q39YdGGH5KhN46y13BEgEAs2ZQ8Q= MIME-Version: 1.0 Received: by 10.100.246.23 with SMTP id t23mr7332426anh.167.1276701439819; Wed, 16 Jun 2010 08:17:19 -0700 (PDT) Received: by 10.100.225.19 with HTTP; Wed, 16 Jun 2010 08:17:19 -0700 (PDT) Received: by 10.100.225.19 with HTTP; Wed, 16 Jun 2010 08:17:19 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF76BD@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4BFAA6AB.8040809@lodderstedt.net> <4BFC3142.6010506@lodderstedt.net> <4BFC371A.5040109@lodderstedt.net> <4C07F407.4050305@lodderstedt.net> <1275663845.7068.94.camel@localhost.localdomain> <4C09732B.5040800@lodderstedt.net> <4C0F6A9C.2060607@lodderstedt.net> <4C1108C4.9040501@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3EAF7473@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C129387.1090703@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3EAF76BD@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Wed, 16 Jun 2010 08:17:19 -0700 Message-ID: From: Breno To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=00504502ec9acdfe7c0489273763 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] proposal: multiple access tokens from a single authorization flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2010 15:17:23 -0000 --00504502ec9acdfe7c0489273763 Content-Type: text/plain; charset=ISO-8859-1 Alternative proposal. Create a new call for 'dropping privileges' where a client can present a single refresh token and scopes and obtain a new refresh token/access token with defined scopes provided that these scopes were already granted to the original token. The advantage of a separate call is that it has less impact in implementations because it does not modify existing flows. It is also more flexible. For instance it would allow a client too split its privileges into tokens with overlapping scopes for arbitrary requirements around security and functionality of delegating its privileges. On Jun 11, 2010 1:12 PM, "Eran Hammer-Lahav" wrote: I'll let you know when I see the I-D :-) EHL > -----Original Message----- > From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > Sent: F... --00504502ec9acdfe7c0489273763 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

    Alternative proposal. Create a new call for 'dropping privileges'= ; where a client can present a single refresh token and scopes and obtain a= new refresh token/access token with defined scopes provided that these sco= pes were already granted to the original token.

    The advantage of a separate call is that it has less impact in implement= ations because it does not modify existing flows. It is also more flexible.= For instance it would allow a client too split its privileges into tokens = with overlapping scopes for arbitrary requirements around security and func= tionality of delegating its privileges.

    On Jun 11, 2010 1:12 PM, "Eran Hammer-Lah= av" <eran@hueniverse.com= > wrote:

    I'll let you know when I see the I-D :-)

    EHL


    > -----Original Message-----
    &g= t; From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]
    > Sent: F...

    --00504502ec9acdfe7c0489273763-- From eran@hueniverse.com Wed Jun 16 08:33:00 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD4B128C136 for ; Wed, 16 Jun 2010 08:33:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.185 X-Spam-Level: X-Spam-Status: No, score=-2.185 tagged_above=-999 required=5 tests=[AWL=0.413, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oID1xyPX2S+N for ; Wed, 16 Jun 2010 08:32:52 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id EF2FA28C118 for ; Wed, 16 Jun 2010 08:32:30 -0700 (PDT) Received: (qmail 22846 invoked from network); 16 Jun 2010 15:32:20 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 16 Jun 2010 15:32:20 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 16 Jun 2010 08:32:17 -0700 From: Eran Hammer-Lahav To: Breno Date: Wed, 16 Jun 2010 08:32:08 -0700 Thread-Topic: [OAUTH-WG] proposal: multiple access tokens from a single authorization flow Thread-Index: AcsNZwQQ6lEmadkSTHqJUbpyWuK4CgAAe4Yg Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB6D08@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4BFAA6AB.8040809@lodderstedt.net> <4BFC3142.6010506@lodderstedt.net> <4BFC371A.5040109@lodderstedt.net> <4C07F407.4050305@lodderstedt.net> <1275663845.7068.94.camel@localhost.localdomain> <4C09732B.5040800@lodderstedt.net> <4C0F6A9C.2060607@lodderstedt.net> <4C1108C4.9040501@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3EAF7473@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C129387.1090703@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3EAF76BD@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_90C41DD21FB7C64BB94121FBBC2E72343B3EBB6D08P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] proposal: multiple access tokens from a single authorization flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2010 15:33:01 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EBB6D08P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The refresh token represents what the resource owner authorized. The access= token can be a subset of that. The current draft already supports asking f= or less scope than was granted. It doesn't support asking for a new refresh= token with less scope. EHL From: Breno [mailto:breno.demedeiros@gmail.com] Sent: Wednesday, June 16, 2010 8:17 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] proposal: multiple access tokens from a single auth= orization flow Alternative proposal. Create a new call for 'dropping privileges' where a c= lient can present a single refresh token and scopes and obtain a new refres= h token/access token with defined scopes provided that these scopes were al= ready granted to the original token. The advantage of a separate call is that it has less impact in implementati= ons because it does not modify existing flows. It is also more flexible. Fo= r instance it would allow a client too split its privileges into tokens wit= h overlapping scopes for arbitrary requirements around security and functio= nality of delegating its privileges. On Jun 11, 2010 1:12 PM, "Eran Hammer-Lahav" > wrote: I'll let you know when I see the I-D :-) EHL > -----Original Message----- > From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > Sent: F... --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EBB6D08P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    The refre= sh token represents what the resource owner authorized. The access token ca= n be a subset of that. The current draft already supports asking for less s= cope than was granted. It doesn’t support asking for a new refresh to= ken with less scope.

     

    EHL

     

    F= rom: Breno [mailto:breno.demedeiros@gmail.com]
    Sent: Wednesda= y, June 16, 2010 8:17 AM
    To: Eran Hammer-Lahav
    Cc: Tors= ten Lodderstedt; OAuth WG (oauth@ietf.org)
    Subject: Re: [OAUTH-WG= ] proposal: multiple access tokens from a single authorization flow

     

    Alternative prop= osal. Create a new call for 'dropping privileges' where a client can presen= t a single refresh token and scopes and obtain a new refresh token/access t= oken with defined scopes provided that these scopes were already granted to= the original token.

    The advantage of a separate call is t= hat it has less impact in implementations because it does not modify existi= ng flows. It is also more flexible. For instance it would allow a client to= o split its privileges into tokens with overlapping scopes for arbitrary re= quirements around security and functionality of delegating its privileges.<= o:p>

    On Jun 11, 2010 1:12 PM, "Eran Hammer-Lahav" &= lt;eran@hueniverse.com> wrote= :

    I'll let you know when I see the I-D :-)

    EHL


    &= gt; -----Original Message-----
    > From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]
    &g= t; Sent: F...

    = --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EBB6D08P3PW5EX1MB01E_-- From jricher@mitre.org Wed Jun 16 08:50:49 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 733BE3A6B3F for ; Wed, 16 Jun 2010 08:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.651 X-Spam-Level: X-Spam-Status: No, score=-5.651 tagged_above=-999 required=5 tests=[AWL=0.949, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XREKUBt0BYfx for ; Wed, 16 Jun 2010 08:50:42 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id CE7B328C179 for ; Wed, 16 Jun 2010 08:49:49 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o5GFnrr1002120 for ; Wed, 16 Jun 2010 11:49:54 -0400 Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o5GFnrCv002117; Wed, 16 Jun 2010 11:49:53 -0400 Received: from [129.83.50.65] (129.83.50.65) by imchub2.MITRE.ORG (129.83.29.74) with Microsoft SMTP Server id 8.2.254.0; Wed, 16 Jun 2010 11:49:53 -0400 From: Justin Richer To: Eran Hammer-Lahav In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB6D08@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4BFAA6AB.8040809@lodderstedt.net> <4BFC3142.6010506@lodderstedt.net> <4BFC371A.5040109@lodderstedt.net> <4C07F407.4050305@lodderstedt.net> <1275663845.7068.94.camel@localhost.localdomain> <4C09732B.5040800@lodderstedt.net> <4C0F6A9C.2060607@lodderstedt.net> <4C1108C4.9040501@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3EAF7473@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C129387.1090703@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3EAF76BD@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3EBB6D08@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset="UTF-8" Date: Wed, 16 Jun 2010 11:49:52 -0400 Message-ID: <1276703392.10716.82.camel@localhost.localdomain> MIME-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] proposal: multiple access tokens from a single authorization flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2010 15:50:50 -0000 We're looking at using the rescope operation to support redelegation, and in this we wouldn't want to give the second client a refresh token of their own, just an access token that is good for a subset of scopes attached to the original refresh/access combination that the user authorized. I'm not seeing a use case for asking for a new refresh token using an existing refresh token as auth, though. Could you elaborate what this might be? -- Justin On Wed, 2010-06-16 at 11:32 -0400, Eran Hammer-Lahav wrote: > The refresh token represents what the resource owner authorized. The > access token can be a subset of that. The current draft already > supports asking for less scope than was granted. It doesn’t support > asking for a new refresh token with less scope. > > > > EHL > > > > From: Breno [mailto:breno.demedeiros@gmail.com] > Sent: Wednesday, June 16, 2010 8:17 AM > To: Eran Hammer-Lahav > Cc: Torsten Lodderstedt; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] proposal: multiple access tokens from a single > authorization flow > > > > Alternative proposal. Create a new call for 'dropping privileges' > where a client can present a single refresh token and scopes and > obtain a new refresh token/access token with defined scopes provided > that these scopes were already granted to the original token. > > The advantage of a separate call is that it has less impact in > implementations because it does not modify existing flows. It is also > more flexible. For instance it would allow a client too split its > privileges into tokens with overlapping scopes for arbitrary > requirements around security and functionality of delegating its > privileges. > > On Jun 11, 2010 1:12 PM, "Eran Hammer-Lahav" > wrote: > > I'll let you know when I see the I-D :-) > > EHL > > > > -----Original Message----- > > From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > > Sent: F... > From breno.demedeiros@gmail.com Wed Jun 16 09:25:11 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 155B33A6A87 for ; Wed, 16 Jun 2010 09:25:11 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31T1lVSSBLot for ; Wed, 16 Jun 2010 09:25:10 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 812A53A6B47 for ; Wed, 16 Jun 2010 09:25:09 -0700 (PDT) Received: by wya21 with SMTP id 21so2181219wya.31 for ; Wed, 16 Jun 2010 09:25:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=eJx3ljLjEbqJ+/pJ7L5Z9aduhR9Mwm1zQQ/b4DDWTSs=; b=NZZAOfOaQw6JXvT45KMJJETardaL22y/D9omjPdhMkBh8ilO3xxLvXT5eGAaTylIle cQeoP6er4p7is7YQmE97qiytpJRtPMqHO/RjttPOKOUCDVhv7I5GpWG5e08y1Nny5Tmj TjNdF3SjJrjAXVVBCW7HWCzzQBPRO8Xc1Q4pc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=FmR3IdAM2glrPgeQxrgpfNYlDuhGU9Jw7gaGPTWzZdybB1nCTfUGWPuAZZ9AA8v/a6 J/WKfMAAOQ5PirS3k+zeU6wwds1z5BNaw94hflTjHe9QyEQQjQC4w7PrHdoYt1tMCADq TpeO+q2UQfuJQPC/AKv3aTqW63osghk99nPyw= MIME-Version: 1.0 Received: by 10.216.91.81 with SMTP id g59mr5199701wef.83.1276705510258; Wed, 16 Jun 2010 09:25:10 -0700 (PDT) Received: by 10.216.221.164 with HTTP; Wed, 16 Jun 2010 09:25:07 -0700 (PDT) In-Reply-To: <1276703392.10716.82.camel@localhost.localdomain> References: <4BFAA6AB.8040809@lodderstedt.net> <4BFC3142.6010506@lodderstedt.net> <4BFC371A.5040109@lodderstedt.net> <4C07F407.4050305@lodderstedt.net> <1275663845.7068.94.camel@localhost.localdomain> <4C09732B.5040800@lodderstedt.net> <4C0F6A9C.2060607@lodderstedt.net> <4C1108C4.9040501@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3EAF7473@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C129387.1090703@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3EAF76BD@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3EBB6D08@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1276703392.10716.82.camel@localhost.localdomain> Date: Wed, 16 Jun 2010 09:25:07 -0700 Message-ID: From: Breno To: Justin Richer Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] proposal: multiple access tokens from a single authorization flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2010 16:25:11 -0000 On Wed, Jun 16, 2010 at 8:49 AM, Justin Richer wrote: > We're looking at using the rescope operation to support redelegation, > and in this we wouldn't want to give the second client a refresh token > of their own, just an access token that is good for a subset of scopes > attached to the original refresh/access combination that the user > authorized. I'm not seeing a use case for asking for a new refresh token > using an existing refresh token as auth, though. Could you elaborate > what this might be? Looking at the beginning of this thread, there is a proposal to return each scope as a separate token. This is presumably a separation of trust issue that the client would like to enforce. >From a protocol perspective, it would be simpler to exchange the new refresh token for one with fewer privileges instead of requesting/receiving one token per scope. > > =A0-- Justin > > On Wed, 2010-06-16 at 11:32 -0400, Eran Hammer-Lahav wrote: >> The refresh token represents what the resource owner authorized. The >> access token can be a subset of that. The current draft already >> supports asking for less scope than was granted. It doesn=92t support >> asking for a new refresh token with less scope. Well, what about just returning a refresh token with the access token when the requested set of scopes for the access token is stricter? Of course, in the user-agent flow there is no refresh token. >> >> >> >> EHL >> >> >> >> From: Breno [mailto:breno.demedeiros@gmail.com] >> Sent: Wednesday, June 16, 2010 8:17 AM >> To: Eran Hammer-Lahav >> Cc: Torsten Lodderstedt; OAuth WG (oauth@ietf.org) >> Subject: Re: [OAUTH-WG] proposal: multiple access tokens from a single >> authorization flow >> >> >> >> Alternative proposal. Create a new call for 'dropping privileges' >> where a client can present a single refresh token and scopes and >> obtain a new refresh token/access token with defined scopes provided >> that these scopes were already granted to the original token. >> >> The advantage of a separate call is that it has less impact in >> implementations because it does not modify existing flows. It is also >> more flexible. For instance it would allow a client too split its >> privileges into tokens with overlapping scopes for arbitrary >> requirements around security and functionality of delegating its >> privileges. >> >> =A0 =A0 =A0 =A0 On Jun 11, 2010 1:12 PM, "Eran Hammer-Lahav" >> =A0 =A0 =A0 =A0 wrote: >> >> =A0 =A0 =A0 =A0 I'll let you know when I see the I-D :-) >> >> =A0 =A0 =A0 =A0 EHL >> >> >> =A0 =A0 =A0 =A0 > -----Original Message----- >> =A0 =A0 =A0 =A0 > From: Torsten Lodderstedt [mailto:torsten@lodderstedt.= net] >> =A0 =A0 =A0 =A0 > Sent: F... >> > > > --=20 Breno de Medeiros From bcampbell@pingidentity.com Wed Jun 16 13:46:21 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEA923A6948 for ; Wed, 16 Jun 2010 13:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.12 X-Spam-Level: X-Spam-Status: No, score=-4.12 tagged_above=-999 required=5 tests=[AWL=-0.557, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44xN5wogh1zv for ; Wed, 16 Jun 2010 13:46:20 -0700 (PDT) Received: from na3sys009aog108.obsmtp.com (na3sys009aog108.obsmtp.com [74.125.149.199]) by core3.amsl.com (Postfix) with SMTP id 908BE3A67F6 for ; Wed, 16 Jun 2010 13:46:19 -0700 (PDT) Received: from source ([209.85.212.45]) by na3sys009aob108.postini.com ([74.125.148.12]) with SMTP ID DSNKTBk4IGHGlgVCBjiQx60PfHJaFLm1uS4H@postini.com; Wed, 16 Jun 2010 13:46:25 PDT Received: by mail-vw0-f45.google.com with SMTP id 17so3060244vws.32 for ; Wed, 16 Jun 2010 13:46:24 -0700 (PDT) Received: by 10.224.59.100 with SMTP id k36mr4667295qah.139.1276721184195; Wed, 16 Jun 2010 13:46:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.11.1 with HTTP; Wed, 16 Jun 2010 13:45:54 -0700 (PDT) From: Brian Campbell Date: Wed, 16 Jun 2010 14:45:54 -0600 Message-ID: To: oauth Content-Type: multipart/alternative; boundary=00c09fa21a7aa946ce04892bd0ab Subject: [OAUTH-WG] Couple minor things in -08 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2010 20:46:21 -0000 --00c09fa21a7aa946ce04892bd0ab Content-Type: text/plain; charset=ISO-8859-1 I noticed (don't ask how) two tiny little things in the POST body in the example in section 4.1.3. Currently it has: grant_type=assertion&client_id=s6BhdRkqt3&client_secret=diejdsks& assertion_type=urn%3Aoasis%3Anames%sAtc%3ASAML%3A2.0%3Aassertion& assertion=PHNhbWxwOl...[ommited for brevity]...ZT4%3D Omitted has a typo/misspelling and "sA" isn't a valid hex number. I"d suggest the following as an alternative: grant_type=assertion&client_id=s6BhdRkqt3&client_secret=diejdsks& assertion_type=urn%3Aoasis%3Anames%3Atc%3ASAML%3A2.0%3Aassertion& assertion=PHNhbWxwOl...[omitted for brevity]...ZT4%3D Thanks, Brian --00c09fa21a7aa946ce04892bd0ab Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 
    I noticed (don't ask how) two tiny little things=
 in the POST body in the example in section 4.1.3.  Currently it has:
         grant_type=3Dassertion&client_id=3Ds6BhdRkqt3&client_secret=
=3Ddiejdsks&
    

     assertion_type=3Durn%3Aoasis%3Anames%sAtc%3ASAML%3A2.0%3Aassertion&=
;
         assertion=3DPHNhbWxwOl...[ommited for brevity]...ZT4%3D

    Om=
itted has a typo/misspelling and "sA" isn't a valid hex numbe=
r.  I"d suggest the following as an alternative:
    


         grant_type=3Dassertion&client_id=3Ds6BhdRkqt3&client_secre=
t=3Ddiejdsks&
         assertion_type=3Durn%3Aoasis%3Anames%3Atc%3ASAML%=
3A2.0%3Aassertion&
         assertion=3DPHNhbWxwOl...[omitted for brevit=
y]...ZT4%3D
    


    Thanks,
    Brian
    --00c09fa21a7aa946ce04892bd0ab-- From James.H.Manger@team.telstra.com Wed Jun 16 18:54:23 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CD2A3A67C1 for ; Wed, 16 Jun 2010 18:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.588 X-Spam-Level: * X-Spam-Status: No, score=1.588 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_50=0.001, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8WIub+HiIFWa for ; Wed, 16 Jun 2010 18:54:22 -0700 (PDT) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by core3.amsl.com (Postfix) with ESMTP id 12F1A3A6782 for ; Wed, 16 Jun 2010 18:54:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,428,1272808800"; d="scan'208,217";a="4430573" Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipobvi.tcif.telstra.com.au with ESMTP; 17 Jun 2010 11:54:22 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6015"; a="3289178" Received: from wsmsg3752.srv.dir.telstra.com ([172.49.40.173]) by ipcbvi.tcif.telstra.com.au with ESMTP; 17 Jun 2010 11:54:24 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3752.srv.dir.telstra.com ([172.49.40.173]) with mapi; Thu, 17 Jun 2010 11:54:23 +1000 From: "Manger, James H" To: Breno Date: Thu, 17 Jun 2010 11:54:22 +1000 Thread-Topic: [OAUTH-WG] proposal: multiple access tokens from a single authorization flow Thread-Index: AcsNZxjGk+58InGbRoG3nbFiIrbeNwASDXxA Message-ID: <255B9BB34FB7D647A506DC292726F6E1126411A9EB@WSMSG3153V.srv.dir.telstra.com> References: <4BFAA6AB.8040809@lodderstedt.net> <4BFC3142.6010506@lodderstedt.net> <4BFC371A.5040109@lodderstedt.net> <4C07F407.4050305@lodderstedt.net> <1275663845.7068.94.camel@localhost.localdomain> <4C09732B.5040800@lodderstedt.net> <4C0F6A9C.2060607@lodderstedt.net> <4C1108C4.9040501@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3EAF7473@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C129387.1090703@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3EAF76BD@P3PW5EX1MB01.EX1.SECURESERVER.NET> 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: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E1126411A9EBWSMSG3153Vsrv_" MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] proposal: multiple access tokens from a single authorization flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2010 01:54:23 -0000 --_000_255B9BB34FB7D647A506DC292726F6E1126411A9EBWSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QnJlbm8sDQoNCg0KDQo+IEFsdGVybmF0aXZlIHByb3Bvc2FsLiBDcmVhdGUgYSBuZXcgY2FsbCBm b3IgJ2Ryb3BwaW5nIHByaXZpbGVnZXMnIHdoZXJlIGEgY2xpZW50IGNhbiBwcmVzZW50IGEgc2lu Z2xlIHJlZnJlc2ggdG9rZW4gYW5kIHNjb3BlcyBhbmQgb2J0YWluIGEgbmV3IHJlZnJlc2ggdG9r ZW4vYWNjZXNzIHRva2VuIHdpdGggZGVmaW5lZCBzY29wZXMgcHJvdmlkZWQgdGhhdCB0aGVzZSBz Y29wZXMgd2VyZSBhbHJlYWR5IGdyYW50ZWQgdG8gdGhlIG9yaWdpbmFsIHRva2VuLg0KDQo+IFRo ZSBhZHZhbnRhZ2Ugb2YgYSBzZXBhcmF0ZSBjYWxsIGlzIHRoYXQgaXQgaGFzIGxlc3MgaW1wYWN0 IGluIGltcGxlbWVudGF0aW9ucyBiZWNhdXNlIGl0IGRvZXMgbm90IG1vZGlmeSBleGlzdGluZyBm bG93cy4gSXQgaXMgYWxzbyBtb3JlIGZsZXhpYmxlLiBGb3IgaW5zdGFuY2UgaXQgd291bGQgYWxs b3cgYSBjbGllbnQgdG9vIHNwbGl0IGl0cyBwcml2aWxlZ2VzIGludG8gdG9rZW5zIHdpdGggb3Zl cmxhcHBpbmcgc2NvcGVzIGZvciBhcmJpdHJhcnkgcmVxdWlyZW1lbnRzIGFyb3VuZCBzZWN1cml0 eSBhbmQgZnVuY3Rpb25hbGl0eSBvZiBkZWxlZ2F0aW5nIGl0cyBwcml2aWxlZ2VzLg0KDQoNCg0K VGhpcyBhbHRlcm5hdGl2ZSAoZHJvcHBpbmcgcHJpdmlsZWdlcykgY291bGQgd29yayBmb3IgY2xp ZW50cyB0aGF0IGtub3cgZXZlcnl0aGluZyBhYm91dCBhIHNlcnZpY2U6IHdoaWNoIHNjb3BlcyBh cmUgbmVjZXNzYXJ5ICYgc3VmZmljaWVudCBmb3IgZWFjaCBjYWxsLCBhbmQgdGhhdCDigJhkcm9w cGluZyBwcml2aWxlZ2Vz4oCZIGlzIHN1cHBvcnRlZC4gSXQgcmVxdWlyZXMgbG90cyBvZiBzZXJ2 aWNlLXNwZWNpZmljIGtub3dsZWRnZSBpbiB0aGUgY2xpZW50LCBhbmQvb3Igc29tZSByZWFzb25h Ymx5IHNvcGhpc3RpY2F0ZWQgZGlzY292ZXJ5ICh3aGljaCBpcyBzbyBmYXIgdW5kZWZpbmVkLCB1 bnRyaWVkLCBhbmQgbm90IG9idmlvdXMgaG93IGl0IHNob3VsZCBiZSBkb25lKS4gQSBzZXJ2aWNl IHRoYXQgcmVxdWlyZXMgZHJvcHBlZCBwcml2aWxlZ2VzIGNhbiBvbmx5IHJlamVjdCBjYWxscyB0 aGF0IHVzZSBmdWxsIHRva2VucyAoYW5kIGhvcGUgdGhhdCBoYXNu4oCZdCBhbHJlYWR5IGNvbXBy b21pc2VkIHNlY3VyaXR5KSwgYW5kIGhvcGUgdGhhdCBjbGllbnRzIGNhbiB0aGVuIGRpc2NvdmVy IGhvdyB0byBkcm9wIHByaXZpbGVnZXMgYW5kIHdoYXQgdG8gZHJvcCB0aGVtIHRvIChlZmZpY2ll bnRseSAmIHNpbXBseSkuDQoNCg0KDQpSZXR1cm5pbmcgbXVsdGlwbGUgdG9rZW5zLCBpbiBjb250 cmFzdCwgZW5hYmxlcyBhIHNlcnZlciB0byBzYXkgdXNlIHRoZXNlICjigJxwcmUtZHJvcHBlZOKA nSkgdG9rZW5zIGF0IHRoZXNlIEFQSSBlbmRwb2ludHMuIE5vIGV4dHJhIGRpc2NvdmVyeSBpcyBy ZXF1aXJlZC4gTm8gZXh0cmEgc2VydmljZS1zcGVjaWZpYyBrbm93bGVkZ2UgaXMgcmVxdWlyZWQg b2YgY2xpZW50cy4NCg0KDQoNCuKAmERyb3BwaW5nIHByaXZpbGVnZXPigJkgaXMgbmljZSBhZGRp dGlvbmFsIGZ1bmN0aW9uYWxpdHksIGJ1dCBJIGRvbuKAmXQgdGhpbmsgaXQgaXMgYSBnb29kIGFs dGVybmF0aXZlIHRvIHJldHVybmluZyBtdWx0aXBsZSB0b2tlbnMuDQoNCg0KDQotLQ0KDQpKYW1l cyBNYW5nZXINCg0K --_000_255B9BB34FB7D647A506DC292726F6E1126411A9EBWSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl Pg0KPCEtLQ0KIC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCiBAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0 IDMgMiA0O30NCiAvKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KIHAuTXNvTm9ybWFsLCBsaS5Nc29O b3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwi c2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0 ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdo dDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0K CWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlm Ijt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgU2Vj dGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIu MHB0IDcyLjBwdDt9DQpkaXYuU2VjdGlvbjENCgl7cGFnZTpTZWN0aW9uMTt9DQotLT4NCjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KIDxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCiAgPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQogPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tQVUiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+QnJlbm8sPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0K Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdCI+Jmd0OyBBbHRlcm5hdGl2ZSBwcm9wb3NhbC4gQ3JlYXRlIGEgbmV3 IGNhbGwgZm9yICdkcm9wcGluZyBwcml2aWxlZ2VzJyB3aGVyZSBhIGNsaWVudCBjYW4gcHJlc2Vu dCBhIHNpbmdsZSByZWZyZXNoIHRva2VuIGFuZCBzY29wZXMgYW5kIG9idGFpbiBhIG5ldyByZWZy ZXNoIHRva2VuL2FjY2VzcyB0b2tlbiB3aXRoIGRlZmluZWQgc2NvcGVzIHByb3ZpZGVkIHRoYXQg dGhlc2Ugc2NvcGVzIHdlcmUgYWxyZWFkeQ0KIGdyYW50ZWQgdG8gdGhlIG9yaWdpbmFsIHRva2Vu LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+Jmd0OyBUaGUgYWR2YW50YWdlIG9mIGEgc2VwYXJhdGUgY2FsbCBpcyB0aGF0IGl0 IGhhcyBsZXNzIGltcGFjdCBpbiBpbXBsZW1lbnRhdGlvbnMgYmVjYXVzZSBpdCBkb2VzIG5vdCBt b2RpZnkgZXhpc3RpbmcgZmxvd3MuIEl0IGlzIGFsc28gbW9yZSBmbGV4aWJsZS4gRm9yIGluc3Rh bmNlIGl0IHdvdWxkIGFsbG93IGEgY2xpZW50IHRvbyBzcGxpdCBpdHMgcHJpdmlsZWdlcw0KIGlu dG8gdG9rZW5zIHdpdGggb3ZlcmxhcHBpbmcgc2NvcGVzIGZvciBhcmJpdHJhcnkgcmVxdWlyZW1l bnRzIGFyb3VuZCBzZWN1cml0eSBhbmQgZnVuY3Rpb25hbGl0eSBvZiBkZWxlZ2F0aW5nIGl0cyBw cml2aWxlZ2VzLjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xv cjojMUY0OTdEIj5UaGlzIGFsdGVybmF0aXZlIChkcm9wcGluZyBwcml2aWxlZ2VzKSBjb3VsZCB3 b3JrIGZvciBjbGllbnRzIHRoYXQga25vdyBldmVyeXRoaW5nIGFib3V0IGEgc2VydmljZTogd2hp Y2ggc2NvcGVzIGFyZSBuZWNlc3NhcnkgJmFtcDsgc3VmZmljaWVudCBmb3IgZWFjaCBjYWxsLA0K IGFuZCB0aGF0IOKAmGRyb3BwaW5nIHByaXZpbGVnZXPigJkgaXMgc3VwcG9ydGVkLiBJdCByZXF1 aXJlcyBsb3RzIG9mIHNlcnZpY2Utc3BlY2lmaWMga25vd2xlZGdlIGluIHRoZSBjbGllbnQsIGFu ZC9vciBzb21lIHJlYXNvbmFibHkgc29waGlzdGljYXRlZCBkaXNjb3ZlcnkgKHdoaWNoIGlzIHNv IGZhciB1bmRlZmluZWQsIHVudHJpZWQsIGFuZCBub3Qgb2J2aW91cyBob3cgaXQgc2hvdWxkIGJl IGRvbmUpLiBBIHNlcnZpY2UgdGhhdA0KPGI+cmVxdWlyZXM8L2I+IGRyb3BwZWQgcHJpdmlsZWdl cyBjYW4gb25seSByZWplY3QgY2FsbHMgdGhhdCB1c2UgZnVsbCB0b2tlbnMgKGFuZCBob3BlIHRo YXQgaGFzbuKAmXQgYWxyZWFkeSBjb21wcm9taXNlZCBzZWN1cml0eSksIGFuZCBob3BlIHRoYXQg Y2xpZW50cyBjYW4gdGhlbiBkaXNjb3ZlciBob3cgdG8gZHJvcCBwcml2aWxlZ2VzIGFuZCB3aGF0 IHRvIGRyb3AgdGhlbSB0byAoZWZmaWNpZW50bHkgJmFtcDsgc2ltcGx5KS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7DQpjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdE Ij5SZXR1cm5pbmcgbXVsdGlwbGUgdG9rZW5zLCBpbiBjb250cmFzdCwgZW5hYmxlcyBhIHNlcnZl ciB0byBzYXkgdXNlIHRoZXNlICjigJxwcmUtZHJvcHBlZOKAnSkgdG9rZW5zIGF0IHRoZXNlIEFQ SSBlbmRwb2ludHMuIE5vIGV4dHJhIGRpc2NvdmVyeSBpcyByZXF1aXJlZC4gTm8NCiBleHRyYSBz ZXJ2aWNlLXNwZWNpZmljIGtub3dsZWRnZSBpcyByZXF1aXJlZCBvZiBjbGllbnRzLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMx RjQ5N0QiPuKAmERyb3BwaW5nIHByaXZpbGVnZXPigJkgaXMgbmljZSBhZGRpdGlvbmFsIGZ1bmN0 aW9uYWxpdHksIGJ1dCBJIGRvbuKAmXQgdGhpbmsgaXQgaXMgYSBnb29kIGFsdGVybmF0aXZlIHRv IHJldHVybmluZyBtdWx0aXBsZSB0b2tlbnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+LS0NCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OzsNCmNvbG9yOiMxRjQ5N0QiPkphbWVzIE1hbmdlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_255B9BB34FB7D647A506DC292726F6E1126411A9EBWSMSG3153Vsrv_-- From eran@hueniverse.com Wed Jun 16 18:56:37 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1992D28B797 for ; Wed, 16 Jun 2010 18:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.262 X-Spam-Level: X-Spam-Status: No, score=-1.262 tagged_above=-999 required=5 tests=[AWL=-0.523, BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QaVaE+pbwE-D for ; Wed, 16 Jun 2010 18:56:36 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 141133A6784 for ; Wed, 16 Jun 2010 18:56:36 -0700 (PDT) Received: (qmail 860 invoked from network); 17 Jun 2010 01:56:40 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 17 Jun 2010 01:56:40 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 16 Jun 2010 18:56:40 -0700 From: Eran Hammer-Lahav To: "Manger, James H" , Breno Date: Wed, 16 Jun 2010 18:56:33 -0700 Thread-Topic: [OAUTH-WG] proposal: multiple access tokens from a single authorization flow Thread-Index: AcsNZxjGk+58InGbRoG3nbFiIrbeNwASDXxAAAQ2grA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB6F2B@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4BFAA6AB.8040809@lodderstedt.net> <4BFC3142.6010506@lodderstedt.net> <4BFC371A.5040109@lodderstedt.net> <4C07F407.4050305@lodderstedt.net> <1275663845.7068.94.camel@localhost.localdomain> <4C09732B.5040800@lodderstedt.net> <4C0F6A9C.2060607@lodderstedt.net> <4C1108C4.9040501@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3EAF7473@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C129387.1090703@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3EAF76BD@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1126411A9EB@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1126411A9EB@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_90C41DD21FB7C64BB94121FBBC2E72343B3EBB6F2BP3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] proposal: multiple access tokens from a single authorization flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2010 01:56:37 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EBB6F2BP3PW5EX1MB01E_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyB1c2UgY2FzZSBzZWVtcyB0byBoYXZlIHNvbWUgc3VwcG9ydCBmb3IgYW4gZXh0ZW5zaW9u LCBidXQgZW5vdWdoIHJlc2lzdGFuY2UgZm9yIGJlaW5nIGFkZGVkIHRvIGNvcmUuIEkgc3VnZ2Vz dCB0aG9zZSB3aG8gY2FyZSBhYm91dCB0aGlzIHdyaXRlIGEgcHJvcG9zYWwgYXMgYW4gSS1ELg0K DQpFSEwNCg0KRnJvbTogb2F1dGgtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm9hdXRoLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNYW5nZXIsIEphbWVzIEgNClNlbnQ6IFdlZG5lc2Rh eSwgSnVuZSAxNiwgMjAxMCA2OjU0IFBNDQpUbzogQnJlbm8NCkNjOiBPQXV0aCBXRyAob2F1dGhA aWV0Zi5vcmcpDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBwcm9wb3NhbDogbXVsdGlwbGUgYWNj ZXNzIHRva2VucyBmcm9tIGEgc2luZ2xlIGF1dGhvcml6YXRpb24gZmxvdw0KDQpCcmVubywNCg0K DQo+IEFsdGVybmF0aXZlIHByb3Bvc2FsLiBDcmVhdGUgYSBuZXcgY2FsbCBmb3IgJ2Ryb3BwaW5n IHByaXZpbGVnZXMnIHdoZXJlIGEgY2xpZW50IGNhbiBwcmVzZW50IGEgc2luZ2xlIHJlZnJlc2gg dG9rZW4gYW5kIHNjb3BlcyBhbmQgb2J0YWluIGEgbmV3IHJlZnJlc2ggdG9rZW4vYWNjZXNzIHRv a2VuIHdpdGggZGVmaW5lZCBzY29wZXMgcHJvdmlkZWQgdGhhdCB0aGVzZSBzY29wZXMgd2VyZSBh bHJlYWR5IGdyYW50ZWQgdG8gdGhlIG9yaWdpbmFsIHRva2VuLg0KPiBUaGUgYWR2YW50YWdlIG9m IGEgc2VwYXJhdGUgY2FsbCBpcyB0aGF0IGl0IGhhcyBsZXNzIGltcGFjdCBpbiBpbXBsZW1lbnRh dGlvbnMgYmVjYXVzZSBpdCBkb2VzIG5vdCBtb2RpZnkgZXhpc3RpbmcgZmxvd3MuIEl0IGlzIGFs c28gbW9yZSBmbGV4aWJsZS4gRm9yIGluc3RhbmNlIGl0IHdvdWxkIGFsbG93IGEgY2xpZW50IHRv byBzcGxpdCBpdHMgcHJpdmlsZWdlcyBpbnRvIHRva2VucyB3aXRoIG92ZXJsYXBwaW5nIHNjb3Bl cyBmb3IgYXJiaXRyYXJ5IHJlcXVpcmVtZW50cyBhcm91bmQgc2VjdXJpdHkgYW5kIGZ1bmN0aW9u YWxpdHkgb2YgZGVsZWdhdGluZyBpdHMgcHJpdmlsZWdlcy4NCg0KVGhpcyBhbHRlcm5hdGl2ZSAo ZHJvcHBpbmcgcHJpdmlsZWdlcykgY291bGQgd29yayBmb3IgY2xpZW50cyB0aGF0IGtub3cgZXZl cnl0aGluZyBhYm91dCBhIHNlcnZpY2U6IHdoaWNoIHNjb3BlcyBhcmUgbmVjZXNzYXJ5ICYgc3Vm ZmljaWVudCBmb3IgZWFjaCBjYWxsLCBhbmQgdGhhdCDigJhkcm9wcGluZyBwcml2aWxlZ2Vz4oCZ IGlzIHN1cHBvcnRlZC4gSXQgcmVxdWlyZXMgbG90cyBvZiBzZXJ2aWNlLXNwZWNpZmljIGtub3ds ZWRnZSBpbiB0aGUgY2xpZW50LCBhbmQvb3Igc29tZSByZWFzb25hYmx5IHNvcGhpc3RpY2F0ZWQg ZGlzY292ZXJ5ICh3aGljaCBpcyBzbyBmYXIgdW5kZWZpbmVkLCB1bnRyaWVkLCBhbmQgbm90IG9i dmlvdXMgaG93IGl0IHNob3VsZCBiZSBkb25lKS4gQSBzZXJ2aWNlIHRoYXQgcmVxdWlyZXMgZHJv cHBlZCBwcml2aWxlZ2VzIGNhbiBvbmx5IHJlamVjdCBjYWxscyB0aGF0IHVzZSBmdWxsIHRva2Vu cyAoYW5kIGhvcGUgdGhhdCBoYXNu4oCZdCBhbHJlYWR5IGNvbXByb21pc2VkIHNlY3VyaXR5KSwg YW5kIGhvcGUgdGhhdCBjbGllbnRzIGNhbiB0aGVuIGRpc2NvdmVyIGhvdyB0byBkcm9wIHByaXZp bGVnZXMgYW5kIHdoYXQgdG8gZHJvcCB0aGVtIHRvIChlZmZpY2llbnRseSAmIHNpbXBseSkuDQoN ClJldHVybmluZyBtdWx0aXBsZSB0b2tlbnMsIGluIGNvbnRyYXN0LCBlbmFibGVzIGEgc2VydmVy IHRvIHNheSB1c2UgdGhlc2UgKOKAnHByZS1kcm9wcGVk4oCdKSB0b2tlbnMgYXQgdGhlc2UgQVBJ IGVuZHBvaW50cy4gTm8gZXh0cmEgZGlzY292ZXJ5IGlzIHJlcXVpcmVkLiBObyBleHRyYSBzZXJ2 aWNlLXNwZWNpZmljIGtub3dsZWRnZSBpcyByZXF1aXJlZCBvZiBjbGllbnRzLg0KDQrigJhEcm9w cGluZyBwcml2aWxlZ2Vz4oCZIGlzIG5pY2UgYWRkaXRpb25hbCBmdW5jdGlvbmFsaXR5LCBidXQg SSBkb27igJl0IHRoaW5rIGl0IGlzIGEgZ29vZCBhbHRlcm5hdGl2ZSB0byByZXR1cm5pbmcgbXVs dGlwbGUgdG9rZW5zLg0KDQotLQ0KSmFtZXMgTWFuZ2VyDQo= --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EBB6F2BP3PW5EX1MB01E_ 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 b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1h cmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVhZD48Ym9keSBsYW5nPUVO LVVTIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+VGhpcyB1c2UgY2FzZSBzZWVtcyB0 byBoYXZlIHNvbWUgc3VwcG9ydCBmb3IgYW4gZXh0ZW5zaW9uLCBidXQgZW5vdWdoIHJlc2lzdGFu Y2UgZm9yIGJlaW5nIGFkZGVkIHRvIGNvcmUuIEkgc3VnZ2VzdCB0aG9zZSB3aG8gY2FyZSBhYm91 dCB0aGlzIHdyaXRlIGEgcHJvcG9zYWwgYXMgYW4gSS1ELjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+RUhM PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxkaXYgc3R5bGU9J2JvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAw aW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy aWYiJz4gb2F1dGgtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5v cmddIDxiPk9uIEJlaGFsZiBPZiA8L2I+TWFuZ2VyLCBKYW1lcyBIPGJyPjxiPlNlbnQ6PC9iPiBX ZWRuZXNkYXksIEp1bmUgMTYsIDIwMTAgNjo1NCBQTTxicj48Yj5Ubzo8L2I+IEJyZW5vPGJyPjxi PkNjOjwvYj4gT0F1dGggV0cgKG9hdXRoQGlldGYub3JnKTxicj48Yj5TdWJqZWN0OjwvYj4gUmU6 IFtPQVVUSC1XR10gcHJvcG9zYWw6IG11bHRpcGxlIGFjY2VzcyB0b2tlbnMgZnJvbSBhIHNpbmds ZSBhdXRob3JpemF0aW9uIGZsb3c8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBsYW5nPUVOLUFVIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+QnJlbm8sPG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUFVIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48 c3BhbiBsYW5nPUVOLUFVPiZndDsgQWx0ZXJuYXRpdmUgcHJvcG9zYWwuIENyZWF0ZSBhIG5ldyBj YWxsIGZvciAnZHJvcHBpbmcgcHJpdmlsZWdlcycgd2hlcmUgYSBjbGllbnQgY2FuIHByZXNlbnQg YSBzaW5nbGUgcmVmcmVzaCB0b2tlbiBhbmQgc2NvcGVzIGFuZCBvYnRhaW4gYSBuZXcgcmVmcmVz aCB0b2tlbi9hY2Nlc3MgdG9rZW4gd2l0aCBkZWZpbmVkIHNjb3BlcyBwcm92aWRlZCB0aGF0IHRo ZXNlIHNjb3BlcyB3ZXJlIGFscmVhZHkgZ3JhbnRlZCB0byB0aGUgb3JpZ2luYWwgdG9rZW4uPG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6 LjVpbic+PHNwYW4gbGFuZz1FTi1BVT4mZ3Q7IFRoZSBhZHZhbnRhZ2Ugb2YgYSBzZXBhcmF0ZSBj YWxsIGlzIHRoYXQgaXQgaGFzIGxlc3MgaW1wYWN0IGluIGltcGxlbWVudGF0aW9ucyBiZWNhdXNl IGl0IGRvZXMgbm90IG1vZGlmeSBleGlzdGluZyBmbG93cy4gSXQgaXMgYWxzbyBtb3JlIGZsZXhp YmxlLiBGb3IgaW5zdGFuY2UgaXQgd291bGQgYWxsb3cgYSBjbGllbnQgdG9vIHNwbGl0IGl0cyBw cml2aWxlZ2VzIGludG8gdG9rZW5zIHdpdGggb3ZlcmxhcHBpbmcgc2NvcGVzIGZvciBhcmJpdHJh cnkgcmVxdWlyZW1lbnRzIGFyb3VuZCBzZWN1cml0eSBhbmQgZnVuY3Rpb25hbGl0eSBvZiBkZWxl Z2F0aW5nIGl0cyBwcml2aWxlZ2VzLjwvc3Bhbj48c3BhbiBsYW5nPUVOLUFVIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFG NDk3RCc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5n PUVOLUFVIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUFVIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+VGhpcyBhbHRl cm5hdGl2ZSAoZHJvcHBpbmcgcHJpdmlsZWdlcykgY291bGQgd29yayBmb3IgY2xpZW50cyB0aGF0 IGtub3cgZXZlcnl0aGluZyBhYm91dCBhIHNlcnZpY2U6IHdoaWNoIHNjb3BlcyBhcmUgbmVjZXNz YXJ5ICZhbXA7IHN1ZmZpY2llbnQgZm9yIGVhY2ggY2FsbCwgYW5kIHRoYXQg4oCYZHJvcHBpbmcg cHJpdmlsZWdlc+KAmSBpcyBzdXBwb3J0ZWQuIEl0IHJlcXVpcmVzIGxvdHMgb2Ygc2VydmljZS1z cGVjaWZpYyBrbm93bGVkZ2UgaW4gdGhlIGNsaWVudCwgYW5kL29yIHNvbWUgcmVhc29uYWJseSBz b3BoaXN0aWNhdGVkIGRpc2NvdmVyeSAod2hpY2ggaXMgc28gZmFyIHVuZGVmaW5lZCwgdW50cmll ZCwgYW5kIG5vdCBvYnZpb3VzIGhvdyBpdCBzaG91bGQgYmUgZG9uZSkuIEEgc2VydmljZSB0aGF0 IDxiPnJlcXVpcmVzPC9iPiBkcm9wcGVkIHByaXZpbGVnZXMgY2FuIG9ubHkgcmVqZWN0IGNhbGxz IHRoYXQgdXNlIGZ1bGwgdG9rZW5zIChhbmQgaG9wZSB0aGF0IGhhc27igJl0IGFscmVhZHkgY29t cHJvbWlzZWQgc2VjdXJpdHkpLCBhbmQgaG9wZSB0aGF0IGNsaWVudHMgY2FuIHRoZW4gZGlzY292 ZXIgaG93IHRvIGRyb3AgcHJpdmlsZWdlcyBhbmQgd2hhdCB0byBkcm9wIHRoZW0gdG8gKGVmZmlj aWVudGx5ICZhbXA7IHNpbXBseSkuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBsYW5nPUVOLUFVIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUFVIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFG NDk3RCc+UmV0dXJuaW5nIG11bHRpcGxlIHRva2VucywgaW4gY29udHJhc3QsIGVuYWJsZXMgYSBz ZXJ2ZXIgdG8gc2F5IHVzZSB0aGVzZSAo4oCccHJlLWRyb3BwZWTigJ0pIHRva2VucyBhdCB0aGVz ZSBBUEkgZW5kcG9pbnRzLiBObyBleHRyYSBkaXNjb3ZlcnkgaXMgcmVxdWlyZWQuIE5vIGV4dHJh IHNlcnZpY2Utc3BlY2lmaWMga25vd2xlZGdlIGlzIHJlcXVpcmVkIG9mIGNsaWVudHMuPG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUFVIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBsYW5nPUVOLUFVIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+4oCYRHJvcHBpbmcgcHJpdmlsZWdl c+KAmSBpcyBuaWNlIGFkZGl0aW9uYWwgZnVuY3Rpb25hbGl0eSwgYnV0IEkgZG9u4oCZdCB0aGlu ayBpdCBpcyBhIGdvb2QgYWx0ZXJuYXRpdmUgdG8gcmV0dXJuaW5nIG11bHRpcGxlIHRva2Vucy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tQVUg c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIGxhbmc9RU4tQVUgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4tLSA8bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tQVUgc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0 OTdEJz5KYW1lcyBNYW5nZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9ib2R5PjwvaHRt bD4= --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EBB6F2BP3PW5EX1MB01E_-- From eran@hueniverse.com Wed Jun 16 23:05:41 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E57E53A67B7 for ; Wed, 16 Jun 2010 23:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.584 X-Spam-Level: X-Spam-Status: No, score=-0.584 tagged_above=-999 required=5 tests=[AWL=-1.185, BAYES_50=0.001, J_CHICKENPOX_53=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HINjXk0AXsuc for ; Wed, 16 Jun 2010 23:05:40 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id B9A323A67B6 for ; Wed, 16 Jun 2010 23:05:40 -0700 (PDT) Received: (qmail 31160 invoked from network); 17 Jun 2010 06:05:44 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 17 Jun 2010 06:05:43 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 16 Jun 2010 23:05:43 -0700 From: Eran Hammer-Lahav To: "OAuth WG (oauth@ietf.org)" Date: Wed, 16 Jun 2010 23:05:36 -0700 Thread-Topic: Proposal: simplification of the end-user authorization endpoint Thread-Index: AcsN3Gk6tEyMBLaSRtS1WphoToVpYw== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB6F56@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: [OAUTH-WG] Proposal: simplification of the end-user authorization endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2010 06:05:42 -0000 This is a joint proposal from David Recordon and me: ** Background: =A0 The latest draft (-08) unified the=A0 web-server and user-agent client type= s into a single authorization request format. This was done because once we= added an optional authorization code to the user-agent response, it became= almost identical to the web-server call. The two remaining differences: =A0 - The web-server response must not return an access token, only an authoriz= ation code. - The web-server response uses the URI query while the user-agent response = uses the URI fragment. =A0 The way in which the client indicates which response is requests is by usin= g the 'type' parameter with either 'web_server' or 'user-agent'. This is al= l documented in: =A0 http://tools.ietf.org/html/draft-ietf-oauth-v2-08#section-3 =A0 Many (if not most) services are likely to implement both the user-agent and= web-server types (based on existing deployment and the requirements expres= sed by many of the participants). The web-server flow requires client authentication (client secret) in order= to obtain an access token. It also enables the registration of a redirecti= on URI. When using the user-agent flow, the client does not authenticate with the a= uthorization server (at all) to obtain an access token. However, it does ne= ed to authenticate if it wants to exchange the optional authorization code = for (another) access token. =A0 The authorization server has a few options when managing the security and t= rust implications of each request type: =A0 - Require that the client provide its type when registering with the servic= e - if the authorization server knows the client type, it can limit that cl= ient to only make requests suitable for that client type, as well as only i= ssue a client secret when the client is not a user-agent. =A0 - Issue different access tokens based on the security context in which they= are obtained - access tokens issued using the direct user-agent request wi= ll provide less access (shorter duration, read only, etc.) than an access t= oken obtained using the web-server request type. =A0 The first approach is problematic for complex clients requesting both an ac= cess token and authorization code using the user-agent request type. In thi= s case, the authorization server is issuing two access tokens, each using a= different level of security. It is means that one developer will need to o= btain a different client identifier for the same application across differe= nt platforms. =A0 The current separation between the two request types (user-agent and web-se= rver) seems artificial. This is especially true when considering the use ca= ses for native applications and the applicability of both options. At the e= nd, the client type doesn't matter. What matters is whether the access toke= n is issued with or without client authentication (and whether that authent= ication can be trusted, which goes beyond what the protocol can provide). =A0 ** Proposal: =A0 Replace the 'type' parameter with a new parameter called 'request' (working= title) which can take one of three values: 'token', 'code', or 'token_and_= code'. This will allow the client (regardless of its type) to explicitly sa= y what it wants. The response is sent as follows: - If the client requests an access token, all the response parameters (incl= uding errors) are included in the fragment=A0(same as the user-agent flow t= oday). - If the client requests an authorization code, all the parameters are incl= uded in the query (same as the web server flow today). - If the client requests both, the 'code', 'status', and 'error' are includ= ed in the query while everything else is included in the fragment=A0(explai= ned in the example below). The authorization server issues the appropriate user warnings and access to= ken based on the authentication level obtained. For example, when issuing a= n access token the server has to consider: =A0 - Was the client authenticated using a secret or other means? - Was the redirection URI registered? - Is this a known client (white list) from a trusted third party (they are = known not to leak their secrets)? =A0 =A0The advantage of this approach is that it more clearly frames the securi= ty context of issuing tokens. It puts native applications at the same level= as the web-server and user-agent clients (no one gets a special parameter = value). ** Examples: To help show the similarities, here are three example requests and response= s: - Token only (aka user-agent): =A0=A0https://server.example.com/oauth/authorize? =A0=A0 =A0client_id=3D...& =A0=A0 =A0redirect_uri=3Dhttp://client.example.com/callback& =A0=A0 =A0request=3Dtoken& =A0=A0 =A0state=3Dfoo =A0=A0http://client.example.com/callback#access_token=3D...&expires_in=3D..= .&state=3Dfoo In this case all of the parameters are in relation to the token and thus co= nsumed directly by the JavaScript, desktop app, etc. - Code only (aka web-server): =A0=A0https://server.example.com/oauth/authorize? =A0=A0 =A0client_id=3D...& =A0=A0 =A0redirect_uri=3Dhttp://client.example.com/callback& =A0=A0 =A0request=3Dcode& =A0=A0 =A0state=3Dfoo =A0=A0http://client.example.com/callback.php?code=3D...&state=3Dfoo In this case there isn't an access token and all of the parameters are cons= umed by the client's server to be traded for an access token via a HTTPS re= quest to the AS. - Token and code: https://server.example.com/oauth/authorize? =A0=A0client_id=3D...& =A0=A0redirect_uri=3Dhttp://client.example.com/callback& =A0=A0request=3Dtoken_and_code& =A0=A0state=3Dfoo http://client.example.com/callback.php?code=3D...&state=3Dfoo#access_token= =3D...&expires_in=3D... In this case the parameters are consumer both by the JavaScript and the cli= ent's server. The parameters about the access token are in the fragment. Th= e code is a query parameter so that the server can access it. state and err= or are useful to both and thus are query parameters which can be accessed b= y the JavaScript and the server. =A0 From recordond@gmail.com Wed Jun 16 23:12:49 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC2F83A6802 for ; Wed, 16 Jun 2010 23:12:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.493 X-Spam-Level: X-Spam-Status: No, score=-0.493 tagged_above=-999 required=5 tests=[AWL=-1.094, BAYES_50=0.001, J_CHICKENPOX_53=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7lHKCTYnd6Z for ; Wed, 16 Jun 2010 23:12:48 -0700 (PDT) Received: from mail-yw0-f194.google.com (mail-yw0-f194.google.com [209.85.211.194]) by core3.amsl.com (Postfix) with ESMTP id 9FADC3A67B6 for ; Wed, 16 Jun 2010 23:12:48 -0700 (PDT) Received: by ywh32 with SMTP id 32so4925989ywh.5 for ; Wed, 16 Jun 2010 23:12:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=QeWbynEtAM34/lQPtWRcPE+pznn32e7idLnrkayhnfI=; b=eVOOq2ahWbsiDPyyfTbuRIjLCdk61RlncczRoqwPRMGGc4/l9cJJ5gRpWO7Are1pvX endtPdqYKEjoiEXJQMoq7/7A/ZM0bunMWXTOUqVa/EYocLPcd8yVsmOY3LxaOP5WcPCM QCi4kINrh4W/4DHTzjg9TuDU9in3Xy5FoBfQE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=YQcpXfNv76/kpkI8Az/wClH0mWHSplMYvwY6adCfTtSRqskAOi7ptexvO87iQxSZoA in05miDdrU23Yv3yAeuXlZOYPW3JeWW4w4d2dyDcaUtXL6GbXNJJerEokDBelawwSdhF WF4/qCClJD3UHJ/Fo6YIeLVFVbP5mdN3ZZFmM= MIME-Version: 1.0 Received: by 10.231.174.201 with SMTP id u9mr11143450ibz.17.1276755170822; Wed, 16 Jun 2010 23:12:50 -0700 (PDT) Received: by 10.231.192.4 with HTTP; Wed, 16 Jun 2010 23:12:50 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB6F56@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB6F56@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Wed, 16 Jun 2010 23:12:50 -0700 Message-ID: From: David Recordon To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Proposal: simplification of the end-user authorization endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2010 06:12:50 -0000 It took me a little while to shift my mind from thinking about how we had drafted the flows previously, but given how similar the flows already were it seems far more clear to have the client ask for a token and/or code versus specifying types of web_server or user_agent. Servers can still document the interactions separately, but it's also become more clear around what servers need to implement given the overlap. --David On Wed, Jun 16, 2010 at 11:05 PM, Eran Hammer-Lahav w= rote: > This is a joint proposal from David Recordon and me: > > ** Background: > > The latest draft (-08) unified the=A0 web-server and user-agent client ty= pes into a single authorization request format. This was done because once = we added an optional authorization code to the user-agent response, it beca= me almost identical to the web-server call. The two remaining differences: > > - The web-server response must not return an access token, only an author= ization code. > - The web-server response uses the URI query while the user-agent respons= e uses the URI fragment. > > The way in which the client indicates which response is requests is by us= ing the 'type' parameter with either 'web_server' or 'user-agent'. This is = all documented in: > > http://tools.ietf.org/html/draft-ietf-oauth-v2-08#section-3 > > Many (if not most) services are likely to implement both the user-agent a= nd web-server types (based on existing deployment and the requirements expr= essed by many of the participants). > > The web-server flow requires client authentication (client secret) in ord= er to obtain an access token. It also enables the registration of a redirec= tion URI. > > When using the user-agent flow, the client does not authenticate with the= authorization server (at all) to obtain an access token. However, it does = need to authenticate if it wants to exchange the optional authorization cod= e for (another) access token. > > The authorization server has a few options when managing the security and= trust implications of each request type: > > - Require that the client provide its type when registering with the serv= ice - if the authorization server knows the client type, it can limit that = client to only make requests suitable for that client type, as well as only= issue a client secret when the client is not a user-agent. > > - Issue different access tokens based on the security context in which th= ey are obtained - access tokens issued using the direct user-agent request = will provide less access (shorter duration, read only, etc.) than an access= token obtained using the web-server request type. > > The first approach is problematic for complex clients requesting both an = access token and authorization code using the user-agent request type. In t= his case, the authorization server is issuing two access tokens, each using= a different level of security. It is means that one developer will need to= obtain a different client identifier for the same application across diffe= rent platforms. > > The current separation between the two request types (user-agent and web-= server) seems artificial. This is especially true when considering the use = cases for native applications and the applicability of both options. At the= end, the client type doesn't matter. What matters is whether the access to= ken is issued with or without client authentication (and whether that authe= ntication can be trusted, which goes beyond what the protocol can provide). > > ** Proposal: > > Replace the 'type' parameter with a new parameter called 'request' (worki= ng title) which can take one of three values: 'token', 'code', or 'token_an= d_code'. This will allow the client (regardless of its type) to explicitly = say what it wants. > > The response is sent as follows: > > - If the client requests an access token, all the response parameters (in= cluding errors) are included in the fragment=A0(same as the user-agent flow= today). > - If the client requests an authorization code, all the parameters are in= cluded in the query (same as the web server flow today). > - If the client requests both, the 'code', 'status', and 'error' are incl= uded in the query while everything else is included in the fragment=A0(expl= ained in the example below). > > The authorization server issues the appropriate user warnings and access = token based on the authentication level obtained. For example, when issuing= an access token the server has to consider: > > - Was the client authenticated using a secret or other means? > - Was the redirection URI registered? > - Is this a known client (white list) from a trusted third party (they ar= e known not to leak their secrets)? > > =A0The advantage of this approach is that it more clearly frames the secu= rity context of issuing tokens. It puts native applications at the same lev= el as the web-server and user-agent clients (no one gets a special paramete= r value). > > ** Examples: > > To help show the similarities, here are three example requests and respon= ses: > > - Token only (aka user-agent): > > =A0=A0https://server.example.com/oauth/authorize? > =A0=A0 =A0client_id=3D...& > =A0=A0 =A0redirect_uri=3Dhttp://client.example.com/callback& > =A0=A0 =A0request=3Dtoken& > =A0=A0 =A0state=3Dfoo > > =A0=A0http://client.example.com/callback#access_token=3D...&expires_in=3D= ...&state=3Dfoo > > In this case all of the parameters are in relation to the token and thus = consumed directly by the JavaScript, desktop app, etc. > > - Code only (aka web-server): > > =A0=A0https://server.example.com/oauth/authorize? > =A0=A0 =A0client_id=3D...& > =A0=A0 =A0redirect_uri=3Dhttp://client.example.com/callback& > =A0=A0 =A0request=3Dcode& > =A0=A0 =A0state=3Dfoo > > =A0=A0http://client.example.com/callback.php?code=3D...&state=3Dfoo > > In this case there isn't an access token and all of the parameters are co= nsumed by the client's server to be traded for an access token via a HTTPS = request to the AS. > > - Token and code: > > https://server.example.com/oauth/authorize? > =A0=A0client_id=3D...& > =A0=A0redirect_uri=3Dhttp://client.example.com/callback& > =A0=A0request=3Dtoken_and_code& > =A0=A0state=3Dfoo > > http://client.example.com/callback.php?code=3D...&state=3Dfoo#access_toke= n=3D...&expires_in=3D... > > In this case the parameters are consumer both by the JavaScript and the c= lient's server. The parameters about the access token are in the fragment. = The code is a query parameter so that the server can access it. state and e= rror are useful to both and thus are query parameters which can be accessed= by the JavaScript and the server. > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From sakimura@gmail.com Wed Jun 16 23:23:36 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 013D63A69BD for ; Wed, 16 Jun 2010 23:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[AWL=-1.600, BAYES_50=0.001, J_CHICKENPOX_53=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wKQJPgAUpK0V for ; Wed, 16 Jun 2010 23:23:33 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 720BE3A6848 for ; Wed, 16 Jun 2010 23:23:31 -0700 (PDT) Received: by gwj16 with SMTP id 16so4923361gwj.31 for ; Wed, 16 Jun 2010 23:23:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=KUSEPsci60E80arAysfuCtWCKHgSA63gXRnMoGPhv3M=; b=GZOQsAO2LK/sF837Xtai849BqTOd+yGJg2FPuWhxvB35XxS9VRi8P5KPl+VQOt7Lp4 XM5MfzfjBuMP2mO7m9HV08WIOQZ7iV1v9+aV8lJV+XwBryVcp3k1/uEzagUw1EA2uO6s CjABMkScpLUTANacpi0mVlL+N5SdO8/fUgxvQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=CXBQ2ot2K7794vhiWs1jAup9VAmi4odV2psi1gNGtDR9pf1f4BRXvJPFSb8Tt2/Lo+ P+RjpxnOfCKP6lyzXwbP3g4c/maPjJZxB/WxOo3Gy7a2IfWwOIFAgJIiJ6CfmWT8HAN9 KxDI1bWjIyJtsxFHCs/WyFC2ubdRMqSEtmvY4= MIME-Version: 1.0 Received: by 10.231.141.15 with SMTP id k15mr277937ibu.161.1276755813430; Wed, 16 Jun 2010 23:23:33 -0700 (PDT) Received: by 10.231.17.139 with HTTP; Wed, 16 Jun 2010 23:23:33 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB6F56@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 17 Jun 2010 15:23:33 +0900 Message-ID: From: Nat Sakimura To: David Recordon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Proposal: simplification of the end-user authorization endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2010 06:23:36 -0000 I like this, thought the name "request_type" or something seems more appropriate title for the parameter. On Thu, Jun 17, 2010 at 3:12 PM, David Recordon wrote= : > It took me a little while to shift my mind from thinking about how we > had drafted the flows previously, but given how similar the flows > already were it seems far more clear to have the client ask for a > token and/or code versus specifying types of web_server or user_agent. > Servers can still document the interactions separately, but it's also > become more clear around what servers need to implement given the > overlap. > > --David > > > On Wed, Jun 16, 2010 at 11:05 PM, Eran Hammer-Lahav = wrote: >> This is a joint proposal from David Recordon and me: >> >> ** Background: >> >> The latest draft (-08) unified the=A0 web-server and user-agent client t= ypes into a single authorization request format. This was done because once= we added an optional authorization code to the user-agent response, it bec= ame almost identical to the web-server call. The two remaining differences: >> >> - The web-server response must not return an access token, only an autho= rization code. >> - The web-server response uses the URI query while the user-agent respon= se uses the URI fragment. >> >> The way in which the client indicates which response is requests is by u= sing the 'type' parameter with either 'web_server' or 'user-agent'. This is= all documented in: >> >> http://tools.ietf.org/html/draft-ietf-oauth-v2-08#section-3 >> >> Many (if not most) services are likely to implement both the user-agent = and web-server types (based on existing deployment and the requirements exp= ressed by many of the participants). >> >> The web-server flow requires client authentication (client secret) in or= der to obtain an access token. It also enables the registration of a redire= ction URI. >> >> When using the user-agent flow, the client does not authenticate with th= e authorization server (at all) to obtain an access token. However, it does= need to authenticate if it wants to exchange the optional authorization co= de for (another) access token. >> >> The authorization server has a few options when managing the security an= d trust implications of each request type: >> >> - Require that the client provide its type when registering with the ser= vice - if the authorization server knows the client type, it can limit that= client to only make requests suitable for that client type, as well as onl= y issue a client secret when the client is not a user-agent. >> >> - Issue different access tokens based on the security context in which t= hey are obtained - access tokens issued using the direct user-agent request= will provide less access (shorter duration, read only, etc.) than an acces= s token obtained using the web-server request type. >> >> The first approach is problematic for complex clients requesting both an= access token and authorization code using the user-agent request type. In = this case, the authorization server is issuing two access tokens, each usin= g a different level of security. It is means that one developer will need t= o obtain a different client identifier for the same application across diff= erent platforms. >> >> The current separation between the two request types (user-agent and web= -server) seems artificial. This is especially true when considering the use= cases for native applications and the applicability of both options. At th= e end, the client type doesn't matter. What matters is whether the access t= oken is issued with or without client authentication (and whether that auth= entication can be trusted, which goes beyond what the protocol can provide)= . >> >> ** Proposal: >> >> Replace the 'type' parameter with a new parameter called 'request' (work= ing title) which can take one of three values: 'token', 'code', or 'token_a= nd_code'. This will allow the client (regardless of its type) to explicitly= say what it wants. >> >> The response is sent as follows: >> >> - If the client requests an access token, all the response parameters (i= ncluding errors) are included in the fragment=A0(same as the user-agent flo= w today). >> - If the client requests an authorization code, all the parameters are i= ncluded in the query (same as the web server flow today). >> - If the client requests both, the 'code', 'status', and 'error' are inc= luded in the query while everything else is included in the fragment=A0(exp= lained in the example below). >> >> The authorization server issues the appropriate user warnings and access= token based on the authentication level obtained. For example, when issuin= g an access token the server has to consider: >> >> - Was the client authenticated using a secret or other means? >> - Was the redirection URI registered? >> - Is this a known client (white list) from a trusted third party (they a= re known not to leak their secrets)? >> >> =A0The advantage of this approach is that it more clearly frames the sec= urity context of issuing tokens. It puts native applications at the same le= vel as the web-server and user-agent clients (no one gets a special paramet= er value). >> >> ** Examples: >> >> To help show the similarities, here are three example requests and respo= nses: >> >> - Token only (aka user-agent): >> >> =A0=A0https://server.example.com/oauth/authorize? >> =A0=A0 =A0client_id=3D...& >> =A0=A0 =A0redirect_uri=3Dhttp://client.example.com/callback& >> =A0=A0 =A0request=3Dtoken& >> =A0=A0 =A0state=3Dfoo >> >> =A0=A0http://client.example.com/callback#access_token=3D...&expires_in= =3D...&state=3Dfoo >> >> In this case all of the parameters are in relation to the token and thus= consumed directly by the JavaScript, desktop app, etc. >> >> - Code only (aka web-server): >> >> =A0=A0https://server.example.com/oauth/authorize? >> =A0=A0 =A0client_id=3D...& >> =A0=A0 =A0redirect_uri=3Dhttp://client.example.com/callback& >> =A0=A0 =A0request=3Dcode& >> =A0=A0 =A0state=3Dfoo >> >> =A0=A0http://client.example.com/callback.php?code=3D...&state=3Dfoo >> >> In this case there isn't an access token and all of the parameters are c= onsumed by the client's server to be traded for an access token via a HTTPS= request to the AS. >> >> - Token and code: >> >> https://server.example.com/oauth/authorize? >> =A0=A0client_id=3D...& >> =A0=A0redirect_uri=3Dhttp://client.example.com/callback& >> =A0=A0request=3Dtoken_and_code& >> =A0=A0state=3Dfoo >> >> http://client.example.com/callback.php?code=3D...&state=3Dfoo#access_tok= en=3D...&expires_in=3D... >> >> In this case the parameters are consumer both by the JavaScript and the = client's server. The parameters about the access token are in the fragment.= The code is a query parameter so that the server can access it. state and = error are useful to both and thus are query parameters which can be accesse= d by the JavaScript and the server. >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 Nat Sakimura (=3Dnat) http://www.sakimura.org/en/ http://twitter.com/_nat_en From sakimura@gmail.com Wed Jun 16 23:28:03 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F5D73A69BD for ; Wed, 16 Jun 2010 23:28:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYsDztHwx+RZ for ; Wed, 16 Jun 2010 23:28:02 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 3BA373A6949 for ; Wed, 16 Jun 2010 23:28:01 -0700 (PDT) Received: by gyh4 with SMTP id 4so4919656gyh.31 for ; Wed, 16 Jun 2010 23:28:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=I2pYh4JWTBmD1ZDSThVV4C6KVyEb5MKVOnY7gc2XYTA=; b=PearuFMQry8CLQCc+HEJMlgzNQEc73i8xNbsDYKEBIz1JCVEdm3xtRSGLASDa7Gk+K tC2ihlKf2kmY2BWPK3Jjo3fxiKKlhe4qo419ipl0LB+h6OcpwHurY8YMIHdRxf9zkKO5 s4vCrW+mXgooyF6Jbl97kfUjKQYLKsbtIszEo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=k7VEjDTxwNUwheoH6p6/GIyBWreRv+OPPaVegUXcQFQ204OWNi4APv05n6XTBzkDS2 UxOAv+suKhnTL12mwwXA8EoZ3TrECUC/DbQ+0B+DSetFz1O5AgaWXm8KIbUvvuY1xJny XrQ31/xinJTzVGJUq2ZEJFvlydSV6E8MHZeZw= MIME-Version: 1.0 Received: by 10.231.170.201 with SMTP id e9mr10446804ibz.119.1276756082512; Wed, 16 Jun 2010 23:28:02 -0700 (PDT) Received: by 10.231.17.139 with HTTP; Wed, 16 Jun 2010 23:28:01 -0700 (PDT) In-Reply-To: References: Date: Thu, 17 Jun 2010 15:28:01 +0900 Message-ID: From: Nat Sakimura To: Eran Hammer-Lahav Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth 2.0 Mobile WebApp Flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2010 06:28:03 -0000 I have just submit an I-D. http://datatracker.ietf.org/doc/draft-sakimura-oauth-requrl/ It has extra things like Signing and Encrypting of the Request payload for some use-case stated in the introduction, but the core is the "request_url". (The draft actually is largely copy and paste of OpenID Artifact Binding, which is based on OAuth2.0). =3Dnat On Sat, Jun 12, 2010 at 6:57 AM, Eran Hammer-Lahav wr= ote: > I=92d still like to see this proposed as a new I-D. It can be very short.= I > will have the extensibility guidelines in the next draft or two, but you = can > start by just declaring a new parameter for the relevant endpoints. > > EHL > > > On 6/7/10 7:53 PM, "Nat Sakimura" wrote: > > I fully agree on it. > > Instead of doing as a flow, defining request_url as one of the core varia= ble > would be better. > The question then is, whether this community accepts the idea. > > On Mon, Jun 7, 2010 at 10:51 PM, Manger, James H > wrote: > > Nat, > >> On the other hand, you are starting to think of it as a generic "include= " >> mechanism, are you? > > Yes. That feels like the simplest mental model for this functionality, an= d > the simplest way to specify it. > > -- > James Manger > > > --=20 Nat Sakimura (=3Dnat) http://www.sakimura.org/en/ http://twitter.com/_nat_en From sakimura@gmail.com Wed Jun 16 23:49:48 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 052033A6967 for ; Wed, 16 Jun 2010 23:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[AWL=0.334, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D8ri4LDKObCe for ; Wed, 16 Jun 2010 23:49:47 -0700 (PDT) Received: from mail-yw0-f194.google.com (mail-yw0-f194.google.com [209.85.211.194]) by core3.amsl.com (Postfix) with ESMTP id DE8723A67CC for ; Wed, 16 Jun 2010 23:49:46 -0700 (PDT) Received: by ywh32 with SMTP id 32so4952370ywh.5 for ; Wed, 16 Jun 2010 23:49:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=B+N3Aq9Fmv5gLA6ccbxTRJewEVKpSMV7Lxe0wxUvhtc=; b=BVGr636fT8dyLxFR46zMqC8dHSPogVNgri6gXqymJOCsCmQjk4ANWrZ8y1OqedcLXN 27XAvb9t2TYDS4TdI2JrlX3wk1D3WMNbuQqh0iKR8NeIgRMa29wv9bM4e0v4F0K6o2Uh zaNZcq1NbWmcVHfFnU7hHpBUxXe+2zIqv6Q74= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=wl669tsvGocmzA3JxzbaL08Wm54wZUpxbgoq0gwFrhV08V8q/8Z2uNal0x4Lx12Xvs 9me9CZgU/5clqBWcvp1rKgV6/SO6bF9OLdrRGtkEI79LCccjnZHb2towjKa8kYeUswXR /1hqwffKdGeWEZ4vi8slqq22IbrCF9dKgl93c= MIME-Version: 1.0 Received: by 10.231.195.143 with SMTP id ec15mr10804275ibb.90.1276757387515; Wed, 16 Jun 2010 23:49:47 -0700 (PDT) Received: by 10.231.17.139 with HTTP; Wed, 16 Jun 2010 23:49:47 -0700 (PDT) In-Reply-To: <4C19C4F2.90805@nri.co.jp> References: <4C19C4F2.90805@nri.co.jp> Date: Thu, 17 Jun 2010 15:49:47 +0900 Message-ID: From: Nat Sakimura To: oauth Content-Type: multipart/alternative; boundary=001636b147988c16940489343e24 Subject: [OAUTH-WG] New Version Notification for draft-sakimura-oauth-requrl-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2010 06:49:48 -0000 --001636b147988c16940489343e24 Content-Type: text/plain; charset=ISO-8859-1 -------- Original Message -------- Subject: New Version Notification for draft-sakimura-oauth-requrl-00 Date: Wed, 16 Jun 2010 23:03:52 -0700 (PDT) From: IETF I-D Submission Tool To: n-sakimura@nri.co.jp A new version of I-D, draft-sakimura-oauth-requrl-00.txt has been successfully submitted by Nat Sakimura and posted to the IETF repository. Filename: draft-sakimura-oauth-requrl Revision: 00 Title: Request by Reference ver.1.0 for OAuth 2.0 Creation_date: 2010-06-17 WG ID: Independent Submission Number_of_pages: 8 Abstract: This document defines a simple mechanism of making request by reference in OAuth 2.0. The reference is given as URL and request parameters are defined as JSON object which is pointed by the URL. The IETF Secretariat. -- Nat Sakimura (=nat) http://www.sakimura.org/en/ http://twitter.com/_nat_en --001636b147988c16940489343e24 Content-Type: text/html; charset=ISO-8859-1


    -------- Original Message --------
    Subject: New Version Notification for draft-sakimura-oauth-requrl-00
    Date: Wed, 16 Jun 2010 23:03:52 -0700 (PDT)
    From: IETF I-D Submission Tool <idsubmission@ietf.org>
    To: n-sakimura@nri.co.jp 


    A new version of I-D, draft-sakimura-oauth-requrl-00.txt has been successfully submitted by Nat Sakimura and posted to the IETF repository.

Filename:	 draft-sakimura-oauth-requrl
Revision:	 00
Title:		 Request by Reference ver.1.0 for OAuth 2.0
Creation_date:	 2010-06-17
WG ID:		 Independent Submission
Number_of_pages: 8

Abstract:
This document defines a simple mechanism of making request by
reference in OAuth 2.0.  The reference is given as URL and request
parameters are defined as JSON object which is pointed by the URL.
                                                                                  


The IETF Secretariat.



    --
    Nat Sakimura (=nat)
    http://www.sakimura.org/en/
    http://twitter.com/_nat_en
    --001636b147988c16940489343e24-- From sakimura@gmail.com Thu Jun 17 00:13:27 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18D713A6A15 for ; Thu, 17 Jun 2010 00:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.294 X-Spam-Level: X-Spam-Status: No, score=-2.294 tagged_above=-999 required=5 tests=[AWL=0.304, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8cfcdXPWxgLQ for ; Thu, 17 Jun 2010 00:13:25 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id AF5C93A67CC for ; Thu, 17 Jun 2010 00:13:25 -0700 (PDT) Received: by iwn2 with SMTP id 2so261908iwn.31 for ; Thu, 17 Jun 2010 00:13:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=xbKlvlxzvPKJPTkbX8mxL92oJ74eZADpFRlQR0NL5CY=; b=dm1rWOk7Bj/DJPX9PurpFNFt5hd8WzxziRDGiC2OPtcXp57orsHg0zZKNivEJ3eIoi Mwd3wW7Gg1cReK7vOXmbEs8Tai4whzR0d1JCHIsY7MK/cbShsbGpFCQMpmkqymVZ/b6k bhJhlnLueMRIxaERD4mFlXYoAoGLvy1b4A3/Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=tZsCTC0v4vE2PZG1N8HwrIOVQ80w5x/L2udcdi/QgOSbACYNA9Tx9T5DkB1cm5mDVz ihVweez0Vdp0GIyBby5jyfYSf4Dh9etTF5owahLgWxM5kWwIE6JeJ8MNrCnprQk8WWME qkWVszRdZRf7vSDmbhxuDWTOs4sA3queTReDQ= MIME-Version: 1.0 Received: by 10.231.196.220 with SMTP id eh28mr10775747ibb.198.1276758807762; Thu, 17 Jun 2010 00:13:27 -0700 (PDT) Received: by 10.231.17.139 with HTTP; Thu, 17 Jun 2010 00:13:27 -0700 (PDT) In-Reply-To: References: <4C19C4F2.90805@nri.co.jp> Date: Thu, 17 Jun 2010 16:13:27 +0900 Message-ID: From: Nat Sakimura To: oauth Content-Type: multipart/alternative; boundary=001636e0a88833565904893493b3 Subject: Re: [OAUTH-WG] New Version Notification for draft-sakimura-oauth-requrl-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2010 07:13:27 -0000 --001636e0a88833565904893493b3 Content-Type: text/plain; charset=ISO-8859-1 P.S. It has extra things like Signing and Encrypting of the Request payload for some use-case stated in the introduction, but the core is the "request_url". (The draftactually is largely copy and paste of OpenID Artifact Binding, which is based on OAuth2.0). > A new version of I-D, draft-sakimura-oauth-requrl-00.txt has been successfully submitted by Nat Sakimura and posted to the IETF repository. > > Filename: draft-sakimura-oauth-requrl > Revision: 00 > Title: Request by Reference ver.1.0 for OAuth 2.0 > Creation_date: 2010-06-17 > WG ID: Independent Submission > Number_of_pages: 8 > > Abstract: > This document defines a simple mechanism of making request by > reference in OAuth 2.0. The reference is given as URL and request > parameters are defined as JSON object which is pointed by the URL. > > > > The IETF Secretariat. > > > > > > > -- > Nat Sakimura (=nat) > http://www.sakimura.org/en/ > http://twitter.com/_nat_en > -- Nat Sakimura (=nat) http://www.sakimura.org/en/ http://twitter.com/_nat_en --001636e0a88833565904893493b3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable P.S.=A0

    A new version of I-D, draft-sakimura-oauth-requrl-00.txt has been succ=
essfully submitted by Nat Sakimura and posted to the IETF repository.

Filename:	 draft-sakimura-oauth-requrl
Revision:	 00
Title:		 Request by Reference ver.1.0 for OAuth 2.0
Creation_date:	 2010-06-17
WG ID:		 Independent Submission
Number_of_pages: 8

Abstract:
This document defines a simple mechanism of making request by
reference in OAuth 2.0.  The reference is given as URL and request
parameters are defined as JSON object which is pointed by the URL.
                                                                           =
      =20


The IETF Secretariat.



    --



    --
    Nat Sakimur= a (=3Dnat)
    http://www.sakimura.o= rg/en/
    http://twitter.com/_na= t_en
    --001636e0a88833565904893493b3-- From laurence.miao@gmail.com Thu Jun 17 03:19:01 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F26993A68FA for ; Thu, 17 Jun 2010 03:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mnln6SiFhk1n for ; Thu, 17 Jun 2010 03:19:00 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 02F9E3A6856 for ; Thu, 17 Jun 2010 03:18:59 -0700 (PDT) Received: by gwj16 with SMTP id 16so5009037gwj.31 for ; Thu, 17 Jun 2010 03:19:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:from:date :message-id:subject:to:content-type; bh=nmUoEB6e/MNYGS4n35FomxagDpUJgv/j3XsmEylhf3s=; b=A4lz6e1nHRphIxDzVlQGhGfWFsCcb8Nya5KcMT/uMPV7U0fqik0T7TmgZAbmuDkfC2 Zvkh3iqe4jSjOK74HCQUhvhmuhegL7yrT7EF2svh/Akgbp8SCRh9qxH58LMGOEz/g1Cu CzjTyMlhFMGiYq3boHl+mzJ/66s82MhEJTrkE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=ovGHcRr8rfmOKKapLyAJ8doYtolUu+Y3IWF+gcb+7SSQ72egWd0pivzZVPd0D5hb3Z DCexXcNev1pHleuisZMbv+xSL10D4N2JLy2wRCNGeb0AjmhloT+mNb4yjw3Ne+0vuLm0 pe9TVa2n0sPlLdrTlLDTrfgZzmt/sY3zTY3wI= Received: by 10.150.194.12 with SMTP id r12mr11691439ybf.272.1276769942158; Thu, 17 Jun 2010 03:19:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.228.7 with HTTP; Thu, 17 Jun 2010 03:18:42 -0700 (PDT) From: Laurence Miao Date: Thu, 17 Jun 2010 18:18:42 +0800 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary=000e0cdf19b4dcc4080489372a8e Subject: [OAUTH-WG] grant type related typo X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2010 10:19:01 -0000 --000e0cdf19b4dcc4080489372a8e Content-Type: text/plain; charset=ISO-8859-1 hi, this seems to be a typo, notice the inconsistency of definition of grant_type value and example of grant_type parameter. this apply to oauth spec 2 draft 08 ========== 4. Obtaining an Access Token ... grant_type REQUIRED. The access grand type included in the request. Value MUST be one of "authorization_code", "user_basic_credentials", "assertion", "refresh_token", or "none" (which indicates the client is acting on behalf of itself). ------------------------ 4.1.2. Resource Owner Basic Credentials ... POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded grant_type=user_basic&client_id=s6BhdRkqt3& client_secret=47HDu8s&username=johndoe&password=A3ddj3w =================== thanks --000e0cdf19b4dcc4080489372a8e Content-Type: text/html; charset=ISO-8859-1 hi,

    this seems to be a typo, notice the inconsistency of definition of grant_type value and example of grant_type parameter.
    this apply to oauth spec 2 draft 08

    ==========
    4. Obtaining an Access Token

      ...
       grant_type
             REQUIRED.  The access grand type included in the request.
             Value MUST be one of "authorization_code",
    

         "user_basic_credentials", "assertion", "refresh_token", or

             "none" (which indicates the client is acting on behalf of
             itself).
    ------------------------
    


    4.1.2. Resource Owner Basic Credentials
      ...
         POST /token HTTP/1.1
         Host: server.example.com

         Content-Type: application/x-www-form-urlencoded
    


         grant_type=user_basic&client_id=s6BhdRkqt3&
         client_secret=47HDu8s&username=johndoe&password=A3ddj3w
    ===================

    thanks
    --000e0cdf19b4dcc4080489372a8e-- From sm@resistor.net Thu Jun 17 04:26:10 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2B203A67F5 for ; Thu, 17 Jun 2010 04:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.16 X-Spam-Level: X-Spam-Status: No, score=-1.16 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RWkBwiutJgSS for ; Thu, 17 Jun 2010 04:26:09 -0700 (PDT) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id 3BCDE3A67F3 for ; Thu, 17 Jun 2010 04:26:09 -0700 (PDT) Received: from SUBMAN.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.5.Alpha0/8.14.5.Alpha0) with ESMTP id o5HBPugx022209 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Jun 2010 04:26:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1276773967; x=1276860367; bh=qeIdNaHZznYmnDkI4qLh3KQ286ztP/Esr2MzOrB0kLg=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=R++aR9fFxsIUC/0xdYiS3eA46M3UZ9JsBCXMgW49B47d2wFcUVIw1I6Fu/OeTvEiX jrniT1dokC+I7ncaOlczV36dLhjFys1w6OmNxVCe8VtTUrb/tXTvq/0TKyeC9dXpf2 OLiP0oCsHcNCygQQ8qNTSU8A26LxD/NUILi+gYvA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1276773967; x=1276860367; bh=qeIdNaHZznYmnDkI4qLh3KQ286ztP/Esr2MzOrB0kLg=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=VCrLuv12TE1l4q4f0nwQopoeX6u99MUyGFj37HbW1FF0BITJRfVTnpKAo+eyh6Prk DJfakyRUY0bzFN/fLdVOshtQg36dJ3lob3qwHPGzLte7kJ1oz7hoeBxuBdWqnx5+HB JhBI0p5r5P4DON6q6pTEyQR1TsiLdo7nkaIQ7VIQ= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=gfgvnEyoUMKMF8pnb7Qj7EHWef6Qm4xjOts4SV66h1bFK9cTanJI1qo7cPkTDwcoP vtQ5GKaqPiY6+3SfsoTUdVsjV7ig58fp/jR9n+S6yPPcVQt7W5azCilQhLdxEbQciWd V0ABhaai+XPJz4fSFxTUfVdmprXXrPCN7im5Gr4= Message-Id: <6.2.5.6.2.20100617041400.0a261ff8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 17 Jun 2010 04:21:49 -0700 To: Eran Hammer-Lahav From: SM In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB66F1@P3PW5EX1MB01.EX 1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB66F1@P3PW5EX1MB01.EX1.SECURESERVER.NET> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Draft iteration frequency X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2010 11:26:11 -0000 Hi Eran, At 10:14 14-06-10, Eran Hammer-Lahav wrote: >I am now making daily changes to the draft. I check these changes in >daily (sometimes more) to my github account [1] but I'm not clear >how often do people here wants me to submit those as I-D revisions. >Frequent submission makes it harder for people to read and provide >feedback because there always seems to be a newer draft, but also >keeps the discussion focused on IETF documents, not personal copies elsewhere. There is author in another WG that was submitting frequent revisions. It's not a good idea for the reasons you outlined above. I suggest that you use your best judgement to determine when the changes are significant enough to submit a new revision of the I-D. If you look at an I-D as a specification which will be implemented, it would be better to avoid frequent iterations. Regards, -sm From torsten@lodderstedt.net Thu Jun 17 04:31:14 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EB653A6A4D for ; Thu, 17 Jun 2010 04:31:14 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IhWY3X+bFVSS for ; Thu, 17 Jun 2010 04:31:11 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.29]) by core3.amsl.com (Postfix) with ESMTP id 3C4413A69DD for ; Thu, 17 Jun 2010 04:30:28 -0700 (PDT) Received: from cust.dyn.95-152-108-150.swisscomdata.ch ([95.152.108.150] helo=[127.0.0.1]) by smtprelay02.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OPDIc-0000ry-Dv; Thu, 17 Jun 2010 13:30:22 +0200 Message-ID: <4C1A074F.40204@lodderstedt.net> Date: Thu, 17 Jun 2010 13:30:23 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <4BFAA6AB.8040809@lodderstedt.net> <4BFC3142.6010506@lodderstedt.net> <4BFC371A.5040109@lodderstedt.net> <4C07F407.4050305@lodderstedt.net> <1275663845.7068.94.camel@localhost.localdomain> <4C09732B.5040800@lodderstedt.net> <4C0F6A9C.2060607@lodderstedt.net> <4C1108C4.9040501@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3EAF7473@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C129387.1090703@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3EAF76BD@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1126411A9EB@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343B3EBB6F2B@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB6F2B@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: multipart/alternative; boundary="------------020501060304070805070105" X-Df-Sender: 141509 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] proposal: multiple access tokens from a single authorization flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2010 11:31:14 -0000 This is a multi-part message in MIME format. --------------020501060304070805070105 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit I'm going to write an I-D for multiple access tokens. If someone else would like to contribute, please contact me. regards, Torsten. Am 17.06.2010 03:56, schrieb Eran Hammer-Lahav: > > This use case seems to have some support for an extension, but enough > resistance for being added to core. I suggest those who care about > this write a proposal as an I-D. > > EHL > > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On > Behalf Of *Manger, James H > *Sent:* Wednesday, June 16, 2010 6:54 PM > *To:* Breno > *Cc:* OAuth WG (oauth@ietf.org) > *Subject:* Re: [OAUTH-WG] proposal: multiple access tokens from a > single authorization flow > > Breno, > > > Alternative proposal. Create a new call for 'dropping privileges' > where a client can present a single refresh token and scopes and > obtain a new refresh token/access token with defined scopes provided > that these scopes were already granted to the original token. > > > The advantage of a separate call is that it has less impact in > implementations because it does not modify existing flows. It is also > more flexible. For instance it would allow a client too split its > privileges into tokens with overlapping scopes for arbitrary > requirements around security and functionality of delegating its > privileges. > > This alternative (dropping privileges) could work for clients that > know everything about a service: which scopes are necessary & > sufficient for each call, and that ‘dropping privileges’ is supported. > It requires lots of service-specific knowledge in the client, and/or > some reasonably sophisticated discovery (which is so far undefined, > untried, and not obvious how it should be done). A service that > *requires* dropped privileges can only reject calls that use full > tokens (and hope that hasn’t already compromised security), and hope > that clients can then discover how to drop privileges and what to drop > them to (efficiently & simply). > > Returning multiple tokens, in contrast, enables a server to say use > these (“pre-droppedâ€) tokens at these API endpoints. No extra > discovery is required. No extra service-specific knowledge is required > of clients. > > ‘Dropping privileges’ is nice additional functionality, but I don’t > think it is a good alternative to returning multiple tokens. > > -- > > James Manger > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --------------020501060304070805070105 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit I'm going to write an I-D for multiple access tokens. If someone else would like to contribute, please contact me.

    regards,
    Torsten.

    Am 17.06.2010 03:56, schrieb Eran Hammer-Lahav:

    This use case seems to have some support for an extension, but enough resistance for being added to core. I suggest those who care about this write a proposal as an I-D.

     

    EHL

     

    From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Manger, James H
    Sent: Wednesday, June 16, 2010 6:54 PM
    To: Breno
    Cc: OAuth WG (oauth@ietf.org)
    Subject: Re: [OAUTH-WG] proposal: multiple access tokens from a single authorization flow

     

    Breno,

     

    > Alternative proposal. Create a new call for 'dropping privileges' where a client can present a single refresh token and scopes and obtain a new refresh token/access token with defined scopes provided that these scopes were already granted to the original token.

    > The advantage of a separate call is that it has less impact in implementations because it does not modify existing flows. It is also more flexible. For instance it would allow a client too split its privileges into tokens with overlapping scopes for arbitrary requirements around security and functionality of delegating its privileges.

     

    This alternative (dropping privileges) could work for clients that know everything about a service: which scopes are necessary & sufficient for each call, and that ‘dropping privileges’ is supported. It requires lots of service-specific knowledge in the client, and/or some reasonably sophisticated discovery (which is so far undefined, untried, and not obvious how it should be done). A service that requires dropped privileges can only reject calls that use full tokens (and hope that hasn’t already compromised security), and hope that clients can then discover how to drop privileges and what to drop them to (efficiently & simply).

     

    Returning multiple tokens, in contrast, enables a server to say use these (“pre-droppedâ€) tokens at these API endpoints. No extra discovery is required. No extra service-specific knowledge is required of clients.

     

    ‘Dropping privileges’ is nice additional functionality, but I don’t think it is a good alternative to returning multiple tokens.

     

    --

    James Manger

    
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
    --------------020501060304070805070105-- From torsten@lodderstedt.net Thu Jun 17 04:33:39 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18CB13A68AF for ; Thu, 17 Jun 2010 04:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.649 X-Spam-Level: X-Spam-Status: No, score=-0.649 tagged_above=-999 required=5 tests=[AWL=-1.600, BAYES_50=0.001, HELO_EQ_DE=0.35, J_CHICKENPOX_53=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f0FX7o76ocTc for ; Thu, 17 Jun 2010 04:33:38 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.27]) by core3.amsl.com (Postfix) with ESMTP id 6A58A3A6A3B for ; Thu, 17 Jun 2010 04:33:37 -0700 (PDT) Received: from cust.dyn.95-152-108-150.swisscomdata.ch ([95.152.108.150] helo=[127.0.0.1]) by smtprelay04.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OPDLp-0006fs-1w; Thu, 17 Jun 2010 13:33:41 +0200 Message-ID: <4C1A0815.6000600@lodderstedt.net> Date: Thu, 17 Jun 2010 13:33:41 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB6F56@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB6F56@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Proposal: simplification of the end-user authorization endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2010 11:33:39 -0000 +1, although "request" sounds a bit wierd. Don't you like "response_type" or just "response"? Am 17.06.2010 08:05, schrieb Eran Hammer-Lahav: > This is a joint proposal from David Recordon and me: > > ** Background: > > The latest draft (-08) unified the web-server and user-agent client types into a single authorization request format. This was done because once we added an optional authorization code to the user-agent response, it became almost identical to the web-server call. The two remaining differences: > > - The web-server response must not return an access token, only an authorization code. > - The web-server response uses the URI query while the user-agent response uses the URI fragment. > > The way in which the client indicates which response is requests is by using the 'type' parameter with either 'web_server' or 'user-agent'. This is all documented in: > > http://tools.ietf.org/html/draft-ietf-oauth-v2-08#section-3 > > Many (if not most) services are likely to implement both the user-agent and web-server types (based on existing deployment and the requirements expressed by many of the participants). > > The web-server flow requires client authentication (client secret) in order to obtain an access token. It also enables the registration of a redirection URI. > > When using the user-agent flow, the client does not authenticate with the authorization server (at all) to obtain an access token. However, it does need to authenticate if it wants to exchange the optional authorization code for (another) access token. > > The authorization server has a few options when managing the security and trust implications of each request type: > > - Require that the client provide its type when registering with the service - if the authorization server knows the client type, it can limit that client to only make requests suitable for that client type, as well as only issue a client secret when the client is not a user-agent. > > - Issue different access tokens based on the security context in which they are obtained - access tokens issued using the direct user-agent request will provide less access (shorter duration, read only, etc.) than an access token obtained using the web-server request type. > > The first approach is problematic for complex clients requesting both an access token and authorization code using the user-agent request type. In this case, the authorization server is issuing two access tokens, each using a different level of security. It is means that one developer will need to obtain a different client identifier for the same application across different platforms. > > The current separation between the two request types (user-agent and web-server) seems artificial. This is especially true when considering the use cases for native applications and the applicability of both options. At the end, the client type doesn't matter. What matters is whether the access token is issued with or without client authentication (and whether that authentication can be trusted, which goes beyond what the protocol can provide). > > ** Proposal: > > Replace the 'type' parameter with a new parameter called 'request' (working title) which can take one of three values: 'token', 'code', or 'token_and_code'. This will allow the client (regardless of its type) to explicitly say what it wants. > > The response is sent as follows: > > - If the client requests an access token, all the response parameters (including errors) are included in the fragment (same as the user-agent flow today). > - If the client requests an authorization code, all the parameters are included in the query (same as the web server flow today). > - If the client requests both, the 'code', 'status', and 'error' are included in the query while everything else is included in the fragment (explained in the example below). > > The authorization server issues the appropriate user warnings and access token based on the authentication level obtained. For example, when issuing an access token the server has to consider: > > - Was the client authenticated using a secret or other means? > - Was the redirection URI registered? > - Is this a known client (white list) from a trusted third party (they are known not to leak their secrets)? > > The advantage of this approach is that it more clearly frames the security context of issuing tokens. It puts native applications at the same level as the web-server and user-agent clients (no one gets a special parameter value). > > ** Examples: > > To help show the similarities, here are three example requests and responses: > > - Token only (aka user-agent): > > https://server.example.com/oauth/authorize? > client_id=...& > redirect_uri=http://client.example.com/callback& > request=token& > state=foo > > http://client.example.com/callback#access_token=...&expires_in=...&state=foo > > In this case all of the parameters are in relation to the token and thus consumed directly by the JavaScript, desktop app, etc. > > - Code only (aka web-server): > > https://server.example.com/oauth/authorize? > client_id=...& > redirect_uri=http://client.example.com/callback& > request=code& > state=foo > > http://client.example.com/callback.php?code=...&state=foo > > In this case there isn't an access token and all of the parameters are consumed by the client's server to be traded for an access token via a HTTPS request to the AS. > > - Token and code: > > https://server.example.com/oauth/authorize? > client_id=...& > redirect_uri=http://client.example.com/callback& > request=token_and_code& > state=foo > > http://client.example.com/callback.php?code=...&state=foo#access_token=...&expires_in=... > > In this case the parameters are consumer both by the JavaScript and the client's server. The parameters about the access token are in the fragment. The code is a query parameter so that the server can access it. state and error are useful to both and thus are query parameters which can be accessed by the JavaScript and the server. > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From laurence.miao@gmail.com Thu Jun 17 02:45:49 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D54EF3A686A for ; Thu, 17 Jun 2010 02:45:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UUNiSTDRuvhk for ; Thu, 17 Jun 2010 02:45:49 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id D408D3A6A2A for ; Thu, 17 Jun 2010 02:45:48 -0700 (PDT) Received: by gxk8 with SMTP id 8so1829935gxk.31 for ; Thu, 17 Jun 2010 02:45:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:from:date :message-id:subject:to:content-type; bh=FSDr4wCYAUN85W9ixrnVZ09nHvHS/sDvoXVP/s8ik0E=; b=gmaizT9G1aANP8YoAa5jSveuDQnv1q6ntn6U6GBmCF3wfmTNZZWZ7CKuejFOdYQFdi GZapN58oHU5Vr68Trr3LWF2e6U02gy8vCG5e2Yp4MgF3M9A7SAFCr+Q2+IYyq8xZniDi 5FFqZWTvejlnvH4SXUno10Kwpa5s4bCP6Y/QA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=VAmWLQ1IrVPI1M7p7aIVp9WpvaW6BzywGKORq0MiC07S0xEt6DGHs4MhJy5ol5GJDj X6A9z7eIiV8JjpRtblsj1w9j80k08hKqy61Fidcf3HJzXVtEli0TyT/OT0kIb2behrLJ EWcG0uM3VVqLHc/g7pNfbHZjE9C1a0uXspfJo= Received: by 10.151.73.41 with SMTP id a41mr11668909ybl.117.1276767947090; Thu, 17 Jun 2010 02:45:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.228.7 with HTTP; Thu, 17 Jun 2010 02:45:25 -0700 (PDT) From: Laurence Miao Date: Thu, 17 Jun 2010 17:45:25 +0800 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary=000e0cd4d7eef9a02b048936b36f X-Mailman-Approved-At: Thu, 17 Jun 2010 07:06:31 -0700 Subject: [OAUTH-WG] grant type related typo X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2010 09:49:46 -0000 --000e0cd4d7eef9a02b048936b36f Content-Type: text/plain; charset=ISO-8859-1 hi, this seems to be a typo, notice the inconsistency of definition of grant_type value and example of grant_type parameter. this apply to oauth spec 2 draft 08 ========== 4. Obtaining an Access Token ... grant_type REQUIRED. The access grand type included in the request. Value MUST be one of "authorization_code", "user_basic_credentials", "assertion", "refresh_token", or "none" (which indicates the client is acting on behalf of itself). ------------------------ 4.1.2. Resource Owner Basic Credentials ... POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded grant_type=user_basic&client_id=s6BhdRkqt3& client_secret=47HDu8s&username=johndoe&password=A3ddj3w =================== thanks --000e0cd4d7eef9a02b048936b36f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hi,

    this seems to be a typo, notice the inconsistency of definition = of grant_type value and example of grant_type parameter.
    this apply to o= auth spec 2 draft 08

    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    4. Obtaining an Access Token
    

  ...
       grant_type
             REQUIRED.  The access grand type include=
d in the request.
             Value MUST be one of "authorization_code=
",
             "user_basic_credentials", "assertion&quo=
t;, "refresh_token", or
    

         "none" (which indicates the client is acting on behalf o=
f
             itself).
    ------------------------

    4.1.2. Resource O=
wner Basic Credentials
      ...
         POST /token HTTP/1.1
         Host: =
server.example.com
    

     Content-Type: application/x-www-form-urlencoded

         grant_type=
=3Duser_basic&client_id=3Ds6BhdRkqt3&
         client_secret=3D47HDu=
8s&username=3Djohndoe&password=3DA3ddj3w
    =3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

    thanks
    --000e0cd4d7eef9a02b048936b36f-- From mscurtescu@google.com Thu Jun 17 10:48:41 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25BC63A6B15 for ; Thu, 17 Jun 2010 10:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.742 X-Spam-Level: X-Spam-Status: No, score=-103.742 tagged_above=-999 required=5 tests=[AWL=-0.965, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fv2ZuKlWF-AA for ; Thu, 17 Jun 2010 10:48:39 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 01E2528C0E1 for ; Thu, 17 Jun 2010 10:48:38 -0700 (PDT) Received: from hpaq3.eem.corp.google.com (hpaq3.eem.corp.google.com [172.25.149.3]) by smtp-out.google.com with ESMTP id o5HHmhfp003197 for ; Thu, 17 Jun 2010 10:48:43 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1276796923; bh=FCEhXyJcQt/tx96L2i1Rkg3vgkg=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=ewh1XgnIgCmURTHu6UmAzZmPPI2CpJK/VMUWwih1AJ1gzGhEKxgdtmy6ozdb8MWLC VpwR6n55uULeMkXUvC06w== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding:x-system-of-record; b=NfOBCma93JQDkKxIAhDjrES7OuXa9o5zEmhakWPsoyPEAnLWy5J4YpvVku/62goPf ySWKdkCCCSFC//R+u1u3Q== Received: from gyh3 (gyh3.prod.google.com [10.243.50.195]) by hpaq3.eem.corp.google.com with ESMTP id o5HHmYwL001027 for ; Thu, 17 Jun 2010 10:48:41 -0700 Received: by gyh3 with SMTP id 3so152655gyh.9 for ; Thu, 17 Jun 2010 10:48:41 -0700 (PDT) Received: by 10.101.168.31 with SMTP id v31mr9218967ano.141.1276796921270; Thu, 17 Jun 2010 10:48:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.189.37 with HTTP; Thu, 17 Jun 2010 10:48:21 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB6F56@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB6F56@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu Date: Thu, 17 Jun 2010 10:48:21 -0700 Message-ID: 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 \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Proposal: simplification of the end-user authorization endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2010 17:48:41 -0000 Shifting from client type profile names to flow type profiles sounds good. Not too sure about the combined case, token_and_code. I am not opposed to it, but I think it would help us wrap our heads around it if a detailed use case was presented. Thanks, Marius On Wed, Jun 16, 2010 at 11:05 PM, Eran Hammer-Lahav w= rote: > This is a joint proposal from David Recordon and me: > > ** Background: > > The latest draft (-08) unified the=A0 web-server and user-agent client ty= pes into a single authorization request format. This was done because once = we added an optional authorization code to the user-agent response, it beca= me almost identical to the web-server call. The two remaining differences: > > - The web-server response must not return an access token, only an author= ization code. > - The web-server response uses the URI query while the user-agent respons= e uses the URI fragment. > > The way in which the client indicates which response is requests is by us= ing the 'type' parameter with either 'web_server' or 'user-agent'. This is = all documented in: > > http://tools.ietf.org/html/draft-ietf-oauth-v2-08#section-3 > > Many (if not most) services are likely to implement both the user-agent a= nd web-server types (based on existing deployment and the requirements expr= essed by many of the participants). > > The web-server flow requires client authentication (client secret) in ord= er to obtain an access token. It also enables the registration of a redirec= tion URI. > > When using the user-agent flow, the client does not authenticate with the= authorization server (at all) to obtain an access token. However, it does = need to authenticate if it wants to exchange the optional authorization cod= e for (another) access token. > > The authorization server has a few options when managing the security and= trust implications of each request type: > > - Require that the client provide its type when registering with the serv= ice - if the authorization server knows the client type, it can limit that = client to only make requests suitable for that client type, as well as only= issue a client secret when the client is not a user-agent. > > - Issue different access tokens based on the security context in which th= ey are obtained - access tokens issued using the direct user-agent request = will provide less access (shorter duration, read only, etc.) than an access= token obtained using the web-server request type. > > The first approach is problematic for complex clients requesting both an = access token and authorization code using the user-agent request type. In t= his case, the authorization server is issuing two access tokens, each using= a different level of security. It is means that one developer will need to= obtain a different client identifier for the same application across diffe= rent platforms. > > The current separation between the two request types (user-agent and web-= server) seems artificial. This is especially true when considering the use = cases for native applications and the applicability of both options. At the= end, the client type doesn't matter. What matters is whether the access to= ken is issued with or without client authentication (and whether that authe= ntication can be trusted, which goes beyond what the protocol can provide). > > ** Proposal: > > Replace the 'type' parameter with a new parameter called 'request' (worki= ng title) which can take one of three values: 'token', 'code', or 'token_an= d_code'. This will allow the client (regardless of its type) to explicitly = say what it wants. > > The response is sent as follows: > > - If the client requests an access token, all the response parameters (in= cluding errors) are included in the fragment=A0(same as the user-agent flow= today). > - If the client requests an authorization code, all the parameters are in= cluded in the query (same as the web server flow today). > - If the client requests both, the 'code', 'status', and 'error' are incl= uded in the query while everything else is included in the fragment=A0(expl= ained in the example below). > > The authorization server issues the appropriate user warnings and access = token based on the authentication level obtained. For example, when issuing= an access token the server has to consider: > > - Was the client authenticated using a secret or other means? > - Was the redirection URI registered? > - Is this a known client (white list) from a trusted third party (they ar= e known not to leak their secrets)? > > =A0The advantage of this approach is that it more clearly frames the secu= rity context of issuing tokens. It puts native applications at the same lev= el as the web-server and user-agent clients (no one gets a special paramete= r value). > > ** Examples: > > To help show the similarities, here are three example requests and respon= ses: > > - Token only (aka user-agent): > > =A0=A0https://server.example.com/oauth/authorize? > =A0=A0 =A0client_id=3D...& > =A0=A0 =A0redirect_uri=3Dhttp://client.example.com/callback& > =A0=A0 =A0request=3Dtoken& > =A0=A0 =A0state=3Dfoo > > =A0=A0http://client.example.com/callback#access_token=3D...&expires_in=3D= ...&state=3Dfoo > > In this case all of the parameters are in relation to the token and thus = consumed directly by the JavaScript, desktop app, etc. > > - Code only (aka web-server): > > =A0=A0https://server.example.com/oauth/authorize? > =A0=A0 =A0client_id=3D...& > =A0=A0 =A0redirect_uri=3Dhttp://client.example.com/callback& > =A0=A0 =A0request=3Dcode& > =A0=A0 =A0state=3Dfoo > > =A0=A0http://client.example.com/callback.php?code=3D...&state=3Dfoo > > In this case there isn't an access token and all of the parameters are co= nsumed by the client's server to be traded for an access token via a HTTPS = request to the AS. > > - Token and code: > > https://server.example.com/oauth/authorize? > =A0=A0client_id=3D...& > =A0=A0redirect_uri=3Dhttp://client.example.com/callback& > =A0=A0request=3Dtoken_and_code& > =A0=A0state=3Dfoo > > http://client.example.com/callback.php?code=3D...&state=3Dfoo#access_toke= n=3D...&expires_in=3D... > > In this case the parameters are consumer both by the JavaScript and the c= lient's server. The parameters about the access token are in the fragment. = The code is a query parameter so that the server can access it. state and e= rror are useful to both and thus are query parameters which can be accessed= by the JavaScript and the server. > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From recordond@gmail.com Thu Jun 17 10:52:25 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB9E63A6958 for ; Thu, 17 Jun 2010 10:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.736 X-Spam-Level: X-Spam-Status: No, score=-1.736 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599, J_CHICKENPOX_53=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jMw-sgPa6d29 for ; Thu, 17 Jun 2010 10:52:24 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id DF4F43A6830 for ; Thu, 17 Jun 2010 10:52:23 -0700 (PDT) Received: by iwn2 with SMTP id 2so104755iwn.31 for ; Thu, 17 Jun 2010 10:52:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=k6Tm5HKGFIT3U7UICW+s0z568BFAvUNDO3j4Zj0aY1g=; b=YJcscZ+MzBOiW3nxp6BjhRhWjZhv+u+w9TqxkpT2IYwuahAexX0nWGn3GYw5E3p4TN igoEHqx7FPWQzd1UmS+B4Re/kxEKcr7eMxrV0g7bb1Vo0NMyYiC+jgFRxroz2qimvORs g67WqNwpqQGMZ31hWd6SBUDUWHow4Mw83i1mg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=dEIiTaDkQZIyYnDq30/pNauYMJysAyV9qPCfmpDCJUFqHSTRzzgAnGdo7E/zCoQ4ck fqaE4FvFTZeCI+aM9DT2X2us3rGTzx38RtDX/x9JTYrKhtgNA1p5RTVS6+8pwUhAnFOf I4MngkyLRl4WCOL/eu4aqeLQi/tpYrlQkENAg= MIME-Version: 1.0 Received: by 10.231.157.201 with SMTP id c9mr10857920ibx.116.1276797146568; Thu, 17 Jun 2010 10:52:26 -0700 (PDT) Received: by 10.231.192.4 with HTTP; Thu, 17 Jun 2010 10:52:26 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB6F56@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 17 Jun 2010 10:52:26 -0700 Message-ID: From: David Recordon To: Marius Scurtescu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Proposal: simplification of the end-user authorization endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2010 17:52:26 -0000 Hey Marius, take a look at http://www.ietf.org/mail-archive/web/oauth/current/msg02657.html from Twitter. On Thu, Jun 17, 2010 at 10:48 AM, Marius Scurtescu wrote: > Shifting from client type profile names to flow type profiles sounds good= . > > Not too sure about the combined case, token_and_code. I am not opposed > to it, but I think it would help us wrap our heads around it if a > detailed use case was presented. > > Thanks, > Marius > > > > On Wed, Jun 16, 2010 at 11:05 PM, Eran Hammer-Lahav = wrote: >> This is a joint proposal from David Recordon and me: >> >> ** Background: >> >> The latest draft (-08) unified the=A0 web-server and user-agent client t= ypes into a single authorization request format. This was done because once= we added an optional authorization code to the user-agent response, it bec= ame almost identical to the web-server call. The two remaining differences: >> >> - The web-server response must not return an access token, only an autho= rization code. >> - The web-server response uses the URI query while the user-agent respon= se uses the URI fragment. >> >> The way in which the client indicates which response is requests is by u= sing the 'type' parameter with either 'web_server' or 'user-agent'. This is= all documented in: >> >> http://tools.ietf.org/html/draft-ietf-oauth-v2-08#section-3 >> >> Many (if not most) services are likely to implement both the user-agent = and web-server types (based on existing deployment and the requirements exp= ressed by many of the participants). >> >> The web-server flow requires client authentication (client secret) in or= der to obtain an access token. It also enables the registration of a redire= ction URI. >> >> When using the user-agent flow, the client does not authenticate with th= e authorization server (at all) to obtain an access token. However, it does= need to authenticate if it wants to exchange the optional authorization co= de for (another) access token. >> >> The authorization server has a few options when managing the security an= d trust implications of each request type: >> >> - Require that the client provide its type when registering with the ser= vice - if the authorization server knows the client type, it can limit that= client to only make requests suitable for that client type, as well as onl= y issue a client secret when the client is not a user-agent. >> >> - Issue different access tokens based on the security context in which t= hey are obtained - access tokens issued using the direct user-agent request= will provide less access (shorter duration, read only, etc.) than an acces= s token obtained using the web-server request type. >> >> The first approach is problematic for complex clients requesting both an= access token and authorization code using the user-agent request type. In = this case, the authorization server is issuing two access tokens, each usin= g a different level of security. It is means that one developer will need t= o obtain a different client identifier for the same application across diff= erent platforms. >> >> The current separation between the two request types (user-agent and web= -server) seems artificial. This is especially true when considering the use= cases for native applications and the applicability of both options. At th= e end, the client type doesn't matter. What matters is whether the access t= oken is issued with or without client authentication (and whether that auth= entication can be trusted, which goes beyond what the protocol can provide)= . >> >> ** Proposal: >> >> Replace the 'type' parameter with a new parameter called 'request' (work= ing title) which can take one of three values: 'token', 'code', or 'token_a= nd_code'. This will allow the client (regardless of its type) to explicitly= say what it wants. >> >> The response is sent as follows: >> >> - If the client requests an access token, all the response parameters (i= ncluding errors) are included in the fragment=A0(same as the user-agent flo= w today). >> - If the client requests an authorization code, all the parameters are i= ncluded in the query (same as the web server flow today). >> - If the client requests both, the 'code', 'status', and 'error' are inc= luded in the query while everything else is included in the fragment=A0(exp= lained in the example below). >> >> The authorization server issues the appropriate user warnings and access= token based on the authentication level obtained. For example, when issuin= g an access token the server has to consider: >> >> - Was the client authenticated using a secret or other means? >> - Was the redirection URI registered? >> - Is this a known client (white list) from a trusted third party (they a= re known not to leak their secrets)? >> >> =A0The advantage of this approach is that it more clearly frames the sec= urity context of issuing tokens. It puts native applications at the same le= vel as the web-server and user-agent clients (no one gets a special paramet= er value). >> >> ** Examples: >> >> To help show the similarities, here are three example requests and respo= nses: >> >> - Token only (aka user-agent): >> >> =A0=A0https://server.example.com/oauth/authorize? >> =A0=A0 =A0client_id=3D...& >> =A0=A0 =A0redirect_uri=3Dhttp://client.example.com/callback& >> =A0=A0 =A0request=3Dtoken& >> =A0=A0 =A0state=3Dfoo >> >> =A0=A0http://client.example.com/callback#access_token=3D...&expires_in= =3D...&state=3Dfoo >> >> In this case all of the parameters are in relation to the token and thus= consumed directly by the JavaScript, desktop app, etc. >> >> - Code only (aka web-server): >> >> =A0=A0https://server.example.com/oauth/authorize? >> =A0=A0 =A0client_id=3D...& >> =A0=A0 =A0redirect_uri=3Dhttp://client.example.com/callback& >> =A0=A0 =A0request=3Dcode& >> =A0=A0 =A0state=3Dfoo >> >> =A0=A0http://client.example.com/callback.php?code=3D...&state=3Dfoo >> >> In this case there isn't an access token and all of the parameters are c= onsumed by the client's server to be traded for an access token via a HTTPS= request to the AS. >> >> - Token and code: >> >> https://server.example.com/oauth/authorize? >> =A0=A0client_id=3D...& >> =A0=A0redirect_uri=3Dhttp://client.example.com/callback& >> =A0=A0request=3Dtoken_and_code& >> =A0=A0state=3Dfoo >> >> http://client.example.com/callback.php?code=3D...&state=3Dfoo#access_tok= en=3D...&expires_in=3D... >> >> In this case the parameters are consumer both by the JavaScript and the = client's server. The parameters about the access token are in the fragment.= The code is a query parameter so that the server can access it. state and = error are useful to both and thus are query parameters which can be accesse= d by the JavaScript and the server. >> >> >> _______________________________________________ >> OAuth mailing 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 jricher@mitre.org Thu Jun 17 11:04:48 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BA1C28C0E1 for ; Thu, 17 Jun 2010 11:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.445 X-Spam-Level: X-Spam-Status: No, score=-5.445 tagged_above=-999 required=5 tests=[AWL=0.554, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XWpoz1bNDlWU for ; Thu, 17 Jun 2010 11:04:47 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 2FAB63A6AB7 for ; Thu, 17 Jun 2010 11:04:46 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o5HI4pH9012765 for ; Thu, 17 Jun 2010 14:04:52 -0400 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o5HI4pMW012762; Thu, 17 Jun 2010 14:04:51 -0400 Received: from [129.83.50.65] (129.83.50.65) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server id 8.2.254.0; Thu, 17 Jun 2010 14:04:51 -0400 From: Justin Richer To: Marius Scurtescu In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB6F56@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset="UTF-8" Date: Thu, 17 Jun 2010 14:04:50 -0400 Message-ID: <1276797890.10716.130.camel@localhost.localdomain> MIME-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Proposal: simplification of the end-user authorization endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2010 18:04:48 -0000 I think I'm missing something on the combined case here. How does the server trust the javascript client code to pass it back valid data? Is it assumed to just rely on an established browser session at that point that the javascript client has access to? -- Justin On Thu, 2010-06-17 at 13:48 -0400, Marius Scurtescu wrote: > Shifting from client type profile names to flow type profiles sounds good. > > Not too sure about the combined case, token_and_code. I am not opposed > to it, but I think it would help us wrap our heads around it if a > detailed use case was presented. > > Thanks, > Marius > > > > On Wed, Jun 16, 2010 at 11:05 PM, Eran Hammer-Lahav wrote: > > This is a joint proposal from David Recordon and me: > > > > ** Background: > > > > The latest draft (-08) unified the web-server and user-agent client types into a single authorization request format. This was done because once we added an optional authorization code to the user-agent response, it became almost identical to the web-server call. The two remaining differences: > > > > - The web-server response must not return an access token, only an authorization code. > > - The web-server response uses the URI query while the user-agent response uses the URI fragment. > > > > The way in which the client indicates which response is requests is by using the 'type' parameter with either 'web_server' or 'user-agent'. This is all documented in: > > > > http://tools.ietf.org/html/draft-ietf-oauth-v2-08#section-3 > > > > Many (if not most) services are likely to implement both the user-agent and web-server types (based on existing deployment and the requirements expressed by many of the participants). > > > > The web-server flow requires client authentication (client secret) in order to obtain an access token. It also enables the registration of a redirection URI. > > > > When using the user-agent flow, the client does not authenticate with the authorization server (at all) to obtain an access token. However, it does need to authenticate if it wants to exchange the optional authorization code for (another) access token. > > > > The authorization server has a few options when managing the security and trust implications of each request type: > > > > - Require that the client provide its type when registering with the service - if the authorization server knows the client type, it can limit that client to only make requests suitable for that client type, as well as only issue a client secret when the client is not a user-agent. > > > > - Issue different access tokens based on the security context in which they are obtained - access tokens issued using the direct user-agent request will provide less access (shorter duration, read only, etc.) than an access token obtained using the web-server request type. > > > > The first approach is problematic for complex clients requesting both an access token and authorization code using the user-agent request type. In this case, the authorization server is issuing two access tokens, each using a different level of security. It is means that one developer will need to obtain a different client identifier for the same application across different platforms. > > > > The current separation between the two request types (user-agent and web-server) seems artificial. This is especially true when considering the use cases for native applications and the applicability of both options. At the end, the client type doesn't matter. What matters is whether the access token is issued with or without client authentication (and whether that authentication can be trusted, which goes beyond what the protocol can provide). > > > > ** Proposal: > > > > Replace the 'type' parameter with a new parameter called 'request' (working title) which can take one of three values: 'token', 'code', or 'token_and_code'. This will allow the client (regardless of its type) to explicitly say what it wants. > > > > The response is sent as follows: > > > > - If the client requests an access token, all the response parameters (including errors) are included in the fragment (same as the user-agent flow today). > > - If the client requests an authorization code, all the parameters are included in the query (same as the web server flow today). > > - If the client requests both, the 'code', 'status', and 'error' are included in the query while everything else is included in the fragment (explained in the example below). > > > > The authorization server issues the appropriate user warnings and access token based on the authentication level obtained. For example, when issuing an access token the server has to consider: > > > > - Was the client authenticated using a secret or other means? > > - Was the redirection URI registered? > > - Is this a known client (white list) from a trusted third party (they are known not to leak their secrets)? > > > > The advantage of this approach is that it more clearly frames the security context of issuing tokens. It puts native applications at the same level as the web-server and user-agent clients (no one gets a special parameter value). > > > > ** Examples: > > > > To help show the similarities, here are three example requests and responses: > > > > - Token only (aka user-agent): > > > > https://server.example.com/oauth/authorize? > > client_id=...& > > redirect_uri=http://client.example.com/callback& > > request=token& > > state=foo > > > > http://client.example.com/callback#access_token=...&expires_in=...&state=foo > > > > In this case all of the parameters are in relation to the token and thus consumed directly by the JavaScript, desktop app, etc. > > > > - Code only (aka web-server): > > > > https://server.example.com/oauth/authorize? > > client_id=...& > > redirect_uri=http://client.example.com/callback& > > request=code& > > state=foo > > > > http://client.example.com/callback.php?code=...&state=foo > > > > In this case there isn't an access token and all of the parameters are consumed by the client's server to be traded for an access token via a HTTPS request to the AS. > > > > - Token and code: > > > > https://server.example.com/oauth/authorize? > > client_id=...& > > redirect_uri=http://client.example.com/callback& > > request=token_and_code& > > state=foo > > > > http://client.example.com/callback.php?code=...&state=foo#access_token=...&expires_in=... > > > > In this case the parameters are consumer both by the JavaScript and the client's server. The parameters about the access token are in the fragment. The code is a query parameter so that the server can access it. state and error are useful to both and thus are query parameters which can be accessed by the JavaScript and the server. > > > > > > _______________________________________________ > > OAuth mailing 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 Thu Jun 17 11:08:42 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D5C128C11A for ; Thu, 17 Jun 2010 11:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.451 X-Spam-Level: X-Spam-Status: No, score=-100.451 tagged_above=-999 required=5 tests=[AWL=-0.563, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_53=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a0lAC8eKeCxs for ; Thu, 17 Jun 2010 11:08:41 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id D0C9A3A6AB7 for ; Thu, 17 Jun 2010 11:08:40 -0700 (PDT) Received: from wpaz13.hot.corp.google.com (wpaz13.hot.corp.google.com [172.24.198.77]) by smtp-out.google.com with ESMTP id o5HI8iHs017344 for ; Thu, 17 Jun 2010 11:08:44 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1276798124; bh=A0OiMDSr/BKleGDLkshzhSZ+GBY=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=Wr2rlB/vYBlV6oSKFk9rS6vaeQvJte0svC4Zpyzv3l0w6ZW4nxD1it01BBGC8+8hp 0Rgpjm91Lr10KDMzd8Yyw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding:x-system-of-record; b=J9sj0q2EsC7qUh9NkfSaRQBIDhTFFDWV7jU7El9H0QIthpColKDsG3ezUP3uVZuCn 2PLxfZrY9sG/mQKLIdHwA== Received: from gyb11 (gyb11.prod.google.com [10.243.49.75]) by wpaz13.hot.corp.google.com with ESMTP id o5HI8YJP010037 for ; Thu, 17 Jun 2010 11:08:43 -0700 Received: by gyb11 with SMTP id 11so183790gyb.22 for ; Thu, 17 Jun 2010 11:08:42 -0700 (PDT) Received: by 10.101.2.18 with SMTP id e18mr9084036ani.72.1276798122133; Thu, 17 Jun 2010 11:08:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.189.37 with HTTP; Thu, 17 Jun 2010 11:08:22 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB6F56@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu Date: Thu, 17 Jun 2010 11:08:22 -0700 Message-ID: To: David Recordon 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] Proposal: simplification of the end-user authorization endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2010 18:08:42 -0000 Yes, I am aware of that thread. I did ask some questions there which are unanswered. Basically, why cannot be that problem solved by 2 different requests, both done by the JavaScript layer? If latency is a problem, it would be good to know exactly where. I assume that authorization codes are issued very infrequently. Does this new token_and_code mode eliminate a transaction every two weeks? Does that make a difference? Also, when and authorization code is issued I guess it cannot be an immediate request. If an approval page is shown to the user anyhow, then a subsequent immediate request to also grab an access token makes no difference at all. Before we introduce a new complicated profile I think it would be good to know in very good details what is this solving. For similar requests the general response was: "write an extension" or "implement it first". Doesn't that make sense in this case as well? Marius On Thu, Jun 17, 2010 at 10:52 AM, David Recordon wrot= e: > Hey Marius, take a look at > http://www.ietf.org/mail-archive/web/oauth/current/msg02657.html from > Twitter. > > > On Thu, Jun 17, 2010 at 10:48 AM, Marius Scurtescu > wrote: >> Shifting from client type profile names to flow type profiles sounds goo= d. >> >> Not too sure about the combined case, token_and_code. I am not opposed >> to it, but I think it would help us wrap our heads around it if a >> detailed use case was presented. >> >> Thanks, >> Marius >> >> >> >> On Wed, Jun 16, 2010 at 11:05 PM, Eran Hammer-Lahav wrote: >>> This is a joint proposal from David Recordon and me: >>> >>> ** Background: >>> >>> The latest draft (-08) unified the=A0 web-server and user-agent client = types into a single authorization request format. This was done because onc= e we added an optional authorization code to the user-agent response, it be= came almost identical to the web-server call. The two remaining differences= : >>> >>> - The web-server response must not return an access token, only an auth= orization code. >>> - The web-server response uses the URI query while the user-agent respo= nse uses the URI fragment. >>> >>> The way in which the client indicates which response is requests is by = using the 'type' parameter with either 'web_server' or 'user-agent'. This i= s all documented in: >>> >>> http://tools.ietf.org/html/draft-ietf-oauth-v2-08#section-3 >>> >>> Many (if not most) services are likely to implement both the user-agent= and web-server types (based on existing deployment and the requirements ex= pressed by many of the participants). >>> >>> The web-server flow requires client authentication (client secret) in o= rder to obtain an access token. It also enables the registration of a redir= ection URI. >>> >>> When using the user-agent flow, the client does not authenticate with t= he authorization server (at all) to obtain an access token. However, it doe= s need to authenticate if it wants to exchange the optional authorization c= ode for (another) access token. >>> >>> The authorization server has a few options when managing the security a= nd trust implications of each request type: >>> >>> - Require that the client provide its type when registering with the se= rvice - if the authorization server knows the client type, it can limit tha= t client to only make requests suitable for that client type, as well as on= ly issue a client secret when the client is not a user-agent. >>> >>> - Issue different access tokens based on the security context in which = they are obtained - access tokens issued using the direct user-agent reques= t will provide less access (shorter duration, read only, etc.) than an acce= ss token obtained using the web-server request type. >>> >>> The first approach is problematic for complex clients requesting both a= n access token and authorization code using the user-agent request type. In= this case, the authorization server is issuing two access tokens, each usi= ng a different level of security. It is means that one developer will need = to obtain a different client identifier for the same application across dif= ferent platforms. >>> >>> The current separation between the two request types (user-agent and we= b-server) seems artificial. This is especially true when considering the us= e cases for native applications and the applicability of both options. At t= he end, the client type doesn't matter. What matters is whether the access = token is issued with or without client authentication (and whether that aut= hentication can be trusted, which goes beyond what the protocol can provide= ). >>> >>> ** Proposal: >>> >>> Replace the 'type' parameter with a new parameter called 'request' (wor= king title) which can take one of three values: 'token', 'code', or 'token_= and_code'. This will allow the client (regardless of its type) to explicitl= y say what it wants. >>> >>> The response is sent as follows: >>> >>> - If the client requests an access token, all the response parameters (= including errors) are included in the fragment=A0(same as the user-agent fl= ow today). >>> - If the client requests an authorization code, all the parameters are = included in the query (same as the web server flow today). >>> - If the client requests both, the 'code', 'status', and 'error' are in= cluded in the query while everything else is included in the fragment=A0(ex= plained in the example below). >>> >>> The authorization server issues the appropriate user warnings and acces= s token based on the authentication level obtained. For example, when issui= ng an access token the server has to consider: >>> >>> - Was the client authenticated using a secret or other means? >>> - Was the redirection URI registered? >>> - Is this a known client (white list) from a trusted third party (they = are known not to leak their secrets)? >>> >>> =A0The advantage of this approach is that it more clearly frames the se= curity context of issuing tokens. It puts native applications at the same l= evel as the web-server and user-agent clients (no one gets a special parame= ter value). >>> >>> ** Examples: >>> >>> To help show the similarities, here are three example requests and resp= onses: >>> >>> - Token only (aka user-agent): >>> >>> =A0=A0https://server.example.com/oauth/authorize? >>> =A0=A0 =A0client_id=3D...& >>> =A0=A0 =A0redirect_uri=3Dhttp://client.example.com/callback& >>> =A0=A0 =A0request=3Dtoken& >>> =A0=A0 =A0state=3Dfoo >>> >>> =A0=A0http://client.example.com/callback#access_token=3D...&expires_in= =3D...&state=3Dfoo >>> >>> In this case all of the parameters are in relation to the token and thu= s consumed directly by the JavaScript, desktop app, etc. >>> >>> - Code only (aka web-server): >>> >>> =A0=A0https://server.example.com/oauth/authorize? >>> =A0=A0 =A0client_id=3D...& >>> =A0=A0 =A0redirect_uri=3Dhttp://client.example.com/callback& >>> =A0=A0 =A0request=3Dcode& >>> =A0=A0 =A0state=3Dfoo >>> >>> =A0=A0http://client.example.com/callback.php?code=3D...&state=3Dfoo >>> >>> In this case there isn't an access token and all of the parameters are = consumed by the client's server to be traded for an access token via a HTTP= S request to the AS. >>> >>> - Token and code: >>> >>> https://server.example.com/oauth/authorize? >>> =A0=A0client_id=3D...& >>> =A0=A0redirect_uri=3Dhttp://client.example.com/callback& >>> =A0=A0request=3Dtoken_and_code& >>> =A0=A0state=3Dfoo >>> >>> http://client.example.com/callback.php?code=3D...&state=3Dfoo#access_to= ken=3D...&expires_in=3D... >>> >>> In this case the parameters are consumer both by the JavaScript and the= client's server. The parameters about the access token are in the fragment= . The code is a query parameter so that the server can access it. state and= error are useful to both and thus are query parameters which can be access= ed by the JavaScript and the server. >>> >>> >>> _______________________________________________ >>> OAuth mailing 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 Thu Jun 17 11:09:46 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D79A83A6A58 for ; Thu, 17 Jun 2010 11:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.566 X-Spam-Level: X-Spam-Status: No, score=-1.566 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, J_CHICKENPOX_53=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mattuE4Kksw3 for ; Thu, 17 Jun 2010 11:09:45 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id A43CB3A68AD for ; Thu, 17 Jun 2010 11:09:45 -0700 (PDT) Received: (qmail 6863 invoked from network); 17 Jun 2010 18:09:50 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 17 Jun 2010 18:09:49 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 17 Jun 2010 11:09:43 -0700 From: Eran Hammer-Lahav To: Justin Richer , Marius Scurtescu Date: Thu, 17 Jun 2010 11:09:37 -0700 Thread-Topic: [OAUTH-WG] Proposal: simplification of the end-user authorization endpoint Thread-Index: AcsOR5cTfzSevFmrRlGsJPJzKMyuFAAAH/CQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB70F7@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB6F56@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1276797890.10716.130.camel@localhost.localdomain> In-Reply-To: <1276797890.10716.130.camel@localhost.localdomain> 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 \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Proposal: simplification of the end-user authorization endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2010 18:09:46 -0000 V2hhdCBkbyB5b3UgbWVhbiBieSB2YWxpZCBkYXRhPw0KDQpJbiB0aGUgdXNlci1hZ2VudCBjYXNl LCB0aGUgc2VydmVyIHJldHVybnMgYW4gYWNjZXNzIHRva2VuLiBXZSBhZGRlZCBhbiBvcHRpb25h bCBhdXRob3JpemF0aW9uIGNvZGUgd2hpY2ggY2FuIG9ubHkgYmUgdXNlZCBhZnRlciBleGNoYW5n aW5nIGl0IGZvciBhbiBhY2Nlc3MgdG9rZW4gd2l0aCByZXF1aXJlZCBjbGllbnQgYXV0aGVudGlj YXRpb24gKGNsaWVudCBzZWNyZXQpLg0KDQpFSEwNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IEp1c3RpbiBSaWNoZXIgW21haWx0bzpqcmljaGVyQG1pdHJlLm9yZ10gDQpTZW50 OiBUaHVyc2RheSwgSnVuZSAxNywgMjAxMCAxMTowNSBBTQ0KVG86IE1hcml1cyBTY3VydGVzY3UN CkNjOiBFcmFuIEhhbW1lci1MYWhhdjsgT0F1dGggV0cgKG9hdXRoQGlldGYub3JnKQ0KU3ViamVj dDogUmU6IFtPQVVUSC1XR10gUHJvcG9zYWw6IHNpbXBsaWZpY2F0aW9uIG9mIHRoZSBlbmQtdXNl ciBhdXRob3JpemF0aW9uIGVuZHBvaW50DQoNCkkgdGhpbmsgSSdtIG1pc3Npbmcgc29tZXRoaW5n IG9uIHRoZSBjb21iaW5lZCBjYXNlIGhlcmUuIEhvdyBkb2VzIHRoZSBzZXJ2ZXIgdHJ1c3QgdGhl IGphdmFzY3JpcHQgY2xpZW50IGNvZGUgdG8gcGFzcyBpdCBiYWNrIHZhbGlkIGRhdGE/IElzIGl0 IGFzc3VtZWQgdG8ganVzdCByZWx5IG9uIGFuIGVzdGFibGlzaGVkIGJyb3dzZXIgc2Vzc2lvbiBh dCB0aGF0IHBvaW50IHRoYXQgdGhlIGphdmFzY3JpcHQgY2xpZW50IGhhcyBhY2Nlc3MgdG8/DQoN CiAtLSBKdXN0aW4NCg0KT24gVGh1LCAyMDEwLTA2LTE3IGF0IDEzOjQ4IC0wNDAwLCBNYXJpdXMg U2N1cnRlc2N1IHdyb3RlOg0KPiBTaGlmdGluZyBmcm9tIGNsaWVudCB0eXBlIHByb2ZpbGUgbmFt ZXMgdG8gZmxvdyB0eXBlIHByb2ZpbGVzIHNvdW5kcyBnb29kLg0KPiANCj4gTm90IHRvbyBzdXJl IGFib3V0IHRoZSBjb21iaW5lZCBjYXNlLCB0b2tlbl9hbmRfY29kZS4gSSBhbSBub3Qgb3Bwb3Nl ZCANCj4gdG8gaXQsIGJ1dCBJIHRoaW5rIGl0IHdvdWxkIGhlbHAgdXMgd3JhcCBvdXIgaGVhZHMg YXJvdW5kIGl0IGlmIGEgDQo+IGRldGFpbGVkIHVzZSBjYXNlIHdhcyBwcmVzZW50ZWQuDQo+IA0K PiBUaGFua3MsDQo+IE1hcml1cw0KPiANCj4gDQo+IA0KPiBPbiBXZWQsIEp1biAxNiwgMjAxMCBh dCAxMTowNSBQTSwgRXJhbiBIYW1tZXItTGFoYXYgPGVyYW5AaHVlbml2ZXJzZS5jb20+IHdyb3Rl Og0KPiA+IFRoaXMgaXMgYSBqb2ludCBwcm9wb3NhbCBmcm9tIERhdmlkIFJlY29yZG9uIGFuZCBt ZToNCj4gPg0KPiA+ICoqIEJhY2tncm91bmQ6DQo+ID4NCj4gPiBUaGUgbGF0ZXN0IGRyYWZ0ICgt MDgpIHVuaWZpZWQgdGhlICB3ZWItc2VydmVyIGFuZCB1c2VyLWFnZW50IGNsaWVudCB0eXBlcyBp bnRvIGEgc2luZ2xlIGF1dGhvcml6YXRpb24gcmVxdWVzdCBmb3JtYXQuIFRoaXMgd2FzIGRvbmUg YmVjYXVzZSBvbmNlIHdlIGFkZGVkIGFuIG9wdGlvbmFsIGF1dGhvcml6YXRpb24gY29kZSB0byB0 aGUgdXNlci1hZ2VudCByZXNwb25zZSwgaXQgYmVjYW1lIGFsbW9zdCBpZGVudGljYWwgdG8gdGhl IHdlYi1zZXJ2ZXIgY2FsbC4gVGhlIHR3byByZW1haW5pbmcgZGlmZmVyZW5jZXM6DQo+ID4NCj4g PiAtIFRoZSB3ZWItc2VydmVyIHJlc3BvbnNlIG11c3Qgbm90IHJldHVybiBhbiBhY2Nlc3MgdG9r ZW4sIG9ubHkgYW4gYXV0aG9yaXphdGlvbiBjb2RlLg0KPiA+IC0gVGhlIHdlYi1zZXJ2ZXIgcmVz cG9uc2UgdXNlcyB0aGUgVVJJIHF1ZXJ5IHdoaWxlIHRoZSB1c2VyLWFnZW50IHJlc3BvbnNlIHVz ZXMgdGhlIFVSSSBmcmFnbWVudC4NCj4gPg0KPiA+IFRoZSB3YXkgaW4gd2hpY2ggdGhlIGNsaWVu dCBpbmRpY2F0ZXMgd2hpY2ggcmVzcG9uc2UgaXMgcmVxdWVzdHMgaXMgYnkgdXNpbmcgdGhlICd0 eXBlJyBwYXJhbWV0ZXIgd2l0aCBlaXRoZXIgJ3dlYl9zZXJ2ZXInIG9yICd1c2VyLWFnZW50Jy4g VGhpcyBpcyBhbGwgZG9jdW1lbnRlZCBpbjoNCj4gPg0KPiA+IGh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtdjItMDgjc2VjdGlvbi0zDQo+ID4NCj4gPiBNYW55IChp ZiBub3QgbW9zdCkgc2VydmljZXMgYXJlIGxpa2VseSB0byBpbXBsZW1lbnQgYm90aCB0aGUgdXNl ci1hZ2VudCBhbmQgd2ViLXNlcnZlciB0eXBlcyAoYmFzZWQgb24gZXhpc3RpbmcgZGVwbG95bWVu dCBhbmQgdGhlIHJlcXVpcmVtZW50cyBleHByZXNzZWQgYnkgbWFueSBvZiB0aGUgcGFydGljaXBh bnRzKS4NCj4gPg0KPiA+IFRoZSB3ZWItc2VydmVyIGZsb3cgcmVxdWlyZXMgY2xpZW50IGF1dGhl bnRpY2F0aW9uIChjbGllbnQgc2VjcmV0KSBpbiBvcmRlciB0byBvYnRhaW4gYW4gYWNjZXNzIHRv a2VuLiBJdCBhbHNvIGVuYWJsZXMgdGhlIHJlZ2lzdHJhdGlvbiBvZiBhIHJlZGlyZWN0aW9uIFVS SS4NCj4gPg0KPiA+IFdoZW4gdXNpbmcgdGhlIHVzZXItYWdlbnQgZmxvdywgdGhlIGNsaWVudCBk b2VzIG5vdCBhdXRoZW50aWNhdGUgd2l0aCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgKGF0IGFs bCkgdG8gb2J0YWluIGFuIGFjY2VzcyB0b2tlbi4gSG93ZXZlciwgaXQgZG9lcyBuZWVkIHRvIGF1 dGhlbnRpY2F0ZSBpZiBpdCB3YW50cyB0byBleGNoYW5nZSB0aGUgb3B0aW9uYWwgYXV0aG9yaXph dGlvbiBjb2RlIGZvciAoYW5vdGhlcikgYWNjZXNzIHRva2VuLg0KPiA+DQo+ID4gVGhlIGF1dGhv cml6YXRpb24gc2VydmVyIGhhcyBhIGZldyBvcHRpb25zIHdoZW4gbWFuYWdpbmcgdGhlIHNlY3Vy aXR5IGFuZCB0cnVzdCBpbXBsaWNhdGlvbnMgb2YgZWFjaCByZXF1ZXN0IHR5cGU6DQo+ID4NCj4g PiAtIFJlcXVpcmUgdGhhdCB0aGUgY2xpZW50IHByb3ZpZGUgaXRzIHR5cGUgd2hlbiByZWdpc3Rl cmluZyB3aXRoIHRoZSBzZXJ2aWNlIC0gaWYgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGtub3dz IHRoZSBjbGllbnQgdHlwZSwgaXQgY2FuIGxpbWl0IHRoYXQgY2xpZW50IHRvIG9ubHkgbWFrZSBy ZXF1ZXN0cyBzdWl0YWJsZSBmb3IgdGhhdCBjbGllbnQgdHlwZSwgYXMgd2VsbCBhcyBvbmx5IGlz c3VlIGEgY2xpZW50IHNlY3JldCB3aGVuIHRoZSBjbGllbnQgaXMgbm90IGEgdXNlci1hZ2VudC4N Cj4gPg0KPiA+IC0gSXNzdWUgZGlmZmVyZW50IGFjY2VzcyB0b2tlbnMgYmFzZWQgb24gdGhlIHNl Y3VyaXR5IGNvbnRleHQgaW4gd2hpY2ggdGhleSBhcmUgb2J0YWluZWQgLSBhY2Nlc3MgdG9rZW5z IGlzc3VlZCB1c2luZyB0aGUgZGlyZWN0IHVzZXItYWdlbnQgcmVxdWVzdCB3aWxsIHByb3ZpZGUg bGVzcyBhY2Nlc3MgKHNob3J0ZXIgZHVyYXRpb24sIHJlYWQgb25seSwgZXRjLikgdGhhbiBhbiBh Y2Nlc3MgdG9rZW4gb2J0YWluZWQgdXNpbmcgdGhlIHdlYi1zZXJ2ZXIgcmVxdWVzdCB0eXBlLg0K PiA+DQo+ID4gVGhlIGZpcnN0IGFwcHJvYWNoIGlzIHByb2JsZW1hdGljIGZvciBjb21wbGV4IGNs aWVudHMgcmVxdWVzdGluZyBib3RoIGFuIGFjY2VzcyB0b2tlbiBhbmQgYXV0aG9yaXphdGlvbiBj b2RlIHVzaW5nIHRoZSB1c2VyLWFnZW50IHJlcXVlc3QgdHlwZS4gSW4gdGhpcyBjYXNlLCB0aGUg YXV0aG9yaXphdGlvbiBzZXJ2ZXIgaXMgaXNzdWluZyB0d28gYWNjZXNzIHRva2VucywgZWFjaCB1 c2luZyBhIGRpZmZlcmVudCBsZXZlbCBvZiBzZWN1cml0eS4gSXQgaXMgbWVhbnMgdGhhdCBvbmUg ZGV2ZWxvcGVyIHdpbGwgbmVlZCB0byBvYnRhaW4gYSBkaWZmZXJlbnQgY2xpZW50IGlkZW50aWZp ZXIgZm9yIHRoZSBzYW1lIGFwcGxpY2F0aW9uIGFjcm9zcyBkaWZmZXJlbnQgcGxhdGZvcm1zLg0K PiA+DQo+ID4gVGhlIGN1cnJlbnQgc2VwYXJhdGlvbiBiZXR3ZWVuIHRoZSB0d28gcmVxdWVzdCB0 eXBlcyAodXNlci1hZ2VudCBhbmQgd2ViLXNlcnZlcikgc2VlbXMgYXJ0aWZpY2lhbC4gVGhpcyBp cyBlc3BlY2lhbGx5IHRydWUgd2hlbiBjb25zaWRlcmluZyB0aGUgdXNlIGNhc2VzIGZvciBuYXRp dmUgYXBwbGljYXRpb25zIGFuZCB0aGUgYXBwbGljYWJpbGl0eSBvZiBib3RoIG9wdGlvbnMuIEF0 IHRoZSBlbmQsIHRoZSBjbGllbnQgdHlwZSBkb2Vzbid0IG1hdHRlci4gV2hhdCBtYXR0ZXJzIGlz IHdoZXRoZXIgdGhlIGFjY2VzcyB0b2tlbiBpcyBpc3N1ZWQgd2l0aCBvciB3aXRob3V0IGNsaWVu dCBhdXRoZW50aWNhdGlvbiAoYW5kIHdoZXRoZXIgdGhhdCBhdXRoZW50aWNhdGlvbiBjYW4gYmUg dHJ1c3RlZCwgd2hpY2ggZ29lcyBiZXlvbmQgd2hhdCB0aGUgcHJvdG9jb2wgY2FuIHByb3ZpZGUp Lg0KPiA+DQo+ID4gKiogUHJvcG9zYWw6DQo+ID4NCj4gPiBSZXBsYWNlIHRoZSAndHlwZScgcGFy YW1ldGVyIHdpdGggYSBuZXcgcGFyYW1ldGVyIGNhbGxlZCAncmVxdWVzdCcgKHdvcmtpbmcgdGl0 bGUpIHdoaWNoIGNhbiB0YWtlIG9uZSBvZiB0aHJlZSB2YWx1ZXM6ICd0b2tlbicsICdjb2RlJywg b3IgJ3Rva2VuX2FuZF9jb2RlJy4gVGhpcyB3aWxsIGFsbG93IHRoZSBjbGllbnQgKHJlZ2FyZGxl c3Mgb2YgaXRzIHR5cGUpIHRvIGV4cGxpY2l0bHkgc2F5IHdoYXQgaXQgd2FudHMuDQo+ID4NCj4g PiBUaGUgcmVzcG9uc2UgaXMgc2VudCBhcyBmb2xsb3dzOg0KPiA+DQo+ID4gLSBJZiB0aGUgY2xp ZW50IHJlcXVlc3RzIGFuIGFjY2VzcyB0b2tlbiwgYWxsIHRoZSByZXNwb25zZSBwYXJhbWV0ZXJz IChpbmNsdWRpbmcgZXJyb3JzKSBhcmUgaW5jbHVkZWQgaW4gdGhlIGZyYWdtZW50IChzYW1lIGFz IHRoZSB1c2VyLWFnZW50IGZsb3cgdG9kYXkpLg0KPiA+IC0gSWYgdGhlIGNsaWVudCByZXF1ZXN0 cyBhbiBhdXRob3JpemF0aW9uIGNvZGUsIGFsbCB0aGUgcGFyYW1ldGVycyBhcmUgaW5jbHVkZWQg aW4gdGhlIHF1ZXJ5IChzYW1lIGFzIHRoZSB3ZWIgc2VydmVyIGZsb3cgdG9kYXkpLg0KPiA+IC0g SWYgdGhlIGNsaWVudCByZXF1ZXN0cyBib3RoLCB0aGUgJ2NvZGUnLCAnc3RhdHVzJywgYW5kICdl cnJvcicgYXJlIGluY2x1ZGVkIGluIHRoZSBxdWVyeSB3aGlsZSBldmVyeXRoaW5nIGVsc2UgaXMg aW5jbHVkZWQgaW4gdGhlIGZyYWdtZW50IChleHBsYWluZWQgaW4gdGhlIGV4YW1wbGUgYmVsb3cp Lg0KPiA+DQo+ID4gVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGlzc3VlcyB0aGUgYXBwcm9wcmlh dGUgdXNlciB3YXJuaW5ncyBhbmQgYWNjZXNzIHRva2VuIGJhc2VkIG9uIHRoZSBhdXRoZW50aWNh dGlvbiBsZXZlbCBvYnRhaW5lZC4gRm9yIGV4YW1wbGUsIHdoZW4gaXNzdWluZyBhbiBhY2Nlc3Mg dG9rZW4gdGhlIHNlcnZlciBoYXMgdG8gY29uc2lkZXI6DQo+ID4NCj4gPiAtIFdhcyB0aGUgY2xp ZW50IGF1dGhlbnRpY2F0ZWQgdXNpbmcgYSBzZWNyZXQgb3Igb3RoZXIgbWVhbnM/DQo+ID4gLSBX YXMgdGhlIHJlZGlyZWN0aW9uIFVSSSByZWdpc3RlcmVkPw0KPiA+IC0gSXMgdGhpcyBhIGtub3du IGNsaWVudCAod2hpdGUgbGlzdCkgZnJvbSBhIHRydXN0ZWQgdGhpcmQgcGFydHkgKHRoZXkgYXJl IGtub3duIG5vdCB0byBsZWFrIHRoZWlyIHNlY3JldHMpPw0KPiA+DQo+ID4gIFRoZSBhZHZhbnRh Z2Ugb2YgdGhpcyBhcHByb2FjaCBpcyB0aGF0IGl0IG1vcmUgY2xlYXJseSBmcmFtZXMgdGhlIHNl Y3VyaXR5IGNvbnRleHQgb2YgaXNzdWluZyB0b2tlbnMuIEl0IHB1dHMgbmF0aXZlIGFwcGxpY2F0 aW9ucyBhdCB0aGUgc2FtZSBsZXZlbCBhcyB0aGUgd2ViLXNlcnZlciBhbmQgdXNlci1hZ2VudCBj bGllbnRzIChubyBvbmUgZ2V0cyBhIHNwZWNpYWwgcGFyYW1ldGVyIHZhbHVlKS4NCj4gPg0KPiA+ ICoqIEV4YW1wbGVzOg0KPiA+DQo+ID4gVG8gaGVscCBzaG93IHRoZSBzaW1pbGFyaXRpZXMsIGhl cmUgYXJlIHRocmVlIGV4YW1wbGUgcmVxdWVzdHMgYW5kIHJlc3BvbnNlczoNCj4gPg0KPiA+IC0g VG9rZW4gb25seSAoYWthIHVzZXItYWdlbnQpOg0KPiA+DQo+ID4gICBodHRwczovL3NlcnZlci5l eGFtcGxlLmNvbS9vYXV0aC9hdXRob3JpemU/DQo+ID4gICAgIGNsaWVudF9pZD0uLi4mDQo+ID4g ICAgIHJlZGlyZWN0X3VyaT1odHRwOi8vY2xpZW50LmV4YW1wbGUuY29tL2NhbGxiYWNrJg0KPiA+ ICAgICByZXF1ZXN0PXRva2VuJg0KPiA+ICAgICBzdGF0ZT1mb28NCj4gPg0KPiA+ICAgDQo+ID4g aHR0cDovL2NsaWVudC5leGFtcGxlLmNvbS9jYWxsYmFjayNhY2Nlc3NfdG9rZW49Li4uJmV4cGly ZXNfaW49Li4uJnMNCj4gPiB0YXRlPWZvbw0KPiA+DQo+ID4gSW4gdGhpcyBjYXNlIGFsbCBvZiB0 aGUgcGFyYW1ldGVycyBhcmUgaW4gcmVsYXRpb24gdG8gdGhlIHRva2VuIGFuZCB0aHVzIGNvbnN1 bWVkIGRpcmVjdGx5IGJ5IHRoZSBKYXZhU2NyaXB0LCBkZXNrdG9wIGFwcCwgZXRjLg0KPiA+DQo+ ID4gLSBDb2RlIG9ubHkgKGFrYSB3ZWItc2VydmVyKToNCj4gPg0KPiA+ICAgaHR0cHM6Ly9zZXJ2 ZXIuZXhhbXBsZS5jb20vb2F1dGgvYXV0aG9yaXplPw0KPiA+ICAgICBjbGllbnRfaWQ9Li4uJg0K PiA+ICAgICByZWRpcmVjdF91cmk9aHR0cDovL2NsaWVudC5leGFtcGxlLmNvbS9jYWxsYmFjayYN Cj4gPiAgICAgcmVxdWVzdD1jb2RlJg0KPiA+ICAgICBzdGF0ZT1mb28NCj4gPg0KPiA+ICAgaHR0 cDovL2NsaWVudC5leGFtcGxlLmNvbS9jYWxsYmFjay5waHA/Y29kZT0uLi4mc3RhdGU9Zm9vDQo+ ID4NCj4gPiBJbiB0aGlzIGNhc2UgdGhlcmUgaXNuJ3QgYW4gYWNjZXNzIHRva2VuIGFuZCBhbGwg b2YgdGhlIHBhcmFtZXRlcnMgYXJlIGNvbnN1bWVkIGJ5IHRoZSBjbGllbnQncyBzZXJ2ZXIgdG8g YmUgdHJhZGVkIGZvciBhbiBhY2Nlc3MgdG9rZW4gdmlhIGEgSFRUUFMgcmVxdWVzdCB0byB0aGUg QVMuDQo+ID4NCj4gPiAtIFRva2VuIGFuZCBjb2RlOg0KPiA+DQo+ID4gaHR0cHM6Ly9zZXJ2ZXIu ZXhhbXBsZS5jb20vb2F1dGgvYXV0aG9yaXplPw0KPiA+ICAgY2xpZW50X2lkPS4uLiYNCj4gPiAg IHJlZGlyZWN0X3VyaT1odHRwOi8vY2xpZW50LmV4YW1wbGUuY29tL2NhbGxiYWNrJg0KPiA+ICAg cmVxdWVzdD10b2tlbl9hbmRfY29kZSYNCj4gPiAgIHN0YXRlPWZvbw0KPiA+DQo+ID4gaHR0cDov L2NsaWVudC5leGFtcGxlLmNvbS9jYWxsYmFjay5waHA/Y29kZT0uLi4mc3RhdGU9Zm9vI2FjY2Vz c190b2tlbj0uLi4mZXhwaXJlc19pbj0uLi4NCj4gPg0KPiA+IEluIHRoaXMgY2FzZSB0aGUgcGFy YW1ldGVycyBhcmUgY29uc3VtZXIgYm90aCBieSB0aGUgSmF2YVNjcmlwdCBhbmQgdGhlIGNsaWVu dCdzIHNlcnZlci4gVGhlIHBhcmFtZXRlcnMgYWJvdXQgdGhlIGFjY2VzcyB0b2tlbiBhcmUgaW4g dGhlIGZyYWdtZW50LiBUaGUgY29kZSBpcyBhIHF1ZXJ5IHBhcmFtZXRlciBzbyB0aGF0IHRoZSBz ZXJ2ZXIgY2FuIGFjY2VzcyBpdC4gc3RhdGUgYW5kIGVycm9yIGFyZSB1c2VmdWwgdG8gYm90aCBh bmQgdGh1cyBhcmUgcXVlcnkgcGFyYW1ldGVycyB3aGljaCBjYW4gYmUgYWNjZXNzZWQgYnkgdGhl IEphdmFTY3JpcHQgYW5kIHRoZSBzZXJ2ZXIuDQo+ID4NCj4gPg0KPiA+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gT0F1dGggbWFpbGluZyBsaXN0 DQo+ID4gT0F1dGhAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL29hdXRoDQo+ID4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gT0F1dGggbWFpbGluZyBsaXN0DQo+IE9BdXRoQGlldGYub3JnDQo+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KDQo= From mscurtescu@google.com Thu Jun 17 11:17:46 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12D193A6919 for ; Thu, 17 Jun 2010 11:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.268 X-Spam-Level: X-Spam-Status: No, score=-105.268 tagged_above=-999 required=5 tests=[AWL=0.709, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g14Gk6-njjkb for ; Thu, 17 Jun 2010 11:17:45 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 128BD3A68FB for ; Thu, 17 Jun 2010 11:17:44 -0700 (PDT) Received: from hpaq2.eem.corp.google.com (hpaq2.eem.corp.google.com [172.25.149.2]) by smtp-out.google.com with ESMTP id o5HIHnsS019138 for ; Thu, 17 Jun 2010 11:17:49 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1276798670; bh=8Q0syZHi5+z8JarK/PAiFhLNAjQ=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=XJFLAdHVzdkKxLv6eTaUn5MDwZgJt6L0MmHXmhADiEwaHhMa75KfCG5sf+mIvt/9s Qh0GLy/hpd2la49xJ+VAQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=N4+Q+gkzxdaR8IPhVL/k4eLcQ93TbNa3c7JRt03UEeKMXDGnmUe/+uL6F5oeAKSFq 8w/km0IJ0QmIijL32eRXQ== Received: from gxk5 (gxk5.prod.google.com [10.202.11.5]) by hpaq2.eem.corp.google.com with ESMTP id o5HIHl6C005138 for ; Thu, 17 Jun 2010 11:17:48 -0700 Received: by gxk5 with SMTP id 5so167931gxk.24 for ; Thu, 17 Jun 2010 11:17:47 -0700 (PDT) Received: by 10.101.203.9 with SMTP id f9mr8734821anq.208.1276798667160; Thu, 17 Jun 2010 11:17:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.189.37 with HTTP; Thu, 17 Jun 2010 11:17:27 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB70F7@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB6F56@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1276797890.10716.130.camel@localhost.localdomain> <90C41DD21FB7C64BB94121FBBC2E72343B3EBB70F7@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu Date: Thu, 17 Jun 2010 11:17:27 -0700 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Proposal: simplification of the end-user authorization endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2010 18:17:46 -0000 On Thu, Jun 17, 2010 at 11:09 AM, Eran Hammer-Lahav wrote: > We added an optional authorization code which can only be used after exchanging it for an access token with required client authentication (client secret). Just to make sure I understand the new flow, the authorization code is supposed to be exchanged for an access *and* a refresh token, right? I don't see the point of swapping it only for an access token. Marius From recordond@gmail.com Thu Jun 17 11:27:18 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7B6A3A699F for ; Thu, 17 Jun 2010 11:27:18 -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.550, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 283z9xJ2qb96 for ; Thu, 17 Jun 2010 11:27:18 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id E38C63A6992 for ; Thu, 17 Jun 2010 11:27:17 -0700 (PDT) Received: by iwn2 with SMTP id 2so139510iwn.31 for ; Thu, 17 Jun 2010 11:27:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=0LdVYh058Y7Bj4lsgUCTtHngsjxGnL73TjgqLw594dE=; b=NXSu2ytZ9lPmX4A9+TFujdHyyh5mSIdqwMfm5HPLycbdulCGfIPEDIElJU5+Amwg4E N00P7aVxjtbKITnTZCOnhHCXXBhDQbt8hfmOtq6Juavr2pSeJ750dMZXGH44PrvsGEds H3sYKjBPJmVZA0VEZRxhcCRiIsF2YW4GngruY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=oevCDZgfY5Oo4x+lsPwwVyWm/DyGw7mstXeKRSKrJ7m+j5W9Kw4Auj/EukRKcq301C lIYglf9/Xi3Xw6qdce84RbCpgD/Ct7QQUG2vGVJzuM1T8lljrnjG7z4jeyj4kB6MyrT9 j5ITb8ocgtkZg4qgD29fJ2s0wDkGKFd9EOmA0= MIME-Version: 1.0 Received: by 10.231.60.7 with SMTP id n7mr12258508ibh.60.1276799239719; Thu, 17 Jun 2010 11:27:19 -0700 (PDT) Received: by 10.231.192.4 with HTTP; Thu, 17 Jun 2010 11:27:19 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB6F56@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1276797890.10716.130.camel@localhost.localdomain> <90C41DD21FB7C64BB94121FBBC2E72343B3EBB70F7@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 17 Jun 2010 11:27:19 -0700 Message-ID: From: David Recordon To: Marius Scurtescu Content-Type: text/plain; charset=ISO-8859-1 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Proposal: simplification of the end-user authorization endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2010 18:27:18 -0000 Sure, a refresh token as well depending on the AS implementation. On Thu, Jun 17, 2010 at 11:17 AM, Marius Scurtescu wrote: > On Thu, Jun 17, 2010 at 11:09 AM, Eran Hammer-Lahav wrote: >> We added an optional authorization code which can only be used after exchanging it for an access token with required client authentication (client secret). > > Just to make sure I understand the new flow, the authorization code is > supposed to be exchanged for an access *and* a refresh token, right? I > don't see the point of swapping it only for an access token. > > Marius > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From jricher@mitre.org Thu Jun 17 11:28:33 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A69983A6821 for ; Thu, 17 Jun 2010 11:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H3Cvo9yVc-jy for ; Thu, 17 Jun 2010 11:28:32 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 121983A68BC for ; Thu, 17 Jun 2010 11:28:31 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o5HISaTQ005624 for ; Thu, 17 Jun 2010 14:28:37 -0400 Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o5HISaU8005621; Thu, 17 Jun 2010 14:28:36 -0400 Received: from [129.83.50.65] (129.83.50.65) by imchub2.MITRE.ORG (129.83.29.74) with Microsoft SMTP Server id 8.2.254.0; Thu, 17 Jun 2010 14:28:36 -0400 From: Justin Richer To: Eran Hammer-Lahav In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB70F7@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB6F56@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1276797890.10716.130.camel@localhost.localdomain> <90C41DD21FB7C64BB94121FBBC2E72343B3EBB70F7@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset="UTF-8" Date: Thu, 17 Jun 2010 14:28:35 -0400 Message-ID: <1276799315.10716.138.camel@localhost.localdomain> MIME-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Proposal: simplification of the end-user authorization endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2010 18:28:33 -0000 OK, nevermind, I think I wasn't reading things correctly. I've re-read both the current spec and the proposal below and I think I've answered my own question. My question was essentially "how does the Javascript client get the authorization code back to the server?", but now I see that it doesn't have to. The callback URL has all the bits that it would need in order to do that since, just as in the web-server flow, the callback URL is on the web-server making the authorization request in the first place. This wouldn't be an option for user-agent clients with a provider-hosted callback URL, obviously. -- Justin On Thu, 2010-06-17 at 14:09 -0400, Eran Hammer-Lahav wrote: > What do you mean by valid data? > > In the user-agent case, the server returns an access token. We added an optional authorization code which can only be used after exchanging it for an access token with required client authentication (client secret). > > EHL > > -----Original Message----- > From: Justin Richer [mailto:jricher@mitre.org] > Sent: Thursday, June 17, 2010 11:05 AM > To: Marius Scurtescu > Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Proposal: simplification of the end-user authorization endpoint > > I think I'm missing something on the combined case here. How does the server trust the javascript client code to pass it back valid data? Is it assumed to just rely on an established browser session at that point that the javascript client has access to? > > -- Justin > > On Thu, 2010-06-17 at 13:48 -0400, Marius Scurtescu wrote: > > Shifting from client type profile names to flow type profiles sounds good. > > > > Not too sure about the combined case, token_and_code. I am not opposed > > to it, but I think it would help us wrap our heads around it if a > > detailed use case was presented. > > > > Thanks, > > Marius > > > > > > > > On Wed, Jun 16, 2010 at 11:05 PM, Eran Hammer-Lahav wrote: > > > This is a joint proposal from David Recordon and me: > > > > > > ** Background: > > > > > > The latest draft (-08) unified the web-server and user-agent client types into a single authorization request format. This was done because once we added an optional authorization code to the user-agent response, it became almost identical to the web-server call. The two remaining differences: > > > > > > - The web-server response must not return an access token, only an authorization code. > > > - The web-server response uses the URI query while the user-agent response uses the URI fragment. > > > > > > The way in which the client indicates which response is requests is by using the 'type' parameter with either 'web_server' or 'user-agent'. This is all documented in: > > > > > > http://tools.ietf.org/html/draft-ietf-oauth-v2-08#section-3 > > > > > > Many (if not most) services are likely to implement both the user-agent and web-server types (based on existing deployment and the requirements expressed by many of the participants). > > > > > > The web-server flow requires client authentication (client secret) in order to obtain an access token. It also enables the registration of a redirection URI. > > > > > > When using the user-agent flow, the client does not authenticate with the authorization server (at all) to obtain an access token. However, it does need to authenticate if it wants to exchange the optional authorization code for (another) access token. > > > > > > The authorization server has a few options when managing the security and trust implications of each request type: > > > > > > - Require that the client provide its type when registering with the service - if the authorization server knows the client type, it can limit that client to only make requests suitable for that client type, as well as only issue a client secret when the client is not a user-agent. > > > > > > - Issue different access tokens based on the security context in which they are obtained - access tokens issued using the direct user-agent request will provide less access (shorter duration, read only, etc.) than an access token obtained using the web-server request type. > > > > > > The first approach is problematic for complex clients requesting both an access token and authorization code using the user-agent request type. In this case, the authorization server is issuing two access tokens, each using a different level of security. It is means that one developer will need to obtain a different client identifier for the same application across different platforms. > > > > > > The current separation between the two request types (user-agent and web-server) seems artificial. This is especially true when considering the use cases for native applications and the applicability of both options. At the end, the client type doesn't matter. What matters is whether the access token is issued with or without client authentication (and whether that authentication can be trusted, which goes beyond what the protocol can provide). > > > > > > ** Proposal: > > > > > > Replace the 'type' parameter with a new parameter called 'request' (working title) which can take one of three values: 'token', 'code', or 'token_and_code'. This will allow the client (regardless of its type) to explicitly say what it wants. > > > > > > The response is sent as follows: > > > > > > - If the client requests an access token, all the response parameters (including errors) are included in the fragment (same as the user-agent flow today). > > > - If the client requests an authorization code, all the parameters are included in the query (same as the web server flow today). > > > - If the client requests both, the 'code', 'status', and 'error' are included in the query while everything else is included in the fragment (explained in the example below). > > > > > > The authorization server issues the appropriate user warnings and access token based on the authentication level obtained. For example, when issuing an access token the server has to consider: > > > > > > - Was the client authenticated using a secret or other means? > > > - Was the redirection URI registered? > > > - Is this a known client (white list) from a trusted third party (they are known not to leak their secrets)? > > > > > > The advantage of this approach is that it more clearly frames the security context of issuing tokens. It puts native applications at the same level as the web-server and user-agent clients (no one gets a special parameter value). > > > > > > ** Examples: > > > > > > To help show the similarities, here are three example requests and responses: > > > > > > - Token only (aka user-agent): > > > > > > https://server.example.com/oauth/authorize? > > > client_id=...& > > > redirect_uri=http://client.example.com/callback& > > > request=token& > > > state=foo > > > > > > > > > http://client.example.com/callback#access_token=...&expires_in=...&s > > > tate=foo > > > > > > In this case all of the parameters are in relation to the token and thus consumed directly by the JavaScript, desktop app, etc. > > > > > > - Code only (aka web-server): > > > > > > https://server.example.com/oauth/authorize? > > > client_id=...& > > > redirect_uri=http://client.example.com/callback& > > > request=code& > > > state=foo > > > > > > http://client.example.com/callback.php?code=...&state=foo > > > > > > In this case there isn't an access token and all of the parameters are consumed by the client's server to be traded for an access token via a HTTPS request to the AS. > > > > > > - Token and code: > > > > > > https://server.example.com/oauth/authorize? > > > client_id=...& > > > redirect_uri=http://client.example.com/callback& > > > request=token_and_code& > > > state=foo > > > > > > http://client.example.com/callback.php?code=...&state=foo#access_token=...&expires_in=... > > > > > > In this case the parameters are consumer both by the JavaScript and the client's server. The parameters about the access token are in the fragment. The code is a query parameter so that the server can access it. state and error are useful to both and thus are query parameters which can be accessed by the JavaScript and the server. > > > > > > > > > _______________________________________________ > > > OAuth mailing 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 Thu Jun 17 14:30:49 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 376C23A69A2 for ; Thu, 17 Jun 2010 14:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.563 X-Spam-Level: X-Spam-Status: No, score=-1.563 tagged_above=-999 required=5 tests=[AWL=-0.164, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, J_CHICKENPOX_53=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NMOeQSa0DAyM for ; Thu, 17 Jun 2010 14:30:47 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 52EA33A68A7 for ; Thu, 17 Jun 2010 14:30:46 -0700 (PDT) Received: (qmail 18777 invoked from network); 17 Jun 2010 21:30:52 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 17 Jun 2010 21:30:51 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 17 Jun 2010 14:30:47 -0700 From: Eran Hammer-Lahav To: Marius Scurtescu , David Recordon Date: Thu, 17 Jun 2010 14:30:38 -0700 Thread-Topic: [OAUTH-WG] Proposal: simplification of the end-user authorization endpoint Thread-Index: AcsOSCIwDk53nPyDTO6lkF+U6WVCawAAHt5w Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB71D0@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB6F56@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 \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Proposal: simplification of the end-user authorization endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2010 21:30:49 -0000 > -----Original Message----- > From: Marius Scurtescu [mailto:mscurtescu@google.com] > Sent: Thursday, June 17, 2010 11:08 AM > To: David Recordon > Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Proposal: simplification of the end-user > authorization endpoint >=20 > Yes, I am aware of that thread. I did ask some questions there which are > unanswered. Please repeat them so we can address them now. > Basically, why cannot be that problem solved by 2 different requests, bot= h > done by the JavaScript layer? >=20 > If latency is a problem, it would be good to know exactly where. I assume > that authorization codes are issued very infrequently. Does this new > token_and_code mode eliminate a transaction every two weeks? > Does that make a difference? The advantage of the user-agent flow is that it address the lack of client = authentication with the presence of the end-user. The server might not know= who the client really is, but it does know that the right user is sitting = in front of the client authorizing the request. It doesn't solve phishing b= ut it provides some security. In the case where a client (native application or user-agent) works in tand= em with a server-based component, using just the web-server flow has two di= sadvantages I'm aware of: the client has to be more complex because it requ= ires callbacks in order to obtain the access token from the server (multipl= e calls and more complex calls than just a simple server-hosted script), bu= t it also lose the benefit of the user presence for security. The problem i= s now moved to the communication between the server component and the user-= agent component of the client. > Also, when and authorization code is issued I guess it cannot be an > immediate request. If an approval page is shown to the user anyhow, then = a > subsequent immediate request to also grab an access token makes no > difference at all. Why not? Both the web-server and user-agent flows were supposed to have imm= ediate mode. > Before we introduce a new complicated profile I think it would be good to > know in very good details what is this solving. For similar requests the = general > response was: "write an extension" or "implement it first". Doesn't that > make sense in this case as well? It makes sense to have a detailed discussion. For similar requests the gene= ral response usually came after it was establish that there was enough inte= rest in pursuing it but not enough consensus to put it in the core spec. Le= t's see where this discussion takes us. Also, this proposal isn't an extens= ion but part of the overall spec flow and architecture. EHL =20 > Marius >=20 >=20 >=20 > On Thu, Jun 17, 2010 at 10:52 AM, David Recordon > wrote: > > Hey Marius, take a look at > > http://www.ietf.org/mail-archive/web/oauth/current/msg02657.html > from > > Twitter. > > > > > > On Thu, Jun 17, 2010 at 10:48 AM, Marius Scurtescu > > wrote: > >> Shifting from client type profile names to flow type profiles sounds g= ood. > >> > >> Not too sure about the combined case, token_and_code. I am not > >> opposed to it, but I think it would help us wrap our heads around it > >> if a detailed use case was presented. > >> > >> Thanks, > >> Marius > >> > >> > >> > >> On Wed, Jun 16, 2010 at 11:05 PM, Eran Hammer-Lahav > wrote: > >>> This is a joint proposal from David Recordon and me: > >>> > >>> ** Background: > >>> > >>> The latest draft (-08) unified the=A0 web-server and user-agent clien= t types > into a single authorization request format. This was done because once we > added an optional authorization code to the user-agent response, it becam= e > almost identical to the web-server call. The two remaining differences: > >>> > >>> - The web-server response must not return an access token, only an > authorization code. > >>> - The web-server response uses the URI query while the user-agent > response uses the URI fragment. > >>> > >>> The way in which the client indicates which response is requests is b= y > using the 'type' parameter with either 'web_server' or 'user-agent'. This= is all > documented in: > >>> > >>> http://tools.ietf.org/html/draft-ietf-oauth-v2-08#section-3 > >>> > >>> Many (if not most) services are likely to implement both the user-age= nt > and web-server types (based on existing deployment and the requirements > expressed by many of the participants). > >>> > >>> The web-server flow requires client authentication (client secret) in > order to obtain an access token. It also enables the registration of a > redirection URI. > >>> > >>> When using the user-agent flow, the client does not authenticate with > the authorization server (at all) to obtain an access token. However, it = does > need to authenticate if it wants to exchange the optional authorization c= ode > for (another) access token. > >>> > >>> The authorization server has a few options when managing the security > and trust implications of each request type: > >>> > >>> - Require that the client provide its type when registering with the > service - if the authorization server knows the client type, it can limit= that > client to only make requests suitable for that client type, as well as on= ly issue > a client secret when the client is not a user-agent. > >>> > >>> - Issue different access tokens based on the security context in whic= h > they are obtained - access tokens issued using the direct user-agent requ= est > will provide less access (shorter duration, read only, etc.) than an acce= ss > token obtained using the web-server request type. > >>> > >>> The first approach is problematic for complex clients requesting both= an > access token and authorization code using the user-agent request type. In > this case, the authorization server is issuing two access tokens, each us= ing a > different level of security. It is means that one developer will need to = obtain > a different client identifier for the same application across different > platforms. > >>> > >>> The current separation between the two request types (user-agent and > web-server) seems artificial. This is especially true when considering th= e use > cases for native applications and the applicability of both options. At t= he end, > the client type doesn't matter. What matters is whether the access token = is > issued with or without client authentication (and whether that > authentication can be trusted, which goes beyond what the protocol can > provide). > >>> > >>> ** Proposal: > >>> > >>> Replace the 'type' parameter with a new parameter called 'request' > (working title) which can take one of three values: 'token', 'code', or > 'token_and_code'. This will allow the client (regardless of its type) to > explicitly say what it wants. > >>> > >>> The response is sent as follows: > >>> > >>> - If the client requests an access token, all the response parameters > (including errors) are included in the fragment=A0(same as the user-agent= flow > today). > >>> - If the client requests an authorization code, all the parameters ar= e > included in the query (same as the web server flow today). > >>> - If the client requests both, the 'code', 'status', and 'error' are = included > in the query while everything else is included in the fragment=A0(explain= ed in > the example below). > >>> > >>> The authorization server issues the appropriate user warnings and > access token based on the authentication level obtained. For example, whe= n > issuing an access token the server has to consider: > >>> > >>> - Was the client authenticated using a secret or other means? > >>> - Was the redirection URI registered? > >>> - Is this a known client (white list) from a trusted third party (the= y are > known not to leak their secrets)? > >>> > >>> =A0The advantage of this approach is that it more clearly frames the > security context of issuing tokens. It puts native applications at the sa= me > level as the web-server and user-agent clients (no one gets a special > parameter value). > >>> > >>> ** Examples: > >>> > >>> To help show the similarities, here are three example requests and > responses: > >>> > >>> - Token only (aka user-agent): > >>> > >>> =A0=A0https://server.example.com/oauth/authorize? > >>> =A0=A0 =A0client_id=3D...& > >>> =A0=A0 =A0redirect_uri=3Dhttp://client.example.com/callback& > >>> =A0=A0 =A0request=3Dtoken& > >>> =A0=A0 =A0state=3Dfoo > >>> > >>> > >>> http://client.example.com/callback#access_token=3D...&expires_in=3D..= .&s > >>> tate=3Dfoo > >>> > >>> In this case all of the parameters are in relation to the token and t= hus > consumed directly by the JavaScript, desktop app, etc. > >>> > >>> - Code only (aka web-server): > >>> > >>> =A0=A0https://server.example.com/oauth/authorize? > >>> =A0=A0 =A0client_id=3D...& > >>> =A0=A0 =A0redirect_uri=3Dhttp://client.example.com/callback& > >>> =A0=A0 =A0request=3Dcode& > >>> =A0=A0 =A0state=3Dfoo > >>> > >>> =A0=A0http://client.example.com/callback.php?code=3D...&state=3Dfoo > >>> > >>> In this case there isn't an access token and all of the parameters ar= e > consumed by the client's server to be traded for an access token via a HT= TPS > request to the AS. > >>> > >>> - Token and code: > >>> > >>> https://server.example.com/oauth/authorize? > >>> =A0=A0client_id=3D...& > >>> =A0=A0redirect_uri=3Dhttp://client.example.com/callback& > >>> =A0=A0request=3Dtoken_and_code& > >>> =A0=A0state=3Dfoo > >>> > >>> > http://client.example.com/callback.php?code=3D...&state=3Dfoo#access_toke= n=3D > ...&expires_in=3D... > >>> > >>> In this case the parameters are consumer both by the JavaScript and t= he > client's server. The parameters about the access token are in the fragmen= t. > The code is a query parameter so that the server can access it. state and > error are useful to both and thus are query parameters which can be > accessed by the JavaScript and the server. > >>> > >>> > >>> _______________________________________________ > >>> OAuth mailing 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 Thu Jun 17 14:36:30 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FF963A6886 for ; Thu, 17 Jun 2010 14:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.16 X-Spam-Level: X-Spam-Status: No, score=-2.16 tagged_above=-999 required=5 tests=[AWL=0.438, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fUpTjkmfEKe4 for ; Thu, 17 Jun 2010 14:36:26 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 218DA3A6884 for ; Thu, 17 Jun 2010 14:36:26 -0700 (PDT) Received: (qmail 27860 invoked from network); 17 Jun 2010 21:36:31 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 17 Jun 2010 21:36:31 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 17 Jun 2010 14:36:23 -0700 From: Eran Hammer-Lahav To: "OAuth WG (oauth@ietf.org)" Date: Thu, 17 Jun 2010 14:36:16 -0700 Thread-Topic: Status update Thread-Index: AcsOZJCddfrI5XZKTIub0GZN0JDsZw== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB71D3@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_90C41DD21FB7C64BB94121FBBC2E72343B3EBB71D3P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: [OAUTH-WG] Status update X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2010 21:36:31 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EBB71D3P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable With the exception of extensibility, I consider draft -08 to be feature com= plete. This means that the draft contains all the features and components n= eeded and other then editorial work is close to finished. I plan to finish = work on the -09 draft by Mon or Tue next week which will include the extens= ibility text, additional editorial work, and resolution of the proposal to = simplify the end-user authorization endpoint. At that point, I intend to as= k for an interim last-call on the normative language (i.e. the implementati= on details). Note that this last-call isn't really a WG last call. The spec can change a= fter that. But it will be a useful milestone to figure out if the draft's i= mplementation details are stable and can be considered complete. All of this of course requires the approval of the chairs. EHL --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EBB71D3P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    With the excepti= on of extensibility, I consider draft -08 to be feature complete. This mean= s that the draft contains all the features and components needed and other = then editorial work is close to finished. I plan to finish work on the -09 = draft by Mon or Tue next week which will include the extensibility text, ad= ditional editorial work, and resolution of the proposal to simplify the end= -user authorization endpoint. At that point, I intend to ask for an interim= last-call on the normative language (i.e. the implementation details).

     

    N= ote that this last-call isn’t really a WG last call. The spec can cha= nge after that. But it will be a useful milestone to figure out if the draf= t’s implementation details are stable and can be considered complete.=

     

    All of this of course requires the approval of the chairs.

     

    EHL

    = --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EBB71D3P3PW5EX1MB01E_-- From mscurtescu@google.com Thu Jun 17 14:55:56 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B6B43A6936 for ; Thu, 17 Jun 2010 14:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.162 X-Spam-Level: X-Spam-Status: No, score=-100.162 tagged_above=-999 required=5 tests=[AWL=-0.785, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZk7zOfAGMxy for ; Thu, 17 Jun 2010 14:55:55 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 0BC023A6359 for ; Thu, 17 Jun 2010 14:55:54 -0700 (PDT) Received: from wpaz33.hot.corp.google.com (wpaz33.hot.corp.google.com [172.24.198.97]) by smtp-out.google.com with ESMTP id o5HLtwFR020431 for ; Thu, 17 Jun 2010 14:55:59 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1276811759; bh=ai+K3GAHRtRfVLq1/f1GVozkz0E=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=fHN8Fex+CK+5D+Jvg+4oWxJsv5aNIEL3hOgWM2CG88tH088FyZ7EqPBDZqYQAPThl SXmhAHR+Ff5Jcv534XlZQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding:x-system-of-record; b=bY5SFr2St5+ggbIAZPYnyI2MCAcIcuR9WGfQmMLClxH/7fcmzE+s6SwfdymOxpd2X axpKIJQ5OrqNOclWOVGCw== Received: from ywh16 (ywh16.prod.google.com [10.192.8.16]) by wpaz33.hot.corp.google.com with ESMTP id o5HLtv3g030531 for ; Thu, 17 Jun 2010 14:55:57 -0700 Received: by ywh16 with SMTP id 16so477050ywh.21 for ; Thu, 17 Jun 2010 14:55:57 -0700 (PDT) Received: by 10.101.130.14 with SMTP id h14mr133846ann.142.1276811757166; Thu, 17 Jun 2010 14:55:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.189.37 with HTTP; Thu, 17 Jun 2010 14:55:37 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB71D0@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB6F56@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3EBB71D0@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu Date: Thu, 17 Jun 2010 14:55:37 -0700 Message-ID: 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 \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Proposal: simplification of the end-user authorization endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2010 21:55:56 -0000 On Thu, Jun 17, 2010 at 2:30 PM, Eran Hammer-Lahav wr= ote: > > >> -----Original Message----- >> From: Marius Scurtescu [mailto:mscurtescu@google.com] >> Sent: Thursday, June 17, 2010 11:08 AM >> To: David Recordon >> Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org) >> Subject: Re: [OAUTH-WG] Proposal: simplification of the end-user >> authorization endpoint >> >> Yes, I am aware of that thread. I did ask some questions there which are >> unanswered. > > Please repeat them so we can address them now. That's what I did below. >> Basically, why cannot be that problem solved by 2 different requests, bo= th >> done by the JavaScript layer? >> >> If latency is a problem, it would be good to know exactly where. I assum= e >> that authorization codes are issued very infrequently. Does this new >> token_and_code mode eliminate a transaction every two weeks? >> Does that make a difference? > > The advantage of the user-agent flow is that it address the lack of clien= t authentication with the presence of the end-user. The server might not kn= ow who the client really is, but it does know that the right user is sittin= g in front of the client authorizing the request. It doesn't solve phishing= but it provides some security. Sure, but how is this affected by token_and_code? The authz server knows who the user is when it issues the access token and the authorization code. The authorization code is passed down to the client server and now the client server asks for access/refresh tokens. No user this time but potentially there is a client secret. > In the case where a client (native application or user-agent) works in ta= ndem with a server-based component, using just the web-server flow has two = disadvantages I'm aware of: the client has to be more complex because it re= quires callbacks in order to obtain the access token from the server (multi= ple calls and more complex calls than just a simple server-hosted script), The JavaScript client can either use the authorization code with a direct call (as you probably suggest), but then it cannot pass the authorization code down to the client server anymore. The JavaScript client can do a separate User-Agent call in immediate mode to get an access token directly. This is what it would normally do. No point in swapping the authorization code since it can be exchanged only once. > but it also lose the benefit of the user presence for security. With the User-Agent immediate call this is not lost. > The problem is now moved to the communication between the server componen= t and the user-agent component of the client. > >> Also, =A0when and authorization code is issued I guess it cannot be an >> immediate request. If an approval page is shown to the user anyhow, then= a >> subsequent immediate request to also grab an access token makes no >> difference at all. > > Why not? Both the web-server and user-agent flows were supposed to have i= mmediate mode. I was saying that it makes no difference from a latency perspective, The end user just clicked an "Approve" button and was redirected, and extra call (direct or immediate) will probably not be felt at all. Thanks, Marius From sakimura@gmail.com Thu Jun 17 16:41:57 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90FC03A6B47 for ; Thu, 17 Jun 2010 16:41:57 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G4DOL3VjVDgl for ; Thu, 17 Jun 2010 16:41:56 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 212433A6B3F for ; Thu, 17 Jun 2010 16:41:56 -0700 (PDT) Received: by pwj8 with SMTP id 8so226749pwj.31 for ; Thu, 17 Jun 2010 16:41:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:x-mailer :mime-version:subject:date:cc; bh=Amq+57uhpJwOkyWzhUwLSGFYhogrCFW3D84UmTwYeZ4=; b=V4rK6lkiZ88dF22kUNnaJOzwdragDnESqYbTgHeY2it0YkR3YIY0Gayh4MK6iqEjS5 GHImnHvFyxvr8Sdopmw/3VC/c4qxtVc/opGqUTvtKZTeRXXEJmvv0OLkE8d7EmIemT3O NkdSH8QANn4o5iq91EdIzFb2lC9X8jitOIWGE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:x-mailer:mime-version:subject:date:cc; b=WyOMAnbJesOObm7jlzE7h4AcjCxJl9Tfl2ml0WWP0QWoSIBfO9VkN7akpgG2aH/3Bb 1w0WxfHLk7cEo3IM0IEvSxGQKxvl0N67pRcwOyuPIqrnDDtssuptamz0ick8IdyWYm91 MNfdcWfDAQR/ueJEH8B/A5rWRcXFa4uFCulKQ= Received: by 10.115.135.24 with SMTP id m24mr190455wan.129.1276818118746; Thu, 17 Jun 2010 16:41:58 -0700 (PDT) Received: from [192.168.2.4] (pd846f3.tokynt01.ap.so-net.ne.jp [111.216.70.243]) by mx.google.com with ESMTPS id 33sm101061994wad.8.2010.06.17.16.41.56 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 17 Jun 2010 16:41:57 -0700 (PDT) References: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB71D3@P3PW5EX1MB01.EX1.SECURESERVER.NET> Message-Id: <35F209BF-D22B-4C3F-919F-15EAD4844A15@gmail.com> From: Nat To: Eran Hammer-Lahav In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB71D3@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=Shift_JIS; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable X-Mailer: iPhone Mail (7E18) Mime-Version: 1.0 (iPhone Mail 7E18) Date: Fri, 18 Jun 2010 08:42:21 +0900 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Status update X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2010 23:41:58 -0000 What about the 'request_url' indirection (without sig and enc)? On 2010/06/18, at 6:36, Eran Hammer-Lahav wrote: > With the exception of extensibility, I consider draft -08 to be =20 > feature complete. This means that the draft contains all the =20 > features and components needed and other then editorial work is =20 > close to finished. I plan to finish work on the -09 draft by Mon or =20= > Tue next week which will include the extensibility text, additional =20= > editorial work, and resolution of the proposal to simplify the end-=20 > user authorization endpoint. At that point, I intend to ask for an =20 > interim last-call on the normative language (i.e. the implementation =20= > details). > > > > Note that this last-call isn=81ft really a WG last call. The spec can = c=20 > hange after that. But it will be a useful milestone to figure out if=20= > the draft=81fs implementation details are stable and can be = considered=20 > complete. > > > > All of this of course requires the approval of the chairs. > > > > EHL > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Thu Jun 17 17:22:45 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD7EB3A6359 for ; Thu, 17 Jun 2010 17:22:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.167 X-Spam-Level: X-Spam-Status: No, score=-2.167 tagged_above=-999 required=5 tests=[AWL=0.432, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vwEgOCbfngVZ for ; Thu, 17 Jun 2010 17:22:44 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 841463A67FC for ; Thu, 17 Jun 2010 17:22:44 -0700 (PDT) Received: (qmail 27712 invoked from network); 18 Jun 2010 00:22:49 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 18 Jun 2010 00:22:49 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 17 Jun 2010 17:22:49 -0700 From: Eran Hammer-Lahav To: Nat Date: Thu, 17 Jun 2010 17:22:45 -0700 Thread-Topic: [OAUTH-WG] Status update Thread-Index: AcsOdq5M+ECUqRRQT5yLrDOQyDdgugABaneQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB7200@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB71D3@P3PW5EX1MB01.EX1.SECURESERVER.NET> <35F209BF-D22B-4C3F-919F-15EAD4844A15@gmail.com> In-Reply-To: <35F209BF-D22B-4C3F-919F-15EAD4844A15@gmail.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 \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Status update X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jun 2010 00:22:45 -0000 Not sure what you are referring to. EHL > -----Original Message----- > From: Nat [mailto:sakimura@gmail.com] > Sent: Thursday, June 17, 2010 4:42 PM > To: Eran Hammer-Lahav > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Status update >=20 > What about the 'request_url' indirection (without sig and enc)? >=20 > On 2010/06/18, at 6:36, Eran Hammer-Lahav wrote: >=20 > > With the exception of extensibility, I consider draft -08 to be > > feature complete. This means that the draft contains all the features > > and components needed and other then editorial work is close to > > finished. I plan to finish work on the -09 draft by Mon or Tue next > > week which will include the extensibility text, additional editorial > > work, and resolution of the proposal to simplify the end- user > > authorization endpoint. At that point, I intend to ask for an interim > > last-call on the normative language (i.e. the implementation details). > > > > > > > > Note that this last-call isn't really a WG last call. The spec can c > > hange after that. But it will be a useful milestone to figure out if > > the draft's implementation details are stable and can be considered > > complete. > > > > > > > > All of this of course requires the approval of the chairs. > > > > > > > > EHL > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth From sakimura@gmail.com Thu Jun 17 18:11:54 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E49213A6874 for ; Thu, 17 Jun 2010 18:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lksbmdhw+XFY for ; Thu, 17 Jun 2010 18:11:51 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id BB0D33A6853 for ; Thu, 17 Jun 2010 18:11:50 -0700 (PDT) Received: by wya21 with SMTP id 21so439939wya.31 for ; Thu, 17 Jun 2010 18:11:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=m27M1RiQAytVAGCTM2p5pE3Gs3Z5BGN0SAKKkO1qPjc=; b=NxAT4cZT5WmZuT7o8wK0d2XN4cj3dpLYq2TRYurfptIdD84IGc7BH4TUVBNMttZ6rE oszkVvsa3YbqZK4xYsnjD/eO+YV80Slc5dDujQ3oulGuGMV2qnqnyc24E4vuBoqS8C4a I6LlZ5XOGsq0l0VWON0PTpDsRzwPqgCsIL1xI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=GKJwKIhCrMZHlqCFbU1gt0q4JbhyPzALP6tYOGSxrjD0v6svv5siZtXWnCGkmG6R+U +Z5hHBxUZkke+h/ma4s9qatXgQSugkNQnNuKkhY3RZ8OBjOBJYeUxdo3OplcNgeoe4E9 VTtvLhy+5izAHYm8/xfyL0NpHWACwF9nGCgT4= MIME-Version: 1.0 Received: by 10.216.185.78 with SMTP id t56mr229834wem.40.1276823512153; Thu, 17 Jun 2010 18:11:52 -0700 (PDT) Received: by 10.216.85.138 with HTTP; Thu, 17 Jun 2010 18:11:52 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB7200@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB71D3@P3PW5EX1MB01.EX1.SECURESERVER.NET> <35F209BF-D22B-4C3F-919F-15EAD4844A15@gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3EBB7200@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Fri, 18 Jun 2010 10:11:52 +0900 Message-ID: From: Nat Sakimura To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Status update X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jun 2010 01:11:55 -0000 I was wondering when you suggested to write an I-D about the request by reference (which started as mobile WebApp flow), you wanted it for the IPR reason or meant that it should be separate from the core. To cover both case, I have submit the I-D http://datatracker.ietf.org/doc/draft-sakimura-oauth-requrl/ "Request by Reference ver.1.0 for OAuth 2.0". I was referring to the subset of it, namely the introduction of "request_url" as the reference parameter for the request parameters to be "included." =nat @ Tokyo via iPhone On 2010/06/18, at 9:22, Eran Hammer-Lahav wrote: > Not sure what you are referring to. > > EHL > >> -----Original Message----- >> From: Nat [mailto:sakimura@gmail.com] >> Sent: Thursday, June 17, 2010 4:42 PM >> To: Eran Hammer-Lahav >> Cc: OAuth WG (oauth@ietf.org) >> Subject: Re: [OAUTH-WG] Status update >> >> What about the 'request_url' indirection (without sig and enc)? >> >> On 2010/06/18, at 6:36, Eran Hammer-Lahav >> wrote: >> >>> With the exception of extensibility, I consider draft -08 to be >>> feature complete. This means that the draft contains all the >>> features >>> and components needed and other then editorial work is close to >>> finished. I plan to finish work on the -09 draft by Mon or Tue next >>> week which will include the extensibility text, additional editorial >>> work, and resolution of the proposal to simplify the end- user >>> authorization endpoint. At that point, I intend to ask for an >>> interim >>> last-call on the normative language (i.e. the implementation >>> details). >>> >>> >>> >>> Note that this last-call isn't really a WG last call. The spec can c >>> hange after that. But it will be a useful milestone to figure out if >>> the draft's implementation details are stable and can be considered >>> complete. >>> >>> >>> >>> All of this of course requires the approval of the chairs. >>> >>> >>> >>> EHL >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Thu Jun 17 18:22:10 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 970A03A67B5 for ; Thu, 17 Jun 2010 18:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[AWL=0.426, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ToKTG1wav7id for ; Thu, 17 Jun 2010 18:22:07 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id BFDEB3A63CB for ; Thu, 17 Jun 2010 18:22:07 -0700 (PDT) Received: (qmail 17697 invoked from network); 18 Jun 2010 01:22:12 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 18 Jun 2010 01:22:11 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 17 Jun 2010 18:22:11 -0700 From: Eran Hammer-Lahav To: Nat Sakimura Date: Thu, 17 Jun 2010 18:22:07 -0700 Thread-Topic: [OAUTH-WG] Status update Thread-Index: AcsOgz2SmH61+73mR6mbKN7/C3+48gAAT+NQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB720B@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB71D3@P3PW5EX1MB01.EX1.SECURESERVER.NET> <35F209BF-D22B-4C3F-919F-15EAD4844A15@gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3EBB7200@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 \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Status update X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jun 2010 01:22:11 -0000 I don't care about IPR. I asked for it to be submitted as I-D because for now, I think we have cons= ensus to move it forward in that form. We can always merge it into core, bu= t for now, it is not part of core. Don't worry about this too much at this = moment. What you need to do is get consensus that the proposal in the I-D i= s solid and has wide support. Then try to merge it in. EHL > -----Original Message----- > From: Nat Sakimura [mailto:sakimura@gmail.com] > Sent: Thursday, June 17, 2010 6:12 PM > To: Eran Hammer-Lahav > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Status update >=20 > I was wondering when you suggested to write an I-D about the request by > reference (which started as mobile WebApp flow), you wanted it for the IP= R > reason or meant that it should be separate from the core. To cover both > case, I have submit the I-D http://datatracker.ietf.org/doc/draft-sakimur= a- > oauth-requrl/ "Request by Reference ver.1.0 for OAuth 2.0". I was referri= ng > to the subset of it, namely the introduction of "request_url" as the refe= rence > parameter for the request parameters to be "included." >=20 > =3Dnat @ Tokyo via iPhone >=20 > On 2010/06/18, at 9:22, Eran Hammer-Lahav wrote: >=20 > > Not sure what you are referring to. > > > > EHL > > > >> -----Original Message----- > >> From: Nat [mailto:sakimura@gmail.com] > >> Sent: Thursday, June 17, 2010 4:42 PM > >> To: Eran Hammer-Lahav > >> Cc: OAuth WG (oauth@ietf.org) > >> Subject: Re: [OAUTH-WG] Status update > >> > >> What about the 'request_url' indirection (without sig and enc)? > >> > >> On 2010/06/18, at 6:36, Eran Hammer-Lahav > >> wrote: > >> > >>> With the exception of extensibility, I consider draft -08 to be > >>> feature complete. This means that the draft contains all the > >>> features and components needed and other then editorial work is > >>> close to finished. I plan to finish work on the -09 draft by Mon or > >>> Tue next week which will include the extensibility text, additional > >>> editorial work, and resolution of the proposal to simplify the end- > >>> user authorization endpoint. At that point, I intend to ask for an > >>> interim last-call on the normative language (i.e. the implementation > >>> details). > >>> > >>> > >>> > >>> Note that this last-call isn't really a WG last call. The spec can c > >>> hange after that. But it will be a useful milestone to figure out if > >>> the draft's implementation details are stable and can be considered > >>> complete. > >>> > >>> > >>> > >>> All of this of course requires the approval of the chairs. > >>> > >>> > >>> > >>> EHL > >>> > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth From torsten@lodderstedt.net Thu Jun 17 23:51:23 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBC283A6949 for ; Thu, 17 Jun 2010 23:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.262 X-Spam-Level: X-Spam-Status: No, score=-1.262 tagged_above=-999 required=5 tests=[AWL=0.987, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5nfUyK-lKuH5 for ; Thu, 17 Jun 2010 23:51:23 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.26]) by core3.amsl.com (Postfix) with ESMTP id ED1E83A69B7 for ; Thu, 17 Jun 2010 23:51:22 -0700 (PDT) Received: from p4fff328c.dip.t-dialin.net ([79.255.50.140] helo=[127.0.0.1]) by smtprelay03.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OPVQE-0001jj-9j; Fri, 18 Jun 2010 08:51:26 +0200 Message-ID: <4C1B1766.7000701@lodderstedt.net> Date: Fri, 18 Jun 2010 08:51:18 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Brian Eaton References: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB68C9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <55E1F9D6-71EC-40CE-8103-790E823B8D58@lodderstedt.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Assertion flow: please add optional refresh_token in response X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jun 2010 06:51:23 -0000 Am 16.06.2010 00:35, schrieb Brian Eaton: > On Tue, Jun 15, 2010 at 8:54 AM, Torsten Lodderstedt > wrote: > >> Wouldn't it be an alternative solution, if the AS first tries to >> authenticate the user using SPNEGO within the Web Server flow? This should >> work in the inhouse scenario. If it fails, it can fall back to >> username/password auth.. >> > This would let you skip password entry, but I think you'd still > require user confirmation to grant the access. > which is ok, if you want to involve the user in the process. So he/her realizes what's going on. Otherwise, the assertion workflow would be the better choice. regards, Torsten. From balfanz@google.com Mon Jun 21 00:04:52 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CC943A66B4 for ; Mon, 21 Jun 2010 00:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.431 X-Spam-Level: X-Spam-Status: No, score=-103.431 tagged_above=-999 required=5 tests=[AWL=-1.056, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_BACKHAIR_42=1, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ieTLMuLcASTe for ; Mon, 21 Jun 2010 00:04:51 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 2A4833A6781 for ; Mon, 21 Jun 2010 00:04:51 -0700 (PDT) Received: from wpaz21.hot.corp.google.com (wpaz21.hot.corp.google.com [172.24.198.85]) by smtp-out.google.com with ESMTP id o5L74vn1028670 for ; Mon, 21 Jun 2010 00:04:57 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1277103897; bh=xXVAoAhlbCXWF9Qju1aQPYbu3sA=; h=MIME-Version:Date:Message-ID:Subject:From:To:Content-Type; b=vBN6V22YtwFVmUr9lo3+VdbSAAQ9C6mrQ261epQfn9Nbe8+RrkuVPjlqgJ2ANTfmS cGVgAiqmacF0p6puthp3Q== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:date:message-id:subject:from:to:content-type:x-system-of-record; b=MO1WVpdVENjEgBRm+brbWeG4R9VD9w0rsLV0LmnnjkmNPdzifXJK1rTZIqcRjcJ8b TjKalwISE34jJhxr8+4pg== Received: from iwn4 (iwn4.prod.google.com [10.241.68.68]) by wpaz21.hot.corp.google.com with ESMTP id o5L74Q3B010717 for ; Mon, 21 Jun 2010 00:04:56 -0700 Received: by iwn4 with SMTP id 4so3520814iwn.21 for ; Mon, 21 Jun 2010 00:04:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.169.6 with SMTP id w6mr4454008iby.5.1277103895850; Mon, 21 Jun 2010 00:04:55 -0700 (PDT) Received: by 10.231.139.231 with HTTP; Mon, 21 Jun 2010 00:04:55 -0700 (PDT) Date: Mon, 21 Jun 2010 00:04:55 -0700 Message-ID: From: Dirk Balfanz To: OAuth WG Content-Type: multipart/alternative; boundary=0016e6d26c550db17b048984ec90 X-System-Of-Record: true Subject: [OAUTH-WG] proposal for signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 07:04:52 -0000 --0016e6d26c550db17b048984ec90 Content-Type: text/plain; charset=ISO-8859-1 Hi guys, I think I owe the list a proposal for signatures. I wrote something down that liberally borrows ideas from Magic Signatures, SWT , and (even the name from) JSON Web Tokens . Here is a short document (called "JSON Tokens") that just explains how to sign something and verify the signature: http://docs.google.com/document/pub?id=1kv6Oz_HRnWa0DaJx_SQ5Qlk_yqs_7zNAm75-FmKwNo4 Here is an extension of JSON Tokens that can be used for signed OAuth tokens: http://docs.google.com/document/pub?id=1JUn3Twd9nXwFDgi-fTKl-unDG_ndyowTZW8OWX9HOUU Here is a different extension of JSON Tokens that can be used for 2-legged flows. The idea is that this could be used as a drop-in replacement for SAML assertions in the OAuth2 assertion flow: http://docs.google.com/document/pub?id=1s4kjRS9P0frG0ulhgP3He01ONlxeTwkFQV_pCoOowzc I also have started to write some codeto implement this as a proof-of-concept. Thoughts? Comments? Dirk. --0016e6d26c550db17b048984ec90 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi guys,=A0

    I think I owe = the list a proposal for signatures.

    I wrote something down th= at=A0liberally=A0borrows ideas from Magic Signatures, SWT, and (even the name from) JSO= N Web Tokens.=A0
    <= br>Here is a short docu= ment (called "JSON Tokens") that just explains how to sign someth= ing and verify the signature:
    http://docs.google.= com/document/pub?id=3D1kv6Oz_HRnWa0DaJx_SQ5Qlk_yqs_7zNAm75-FmKwNo4

    Here is an extension of JSON Tokens that = can be used for signed OAuth tokens:

    Here is a = different extension of JSON Tokens that can be used for 2-legged flows. The= idea is that this could be used as a drop-in replacement for SAML assertio= ns in the OAuth2 assertion flow:
    http://docs.google.= com/document/pub?id=3D1s4kjRS9P0frG0ulhgP3He01ONlxeTwkFQV_pCoOowzc

    I also have started to write some code to implement this as a proof-of-concept.=A0

    Thoughts? Comments?

    Dirk.

    --0016e6d26c550db17b048984ec90-- From benl@google.com Mon Jun 21 04:18:25 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAC453A6A5B for ; Mon, 21 Jun 2010 04:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8SQ3vHCVrhfF for ; Mon, 21 Jun 2010 04:18:25 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 9CC0D3A68C2 for ; Mon, 21 Jun 2010 04:18:24 -0700 (PDT) Received: from hpaq5.eem.corp.google.com (hpaq5.eem.corp.google.com [172.25.149.5]) by smtp-out.google.com with ESMTP id o5LBIU04009847 for ; Mon, 21 Jun 2010 04:18:30 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1277119110; bh=z7FAMW1UeWGYcEka3prY0pTb94s=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=qRxdiRYUWCLhvT5ayXorJuQNUnzQtuMRpcrIgejiUO1PGdiQ/4Fdn8ffitVXcvXuj n7tee8BqF8wo8vrBF8J+w== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=fhX1g9brn9qwSys5/YaeyghdQrJEz0isnj/EzHssXtheE/oKBLbbnnE5knoQAmyt1 i/LlwjODCG2bUk1fQoHEA== Received: from vws4 (vws4.prod.google.com [10.241.21.132]) by hpaq5.eem.corp.google.com with ESMTP id o5LBIS9v024534 for ; Mon, 21 Jun 2010 04:18:29 -0700 Received: by vws4 with SMTP id 4so515886vws.28 for ; Mon, 21 Jun 2010 04:18:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.80.105 with SMTP id s41mr1986041vck.192.1277119108189; Mon, 21 Jun 2010 04:18:28 -0700 (PDT) Received: by 10.220.57.205 with HTTP; Mon, 21 Jun 2010 04:18:28 -0700 (PDT) In-Reply-To: References: Date: Mon, 21 Jun 2010 12:18:28 +0100 Message-ID: From: Ben Laurie To: Dirk Balfanz 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] proposal for signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 11:18:26 -0000 On 21 June 2010 08:04, Dirk Balfanz wrote: > Hi guys, > I think I owe the list a proposal for signatures. > I wrote something down that=A0liberally=A0borrows ideas from Magic Signat= ures, > SWT, and (even the name from) JSON Web Tokens. > Here is a short document (called "JSON Tokens") that just explains how to > sign something and verify the signature: > http://docs.google.com/document/pub?id=3D1kv6Oz_HRnWa0DaJx_SQ5Qlk_yqs_7zN= Am75-FmKwNo4 "signature is a base64-encoded string of the signature bits." should be websafe-base64? "the current time is not after the expiration time of the token (defined as not_before + session_length)" should be not_before + token_lifetime, right? But I'd prefer a not_after instead. What is a Service Descriptor? Is this something to do with webfinger, or something else? In the HMAC keys section you describe the keys as symmetric, which is strictly accurate, but more normally called shared keys for this use. Obviously you'll need to be a bit more specific about what you mean by "RSA-SHA256". > Here is an extension of JSON Tokens that can be used for signed OAuth > tokens: > http://docs.google.com/document/pub?id=3D1JUn3Twd9nXwFDgi-fTKl-unDG_ndyow= TZW8OWX9HOUU As you know, I hate the term "non-repudation". Can't you just call it "sign= ing"? "Protection against leaked authentication tokens: Protocols such as OAuth2 use bearer tokens, which may leak when used over non-SSL. Signing requests when using bearer tokens lets the recipient of such a request verify that the issuer of the request was a legitimate holder of the bearer token." - only true if you make the checking of the nonce a MUST instead of "may". And even then, MitM wins, of course. Why is body_hash optional? > Here is a different extension of JSON Tokens that can be used for 2-legge= d > flows. The idea is that this could be used as a drop-in replacement for S= AML > assertions in the OAuth2 assertion flow: > http://docs.google.com/document/pub?id=3D1s4kjRS9P0frG0ulhgP3He01ONlxeTwk= FQV_pCoOowzc You use the abbreviation AS before the full name Authorization Server. > I also have started to write some code to implement this as a> proof-of-c= oncept. > > Thoughts? Comments? Nice. > Dirk. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From rrichards@cdatazone.org Mon Jun 21 04:54:29 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3FF63A6A6A for ; Mon, 21 Jun 2010 04:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.649 X-Spam-Level: X-Spam-Status: No, score=-0.649 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YOQ1lXvRIp8U for ; Mon, 21 Jun 2010 04:54:29 -0700 (PDT) Received: from smtp2go.com (smtp2go.com [207.58.142.213]) by core3.amsl.com (Postfix) with ESMTP id 0472A3A6956 for ; Mon, 21 Jun 2010 04:54:29 -0700 (PDT) Received: from [67.158.171.203] (helo=Rob-Richardss-MacBook-Pro.local) by smtp2go.com with esmtp (Exim 4.69) (envelope-from ) id 1OQfaA-0007s2-CS; Mon, 21 Jun 2010 11:54:30 +0000 Message-ID: <4C1F52F5.4080904@cdatazone.org> Date: Mon, 21 Jun 2010 07:54:29 -0400 From: Rob Richards User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Eran Hammer-Lahav References: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB71D3@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB71D3@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-SMTP2Go-MailScanner-Information: Please contact support@smtp2go.com for more information X-SMTP2Go-MailScanner-ID: 1OQfaA-0007s2-CS X-SMTP2Go-MailScanner: Found to be clean X-SMTP2Go-MailScanner-From: rrichards@cdatazone.org Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Status update X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 11:54:29 -0000 I still think that the issue of running both 1.0 and 2.0 on an resource endpoint needs to be addressed in the spec. It is unrealistic to think that a provider currently running 1.0 can just do a complete cutover to 2.0 and shut down 1.0 access, or providers arbitrarily making the decision what constitutes 1.0 and what constitutes 2.0. Personally I think that an oauth_version parameter should be required for the resource endpoint as it will definitely allow version to be determined and prevent this potential problem from any future versions as well. Others think that just by checking for non-existance of parameters would work, though it is only best guess at that point because it could be a 1.0 call requiring a 400 error to be returned. In either case, this really needs to be addressed in the spec so that all providers are doing the check in the exact same way to avoid ambiguity. Rob Eran Hammer-Lahav wrote: > > With the exception of extensibility, I consider draft -08 to be > feature complete. This means that the draft contains all the features > and components needed and other then editorial work is close to > finished. I plan to finish work on the -09 draft by Mon or Tue next > week which will include the extensibility text, additional editorial > work, and resolution of the proposal to simplify the end-user > authorization endpoint. At that point, I intend to ask for an interim > last-call on the normative language (i.e. the implementation details). > > Note that this last-call isn’t really a WG last call. The spec can > change after that. But it will be a useful milestone to figure out if > the draft’s implementation details are stable and can be considered > complete. > > All of this of course requires the approval of the chairs. > From sakimura@gmail.com Mon Jun 21 06:22:52 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72AA23A69A6 for ; Mon, 21 Jun 2010 06:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.02 X-Spam-Level: X-Spam-Status: No, score=-1.02 tagged_above=-999 required=5 tests=[AWL=-1.021, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OdYK-PlmTILK for ; Mon, 21 Jun 2010 06:22:50 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 24EC73A6867 for ; Mon, 21 Jun 2010 06:22:50 -0700 (PDT) Received: by iwn9 with SMTP id 9so504260iwn.31 for ; Mon, 21 Jun 2010 06:22:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=2k3IblJbETbQYmSnVR+pvZIYSNFdYfShbCD5Kyv6M1Y=; b=pgl6gwFS9flYYtbOFqFjKq99A8Mg+v8s7aEmrWecqkzfiAccuArlp9xrXieUF9GZ3/ 7nLADrMwPsIcfA6W20D4VAiQJGDgQGhCpKs55yxZZipaIiN137EbL1csOKWCFTPmBX4N H16NKcMHPs9rJ73dItjNDlAVcoMlMKnpbLB50= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=x4CLXiwyEl4qYPBr+2ggrv/JpFgA5leEB10iz/TnYubY5p3NtbZmkFqVG8/3sdOAzv 79Qtj79cQaIC121mopJFNwGF5+RIP4M1PL4JXYDW/ZyNz7PpAIMXPFBw+zg0cyCKOKbi Cslws7d+vvitxOppeZv15j+lyej+t+LxMzIh0= MIME-Version: 1.0 Received: by 10.42.36.139 with SMTP id u11mr1741282icd.76.1277126573736; Mon, 21 Jun 2010 06:22:53 -0700 (PDT) Received: by 10.231.17.139 with HTTP; Mon, 21 Jun 2010 06:22:53 -0700 (PDT) In-Reply-To: References: Date: Mon, 21 Jun 2010 22:22:53 +0900 Message-ID: From: Nat Sakimura To: Dirk Balfanz , Ben Laurie Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 13:22:52 -0000 Hi Dirk, In addition to Ben's questions, I have another. For X.509, you seem to be using DER. How do you express the entire certificate chain using DER? (With PEM, you can just concatenate ... ) And here is some comments: If body_hash is not used, it seems it is just doing the client authentication via asymmetric crypto. This is a valid use case, and actually is quite nice. I think this is the main use case. If we wanted to make sure that the request itself is not tampered, we need to sign the body. For this, I somehow feel that Magic Signatures is more interoperable since it actually sends the armored ASCII strings with it. =3Dnat On Mon, Jun 21, 2010 at 8:18 PM, Ben Laurie wrote: > On 21 June 2010 08:04, Dirk Balfanz wrote: >> Hi guys, >> I think I owe the list a proposal for signatures. >> I wrote something down that=A0liberally=A0borrows ideas from Magic Signa= tures, >> SWT, and (even the name from) JSON Web Tokens. >> Here is a short document (called "JSON Tokens") that just explains how t= o >> sign something and verify the signature: >> http://docs.google.com/document/pub?id=3D1kv6Oz_HRnWa0DaJx_SQ5Qlk_yqs_7z= NAm75-FmKwNo4 > > "signature is a base64-encoded string of the signature bits." should > be websafe-base64? > > "the current time is not after the expiration time of the token > (defined as not_before + session_length)" should be not_before + > token_lifetime, right? But I'd prefer a not_after instead. > > What is a Service Descriptor? Is this something to do with webfinger, > or something else? > > In the HMAC keys section you describe the keys as symmetric, which is > strictly accurate, but more normally called shared keys for this use. > > Obviously you'll need to be a bit more specific about what you mean by > "RSA-SHA256". > >> Here is an extension of JSON Tokens that can be used for signed OAuth >> tokens: >> http://docs.google.com/document/pub?id=3D1JUn3Twd9nXwFDgi-fTKl-unDG_ndyo= wTZW8OWX9HOUU > > As you know, I hate the term "non-repudation". Can't you just call it "si= gning"? > > "Protection against leaked authentication tokens: Protocols such as > OAuth2 use bearer tokens, which may leak when used over non-SSL. > Signing requests when using bearer tokens lets the recipient of such a > request verify that the issuer of the request was a legitimate holder > of the bearer token." - only true if you make the checking of the > nonce a MUST instead of "may". And even then, MitM wins, of course. > > Why is body_hash optional? > >> Here is a different extension of JSON Tokens that can be used for 2-legg= ed >> flows. The idea is that this could be used as a drop-in replacement for = SAML >> assertions in the OAuth2 assertion flow: >> http://docs.google.com/document/pub?id=3D1s4kjRS9P0frG0ulhgP3He01ONlxeTw= kFQV_pCoOowzc > > You use the abbreviation AS before the full name Authorization Server. > >> I also have started to write some code to implement this as a> proof-of-= concept. >> >> Thoughts? Comments? > > Nice. > >> Dirk. >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 Nat Sakimura (=3Dnat) http://www.sakimura.org/en/ http://twitter.com/_nat_en From benl@google.com Mon Jun 21 06:26:45 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BC0B3A677D for ; Mon, 21 Jun 2010 06:26:45 -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_41=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xfLZM-5Dpfv4 for ; Mon, 21 Jun 2010 06:26:43 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id B8F603A69C3 for ; Mon, 21 Jun 2010 06:26:43 -0700 (PDT) Received: from hpaq13.eem.corp.google.com (hpaq13.eem.corp.google.com [172.25.149.13]) by smtp-out.google.com with ESMTP id o5LDQn8u013008 for ; Mon, 21 Jun 2010 06:26:49 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1277126809; bh=mQMv6b5ZoeWix+Dw01it+0thOIA=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=FsF5/TmIzuOOSV+OTZi3esEKADuMTU7QIKCitjEV56+m61IyAyyEofPhk73xRxfBi I/5Tp1MTrdvJXwpoKWncw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=j5Dng1Fjr2uMS8gjWdcikHLj9OiuXAGld9TEB2lXYgcUunTWsEhUbIdjywhEdeC67 GaV1NqzXWfB4lvLjm7ukw== Received: from vws19 (vws19.prod.google.com [10.241.21.147]) by hpaq13.eem.corp.google.com with ESMTP id o5LDQlV2029121 for ; Mon, 21 Jun 2010 06:26:48 -0700 Received: by vws19 with SMTP id 19so1486994vws.6 for ; Mon, 21 Jun 2010 06:26:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.62.197 with SMTP id y5mr2066184vch.248.1277126807107; Mon, 21 Jun 2010 06:26:47 -0700 (PDT) Received: by 10.220.57.205 with HTTP; Mon, 21 Jun 2010 06:26:47 -0700 (PDT) In-Reply-To: References: Date: Mon, 21 Jun 2010 14:26:47 +0100 Message-ID: From: Ben Laurie To: Nat Sakimura 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] proposal for signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 13:26:45 -0000 On 21 June 2010 14:22, Nat Sakimura wrote: > Hi Dirk, > > In addition to Ben's questions, I have another. For X.509, you seem to > be using DER. How do you express the entire certificate chain using > DER? > (With PEM, you can just concatenate ... ) With DER you can concatenate, too, of course. There's also PKCS#n (for some value of n which I forget ... 12?) which allows bundling of cert chains. > > And here is some comments: > > If body_hash is not used, it seems it is just doing the client > authentication via asymmetric crypto. > This is a valid use case, and actually is quite nice. I think this is > the main use case. > > If we wanted to make sure that the request itself is not tampered, we > need to sign the body. > For this, I somehow feel that Magic Signatures is more interoperable > since it actually sends the armored ASCII strings with it. > > =3Dnat > > > > On Mon, Jun 21, 2010 at 8:18 PM, Ben Laurie wrote: >> On 21 June 2010 08:04, Dirk Balfanz wrote: >>> Hi guys, >>> I think I owe the list a proposal for signatures. >>> I wrote something down that=A0liberally=A0borrows ideas from Magic Sign= atures, >>> SWT, and (even the name from) JSON Web Tokens. >>> Here is a short document (called "JSON Tokens") that just explains how = to >>> sign something and verify the signature: >>> http://docs.google.com/document/pub?id=3D1kv6Oz_HRnWa0DaJx_SQ5Qlk_yqs_7= zNAm75-FmKwNo4 >> >> "signature is a base64-encoded string of the signature bits." should >> be websafe-base64? >> >> "the current time is not after the expiration time of the token >> (defined as not_before + session_length)" should be not_before + >> token_lifetime, right? But I'd prefer a not_after instead. >> >> What is a Service Descriptor? Is this something to do with webfinger, >> or something else? >> >> In the HMAC keys section you describe the keys as symmetric, which is >> strictly accurate, but more normally called shared keys for this use. >> >> Obviously you'll need to be a bit more specific about what you mean by >> "RSA-SHA256". >> >>> Here is an extension of JSON Tokens that can be used for signed OAuth >>> tokens: >>> http://docs.google.com/document/pub?id=3D1JUn3Twd9nXwFDgi-fTKl-unDG_ndy= owTZW8OWX9HOUU >> >> As you know, I hate the term "non-repudation". Can't you just call it "s= igning"? >> >> "Protection against leaked authentication tokens: Protocols such as >> OAuth2 use bearer tokens, which may leak when used over non-SSL. >> Signing requests when using bearer tokens lets the recipient of such a >> request verify that the issuer of the request was a legitimate holder >> of the bearer token." - only true if you make the checking of the >> nonce a MUST instead of "may". And even then, MitM wins, of course. >> >> Why is body_hash optional? >> >>> Here is a different extension of JSON Tokens that can be used for 2-leg= ged >>> flows. The idea is that this could be used as a drop-in replacement for= SAML >>> assertions in the OAuth2 assertion flow: >>> http://docs.google.com/document/pub?id=3D1s4kjRS9P0frG0ulhgP3He01ONlxeT= wkFQV_pCoOowzc >> >> You use the abbreviation AS before the full name Authorization Server. >> >>> I also have started to write some code to implement this as a> proof-of= -concept. >>> >>> Thoughts? Comments? >> >> Nice. >> >>> Dirk. >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > > > -- > Nat Sakimura (=3Dnat) > http://www.sakimura.org/en/ > http://twitter.com/_nat_en > From hardjono@mit.edu Mon Jun 21 07:10:08 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 767BF3A67DB for ; Mon, 21 Jun 2010 07:10:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[AWL=-0.663, BAYES_50=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BVxPGtM0H7yo for ; Mon, 21 Jun 2010 07:10:05 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (DMZ-MAILSEC-SCANNER-8.MIT.EDU [18.7.68.37]) by core3.amsl.com (Postfix) with ESMTP id 5AAC33A681C for ; Mon, 21 Jun 2010 07:10:04 -0700 (PDT) X-AuditID: 12074425-b7c68ae000000a19-74-4c1f72c2d571 Received: from mailhub-auth-1.mit.edu (MAILHUB-AUTH-1.MIT.EDU [18.9.21.35]) by dmz-mailsec-scanner-8.mit.edu (Symantec Brightmail Gateway) with SMTP id AA.DF.02585.2C27F1C4; Mon, 21 Jun 2010 10:10:10 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-EXCHANGE-1.MIT.EDU [18.9.28.15]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id o5LEAA6r009348; Mon, 21 Jun 2010 10:10:10 -0400 Received: from oc11exedge1.exchange.mit.edu (OC11EXEDGE1.EXCHANGE.MIT.EDU [18.9.3.17]) ) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id o5LEA4CE009591; Mon, 21 Jun 2010 10:10:09 -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.1.393.1; Mon, 21 Jun 2010 10:09:23 -0400 Received: from EXPO10.exchange.mit.edu ([18.9.4.15]) by oc11exhub6.exchange.mit.edu ([18.9.3.16]) with mapi; Mon, 21 Jun 2010 10:10:07 -0400 From: Thomas Hardjono To: Rob Richards , Eran Hammer-Lahav Date: Mon, 21 Jun 2010 10:10:06 -0400 Thread-Topic: [OAUTH-WG] Status update Thread-Index: AcsROIgkG+Tuhs1BSgibwpzj6dFG5AAEe+Yw Message-ID: References: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB71D3@P3PW5EX1MB01.EX1.SECURESERVER.NET>, <4C1F52F5.4080904@cdatazone.org> In-Reply-To: <4C1F52F5.4080904@cdatazone.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Status update X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 14:10:08 -0000 Another newbie question: what is the technical reason for NOT including an oauth protocol version number? Including protocol versions numbering is the norm in most/all IETF protocol= s. Also exchange types, cipher types, etc. etc. /thomas/ ________________________________________ From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Rob Rich= ards [rrichards@cdatazone.org] Sent: Monday, June 21, 2010 7:54 AM To: Eran Hammer-Lahav Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Status update I still think that the issue of running both 1.0 and 2.0 on an resource endpoint needs to be addressed in the spec. It is unrealistic to think that a provider currently running 1.0 can just do a complete cutover to 2.0 and shut down 1.0 access, or providers arbitrarily making the decision what constitutes 1.0 and what constitutes 2.0. Personally I think that an oauth_version parameter should be required for the resource endpoint as it will definitely allow version to be determined and prevent this potential problem from any future versions as well. Others think that just by checking for non-existance of parameters would work, though it is only best guess at that point because it could be a 1.0 call requiring a 400 error to be returned. In either case, this really needs to be addressed in the spec so that all providers are doing the check in the exact same way to avoid ambiguity. Rob Eran Hammer-Lahav wrote: > > With the exception of extensibility, I consider draft -08 to be > feature complete. This means that the draft contains all the features > and components needed and other then editorial work is close to > finished. I plan to finish work on the -09 draft by Mon or Tue next > week which will include the extensibility text, additional editorial > work, and resolution of the proposal to simplify the end-user > authorization endpoint. At that point, I intend to ask for an interim > last-call on the normative language (i.e. the implementation details). > > Note that this last-call isn=92t really a WG last call. The spec can > change after that. But it will be a useful milestone to figure out if > the draft=92s implementation details are stable and can be considered > complete. > > All of this of course requires the approval of the chairs. > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From dick.hardt@gmail.com Mon Jun 21 07:22:25 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE8243A67CF for ; Mon, 21 Jun 2010 07:22:25 -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.226, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P5l9b3oLOSBW for ; Mon, 21 Jun 2010 07:22:24 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id CC4F528C0F0 for ; Mon, 21 Jun 2010 07:22:24 -0700 (PDT) Received: by pwi6 with SMTP id 6so1225554pwi.31 for ; Mon, 21 Jun 2010 07:22:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=evNllVp3UHp1NdNtiKeCBan0j8zluX9ve0RfERWHZ/Y=; b=i21WiEUG+JzeYRa1RPB23OARqhGHM9UgN3B2tPX9jKwdRs6z587TJudgkFsPM3wEJQ siZRXTxzXESx4tyxEfRDRabgdh7L31YVE2WAGkAumBdS6EIowd4vToc9dfgVWeu5Ltpj WEYNMthCgead9ba9ohJ53zpbrWuCsTo3BNFnc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=gIHm6gz7nFs/wZW/YETLAgE4nlxrC7Ra/c2XgFMbw0+UUOGjXX0yolY4ruZ5zbswFA 63S3pSQm5zjdhJGYQM8sMYkgghqJhMjmpkO86857BUWVq0I4Thc4xW95TXpvgBz8H9h/ DppNpdJam39oVbhsQHOCWghIXIIibVpO1YJYI= Received: by 10.115.112.22 with SMTP id p22mr3949715wam.53.1277130148466; Mon, 21 Jun 2010 07:22:28 -0700 (PDT) Received: from [192.168.1.2] (c-24-130-32-55.hsd1.ca.comcast.net [24.130.32.55]) by mx.google.com with ESMTPS id c22sm85465028wam.18.2010.06.21.07.22.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 21 Jun 2010 07:22:27 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=windows-1252 From: Dick Hardt In-Reply-To: <4C1F52F5.4080904@cdatazone.org> Date: Mon, 21 Jun 2010 07:22:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB71D3@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C1F52F5.4080904@cdatazone.org> To: Rob Richards X-Mailer: Apple Mail (2.1078) Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Status update X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 14:22:25 -0000 Good point that version checking be clearly included in the spec. On 2010-06-21, at 4:54 AM, Rob Richards wrote: > I still think that the issue of running both 1.0 and 2.0 on an = resource endpoint needs to be addressed in the spec. It is unrealistic = to think that a provider currently running 1.0 can just do a complete = cutover to 2.0 and shut down 1.0 access, or providers arbitrarily making = the decision what constitutes 1.0 and what constitutes 2.0. Personally I = think that an oauth_version parameter should be required for the = resource endpoint as it will definitely allow version to be determined = and prevent this potential problem from any future versions as well. = Others think that just by checking for non-existance of parameters would = work, though it is only best guess at that point because it could be a = 1.0 call requiring a 400 error to be returned. In either case, this = really needs to be addressed in the spec so that all providers are doing = the check in the exact same way to avoid ambiguity. >=20 > Rob >=20 > Eran Hammer-Lahav wrote: >>=20 >> With the exception of extensibility, I consider draft -08 to be = feature complete. This means that the draft contains all the features = and components needed and other then editorial work is close to = finished. I plan to finish work on the -09 draft by Mon or Tue next week = which will include the extensibility text, additional editorial work, = and resolution of the proposal to simplify the end-user authorization = endpoint. At that point, I intend to ask for an interim last-call on the = normative language (i.e. the implementation details). >>=20 >> Note that this last-call isn=92t really a WG last call. The spec can = change after that. But it will be a useful milestone to figure out if = the draft=92s implementation details are stable and can be considered = complete. >>=20 >> All of this of course requires the approval of the chairs. >>=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From dick.hardt@gmail.com Mon Jun 21 07:43:16 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 005EC3A6826 for ; Mon, 21 Jun 2010 07:43:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.391 X-Spam-Level: X-Spam-Status: No, score=-2.391 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6CesR0h3tY3 for ; Mon, 21 Jun 2010 07:43:14 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id E8DA53A6803 for ; Mon, 21 Jun 2010 07:43:12 -0700 (PDT) Received: by pxi5 with SMTP id 5so1481388pxi.31 for ; Mon, 21 Jun 2010 07:43:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:message-id:references:to :x-mailer; bh=c0X2WtmNIE/4Wg4QeqeE+ilLfHiXLavyTPYokMrlnSA=; b=L93na32oYiKXR0rJeL4mUck9dkfIlDfAj0rx86XyyYirckhF/qJ8GNnmTrdFjaAvAv VpRx0nCpkRq9uC2o86JlbMcbHPXDycuYHzabH6utLX1V72ph52sBjGcX0UGnU3RgUo0/ plnhJpNdgRZF22KsxknCtpiV5v33zQ/LfLbBM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; b=kOFi451T7UiVSWdGcwMoqxEjr0HPigJKgI4IvExlAlf6QDaXlh6VaU8WmjQGx+eBR/ lTFGvrt9qDBgf0KSX9yoK3QaU1BeokVnMxgd3w792L/bILA50IwHIpNNIuSpAXaie1mW AFTQMRnMJMFWWD1y0tA+j098xz1gGtPXR/vNM= Received: by 10.114.186.21 with SMTP id j21mr3977490waf.71.1277131397189; Mon, 21 Jun 2010 07:43:17 -0700 (PDT) Received: from [192.168.1.2] (c-24-130-32-55.hsd1.ca.comcast.net [24.130.32.55]) by mx.google.com with ESMTPS id c14sm57742660waa.13.2010.06.21.07.43.15 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 21 Jun 2010 07:43:15 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/alternative; boundary=Apple-Mail-2-323967201 From: Dick Hardt In-Reply-To: Date: Mon, 21 Jun 2010 07:43:14 -0700 Message-Id: References: To: Dirk Balfanz X-Mailer: Apple Mail (2.1078) Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 14:43:16 -0000 --Apple-Mail-2-323967201 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks for writing this up Dirk. I would suggest that the token be: payload "." envelope "." signature This enables the payload to be encrypted and independent from the = envelope.=20 Token signing, verification, encryption and decryption code can then be = generic and not understand the payload of the token.=20 I would only include issuer, key_id and alg in the envelope.=20 Audience, scope, nonce, and validation time information etc. would be in = the payload. -- Dick On 2010-06-21, at 12:04 AM, Dirk Balfanz wrote: > Hi guys,=20 >=20 > I think I owe the list a proposal for signatures. >=20 > I wrote something down that liberally borrows ideas from Magic = Signatures, SWT, and (even the name from) JSON Web Tokens.=20 >=20 > Here is a short document (called "JSON Tokens") that just explains how = to sign something and verify the signature: > = http://docs.google.com/document/pub?id=3D1kv6Oz_HRnWa0DaJx_SQ5Qlk_yqs_7zNA= m75-FmKwNo4 >=20 > Here is an extension of JSON Tokens that can be used for signed OAuth = tokens: > = http://docs.google.com/document/pub?id=3D1JUn3Twd9nXwFDgi-fTKl-unDG_ndyowT= ZW8OWX9HOUU >=20 > Here is a different extension of JSON Tokens that can be used for = 2-legged flows. The idea is that this could be used as a drop-in = replacement for SAML assertions in the OAuth2 assertion flow: > = http://docs.google.com/document/pub?id=3D1s4kjRS9P0frG0ulhgP3He01ONlxeTwkF= QV_pCoOowzc >=20 > I also have started to write some code to implement this as a = proof-of-concept.=20 >=20 > Thoughts? Comments? >=20 > Dirk. >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-2-323967201 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii payload "." envelope "." = signature

    This enables the payload to be = encrypted and independent from the = envelope. 

    Token signing, verification, = encryption and decryption code can then be generic and not understand = the payload of the token. 

    I would only = include issuer, key_id and alg in the = envelope. 

    Audience, scope, nonce, and = validation time information etc. would be in the = payload.

    -- Dick

    On = 2010-06-21, at 12:04 AM, Dirk Balfanz wrote:

    Hi = guys, 

    I think I owe the list a proposal for = signatures.

    I wrote = something down that liberally borrows ideas from Magic Signatures, SWT, and (even = the name from) JSON Web Tokens. 

    Here is a short document (called "JSON = Tokens") that just explains how to sign something and verify the = signature:
    http://docs.google.com/document/pub?id=3D1kv6Oz_HRnWa0DaJx_SQ5Qlk_yqs_7z= NAm75-FmKwNo4
    Here is = an extension of JSON Tokens that can be used for signed OAuth tokens:

    Here = is a different extension of JSON Tokens that can be used for 2-legged = flows. The idea is that this could be used as a drop-in replacement for = SAML assertions in the OAuth2 assertion flow:
    http://docs.google.com/document/pub?id=3D1s4kjRS9P0frG0ulhgP3He01ONlxeTw= kFQV_pCoOowzc

    I also have started to write some code to implement this as a = proof-of-concept. 

    Thoughts? Comments?

    Dirk.

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

    = --Apple-Mail-2-323967201-- From sakimura@gmail.com Mon Jun 21 08:33:11 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F1463A6800 for ; Mon, 21 Jun 2010 08:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.941 X-Spam-Level: X-Spam-Status: No, score=-1.941 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, J_CHICKENPOX_41=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jX+Fm2tGPrR0 for ; Mon, 21 Jun 2010 08:33:10 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 691753A6818 for ; Mon, 21 Jun 2010 08:33:09 -0700 (PDT) Received: by iwn9 with SMTP id 9so616680iwn.31 for ; Mon, 21 Jun 2010 08:33:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=YGuvXXETd/y2/xHGU1ndAV2/1wNi41t7M4OgviUaO/E=; b=uuXdUDLZwtyx67Eh8Awd5JJ/E27d6ToUZ61lkD7Io4cvUbBBNAU2KmhTxIbGxFbqRI YAuRbU5jAESZOl7QzsOn9sRAo53GWs9wlkukH26i3i84KF2AKfwFuXSQsv3XrIleoWWp omrpYPIpqyxbAaMh3zKnmyivD2ullrKftVpwc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=viwTS6uRLWZANMmJiVpQNEKQPX9RKVWQJzvt3TSsJ4MeFdu6z29Kbdp8ST79sGNUsJ hg9X2kqwnZxMSptMirPxJZJs4+uOjF1blU0mN+JQM+MQ7eaAAy4rV1pyOd4eRJgfDspH FFVRkkJFSUFRoB8D5+Rmml4SQ4Rg3s1zqIHWo= MIME-Version: 1.0 Received: by 10.231.157.205 with SMTP id c13mr5980950ibx.53.1277134392846; Mon, 21 Jun 2010 08:33:12 -0700 (PDT) Received: by 10.231.17.139 with HTTP; Mon, 21 Jun 2010 08:33:12 -0700 (PDT) In-Reply-To: References: Date: Tue, 22 Jun 2010 00:33:12 +0900 Message-ID: From: Nat Sakimura To: Ben Laurie Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 15:33:11 -0000 On Mon, Jun 21, 2010 at 10:26 PM, Ben Laurie wrote: > On 21 June 2010 14:22, Nat Sakimura wrote: >> Hi Dirk, >> >> In addition to Ben's questions, I have another. For X.509, you seem to >> be using DER. How do you express the entire certificate chain using >> DER? >> (With PEM, you can just concatenate ... ) > > With DER you can concatenate, too, of course. There's also PKCS#n (for > some value of n which I forget ... 12?) which allows bundling of cert > chains. That's PKCS#12, I suppose. I had under an impression that PKCS#12 includes = the private key, though. > >> >> And here is some comments: >> >> If body_hash is not used, it seems it is just doing the client >> authentication via asymmetric crypto. >> This is a valid use case, and actually is quite nice. I think this is >> the main use case. >> >> If we wanted to make sure that the request itself is not tampered, we >> need to sign the body. >> For this, I somehow feel that Magic Signatures is more interoperable >> since it actually sends the armored ASCII strings with it. >> >> =3Dnat >> >> >> >> On Mon, Jun 21, 2010 at 8:18 PM, Ben Laurie wrote: >>> On 21 June 2010 08:04, Dirk Balfanz wrote: >>>> Hi guys, >>>> I think I owe the list a proposal for signatures. >>>> I wrote something down that=A0liberally=A0borrows ideas from Magic Sig= natures, >>>> SWT, and (even the name from) JSON Web Tokens. >>>> Here is a short document (called "JSON Tokens") that just explains how= to >>>> sign something and verify the signature: >>>> http://docs.google.com/document/pub?id=3D1kv6Oz_HRnWa0DaJx_SQ5Qlk_yqs_= 7zNAm75-FmKwNo4 >>> >>> "signature is a base64-encoded string of the signature bits." should >>> be websafe-base64? >>> >>> "the current time is not after the expiration time of the token >>> (defined as not_before + session_length)" should be not_before + >>> token_lifetime, right? But I'd prefer a not_after instead. >>> >>> What is a Service Descriptor? Is this something to do with webfinger, >>> or something else? >>> >>> In the HMAC keys section you describe the keys as symmetric, which is >>> strictly accurate, but more normally called shared keys for this use. >>> >>> Obviously you'll need to be a bit more specific about what you mean by >>> "RSA-SHA256". >>> >>>> Here is an extension of JSON Tokens that can be used for signed OAuth >>>> tokens: >>>> http://docs.google.com/document/pub?id=3D1JUn3Twd9nXwFDgi-fTKl-unDG_nd= yowTZW8OWX9HOUU >>> >>> As you know, I hate the term "non-repudation". Can't you just call it "= signing"? >>> >>> "Protection against leaked authentication tokens: Protocols such as >>> OAuth2 use bearer tokens, which may leak when used over non-SSL. >>> Signing requests when using bearer tokens lets the recipient of such a >>> request verify that the issuer of the request was a legitimate holder >>> of the bearer token." - only true if you make the checking of the >>> nonce a MUST instead of "may". And even then, MitM wins, of course. >>> >>> Why is body_hash optional? >>> >>>> Here is a different extension of JSON Tokens that can be used for 2-le= gged >>>> flows. The idea is that this could be used as a drop-in replacement fo= r SAML >>>> assertions in the OAuth2 assertion flow: >>>> http://docs.google.com/document/pub?id=3D1s4kjRS9P0frG0ulhgP3He01ONlxe= TwkFQV_pCoOowzc >>> >>> You use the abbreviation AS before the full name Authorization Server. >>> >>>> I also have started to write some code to implement this as a> proof-o= f-concept. >>>> >>>> Thoughts? Comments? >>> >>> Nice. >>> >>>> Dirk. >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> >> >> >> -- >> Nat Sakimura (=3Dnat) >> http://www.sakimura.org/en/ >> http://twitter.com/_nat_en >> > --=20 Nat Sakimura (=3Dnat) http://www.sakimura.org/en/ http://twitter.com/_nat_en From benl@google.com Mon Jun 21 08:43:41 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71E793A681E for ; Mon, 21 Jun 2010 08:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.677 X-Spam-Level: X-Spam-Status: No, score=-101.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_41=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zudUUKJhvToI for ; Mon, 21 Jun 2010 08:43:40 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id DA5923A6800 for ; Mon, 21 Jun 2010 08:43:39 -0700 (PDT) Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id o5LFhiXN015102 for ; Mon, 21 Jun 2010 08:43:45 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1277135025; bh=LIQOmAXB6TdFVxK28/oXB1tQW5w=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=t5ibL9wjpOzjixaGH3175OTu1VY93zJhScD6GwcmhcRY7oJc8u3S2SfjQDtJ/z2au Ppw9B2NOcU2XsuGYljXgA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=Uoa+mwKPFhcnP5PLNeHmXgAJF5ZJEDYjGtAC2xbSdXFX2CxayI6unfaCVx68qUm0N yDUrNq12U1+WY+6LRZQVg== Received: from yxk30 (yxk30.prod.google.com [10.190.3.158]) by wpaz17.hot.corp.google.com with ESMTP id o5LFhg91023600 for ; Mon, 21 Jun 2010 08:43:43 -0700 Received: by yxk30 with SMTP id 30so469807yxk.6 for ; Mon, 21 Jun 2010 08:43:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.112.5 with SMTP id u5mr3206985qap.81.1277135021910; Mon, 21 Jun 2010 08:43:41 -0700 (PDT) Received: by 10.220.57.205 with HTTP; Mon, 21 Jun 2010 08:43:41 -0700 (PDT) In-Reply-To: References: Date: Mon, 21 Jun 2010 16:43:41 +0100 Message-ID: From: Ben Laurie To: Nat Sakimura 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] proposal for signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 15:43:41 -0000 On 21 June 2010 16:33, Nat Sakimura wrote: > On Mon, Jun 21, 2010 at 10:26 PM, Ben Laurie wrote: >> On 21 June 2010 14:22, Nat Sakimura wrote: >>> Hi Dirk, >>> >>> In addition to Ben's questions, I have another. For X.509, you seem to >>> be using DER. How do you express the entire certificate chain using >>> DER? >>> (With PEM, you can just concatenate ... ) >> >> With DER you can concatenate, too, of course. There's also PKCS#n (for >> some value of n which I forget ... 12?) which allows bundling of cert >> chains. > > That's PKCS#12, I suppose. I had under an impression that PKCS#12 include= s the > private key, though. Doesn't have to, though admittedly it isn't quite designed for this application. Presumably if we went down this route we'd have do no encryption and a well-known "secret" for the HMAC key. > >> >>> >>> And here is some comments: >>> >>> If body_hash is not used, it seems it is just doing the client >>> authentication via asymmetric crypto. >>> This is a valid use case, and actually is quite nice. I think this is >>> the main use case. >>> >>> If we wanted to make sure that the request itself is not tampered, we >>> need to sign the body. >>> For this, I somehow feel that Magic Signatures is more interoperable >>> since it actually sends the armored ASCII strings with it. >>> >>> =3Dnat >>> >>> >>> >>> On Mon, Jun 21, 2010 at 8:18 PM, Ben Laurie wrote: >>>> On 21 June 2010 08:04, Dirk Balfanz wrote: >>>>> Hi guys, >>>>> I think I owe the list a proposal for signatures. >>>>> I wrote something down that=A0liberally=A0borrows ideas from Magic Si= gnatures, >>>>> SWT, and (even the name from) JSON Web Tokens. >>>>> Here is a short document (called "JSON Tokens") that just explains ho= w to >>>>> sign something and verify the signature: >>>>> http://docs.google.com/document/pub?id=3D1kv6Oz_HRnWa0DaJx_SQ5Qlk_yqs= _7zNAm75-FmKwNo4 >>>> >>>> "signature is a base64-encoded string of the signature bits." should >>>> be websafe-base64? >>>> >>>> "the current time is not after the expiration time of the token >>>> (defined as not_before + session_length)" should be not_before + >>>> token_lifetime, right? But I'd prefer a not_after instead. >>>> >>>> What is a Service Descriptor? Is this something to do with webfinger, >>>> or something else? >>>> >>>> In the HMAC keys section you describe the keys as symmetric, which is >>>> strictly accurate, but more normally called shared keys for this use. >>>> >>>> Obviously you'll need to be a bit more specific about what you mean by >>>> "RSA-SHA256". >>>> >>>>> Here is an extension of JSON Tokens that can be used for signed OAuth >>>>> tokens: >>>>> http://docs.google.com/document/pub?id=3D1JUn3Twd9nXwFDgi-fTKl-unDG_n= dyowTZW8OWX9HOUU >>>> >>>> As you know, I hate the term "non-repudation". Can't you just call it = "signing"? >>>> >>>> "Protection against leaked authentication tokens: Protocols such as >>>> OAuth2 use bearer tokens, which may leak when used over non-SSL. >>>> Signing requests when using bearer tokens lets the recipient of such a >>>> request verify that the issuer of the request was a legitimate holder >>>> of the bearer token." - only true if you make the checking of the >>>> nonce a MUST instead of "may". And even then, MitM wins, of course. >>>> >>>> Why is body_hash optional? >>>> >>>>> Here is a different extension of JSON Tokens that can be used for 2-l= egged >>>>> flows. The idea is that this could be used as a drop-in replacement f= or SAML >>>>> assertions in the OAuth2 assertion flow: >>>>> http://docs.google.com/document/pub?id=3D1s4kjRS9P0frG0ulhgP3He01ONlx= eTwkFQV_pCoOowzc >>>> >>>> You use the abbreviation AS before the full name Authorization Server. >>>> >>>>> I also have started to write some code to implement this as a> proof-= of-concept. >>>>> >>>>> Thoughts? Comments? >>>> >>>> Nice. >>>> >>>>> Dirk. >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> >>> >>> >>> -- >>> Nat Sakimura (=3Dnat) >>> http://www.sakimura.org/en/ >>> http://twitter.com/_nat_en >>> >> > > > > -- > Nat Sakimura (=3Dnat) > http://www.sakimura.org/en/ > http://twitter.com/_nat_en > From beaton@google.com Mon Jun 21 09:48:32 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73B623A6926 for ; Mon, 21 Jun 2010 09:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.652 X-Spam-Level: X-Spam-Status: No, score=-101.652 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bh7uxPQu9MGl for ; Mon, 21 Jun 2010 09:48:31 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 78E483A67EF for ; Mon, 21 Jun 2010 09:48:31 -0700 (PDT) Received: from hpaq6.eem.corp.google.com (hpaq6.eem.corp.google.com [172.25.149.6]) by smtp-out.google.com with ESMTP id o5LGmbKG018522 for ; Mon, 21 Jun 2010 09:48:37 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1277138917; bh=x50bBoYoOhyuCSDcylIt86T1zdo=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=Bz9BAQ4WRZ3wI08j/o3bSbhtiwcwyMXJvtsa+8/sn5widZDSWNtOxf5c/ZVhCU8eq bXsZ7LRZIocGa3eeBQX1g== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=JsoUmzxLBaJHs7t6CyNtUax6jop6QesTXmX0cfhV3JfKmKhgHzwC8AdCtjaXmLWiy 5pLGz+YwS9/i/czcnqyng== Received: from pvg16 (pvg16.prod.google.com [10.241.210.144]) by hpaq6.eem.corp.google.com with ESMTP id o5LGmZDY022036 for ; Mon, 21 Jun 2010 09:48:36 -0700 Received: by pvg16 with SMTP id 16so1303011pvg.14 for ; Mon, 21 Jun 2010 09:48:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.26.12 with SMTP id d12mr3658158wfj.242.1277138915170; Mon, 21 Jun 2010 09:48:35 -0700 (PDT) Received: by 10.142.207.21 with HTTP; Mon, 21 Jun 2010 09:48:35 -0700 (PDT) In-Reply-To: References: Date: Mon, 21 Jun 2010 09:48:35 -0700 Message-ID: From: Brian Eaton To: Dick Hardt Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 16:48:32 -0000 On Mon, Jun 21, 2010 at 7:43 AM, Dick Hardt wrote: > Thanks for writing this up Dirk. > I would suggest that the token be: > payload "." envelope "." signature > This enables the payload to be encrypted and independent from the envelope. > Token signing, verification, encryption and decryption code can then be > generic and not understand the payload of the token. I think you can still do that even if payload and envelope are combined. the signed json would become: { signer: encrypted_for: encrypted_payload: } From justinsm@microsoft.com Mon Jun 21 10:55:24 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B816F3A6AB2 for ; Mon, 21 Jun 2010 10:55:24 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tUGAaIYGSjCM for ; Mon, 21 Jun 2010 10:55:23 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id A75C33A6A76 for ; Mon, 21 Jun 2010 10:55:23 -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; Mon, 21 Jun 2010 10:55:24 -0700 Received: from TK5EX14MBXC119.redmond.corp.microsoft.com ([169.254.10.28]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.01.0160.007; Mon, 21 Jun 2010 10:55:24 -0700 From: Justin Smith To: Brian Eaton , Dick Hardt Thread-Topic: [OAUTH-WG] proposal for signatures Thread-Index: AQHLERAtRgBkky6d/EuyCSiQKsIiH5KM82AAgAAjBoD//5wlYA== Date: Mon, 21 Jun 2010 17:54:30 +0000 Deferred-Delivery: Mon, 21 Jun 2010 17:55:00 +0000 Message-ID: <191F411E00E19F4E943ECDB6D65C60851FB34C6F@TK5EX14MBXC119.redmond.corp.microsoft.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 17:55:24 -0000 I'm not emphatic about either, but my vote is to remove the envelope. -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of B= rian Eaton Sent: Monday, June 21, 2010 9:49 AM To: Dick Hardt Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for signatures On Mon, Jun 21, 2010 at 7:43 AM, Dick Hardt wrote: > Thanks for writing this up Dirk. > I would suggest that the token be: > payload "." envelope "." signature > This enables the payload to be encrypted and independent from the envelop= e. > Token signing, verification, encryption and decryption code can then=20 > be generic and not understand the payload of the token. I think you can still do that even if payload and envelope are combined. the signed json would become: { signer: encrypted_for: encrypted_payload: } __________________________= _____________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From dick.hardt@gmail.com Mon Jun 21 11:56:19 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AB1E28C0D0 for ; Mon, 21 Jun 2010 11:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v2DaYPX+3yYu for ; Mon, 21 Jun 2010 11:56:17 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 7654C3A6A83 for ; Mon, 21 Jun 2010 11:56:17 -0700 (PDT) Received: by pwi6 with SMTP id 6so1344478pwi.31 for ; Mon, 21 Jun 2010 11:56:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=+xWCkzqbpwoavt+4HcdUS4BrTvoCsOWiHMa9eCAugtk=; b=SGl5Felj2DNbbUAORu5uiTnBhrBR/1bNneh7kGcHZ3FGUbACbogE5Fro5tGBBopXIV DjQT04exNwOgZRC2oR1rVNzYVYAsmkkWsQcgo4l6g0UGahgUTXXlNcgSau2X3DX+OE0T xavc/jUeQ2ybo3Ss4OZ5aNgjC7h86O2tIjOR8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=YgCLw9aFuLOd0u2bw7n/kcgpUoCamKtXimgy0IUIbX4DA83NPx+acBVudhPb6JJiXd gklhpNzro8UokdcP60vtuaKkVK/RedRaWRqUZ4kuT68AWc92+0NQyirR/E5vNrp6ol3U YbI8cGc0qLbhR0aTlkorOWilUY6m+exaIisQ8= MIME-Version: 1.0 Received: by 10.142.67.33 with SMTP id p33mr3792005wfa.231.1277146277339; Mon, 21 Jun 2010 11:51:17 -0700 (PDT) Received: by 10.143.14.8 with HTTP; Mon, 21 Jun 2010 11:51:17 -0700 (PDT) In-Reply-To: <191F411E00E19F4E943ECDB6D65C60851FB34C6F@TK5EX14MBXC119.redmond.corp.microsoft.com> References: <191F411E00E19F4E943ECDB6D65C60851FB34C6F@TK5EX14MBXC119.redmond.corp.microsoft.com> Date: Mon, 21 Jun 2010 11:51:17 -0700 Message-ID: From: Dick Hardt To: Justin Smith Content-Type: multipart/alternative; boundary=001636e0a7d42fe39304898eca8c Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 18:56:19 -0000 --001636e0a7d42fe39304898eca8c Content-Type: text/plain; charset=ISO-8859-1 A couple of advantages of separating: 1) everything but the envelope data (key_id, signer, algorithm) gets encrypted 2) if the encrypted data is an object in the JSON, then it has been base64 encoded, and then gets base64 encoded again. Much more efficient to include the base64 encoded binary of the encrypted data as a separate field (this is what motivated me to this separation to begin with -- Dick On Mon, Jun 21, 2010 at 10:54 AM, Justin Smith wrote: > I'm not emphatic about either, but my vote is to remove the envelope. > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of > Brian Eaton > Sent: Monday, June 21, 2010 9:49 AM > To: Dick Hardt > Cc: OAuth WG > Subject: Re: [OAUTH-WG] proposal for signatures > > On Mon, Jun 21, 2010 at 7:43 AM, Dick Hardt wrote: > > Thanks for writing this up Dirk. > > I would suggest that the token be: > > payload "." envelope "." signature > > This enables the payload to be encrypted and independent from the > envelope. > > Token signing, verification, encryption and decryption code can then > > be generic and not understand the payload of the token. > > I think you can still do that even if payload and envelope are combined. > > the signed json would become: > > { > signer: > encrypted_for: > encrypted_payload: } > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001636e0a7d42fe39304898eca8c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    A couple of advantages of separating:

    1) ever= ything but the envelope data (key_id, signer, algorithm) gets encrypted=A0<= /div>

    2) if the encrypted data is an object in the JSON,= then it has been base64 encoded, and then gets base64 encoded again. Much = more efficient to include the base64 encoded binary of the encrypted data a= s a separate field (this is what motivated me to this separation to begin w= ith

    -- Dick


    On Mon, Jun 21, 2010 at 10:54 AM, Justin Smith &= lt;justinsm@microsoft.com>= wrote:
    I'm not emphatic about either, but my v= ote is to remove the envelope.

    -----Original Message-----
    From: oauth-bounces@ietf.org = [mailto:oauth-bounces@ietf.org] On Behalf Of Brian Eaton
    Sent: Monday, June 21, 2010 9:49 AM
    To: Dick Hardt
    Cc: OAuth WG
    Subject: Re: [OAUTH-WG] proposal for signatures

    On Mon, Jun 21, 2010 at 7:43 AM, Dick Hardt <    dick.hardt@gmail.com> wrote:
    > Thanks for writing this up Dirk.
    > I would suggest that the token be:
    > payload "." envelope "." signature
    > This enables the payload to be encrypted and independent from the enve= lope.
    > Token signing, verification, encryption and decryption code can then > be generic and not understand the payload of the token.

    I think you can still do that even if payload and envelope are combined.
    the signed json would become:

    {
    =A0 =A0signer: <whoever-signed>
    =A0 =A0encrypted_for: <intended-destination>
    =A0 =A0encrypted_payload: <the-encrypted-payload> } ____= ___________________________________________

    --001636e0a7d42fe39304898eca8c-- From beaton@google.com Mon Jun 21 12:00:31 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E8DF3A6AEB for ; Mon, 21 Jun 2010 12:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.717 X-Spam-Level: X-Spam-Status: No, score=-101.717 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gjExuT4N+4iE for ; Mon, 21 Jun 2010 12:00:30 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id D03A93A6B13 for ; Mon, 21 Jun 2010 12:00:17 -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 o5LJ0M29020215 for ; Mon, 21 Jun 2010 12:00:23 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1277146823; bh=f8M/Z7c5zBUNnktZ9LERvGziTV0=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=Wtj+dr2BMHlWzwildibjLxgP3Qh+175OHOo8HnVNb5wgsDhk8k5/3P/oGEBALZ0ll reYdDUIJHBB5FOCmjciQg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=jsJQITNMpPR6onUrSqpawOY6gtqHeJ90AqVpgxIRLOpLOmtWUTp9e1pWb5/kV0X3R PnYRHgCYkck6vGOHsHA5g== Received: from pxi7 (pxi7.prod.google.com [10.243.27.7]) by kpbe20.cbf.corp.google.com with ESMTP id o5LJ0LqO020205 for ; Mon, 21 Jun 2010 12:00:21 -0700 Received: by pxi7 with SMTP id 7so300891pxi.13 for ; Mon, 21 Jun 2010 12:00:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.26.12 with SMTP id d12mr3858605wfj.242.1277146821317; Mon, 21 Jun 2010 12:00:21 -0700 (PDT) Received: by 10.142.207.21 with HTTP; Mon, 21 Jun 2010 12:00:21 -0700 (PDT) In-Reply-To: References: <191F411E00E19F4E943ECDB6D65C60851FB34C6F@TK5EX14MBXC119.redmond.corp.microsoft.com> Date: Mon, 21 Jun 2010 12:00:21 -0700 Message-ID: From: Brian Eaton To: Dick Hardt Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 19:00:31 -0000 On Mon, Jun 21, 2010 at 11:51 AM, Dick Hardt wrote: > A couple of advantages of separating: > 1) everything but the envelope data (key_id, signer, algorithm) gets > encrypted I think this is true of my proposal as well...? > 2) if the encrypted data is an object in the JSON, then it has been base64 > encoded, and then gets base64 encoded again. Much more efficient to include > the base64 encoded binary of the encrypted data as a separate field (this is > what motivated me to this separation to begin with Yeah, this would be a problem. From mscurtescu@google.com Mon Jun 21 17:54:22 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD6D23A6915 for ; Mon, 21 Jun 2010 17:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.418 X-Spam-Level: X-Spam-Status: No, score=-101.418 tagged_above=-999 required=5 tests=[AWL=0.559, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUI5DZ3Oyw8W for ; Mon, 21 Jun 2010 17:54:21 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 6ECD13A68DC for ; Mon, 21 Jun 2010 17:54:21 -0700 (PDT) Received: from hpaq3.eem.corp.google.com (hpaq3.eem.corp.google.com [172.25.149.3]) by smtp-out.google.com with ESMTP id o5M0sRnd002497 for ; Mon, 21 Jun 2010 17:54:27 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1277168067; bh=RRSkN18VDbenI9Xv5pTLE1cNZRw=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=c0H3C5Jo1ZkqXNoKInQirxttCuXXFmqT3MInpWjPN6VqFQIRxPDLzHDLAuLMRibqp pJusQ8hMpD5clRcgpiKtQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=QonH8FhMCiiZeMENlEmI9XWg6LabHFMWnp7NhN0JBXCrBsyHu/RyLH79pjaKdYDwd V4OO2gh+lkUy0JNOCPcCg== Received: from vws16 (vws16.prod.google.com [10.241.21.144]) by hpaq3.eem.corp.google.com with ESMTP id o5M0sPO5032275 for ; Mon, 21 Jun 2010 17:54:26 -0700 Received: by vws16 with SMTP id 16so2323233vws.29 for ; Mon, 21 Jun 2010 17:54:25 -0700 (PDT) Received: by 10.220.62.196 with SMTP id y4mr2641918vch.242.1277168065181; Mon, 21 Jun 2010 17:54:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.198.199 with HTTP; Mon, 21 Jun 2010 17:54:05 -0700 (PDT) In-Reply-To: References: From: Marius Scurtescu Date: Mon, 21 Jun 2010 17:54:05 -0700 Message-ID: To: David Recordon Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth 2 for Native Apps X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 00:54:22 -0000 Here is the wiki page: http://wiki.oauth.net/OAuth-2-for-Native-Apps Feel free to edit or comment. Marius On Wed, Jun 9, 2010 at 10:59 AM, David Recordon wrote: > Want to put this on the wiki http://wiki.oauth.net/? > > > On Mon, Jun 7, 2010 at 12:25 PM, Marius Scurtescu wrote: >> Hi, >> >> I attached a document that summaries how native applications can use OAuth 2. >> >> Feedback more than welcome, especially if you have experience with >> native apps and OAuth. >> >> The current Web Server and Device flows need small changes and >> clarifications in order to properly support native apps, I will start >> a separate thread on that. >> >> Marius >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > From balfanz@google.com Mon Jun 21 18:14:41 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D7773A6921 for ; Mon, 21 Jun 2010 18:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.704 X-Spam-Level: X-Spam-Status: No, score=-104.704 tagged_above=-999 required=5 tests=[AWL=1.272, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6fO2uzEgUy75 for ; Mon, 21 Jun 2010 18:14:40 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 763383A691A for ; Mon, 21 Jun 2010 18:14:39 -0700 (PDT) Received: from hpaq13.eem.corp.google.com (hpaq13.eem.corp.google.com [172.25.149.13]) by smtp-out.google.com with ESMTP id o5M1EjBw025007 for ; Mon, 21 Jun 2010 18:14:45 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1277169285; bh=kGO2ySfMi1CToCpUVhU8jZ34Xe4=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=iRw8t2m0oeK34wujJpTM1FsW43ZGBPraoo0BlYPXRYESJqjulGk/WotK7HrDEse0/ ko3p/ggI2I1l9jT9ZWy8A== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=UvxwgyS3AV/RJMh8rQhzokejVWC/+gzmcF6E46f4miFJJr1qK2lAizuAZ2eOR+SgQ heYMkLfYGuivSX8qQNVzg== Received: from iwn9 (iwn9.prod.google.com [10.241.68.73]) by hpaq13.eem.corp.google.com with ESMTP id o5M1EJKY030358 for ; Mon, 21 Jun 2010 18:14:43 -0700 Received: by iwn9 with SMTP id 9so1018432iwn.3 for ; Mon, 21 Jun 2010 18:14:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.82.74 with SMTP id a10mr6434316ibl.183.1277169282799; Mon, 21 Jun 2010 18:14:42 -0700 (PDT) Received: by 10.231.139.231 with HTTP; Mon, 21 Jun 2010 18:14:42 -0700 (PDT) In-Reply-To: References: Date: Mon, 21 Jun 2010 18:14:42 -0700 Message-ID: From: Dirk Balfanz To: Ben Laurie Content-Type: multipart/alternative; boundary=000e0cdf16a46b597e0489942530 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 01:14:41 -0000 --000e0cdf16a46b597e0489942530 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jun 21, 2010 at 4:18 AM, Ben Laurie wrote: > On 21 June 2010 08:04, Dirk Balfanz wrote: > > Hi guys, > > I think I owe the list a proposal for signatures. > > I wrote something down that liberally borrows ideas from Magic > Signatures, > > SWT, and (even the name from) JSON Web Tokens. > > Here is a short document (called "JSON Tokens") that just explains how to > > sign something and verify the signature: > > > http://docs.google.com/document/pub?id=1kv6Oz_HRnWa0DaJx_SQ5Qlk_yqs_7zNAm75-FmKwNo4 > > "signature is a base64-encoded string of the signature bits." should > be websafe-base64? > Yes. > > "the current time is not after the expiration time of the token > (defined as not_before + session_length)" should be not_before + > token_lifetime, right? Yes. > But I'd prefer a not_after instead. > Either way is fine with me. I picked token_lifetime b/c it tends to take up a little less space than a not_after, but I don't feel strongly about it. > > What is a Service Descriptor? Is this something to do with webfinger, > or something else? > Something else. I'm proposing that an OAuth Client be identifiable by a URL. You resolve the URL, you get everything you need to know about that Client. Simpler than webfinger. > In the HMAC keys section you describe the keys as symmetric, which is > strictly accurate, but more normally called shared keys for this use. > > Obviously you'll need to be a bit more specific about what you mean by > "RSA-SHA256". > Right. Any suggestions what RSA-SHA256 should specifically refer to? If I stick that into a Signature.getInstance() call in Java, it returns _something_. Any idea what that is? I'd like say that whatever that is is what I mean by RSA-SHA256. > > > Here is an extension of JSON Tokens that can be used for signed OAuth > > tokens: > > > http://docs.google.com/document/pub?id=1JUn3Twd9nXwFDgi-fTKl-unDG_ndyowTZW8OWX9HOUU > > As you know, I hate the term "non-repudation". Can't you just call it > "signing"? > What would you say is the advantage of public-key signatures over shared-key signatures? I do want to point out that this proposal includes public-key signatures, and therefore brings to advantages to the table. > > "Protection against leaked authentication tokens: Protocols such as > OAuth2 use bearer tokens, which may leak when used over non-SSL. > Signing requests when using bearer tokens lets the recipient of such a > request verify that the issuer of the request was a legitimate holder > of the bearer token." - only true if you make the checking of the > nonce a MUST instead of "may". And even then, MitM wins, of course. > MITM wins while the token is valid as per not_before and token_lifetime (or not_after). > Why is body_hash optional? > Maybe some Clients/PRs don't care? I remember that in OAuth 1, we couldn't ever get agreement on what to do about POST body signing, so I made it optional. I'm not going to stand in the way if people want this to be required. > > > Here is a different extension of JSON Tokens that can be used for > 2-legged > > flows. The idea is that this could be used as a drop-in replacement for > SAML > > assertions in the OAuth2 assertion flow: > > > http://docs.google.com/document/pub?id=1s4kjRS9P0frG0ulhgP3He01ONlxeTwkFQV_pCoOowzc > > You use the abbreviation AS before the full name Authorization Server. > Oops - sorry. :-) I'll try to do a revision later tonight... Thanks for the feedback! Dirk. > > I also have started to write some code to implement this as a> > proof-of-concept. > > > > Thoughts? Comments? > > Nice. > > > Dirk. > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > --000e0cdf16a46b597e0489942530 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

    On Mon, Jun 21, 2010 at 4:18 AM, Ben Lau= rie <benl@google.co= m> wrote:
    On 21 June 2010 08:04, Dirk Balfanz <balfanz@google.com> wrote:
    > Hi guys,
    > I think I owe the list a proposal for signatures.
    > I wrote something down that=A0liberally=A0borrows ideas from Magic Sig= natures,
    > SWT, and (even the name from) JSON Web Tokens.
    > Here is a short document (called "JSON Tokens") that just ex= plains how to
    > sign something and verify the signature:
    > http://docs.google.com/docume= nt/pub?id=3D1kv6Oz_HRnWa0DaJx_SQ5Qlk_yqs_7zNAm75-FmKwNo4

    "signature is a base64-encoded string of the signature bits.&quo= t; should
    be websafe-base64?

    Yes.
    =A0

    "the current time is not after the expiration time of the token
    (defined as not_before + session_length)" should be not_before +
    token_lifetime, right?

    Yes.
    =A0
    But I'd prefer a not_after instead= .

    Either way is fine with me. I picked token= _lifetime b/c it tends to take up a little less space than a not_after, but= I don't feel strongly about it.
    =A0

    What is a Service Descriptor? Is this something to do with webfinger,
    or something else?

    Something else. I= 9;m proposing that an OAuth Client be identifiable by a URL. You resolve th= e URL, you get everything you need to know about that Client. Simpler than = webfinger.
    =A0
    In the HMAC keys section you = describe the keys as symmetric, which is
    strictly accurate, but more normally called shared keys for this use.

    Obviously you'll need to be a bit more specific about what you mean by<= br> "RSA-SHA256".

    Right. Any sugg= estions what RSA-SHA256 should specifically refer to? If I stick that into = a Signature.getInstance() call in Java, it returns _something_. Any idea wh= at that is? I'd like say that whatever that is is what I mean by RSA-SH= A256.
    =A0

    > Here is an extension of JSON Tokens that can be used for signed OAuth<= br> > tokens:
    > http://docs.google.com/docume= nt/pub?id=3D1JUn3Twd9nXwFDgi-fTKl-unDG_ndyowTZW8OWX9HOUU

    As you know, I hate the term "non-repudation". Can't yo= u just call it "signing"?

    Wha= t would you say is the advantage of public-key signatures over shared-key s= ignatures? I do want to point out that this proposal includes public-key si= gnatures, and therefore brings to advantages to the table.
    =A0

    "Protection against leaked authentication tokens: Protocols such as OAuth2 use bearer tokens, which may leak when used over non-SSL.
    Signing requests when using bearer tokens lets the recipient of such a
    request verify that the issuer of the request was a legitimate holder
    of the bearer token." - only true if you make the checking of the
    nonce a MUST instead of "may". And even then, MitM wins, of cours= e.

    MITM wins while the token is valid a= s per not_before and token_lifetime (or not_after).
    =A0
    Why is body_hash optional?

    Maybe some C= lients/PRs don't care? I remember that in OAuth 1, we couldn't ever= get agreement on what to do about POST body signing, so I made it optional= . I'm not going to stand in the way if people want this to be required.=
    =A0

    > Here is a different extension of JSON Tokens that can be used for 2-le= gged
    > flows. The idea is that this could be used as a drop-in replacement fo= r SAML
    > assertions in the OAuth2 assertion flow:
    > http://docs.google.com/docume= nt/pub?id=3D1s4kjRS9P0frG0ulhgP3He01ONlxeTwkFQV_pCoOowzc

    You use the abbreviation AS before the full name Authorization Server= .

    Oops - sorry. :-) I'll try to do = a revision later tonight...
    =A0
    Thanks for the feedback= !

    Dirk.


    > I also have started to write some code to implement this as a> proo= f-of-concept.
    >
    > Thoughts? Comments?

    Nice.

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

    --000e0cdf16a46b597e0489942530-- From balfanz@google.com Mon Jun 21 18:20:36 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E65F3A6914 for ; Mon, 21 Jun 2010 18:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.128 X-Spam-Level: X-Spam-Status: No, score=-105.128 tagged_above=-999 required=5 tests=[AWL=0.848, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bVrWJqCdBReS for ; Mon, 21 Jun 2010 18:20:32 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id E007E3A690A for ; Mon, 21 Jun 2010 18:20:31 -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 o5M1KcGZ019227 for ; Mon, 21 Jun 2010 18:20:38 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1277169638; bh=Rei8pLzWM6OWTFr+M+WjesnM+4E=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=uqJZiZJl/NNV6O55W5Jzcb0plT9QOHYGKfYGG0RTCon2BGt9LYvUXOCpMGCxqusGw IXJGgWROmz+8SwOBG38mg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=LF9MsY+HA3dXuVJVWMKF716hmChGHiuT7uExFbbQI1H+95puj2CZSUHSf5XZhaLJz 8ZuzTO2vINAJf3TkgInRA== Received: from iwn9 (iwn9.prod.google.com [10.241.68.73]) by hpaq14.eem.corp.google.com with ESMTP id o5M1KaHu010514 for ; Mon, 21 Jun 2010 18:20:36 -0700 Received: by iwn9 with SMTP id 9so1023810iwn.3 for ; Mon, 21 Jun 2010 18:20:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.169.129 with SMTP id z1mr6745688iby.26.1277169635398; Mon, 21 Jun 2010 18:20:35 -0700 (PDT) Received: by 10.231.139.231 with HTTP; Mon, 21 Jun 2010 18:20:35 -0700 (PDT) In-Reply-To: References: Date: Mon, 21 Jun 2010 18:20:35 -0700 Message-ID: From: Dirk Balfanz To: Nat Sakimura Content-Type: multipart/alternative; boundary=0016e6d26d676f97230489943acb X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 01:20:36 -0000 --0016e6d26d676f97230489943acb Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jun 21, 2010 at 6:22 AM, Nat Sakimura wrote: > Hi Dirk, > > In addition to Ben's questions, I have another. For X.509, you seem to > be using DER. How do you express the entire certificate chain using > DER? > (With PEM, you can just concatenate ... ) > Good question: strawman answer: Don't put cert chains into the server info document. The verifier hopefully fetches the server info document over SSL, and can verify all the cert chains it wants in the SSL layer. We simply need a public key in the server info document. The option to include a certificate is purely there in case it's easier for you to generate an X.509 cert than a Magic Key. For example, if you already have concatenated PEMs, throw all but the first away, remove the newlines, prepend "X509." and you have a valid representation of a public key, as far as JSON Tokens are concerned. What do you think? Dirk. > And here is some comments: > > If body_hash is not used, it seems it is just doing the client > authentication via asymmetric crypto. > This is a valid use case, and actually is quite nice. I think this is > the main use case. > > If we wanted to make sure that the request itself is not tampered, we > need to sign the body. > For this, I somehow feel that Magic Signatures is more interoperable > since it actually sends the armored ASCII strings with it. > > =nat > > > > On Mon, Jun 21, 2010 at 8:18 PM, Ben Laurie wrote: > > On 21 June 2010 08:04, Dirk Balfanz wrote: > >> Hi guys, > >> I think I owe the list a proposal for signatures. > >> I wrote something down that liberally borrows ideas from Magic > Signatures, > >> SWT, and (even the name from) JSON Web Tokens. > >> Here is a short document (called "JSON Tokens") that just explains how > to > >> sign something and verify the signature: > >> > http://docs.google.com/document/pub?id=1kv6Oz_HRnWa0DaJx_SQ5Qlk_yqs_7zNAm75-FmKwNo4 > > > > "signature is a base64-encoded string of the signature bits." should > > be websafe-base64? > > > > "the current time is not after the expiration time of the token > > (defined as not_before + session_length)" should be not_before + > > token_lifetime, right? But I'd prefer a not_after instead. > > > > What is a Service Descriptor? Is this something to do with webfinger, > > or something else? > > > > In the HMAC keys section you describe the keys as symmetric, which is > > strictly accurate, but more normally called shared keys for this use. > > > > Obviously you'll need to be a bit more specific about what you mean by > > "RSA-SHA256". > > > >> Here is an extension of JSON Tokens that can be used for signed OAuth > >> tokens: > >> > http://docs.google.com/document/pub?id=1JUn3Twd9nXwFDgi-fTKl-unDG_ndyowTZW8OWX9HOUU > > > > As you know, I hate the term "non-repudation". Can't you just call it > "signing"? > > > > "Protection against leaked authentication tokens: Protocols such as > > OAuth2 use bearer tokens, which may leak when used over non-SSL. > > Signing requests when using bearer tokens lets the recipient of such a > > request verify that the issuer of the request was a legitimate holder > > of the bearer token." - only true if you make the checking of the > > nonce a MUST instead of "may". And even then, MitM wins, of course. > > > > Why is body_hash optional? > > > >> Here is a different extension of JSON Tokens that can be used for > 2-legged > >> flows. The idea is that this could be used as a drop-in replacement for > SAML > >> assertions in the OAuth2 assertion flow: > >> > http://docs.google.com/document/pub?id=1s4kjRS9P0frG0ulhgP3He01ONlxeTwkFQV_pCoOowzc > > > > You use the abbreviation AS before the full name Authorization Server. > > > >> I also have started to write some code to implement this as a> > proof-of-concept. > >> > >> Thoughts? Comments? > > > > Nice. > > > >> Dirk. > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > >> > >> > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > -- > Nat Sakimura (=nat) > http://www.sakimura.org/en/ > http://twitter.com/_nat_en > --0016e6d26d676f97230489943acb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

    On Mon, Jun 21, 2010 at 6:22 AM, Nat Sak= imura <sakimura@= gmail.com> wrote:
    Hi Dirk,

    In addition to Ben's questions, I have another. For X.509, you seem to<= br> be using DER. How do you express the entire certificate chain using
    DER?
    (With PEM, you can just concatenate ... )

    Good question: strawman answer: Don't put cert chains into the serve= r info document. The verifier hopefully fetches the server info document ov= er SSL, and can verify all the cert chains it wants in the SSL layer. We si= mply need a public key in the server info document. The option to include a= certificate is purely there in case it's easier for you to generate an= X.509 cert than a Magic Key. For example, if you already have concatenated= PEMs, throw all but the first away, remove the newlines, prepend "X50= 9." and you have a valid representation of a public key, as far as JSO= N Tokens are concerned.=A0

    What do you think?
    =A0
    Dirk.
    <= div>

    And here is some comments:

    If body_hash is not used, it seems it is just doing the client
    authentication via asymmetric crypto.
    This is a valid use case, and actually is quite nice. I think this is
    the main use case.

    If we wanted to make sure that the request itself is not tampered, we
    need to sign the body.
    For this, I somehow feel that Magic Signatures is more interoperable
    since it actually sends the armored ASCII strings with it.

    =3Dnat



    On Mon, Jun 21, 2010 at 8:18 PM, Ben Laurie <benl@google.com> wrote:
    > On 21 June 2010 08:04, Dirk Balfanz <balfanz@google.com> wrote:
    >> Hi guys,
    >> I think I owe the list a proposal for signatures.
    >> I wrote something down that=A0liberally=A0borrows ideas from Magic= Signatures,
    >> SWT, and (even the name from) JSON Web Tokens.
    >> Here is a short document (called "JSON Tokens") that jus= t explains how to
    >> sign something and verify the signature:
    >> http://docs.google.com/do= cument/pub?id=3D1kv6Oz_HRnWa0DaJx_SQ5Qlk_yqs_7zNAm75-FmKwNo4
    >
    > "signature is a base64-encoded string of the signature bits."= ; should
    > be websafe-base64?
    >
    > "the current time is not after the expiration time of the token > (defined as not_before + session_length)" should be not_before +<= br> > token_lifetime, right? But I'd prefer a not_after instead.
    >
    > What is a Service Descriptor? Is this something to do with webfinger,<= br> > or something else?
    >
    > In the HMAC keys section you describe the keys as symmetric, which is<= br> > strictly accurate, but more normally called shared keys for this use.<= br> >
    > Obviously you'll need to be a bit more specific about what you mea= n by
    > "RSA-SHA256".
    >
    >> Here is an extension of JSON Tokens that can be used for signed OA= uth
    >> tokens:
    >> http://docs.google.com/do= cument/pub?id=3D1JUn3Twd9nXwFDgi-fTKl-unDG_ndyowTZW8OWX9HOUU
    >
    > As you know, I hate the term "non-repudation". Can't you= just call it "signing"?
    >
    > "Protection against leaked authentication tokens: Protocols such = as
    > OAuth2 use bearer tokens, which may leak when used over non-SSL.
    > Signing requests when using bearer tokens lets the recipient of such a=
    > request verify that the issuer of the request was a legitimate holder<= br> > of the bearer token." - only true if you make the checking of the=
    > nonce a MUST instead of "may". And even then, MitM wins, of = course.
    >
    > Why is body_hash optional?
    >
    >> Here is a different extension of JSON Tokens that can be used for = 2-legged
    >> flows. The idea is that this could be used as a drop-in replacemen= t for SAML
    >> assertions in the OAuth2 assertion flow:
    >> http://docs.google.com/do= cument/pub?id=3D1s4kjRS9P0frG0ulhgP3He01ONlxeTwkFQV_pCoOowzc
    >
    > You use the abbreviation AS before the full name Authorization Server.=
    >
    >> I also have started to write some code to implement this as a> = proof-of-concept.
    >>
    >> Thoughts? Comments?
    >
    > Nice.
    >
    >> Dirk.
    >>
    >> _______________________________________________
    >> OAuth mailing list
    >> OAuth@ietf.org
    >> https://www.ietf.org/mailman/listinfo/oauth
    >>
    >>
    > _______________________________________________
    > OAuth mailing list
    > OAuth@ietf.org
    > https://www.ietf.org/mailman/listinfo/oauth
    >



    --
    Nat Sakimura (=3Dnat)
    http://www.sakimu= ra.org/en/
    http://twitter.com= /_nat_en

    --0016e6d26d676f97230489943acb-- From James.H.Manger@team.telstra.com Mon Jun 21 18:40:45 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A18283A6921 for ; Mon, 21 Jun 2010 18:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.346 X-Spam-Level: * X-Spam-Status: No, score=1.346 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_05=-1.11, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZo5wBl5gOYL for ; Mon, 21 Jun 2010 18:40:44 -0700 (PDT) Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by core3.amsl.com (Postfix) with ESMTP id 7C4E63A6918 for ; Mon, 21 Jun 2010 18:40:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,457,1272808800"; d="scan'208,217";a="6034797" Received: from unknown (HELO ipcdni.tcif.telstra.com.au) ([10.97.216.212]) by ipoani.tcif.telstra.com.au with ESMTP; 22 Jun 2010 11:40:48 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6020"; a="3583005" Received: from wsmsg3704.srv.dir.telstra.com ([172.49.40.197]) by ipcdni.tcif.telstra.com.au with ESMTP; 22 Jun 2010 11:40:49 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3704.srv.dir.telstra.com ([172.49.40.197]) with mapi; Tue, 22 Jun 2010 11:40:49 +1000 From: "Manger, James H" To: OAuth WG Date: Tue, 22 Jun 2010 11:40:48 +1000 Thread-Topic: [OAUTH-WG] proposal for signatures Thread-Index: AcsREBWPFXj/sYxwSUKACRqsQdtvywAmKquw Message-ID: <255B9BB34FB7D647A506DC292726F6E11264272EBE@WSMSG3153V.srv.dir.telstra.com> References: 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: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E11264272EBEWSMSG3153Vsrv_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] proposal for signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 01:40:46 -0000 --_000_255B9BB34FB7D647A506DC292726F6E11264272EBEWSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TmF0IGFuZCBCZW4sDQoNCg0KDQo+Pj4gSW4gYWRkaXRpb24gdG8gQmVuJ3MgcXVlc3Rpb25zLCBJ IGhhdmUgYW5vdGhlci4gRm9yIFguNTA5LCB5b3Ugc2VlbSB0bw0KDQo+Pj4gYmUgdXNpbmcgREVS LiBIb3cgZG8geW91IGV4cHJlc3MgdGhlIGVudGlyZSBjZXJ0aWZpY2F0ZSBjaGFpbiB1c2luZw0K DQo+Pj4gREVSPw0KDQo+Pj4gKFdpdGggUEVNLCB5b3UgY2FuIGp1c3QgY29uY2F0ZW5hdGUgLi4u ICkNCg0KPj4NCg0KPj4gV2l0aCBERVIgeW91IGNhbiBjb25jYXRlbmF0ZSwgdG9vLCBvZiBjb3Vy c2UuIFRoZXJlJ3MgYWxzbyBQS0NTI24gKGZvcg0KDQo+PiBzb21lIHZhbHVlIG9mIG4gd2hpY2gg SSBmb3JnZXQgLi4uIDEyPykgd2hpY2ggYWxsb3dzIGJ1bmRsaW5nIG9mIGNlcnQNCg0KPj4gY2hh aW5zLg0KDQo+DQoNCj4gVGhhdCdzIFBLQ1MjMTIsIEkgc3VwcG9zZS4gSSBoYWQgdW5kZXIgYW4g aW1wcmVzc2lvbiB0aGF0IFBLQ1MjMTIgaW5jbHVkZXMgdGhlDQoNCj4gcHJpdmF0ZSBrZXksIHRo b3VnaC4NCg0KDQoNCg0KDQpBICoucDdjIGZpbGUgY2FuIGJlIHVzZWQgdG8gaG9sZCBhbnkgbnVt YmVyIG9mIGNlcnRpZmljYXRlcy4gSXQgaXMgYSBCRVItZW5jb2RlZCBQS0NTIzcgdmFsdWUsIG5v dyBrbm93biBhcyBDcnlwdG9ncmFwaGljIE1lc3NhZ2UgU3ludGF4IChDTVMpIHN0YW5kYXJkIFtS RkMgNTY1MjxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1NjUyI3NlY3Rpb24tNS4xPl0u IEl0IGlzIHRoZSBBU04uMSBzeW50YXggdXNlZCBmb3IgUy9NSU1FIHNpZ25lZCBlbWFpbC4gSWYg eW91IG9ubHkgd2FudCB0byBzZW5kIGNlcnRpZmljYXRlcywganVzdCBsZWF2aW5nIG91dCB0aGUg Y29udGVudC10by1iZS1zaWduZWQsIGFuZCB0aGUgc2lnbmF0dXJlcy4NCg0KDQoNClN1Y2ggYSBm aWxlIGNhbiBob2xkIGFueSBudW1iZXIgb2YgY2VydGlmaWNhdGVzLCBpbmNsdWRpbmcgcHVibGlj LWtleSBjZXJ0aWZpY2F0ZXMsIGF0dHJpYnV0ZSBjZXJ0aWZpY2F0ZXMsIG9yIG90aGVyIGNlcnRp ZmljYXRlIGZvcm1hdHMuDQoNCkl0IGNhbiBhbHNvIGhvbGQgQ1JMcyBhbmQgb3RoZXIgcmV2b2Nh dGlvbiBpbmZvcm1hdGlvbiAoaW5jbHVkaW5nIE9DU1AgcmVzcG9uc2VzIGFzIHBlciBkcmFmdC10 dXJuZXItYWRkaXRpb25hbC1jbXMtcmktY2hvaWNlczxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC10dXJuZXItYWRkaXRpb25hbC1jbXMtcmktY2hvaWNlcz4pLg0KDQoNCg0KQ01TL1BL Q1MjNyBpcyBiZXR0ZXIgZm9yIHRoaXMgcHVycG9zZSB0aGFuIFBLQ1MjMTIuDQoNCg0KDQotLQ0K DQpKYW1lcyBNYW5nZXINCg0K --_000_255B9BB34FB7D647A506DC292726F6E11264272EBEWSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9 Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9 Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0 cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0 dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3 Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0 cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6 cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3 LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVu dC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0i R2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+ DQo8c3R5bGU+DQo8IS0tDQogLyogRm9udCBEZWZpbml0aW9ucyAqLw0KIEBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1 IDIgMiAyIDQgMyAyIDQ7fQ0KIC8qIFN0eWxlIERlZmluaXRpb25zICovDQogcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bh bi5hcHBsZS1zdHlsZS1zcGFuDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLXN0eWxlLXNwYW47fQ0K c3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFNlY3Rpb24x DQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3 Mi4wcHQ7fQ0KZGl2LlNlY3Rpb24xDQoJe3BhZ2U6U2VjdGlvbjE7fQ0KLS0+DQo8L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCiA8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQogIDxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KIDwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkVOLUFVIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IlNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPk5hdCBhbmQgQmVuLDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsN CmNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPiZn dDsmZ3Q7Jmd0OyBJbiBhZGRpdGlvbiB0byBCZW4ncyBxdWVzdGlvbnMsIEkgaGF2ZSBhbm90aGVy LiBGb3IgWC41MDksIHlvdSBzZWVtIHRvPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+ Jmd0OyZndDsmZ3Q7IGJlIHVzaW5nIERFUi4gSG93IGRvIHlvdSBleHByZXNzIHRoZSBlbnRpcmUg Y2VydGlmaWNhdGUgY2hhaW4gdXNpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj4m Z3Q7Jmd0OyZndDsgREVSPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPiZndDsmZ3Q7 Jmd0OyAoV2l0aCBQRU0sIHlvdSBjYW4ganVzdCBjb25jYXRlbmF0ZSAuLi4gKTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OzsNCmNvbG9yOiMxRjQ5N0QiPiZndDsmZ3Q7PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29s b3I6IzFGNDk3RCI+Jmd0OyZndDsgV2l0aCBERVIgeW91IGNhbiBjb25jYXRlbmF0ZSwgdG9vLCBv ZiBjb3Vyc2UuIFRoZXJlJ3MgYWxzbyBQS0NTI24gKGZvcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9y OiMxRjQ5N0QiPiZndDsmZ3Q7IHNvbWUgdmFsdWUgb2YgbiB3aGljaCBJIGZvcmdldCAuLi4gMTI/ KSB3aGljaCBhbGxvd3MgYnVuZGxpbmcgb2YgY2VydDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMx RjQ5N0QiPiZndDsmZ3Q7IGNoYWlucy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj4m Z3Q7PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+Jmd0OyBUaGF0J3MgUEtD UyMxMiwgSSBzdXBwb3NlLiBJIGhhZCB1bmRlciBhbiBpbXByZXNzaW9uIHRoYXQgUEtDUyMxMiBp bmNsdWRlcyB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj4mZ3Q7IHByaXZhdGUg a2V5LCB0aG91Z2guPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6 IzFGNDk3RCI+QSAqLnA3YyBmaWxlIGNhbiBiZSB1c2VkIHRvIGhvbGQgYW55IG51bWJlciBvZiBj ZXJ0aWZpY2F0ZXMuIEl0IGlzIGEgQkVSLWVuY29kZWQgUEtDUyM3IHZhbHVlLCBub3cga25vd24g YXMgQ3J5cHRvZ3JhcGhpYyBNZXNzYWdlIFN5bnRheCAoQ01TKSBzdGFuZGFyZCBbPGEgaHJlZj0i aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTY1MiNzZWN0aW9uLTUuMSI+UkZDDQogNTY1 MjwvYT5dLiBJdCBpcyB0aGUgQVNOLjEgc3ludGF4IHVzZWQgZm9yIFMvTUlNRSBzaWduZWQgZW1h aWwuIElmIHlvdSBvbmx5IHdhbnQgdG8gc2VuZCBjZXJ0aWZpY2F0ZXMsIGp1c3QgbGVhdmluZyBv dXQgdGhlIGNvbnRlbnQtdG8tYmUtc2lnbmVkLCBhbmQgdGhlIHNpZ25hdHVyZXMuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFG NDk3RCI+U3VjaCBhIGZpbGUgY2FuIGhvbGQgYW55IG51bWJlciBvZiBjZXJ0aWZpY2F0ZXMsIGlu Y2x1ZGluZyBwdWJsaWMta2V5IGNlcnRpZmljYXRlcywgYXR0cmlidXRlIGNlcnRpZmljYXRlcywg b3Igb3RoZXIgY2VydGlmaWNhdGUgZm9ybWF0cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0 OTdEIj5JdCBjYW4gYWxzbyBob2xkIENSTHMgYW5kIG90aGVyIHJldm9jYXRpb24gaW5mb3JtYXRp b24gKGluY2x1ZGluZyBPQ1NQIHJlc3BvbnNlcyBhcyBwZXINCjxhIGhyZWY9Imh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LXR1cm5lci1hZGRpdGlvbmFsLWNtcy1yaS1jaG9pY2VzIj5k cmFmdC10dXJuZXItYWRkaXRpb25hbC1jbXMtcmktY2hvaWNlczwvYT4pLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OzsNCmNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0Qi PkNNUy9QS0NTIzcgaXMgYmV0dGVyIGZvciB0aGlzIHB1cnBvc2UgdGhhbiBQS0NTIzEyLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9y OiMxRjQ5N0QiPi0tDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj5KYW1lcyBNYW5n ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_255B9BB34FB7D647A506DC292726F6E11264272EBEWSMSG3153Vsrv_-- From eran@hueniverse.com Mon Jun 21 19:27:02 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CBC43A67FC for ; Mon, 21 Jun 2010 19:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.879 X-Spam-Level: X-Spam-Status: No, score=-0.879 tagged_above=-999 required=5 tests=[AWL=-0.881, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11hlS2DwLBLf for ; Mon, 21 Jun 2010 19:27:01 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 91ECA3A67D0 for ; Mon, 21 Jun 2010 19:27:01 -0700 (PDT) Received: (qmail 23745 invoked from network); 22 Jun 2010 02:27:08 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 22 Jun 2010 02:27:08 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 21 Jun 2010 19:27:08 -0700 From: Eran Hammer-Lahav To: "OAuth WG (oauth@ietf.org)" Date: Mon, 21 Jun 2010 19:27:03 -0700 Thread-Topic: Last call for feedback on -08 Thread-Index: AcsRsjZfjqdQ/zINQyeO85NMzOpwrA== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EC83F35@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_90C41DD21FB7C64BB94121FBBC2E72343B3EC83F35P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: [OAUTH-WG] Last call for feedback on -08 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 02:27:02 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EC83F35P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am working on -09 which I hope will be the last major revision of the spe= cification. If you were planning on submitting any feedback on draft -08 or= the simplification proposal from David and me, please do so by tomorrow to= be included in the next draft. EHL --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EC83F35P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    I am working on = -09 which I hope will be the last major revision of the specification. If y= ou were planning on submitting any feedback on draft -08 or the simplificat= ion proposal from David and me, please do so by tomorrow to be included in = the next draft.

     

    EHL

    = --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EC83F35P3PW5EX1MB01E_-- From James.H.Manger@team.telstra.com Mon Jun 21 20:02:52 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B5463A67D0 for ; Mon, 21 Jun 2010 20:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.584 X-Spam-Level: * X-Spam-Status: No, score=1.584 tagged_above=-999 required=5 tests=[AWL=-0.115, BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSM6blxZOg2b for ; Mon, 21 Jun 2010 20:02:50 -0700 (PDT) Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by core3.amsl.com (Postfix) with ESMTP id B01613A659B for ; Mon, 21 Jun 2010 20:02:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,457,1272808800"; d="scan'208";a="6045544" Received: from unknown (HELO ipcdni.tcif.telstra.com.au) ([10.97.216.212]) by ipoani.tcif.telstra.com.au with ESMTP; 22 Jun 2010 13:02:54 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6020"; a="3589561" Received: from wsmsg3755.srv.dir.telstra.com ([172.49.40.196]) by ipcdni.tcif.telstra.com.au with ESMTP; 22 Jun 2010 13:02:56 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3755.srv.dir.telstra.com ([172.49.40.196]) with mapi; Tue, 22 Jun 2010 13:02:56 +1000 From: "Manger, James H" To: Eran Hammer-Lahav , "OAuth WG (oauth@ietf.org)" Date: Tue, 22 Jun 2010 13:02:51 +1000 Thread-Topic: OAuth discovery draft? Thread-Index: AcsMLfi0k1bL/UTuTyKlbQqO9cCDCgFh6zFg Message-ID: <255B9BB34FB7D647A506DC292726F6E1126427308C@WSMSG3153V.srv.dir.telstra.com> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB68D9@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB68D9@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {4CD628C3-3E13-4620-9930-B167B6A79BF8} x-cr-hashedpuzzle: A3da Ci0J C5B5 ELIy EhyX FR/3 F1D9 KIZ9 LD7C MqSL NYs5 OGMW PMZI QdFM Q7n3 U0bb; 2; ZQByAGEAbgBAAGgAdQBlAG4AaQB2AGUAcgBzAGUALgBjAG8AbQA7AG8AYQB1AHQAaABAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {4CD628C3-3E13-4620-9930-B167B6A79BF8}; agBhAG0AZQBzAC4AaAAuAG0AYQBuAGcAZQByAEAAdABlAGEAbQAuAHQAZQBsAHMAdAByAGEALgBjAG8AbQA=; Tue, 22 Jun 2010 03:02:51 GMT;TwBBAHUAdABoACAAZABpAHMAYwBvAHYAZQByAHkAIABkAHIAYQBmAHQAPwA= acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [OAUTH-WG] OAuth discovery draft? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 03:02:52 -0000 RXJhbiwNCg0KVGhlcmUgaGF2ZSBiZWVuIGEgZmV3IG1lbnRpb25zIHJlY2VudGx5IG9mIGFuIE9B dXRoIGRpc2NvdmVyeSBkcmFmdC4gSXMgdGhlcmUgYW55IHN1Y2ggZHJhZnQgeWV0LCBvciBpcyB0 aGlzIGp1c3QgYSBwYXJ0IHRoYXQgd2Uga25vdyBuZWVkcyB0byBiZSBkb25lPw0KDQpUaGUgZW1h aWwgb24gIk9BdXRoIG1lZXRpbmcgbm90ZXMgb24gLTA1ICh3aXRoIHVwZGF0ZXMpIiBzYWlkOg0K DQo+PiA2LjEuMS4gLSBkZXNjcmliaW5nIHRoZSBXV1ctQXV0aGVudGljYXRlIHJlc3BvbnNlIGhl YWRlcg0KPj4NCj4+IC0gRGlzY292ZXJ5IG5lZWRlZCBmb3IgdmFyaW91cyBlbGVtZW50cw0KPg0K PiBZZXMuIFRoYXQncyBmb3IgdGhlIGRpc2NvdmVyeSBkcmFmdC4NCg0KDQpBIHdpa2kgcGFnZSBv biAiRnV0dXJlIE9wZW5JRCBUZWNobmljYWwgUmVxdWlyZW1lbnRzIiA8aHR0cDovL3dpa2kub3Bl bmlkLm5ldC9GdXR1cmUtT3BlbklELVRlY2huaWNhbC1SZXF1aXJlbWVudHM+IHNheXM6DQoNCj4g NikgSWRQIERpc2NvdmVyeQ0KPg0KPiAgICAqIE11Y2ggb2YgdGhpcyB3aWxsIGJlIGNvdmVyZWQg YnkgT0F1dGgyIERpc2NvdmVyeSwNCj4gICAgICBob3dldmVyIE9JQyBtYXkgbmVlZCB0byBkZWZp bmUgT3BlbklEIHNwZWNpZmljIGZlYXR1cmVzLg0KPuKApg0KPiAxNykgU2ltcGxlciBkaXNjb3Zl cnkNCj4NCj4gICAgKiBTZWUgRXJhbidzIE9BdXRoIERpc2NvdmVyeSBwcm9wb3NhbA0KDQoNClRo ZXJlIHdhcyBhbiBPQXV0aCAxLjAgRGlzY292ZXJ5IGRyYWZ0IG92ZXIgMiB5ZWFycyBhZ28sIGJ1 dCB0aGF0IGlzIHRhZ2dlZDogImV4cGlyZWQiLCAibWFya2VkIGFzIG9ic29sZXRlIGJ5IGl0cyBh dXRob3IiLCAiZGlzY291cmFnZWQgZnJvbSBpbXBsZW1lbnRpbmciLCAibm8gdXBkYXRlIGlzIGV4 cGVjdGVkIiwgInJlcGxhY2VkIGJ5IHRoZSBPQXV0aCAyLjAgZWZmb3J0Ii4NCg0KSSBrbm93IEkg c2hvdWxkIHdyaXRlIGEgZGlzY292ZXJ5IGRyYWZ0IG15c2VsZi4NCg0KLS0gDQpKYW1lcyBNYW5n ZXINCg== From eran@hueniverse.com Mon Jun 21 21:50:23 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D343B3A6953 for ; Mon, 21 Jun 2010 21:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.867 X-Spam-Level: X-Spam-Status: No, score=-0.867 tagged_above=-999 required=5 tests=[AWL=-0.868, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-Iy6Hba3F01 for ; Mon, 21 Jun 2010 21:50:16 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id C25203A6954 for ; Mon, 21 Jun 2010 21:50:04 -0700 (PDT) Received: (qmail 22812 invoked from network); 22 Jun 2010 04:50:10 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 22 Jun 2010 04:50:07 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Mon, 21 Jun 2010 21:50:07 -0700 From: Eran Hammer-Lahav To: "Manger, James H" , "OAuth WG (oauth@ietf.org)" Date: Mon, 21 Jun 2010 21:50:00 -0700 Thread-Topic: OAuth discovery draft? Thread-Index: AcsMLfi0k1bL/UTuTyKlbQqO9cCDCgFh6zFgAAQndLA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EC83F46@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB68D9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1126427308C@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1126427308C@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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [OAUTH-WG] OAuth discovery draft? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 04:50:23 -0000 WWVzLCBpdCdzIG9uIG15IGRlc2sgYW5kIG5vdCB5ZXQgcmVhZHksIGJ1dCBJIGFtIHdvcmtpbmcg b24gb25lLiBJdCBpbmNsdWRlcyB5b3VyIHNpdGVzIHByb3Bvc2FsIGFtb25nIG90aGVyIHRoaW5n cy4gSSBhbSB0cnlpbmcgdG8gZ2V0IHRoZSBjb3JlIHNwZWMgc3RhYmxlIHRoaXMgd2VlayBhbmQg Zm9jdXMgb24gdGhhdCBuZXh0Lg0KDQpFSEwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiBGcm9tOiBNYW5nZXIsIEphbWVzIEggW21haWx0bzpKYW1lcy5ILk1hbmdlckB0ZWFtLnRl bHN0cmEuY29tXQ0KPiBTZW50OiBNb25kYXksIEp1bmUgMjEsIDIwMTAgODowMyBQTQ0KPiBUbzog RXJhbiBIYW1tZXItTGFoYXY7IE9BdXRoIFdHIChvYXV0aEBpZXRmLm9yZykNCj4gU3ViamVjdDog T0F1dGggZGlzY292ZXJ5IGRyYWZ0Pw0KPiANCj4gRXJhbiwNCj4gDQo+IFRoZXJlIGhhdmUgYmVl biBhIGZldyBtZW50aW9ucyByZWNlbnRseSBvZiBhbiBPQXV0aCBkaXNjb3ZlcnkgZHJhZnQuIElz DQo+IHRoZXJlIGFueSBzdWNoIGRyYWZ0IHlldCwgb3IgaXMgdGhpcyBqdXN0IGEgcGFydCB0aGF0 IHdlIGtub3cgbmVlZHMgdG8gYmUNCj4gZG9uZT8NCj4gDQo+IFRoZSBlbWFpbCBvbiAiT0F1dGgg bWVldGluZyBub3RlcyBvbiAtMDUgKHdpdGggdXBkYXRlcykiIHNhaWQ6DQo+IA0KPiA+PiA2LjEu MS4gLSBkZXNjcmliaW5nIHRoZSBXV1ctQXV0aGVudGljYXRlIHJlc3BvbnNlIGhlYWRlcg0KPiA+ Pg0KPiA+PiAtIERpc2NvdmVyeSBuZWVkZWQgZm9yIHZhcmlvdXMgZWxlbWVudHMNCj4gPg0KPiA+ IFllcy4gVGhhdCdzIGZvciB0aGUgZGlzY292ZXJ5IGRyYWZ0Lg0KPiANCj4gDQo+IEEgd2lraSBw YWdlIG9uICJGdXR1cmUgT3BlbklEIFRlY2huaWNhbCBSZXF1aXJlbWVudHMiDQo+IDxodHRwOi8v d2lraS5vcGVuaWQubmV0L0Z1dHVyZS1PcGVuSUQtVGVjaG5pY2FsLVJlcXVpcmVtZW50cz4gc2F5 czoNCj4gDQo+ID4gNikgSWRQIERpc2NvdmVyeQ0KPiA+DQo+ID4gICAgKiBNdWNoIG9mIHRoaXMg d2lsbCBiZSBjb3ZlcmVkIGJ5IE9BdXRoMiBEaXNjb3ZlcnksDQo+ID4gICAgICBob3dldmVyIE9J QyBtYXkgbmVlZCB0byBkZWZpbmUgT3BlbklEIHNwZWNpZmljIGZlYXR1cmVzLg0KPiA+4oCmDQo+ ID4gMTcpIFNpbXBsZXIgZGlzY292ZXJ5DQo+ID4NCj4gPiAgICAqIFNlZSBFcmFuJ3MgT0F1dGgg RGlzY292ZXJ5IHByb3Bvc2FsDQo+IA0KPiANCj4gVGhlcmUgd2FzIGFuIE9BdXRoIDEuMCBEaXNj b3ZlcnkgZHJhZnQgb3ZlciAyIHllYXJzIGFnbywgYnV0IHRoYXQgaXMgdGFnZ2VkOg0KPiAiZXhw aXJlZCIsICJtYXJrZWQgYXMgb2Jzb2xldGUgYnkgaXRzIGF1dGhvciIsICJkaXNjb3VyYWdlZCBm cm9tDQo+IGltcGxlbWVudGluZyIsICJubyB1cGRhdGUgaXMgZXhwZWN0ZWQiLCAicmVwbGFjZWQg YnkgdGhlIE9BdXRoIDIuMCBlZmZvcnQiLg0KPiANCj4gSSBrbm93IEkgc2hvdWxkIHdyaXRlIGEg ZGlzY292ZXJ5IGRyYWZ0IG15c2VsZi4NCj4gDQo+IC0tDQo+IEphbWVzIE1hbmdlcg0K From recordond@gmail.com Mon Jun 21 23:03:12 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCC4A3A6942 for ; Mon, 21 Jun 2010 23:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.075 X-Spam-Level: X-Spam-Status: No, score=-2.075 tagged_above=-999 required=5 tests=[AWL=0.524, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jD8Lem5ej11s for ; Mon, 21 Jun 2010 23:03:11 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 8D3843A68BB for ; Mon, 21 Jun 2010 23:03:11 -0700 (PDT) Received: by iwn9 with SMTP id 9so1345930iwn.31 for ; Mon, 21 Jun 2010 23:03:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=F641rUnmuLl55zNeZxjs6tm0Lw3ih37xQcaPo40WMRk=; b=Zpimyz7F4uYyUn5YxVUqZfLZ6J+j4hiT+kH/PCVp3WL0FpSOeM5zsIdOiPxw6Gz05M n5oLTQuEe1CVvr43Z5eqDKuUQU6e3rmqlDaFESCoPzd0gixEy0V9WrhdEsSptQfENZCd Kipyd7TuJZdBTfU5pSZV9hy9S1AhP7smO8gos= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=SzpCqNZ9GXchUpDS3K33BtBszKbaX/zKmJyDLtjDl/+8B5qTG4SRd/TYicFD+zYmwy ItKo7Yuef1xWHfGcgTbiSRdzBnPou1aXMFHSpFE8cgt7Gsi8yLs4elMXDyfpKjWz7gDm yFBdtQH42zlIAYAYWLIDqOHsqwa/ero2t4Th8= MIME-Version: 1.0 Received: by 10.42.4.210 with SMTP id 18mr2122228ict.0.1277186595867; Mon, 21 Jun 2010 23:03:15 -0700 (PDT) Received: by 10.231.191.81 with HTTP; Mon, 21 Jun 2010 23:03:15 -0700 (PDT) In-Reply-To: References: Date: Mon, 21 Jun 2010 23:03:15 -0700 Message-ID: From: David Recordon To: Dirk Balfanz Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 06:03:12 -0000 Thanks for writing this. A few questions... Do we need both `issuer` and `key_id`? Shouldn't we use `client_id` instead at least for OAuth? Can we write out algorithm instead of `alg`? How do you generate the body hash? Does "websafe-base64-encoded" mean that I can't just blindly use my languages built in base64 encode function? Don't we still have the more fundamental question to answer about decoupling what's being signed from the underlying HTTP request? --David On Mon, Jun 21, 2010 at 12:04 AM, Dirk Balfanz wrote: > Hi guys, > I think I owe the list a proposal for signatures. > I wrote something down that=A0liberally=A0borrows ideas from Magic Signat= ures, > SWT, and (even the name from) JSON Web Tokens. > Here is a short document (called "JSON Tokens") that just explains how to > sign something and verify the signature: > http://docs.google.com/document/pub?id=3D1kv6Oz_HRnWa0DaJx_SQ5Qlk_yqs_7zN= Am75-FmKwNo4 > > Here is an extension of JSON Tokens that can be used for signed OAuth > tokens: > http://docs.google.com/document/pub?id=3D1JUn3Twd9nXwFDgi-fTKl-unDG_ndyow= TZW8OWX9HOUU > Here is a different extension of JSON Tokens that can be used for 2-legge= d > flows. The idea is that this could be used as a drop-in replacement for S= AML > assertions in the OAuth2 assertion flow: > http://docs.google.com/document/pub?id=3D1s4kjRS9P0frG0ulhgP3He01ONlxeTwk= FQV_pCoOowzc > I also have started to write some code to implement this as a > proof-of-concept. > > Thoughts? Comments? > Dirk. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From eran@hueniverse.com Mon Jun 21 23:28:28 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A09823A6959 for ; Mon, 21 Jun 2010 23:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[AWL=0.424, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0gctQpsT+xqW for ; Mon, 21 Jun 2010 23:28:27 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 331BF3A695D for ; Mon, 21 Jun 2010 23:28:27 -0700 (PDT) Received: (qmail 1697 invoked from network); 22 Jun 2010 06:28:34 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 22 Jun 2010 06:28:34 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 21 Jun 2010 23:28:34 -0700 From: Eran Hammer-Lahav To: "OAuth WG (oauth@ietf.org)" Date: Mon, 21 Jun 2010 23:28:29 -0700 Thread-Topic: Re: [OAUTH-WG] OAuth discovery draft? Thread-Index: AcsR1CEa9v9sciQqRpy6XnVIjlLCwg== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EC83F4B@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_90C41DD21FB7C64BB94121FBBC2E72343B3EC83F4BP3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] OAuth discovery draft? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 06:28:28 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EC83F4BP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, it's on my desk and not yet ready, but I am working on one. It include= s your sites proposal among other things. I am trying to get the core spec = stable this week and focus on that next. EHL > -----Original Message----- > From: Manger, James H > Sent: Monday, June 21, 2010 8:03 PM > To: Eran Hammer-Lahav; OAuth WG > Subject: OAuth discovery draft? > > Eran, > > There have been a few mentions recently of an OAuth discovery draft. Is > there any such draft yet, or is this just a part that we know needs to be > done? --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EC83F4BP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Yes, it's on = my desk and not yet ready, but I am working on one. It includes your sites = proposal among other things. I am trying to get the core spec stable this w= eek and focus on that next.

    &nbs= p;

    EHL

     

    > -----Original Message-= ----

    > From: Manger, James H<= /o:p>

    > Sent: Monday, June 21, 2010 8:03 PM

    > To: Eran Hammer-Lahav; OAuth WG

    > Subject: OAuth discovery draft?

    > 

    > Eran,

    > =

    > There have been a few mentions recen= tly of an OAuth discovery draft. Is

    &= gt; there any such draft yet, or is this just a part that we know needs to = be

    > done?

     

    = --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EC83F4BP3PW5EX1MB01E_-- From recordond@gmail.com Tue Jun 22 01:11:07 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CE543A698D for ; Tue, 22 Jun 2010 01:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.113 X-Spam-Level: X-Spam-Status: No, score=-2.113 tagged_above=-999 required=5 tests=[AWL=0.486, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7eIBwbA+UD6Z for ; Tue, 22 Jun 2010 01:11:06 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 210F23A698B for ; Tue, 22 Jun 2010 01:11:01 -0700 (PDT) Received: by iwn9 with SMTP id 9so1445179iwn.31 for ; Tue, 22 Jun 2010 01:11:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=rFebMd1rVVq492UqBEY9G+ELaF17zAWKHnYK1ONObHk=; b=s1TZpclMddSI6fuhX8HMCaN9ErFDl5HtrDABCFKV2PTcCLG1DaAyEB52mXueXrpML8 XIilWoHhh4SSqYpxshBuHYUFGJtTeXFhtXKMM5hqFGa9Fs7sm2/OYouTO3iUmZGh+MZz Qp/D0m/9myVGlhX5a9Ces6l/pp0ygGYYgcMwU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Ler+qi82dqaUxrMR8/0Q6wKQvIBPnOdeULObaWLeASKIoWNFFH3osYtlCl093pOG/7 CQqXJ6zxnT2/rBTE9mA4GFMG6MDoQa8YZyVlF+wC6bHfKZMp4O8CZUj2BvLW3zlSsG8l KJYeBxPqAeDhkpHdop6Bj9z0izfvN2S8B1VU8= MIME-Version: 1.0 Received: by 10.231.158.203 with SMTP id g11mr7164885ibx.24.1277194268416; Tue, 22 Jun 2010 01:11:08 -0700 (PDT) Received: by 10.231.191.81 with HTTP; Tue, 22 Jun 2010 01:11:08 -0700 (PDT) In-Reply-To: References: Date: Tue, 22 Jun 2010 01:11:08 -0700 Message-ID: From: David Recordon To: Dirk Balfanz Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 08:11:07 -0000 btw, I wrote a very naive PHP sample. http://gist.github.com/448164 On Mon, Jun 21, 2010 at 11:03 PM, David Recordon wrot= e: > Thanks for writing this. A few questions... > > Do we need both `issuer` and `key_id`? Shouldn't we use `client_id` > instead at least for OAuth? > > Can we write out algorithm instead of `alg`? > > How do you generate the body hash? > > Does "websafe-base64-encoded" mean that I can't just blindly use my > languages built in base64 encode function? > > Don't we still have the more fundamental question to answer about > decoupling what's being signed from the underlying HTTP request? > > --David > > > On Mon, Jun 21, 2010 at 12:04 AM, Dirk Balfanz wrote= : >> Hi guys, >> I think I owe the list a proposal for signatures. >> I wrote something down that=A0liberally=A0borrows ideas from Magic Signa= tures, >> SWT, and (even the name from) JSON Web Tokens. >> Here is a short document (called "JSON Tokens") that just explains how t= o >> sign something and verify the signature: >> http://docs.google.com/document/pub?id=3D1kv6Oz_HRnWa0DaJx_SQ5Qlk_yqs_7z= NAm75-FmKwNo4 >> >> Here is an extension of JSON Tokens that can be used for signed OAuth >> tokens: >> http://docs.google.com/document/pub?id=3D1JUn3Twd9nXwFDgi-fTKl-unDG_ndyo= wTZW8OWX9HOUU >> Here is a different extension of JSON Tokens that can be used for 2-legg= ed >> flows. The idea is that this could be used as a drop-in replacement for = SAML >> assertions in the OAuth2 assertion flow: >> http://docs.google.com/document/pub?id=3D1s4kjRS9P0frG0ulhgP3He01ONlxeTw= kFQV_pCoOowzc >> I also have started to write some code to implement this as a >> proof-of-concept. >> >> Thoughts? Comments? >> Dirk. >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > From chasen@ironmoney.com Tue Jun 22 01:18:25 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0B4228C0E9 for ; Tue, 22 Jun 2010 01:18:25 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PDrNWuo43xsb for ; Tue, 22 Jun 2010 01:18:24 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id CD9DF3A697B for ; Tue, 22 Jun 2010 01:18:24 -0700 (PDT) Received: by pxi5 with SMTP id 5so1961934pxi.31 for ; Tue, 22 Jun 2010 01:18:26 -0700 (PDT) Received: by 10.114.187.7 with SMTP id k7mr5124116waf.92.1277188695193; Mon, 21 Jun 2010 23:38:15 -0700 (PDT) Received: from [10.0.1.9] ([108.0.223.109]) by mx.google.com with ESMTPS id n29sm17039696wae.4.2010.06.21.23.38.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 21 Jun 2010 23:38:14 -0700 (PDT) From: Chasen Le Hara Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Mon, 21 Jun 2010 23:37:34 -0700 Message-Id: <1E9B2E48-51E4-4080-A458-F598D23101FC@ironmoney.com> To: "OAuth WG (oauth@ietf.org)" Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [OAUTH-WG] Minor corrections to -08 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 08:18:25 -0000 Hello, In section 1.4., =93exchaning=94 should be =93exchanging.=94 In section 1.4.3., =93user-agnet=94 should be =93user-agent.=94 In section 4., =93support addition mechanisms=94 should be =93support = additional mechanisms.=94 And, as already mentioned on the list, =93access grand type=94 in = section 4 should be =93access grant type.=94 Cheers, Chasen= From benl@google.com Tue Jun 22 02:28:33 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22A2B3A685E for ; Tue, 22 Jun 2010 02:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.827 X-Spam-Level: X-Spam-Status: No, score=-101.827 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bf2vIsCPesvd for ; Tue, 22 Jun 2010 02:28:29 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id C4C893A6845 for ; Tue, 22 Jun 2010 02:28:28 -0700 (PDT) Received: from hpaq6.eem.corp.google.com (hpaq6.eem.corp.google.com [172.25.149.6]) by smtp-out.google.com with ESMTP id o5M9SYp3008545 for ; Tue, 22 Jun 2010 02:28:34 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1277198914; bh=gGL749CkRZ8FVQx+UYflZ8g4E3A=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=mkQ6zNLteuCjuw8rtcEVPQi3reV+XMcwcPIZCXNFNWYqLLNWlZ5qXmIV1D183Rhx0 wVF2GVmZumJHwEgk+aMTA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=tpTTavEGHmsu84RBo7ieirrZUEOnzWZre2OBFZUs3kzY8p8SBgxo5magCV3XD9RlS iBfJZqye+q247Ds3Sg2/g== Received: from vws15 (vws15.prod.google.com [10.241.21.143]) by hpaq6.eem.corp.google.com with ESMTP id o5M9S4Je014122 for ; Tue, 22 Jun 2010 02:28:33 -0700 Received: by vws15 with SMTP id 15so3336500vws.17 for ; Tue, 22 Jun 2010 02:28:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.89.234 with SMTP id f42mr2987614vcm.212.1277198910979; Tue, 22 Jun 2010 02:28:30 -0700 (PDT) Received: by 10.220.57.205 with HTTP; Tue, 22 Jun 2010 02:28:30 -0700 (PDT) In-Reply-To: References: Date: Tue, 22 Jun 2010 10:28:30 +0100 Message-ID: From: Ben Laurie To: Dirk Balfanz 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] proposal for signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 09:28:33 -0000 On 22 June 2010 02:14, Dirk Balfanz wrote: > > > On Mon, Jun 21, 2010 at 4:18 AM, Ben Laurie wrote: >> >> On 21 June 2010 08:04, Dirk Balfanz wrote: >> > Hi guys, >> > I think I owe the list a proposal for signatures. >> > I wrote something down that=A0liberally=A0borrows ideas from Magic >> > Signatures, >> > SWT, and (even the name from) JSON Web Tokens. >> > Here is a short document (called "JSON Tokens") that just explains how >> > to >> > sign something and verify the signature: >> > >> > http://docs.google.com/document/pub?id=3D1kv6Oz_HRnWa0DaJx_SQ5Qlk_yqs_= 7zNAm75-FmKwNo4 >> >> "signature is a base64-encoded string of the signature bits." should >> be websafe-base64? > > Yes. I think there are a couple of other places that also need this change. >> "the current time is not after the expiration time of the token >> (defined as not_before + session_length)" should be not_before + >> token_lifetime, right? > > Yes. > >> >> But I'd prefer a not_after instead. > > Either way is fine with me. I picked token_lifetime b/c it tends to take = up > a little less space than a not_after, but I don't feel strongly about it. not_after is in line with X.509, and also means implementations are a few characters shorter :-) >> What is a Service Descriptor? Is this something to do with webfinger, >> or something else? > > Something else. I'm proposing that an OAuth Client be identifiable by a U= RL. > You resolve the URL, you get everything you need to know about that Clien= t. > Simpler than webfinger. Why? What's wrong with webfinger? >> In the HMAC keys section you describe the keys as symmetric, which is >> strictly accurate, but more normally called shared keys for this use. >> >> Obviously you'll need to be a bit more specific about what you mean by >> "RSA-SHA256". > > Right. Any suggestions what RSA-SHA256 should specifically refer to? If I > stick that into a Signature.getInstance() call in Java, it returns > _something_. Any idea what that is? I'd like say that whatever that is is > what I mean by RSA-SHA256. RSA in Java Signature means a PKCS#1 signature (see http://java.sun.com/javase/6/docs/technotes/guides/security/StandardNames.h= tml#Signature). Of course, there are actually two PKCS#1 signature schemes, and the Java docs are quite unclear about which they use, but reading between the lines, I'd say that "SHA256withRSA" (presumably what you meant by "RSA-SHA256"?) yields a PKCS1_v1_5 signature (what they call RSASSA-PKCS1_v1_5) and "SHA256withRSAandMGF1" yields an RSASSA-PSS signature, which is recommended for new applications. >> > Here is an extension of JSON Tokens that can be used for signed OAuth >> > tokens: >> > >> > http://docs.google.com/document/pub?id=3D1JUn3Twd9nXwFDgi-fTKl-unDG_nd= yowTZW8OWX9HOUU >> >> As you know, I hate the term "non-repudation". Can't you just call it >> "signing"? > > What would you say is the advantage of public-key signatures over shared-= key > signatures? I do want to point out that this proposal includes public-key > signatures, and therefore brings to advantages to the table. Well, the advantages are that a) the signature cannot be forged by the verifier (assuming no key leakage)= . b) verifying key distribution is easier (since it is public). I don't know of a short way to describe this other than "public key" or "asymmetric". >> "Protection against leaked authentication tokens: Protocols such as >> OAuth2 use bearer tokens, which may leak when used over non-SSL. >> Signing requests when using bearer tokens lets the recipient of such a >> request verify that the issuer of the request was a legitimate holder >> of the bearer token." - only true if you make the checking of the >> nonce a MUST instead of "may". And even then, MitM wins, of course. > > MITM wins while the token is valid as per not_before and token_lifetime (= or > not_after). Right. >> Why is body_hash optional? > > Maybe some Clients/PRs don't care? I remember that in OAuth 1, we couldn'= t > ever get agreement on what to do about POST body signing, so I made it > optional. I'm not going to stand in the way if people want this to be > required. > >> >> > Here is a different extension of JSON Tokens that can be used for >> > 2-legged >> > flows. The idea is that this could be used as a drop-in replacement fo= r >> > SAML >> > assertions in the OAuth2 assertion flow: >> > >> > http://docs.google.com/document/pub?id=3D1s4kjRS9P0frG0ulhgP3He01ONlxe= TwkFQV_pCoOowzc >> >> You use the abbreviation AS before the full name Authorization Server. > > Oops - sorry. :-) I'll try to do a revision later tonight... > > Thanks for the feedback! > Dirk. >> >> > I also have started to write some code to implement this as a> >> > proof-of-concept. >> > >> > Thoughts? Comments? >> >> Nice. >> >> > Dirk. >> > >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth >> > >> > > > From benl@google.com Tue Jun 22 02:33:31 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4A8F3A6845 for ; Tue, 22 Jun 2010 02:33:31 -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_41=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T02fkPyC3xkM for ; Tue, 22 Jun 2010 02:33:30 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 8F27B3A685F for ; Tue, 22 Jun 2010 02:33:30 -0700 (PDT) Received: from hpaq6.eem.corp.google.com (hpaq6.eem.corp.google.com [172.25.149.6]) by smtp-out.google.com with ESMTP id o5M9Xa0f017091 for ; Tue, 22 Jun 2010 02:33:36 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1277199217; bh=ekJomGeAVoU6vqaSbjehm7noqLs=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=uIkKSR6X7hxog3xQgipdMlYAJZ3dKIBhje6Lmm5MQAtbpOKv0IPdyvj4DbbUIcVD4 gsalWjq6LWKvTrb4sL1MA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=V/KRr8Sy5XI+CwwcRCTiu6wKSqNtidqSEj2u/QIQu7fCF/xuld4He/E1WgdBPwdIr piyMgKNRVDSRkJp1g7LrQ== Received: from vws13 (vws13.prod.google.com [10.241.21.141]) by hpaq6.eem.corp.google.com with ESMTP id o5M9XZMa018675 for ; Tue, 22 Jun 2010 02:33:35 -0700 Received: by vws13 with SMTP id 13so1168258vws.8 for ; Tue, 22 Jun 2010 02:33:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.125.101 with SMTP id x37mr3087999vcr.23.1277199214333; Tue, 22 Jun 2010 02:33:34 -0700 (PDT) Received: by 10.220.57.205 with HTTP; Tue, 22 Jun 2010 02:33:34 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11264272EBE@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E11264272EBE@WSMSG3153V.srv.dir.telstra.com> Date: Tue, 22 Jun 2010 10:33:34 +0100 Message-ID: From: Ben Laurie To: "Manger, James H" Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 09:33:31 -0000 On 22 June 2010 02:40, Manger, James H wrote: > Nat and Ben, > > > >>>> In addition to Ben's questions, I have another. For X.509, you seem to > >>>> be using DER. How do you express the entire certificate chain using > >>>> DER? > >>>> (With PEM, you can just concatenate ... ) > >>> > >>> With DER you can concatenate, too, of course. There's also PKCS#n (for > >>> some value of n which I forget ... 12?) which allows bundling of cert > >>> chains. > >> > >> That's PKCS#12, I suppose. I had under an impression that PKCS#12 includes >> the > >> private key, though. > > > > > > A *.p7c file can be used to hold any number of certificates. It is a > BER-encoded PKCS#7 value, now known as Cryptographic Message Syntax (CMS) > standard [RFC 5652]. It is the ASN.1 syntax used for S/MIME signed email. If > you only want to send certificates, just leaving out the > content-to-be-signed, and the signatures. Ah, thanks, I thought there was something less kludgey than PKCS#12. > > > > Such a file can hold any number of certificates, including public-key > certificates, attribute certificates, or other certificate formats. > > It can also hold CRLs and other revocation information (including OCSP > responses as per draft-turner-additional-cms-ri-choices). > > > > CMS/PKCS#7 is better for this purpose than PKCS#12. > > > > -- > > James Manger > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From benl@google.com Tue Jun 22 02:36:40 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD8743A659A for ; Tue, 22 Jun 2010 02:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.677 X-Spam-Level: X-Spam-Status: No, score=-105.677 tagged_above=-999 required=5 tests=[AWL=0.300, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3K6LP+vgoV9 for ; Tue, 22 Jun 2010 02:36:34 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id B61FE3A685F for ; Tue, 22 Jun 2010 02:36:33 -0700 (PDT) Received: from wpaz1.hot.corp.google.com (wpaz1.hot.corp.google.com [172.24.198.65]) by smtp-out.google.com with ESMTP id o5M9aeDR020770 for ; Tue, 22 Jun 2010 02:36:40 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1277199400; bh=d7l6vSBixlHBjSSQKkQW0HVSjfk=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=BfgLknIbOxEjLO+DaPS3GZpXvclrMVQdUGrTUtsEv0KcWok+mJAmZ3DQGgW+j6EMp fuH4V3o5j9h+wuINHAW/w== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=u32mpCGszIcOvyhz6VzZTEvPwxExA4h5Al1Uh6tjZHT0kbTs9aKvwOnukxfwC5pDb UqNJgt98XeSY152f7dsbg== Received: from vws3 (vws3.prod.google.com [10.241.21.131]) by wpaz1.hot.corp.google.com with ESMTP id o5M9ad10029001 for ; Tue, 22 Jun 2010 02:36:40 -0700 Received: by vws3 with SMTP id 3so105537vws.9 for ; Tue, 22 Jun 2010 02:36:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.124.105 with SMTP id t41mr3025813vcr.146.1277199399302; Tue, 22 Jun 2010 02:36:39 -0700 (PDT) Received: by 10.220.57.205 with HTTP; Tue, 22 Jun 2010 02:36:39 -0700 (PDT) In-Reply-To: References: Date: Tue, 22 Jun 2010 10:36:39 +0100 Message-ID: From: Ben Laurie To: David Recordon 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] proposal for signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 09:36:40 -0000 On 22 June 2010 07:03, David Recordon wrote: > Thanks for writing this. A few questions... > > Do we need both `issuer` and `key_id`? Shouldn't we use `client_id` > instead at least for OAuth? > > Can we write out algorithm instead of `alg`? > > How do you generate the body hash? > > Does "websafe-base64-encoded" mean that I can't just blindly use my > languages built in base64 encode function? No, you need the websafe alphabet, which substitutes '-' and '_' for '+' and '/' in the standard alphabet. Which reminds me, Dirk needs to specify whether padding is used. > Don't we still have the more fundamental question to answer about > decoupling what's being signed from the underlying HTTP request? > > --David > > > On Mon, Jun 21, 2010 at 12:04 AM, Dirk Balfanz wrote= : >> Hi guys, >> I think I owe the list a proposal for signatures. >> I wrote something down that=A0liberally=A0borrows ideas from Magic Signa= tures, >> SWT, and (even the name from) JSON Web Tokens. >> Here is a short document (called "JSON Tokens") that just explains how t= o >> sign something and verify the signature: >> http://docs.google.com/document/pub?id=3D1kv6Oz_HRnWa0DaJx_SQ5Qlk_yqs_7z= NAm75-FmKwNo4 >> >> Here is an extension of JSON Tokens that can be used for signed OAuth >> tokens: >> http://docs.google.com/document/pub?id=3D1JUn3Twd9nXwFDgi-fTKl-unDG_ndyo= wTZW8OWX9HOUU >> Here is a different extension of JSON Tokens that can be used for 2-legg= ed >> flows. The idea is that this could be used as a drop-in replacement for = SAML >> assertions in the OAuth2 assertion flow: >> http://docs.google.com/document/pub?id=3D1s4kjRS9P0frG0ulhgP3He01ONlxeTw= kFQV_pCoOowzc >> I also have started to write some code to implement this as a >> proof-of-concept. >> >> Thoughts? Comments? >> Dirk. >> >> _______________________________________________ >> OAuth mailing 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 jricher@mitre.org Tue Jun 22 06:23:57 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B3433A6962 for ; Tue, 22 Jun 2010 06:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.606 X-Spam-Level: X-Spam-Status: No, score=-4.606 tagged_above=-999 required=5 tests=[AWL=-0.421, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yLTf+DHeE1CQ for ; Tue, 22 Jun 2010 06:23:55 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 42DDC3A6804 for ; Tue, 22 Jun 2010 06:23:55 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o5MDO1iP018172 for ; Tue, 22 Jun 2010 09:24:01 -0400 Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o5MDO1lh018169; Tue, 22 Jun 2010 09:24:01 -0400 Received: from [129.83.50.65] (129.83.50.65) by imchub2.MITRE.ORG (129.83.29.74) with Microsoft SMTP Server id 8.2.254.0; Tue, 22 Jun 2010 09:24:01 -0400 From: Justin Richer To: Eran Hammer-Lahav In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EC83F35@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EC83F35@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset="UTF-8" Date: Tue, 22 Jun 2010 09:24:00 -0400 Message-ID: <1277213040.1814.10.camel@localhost.localdomain> MIME-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: OAuth WG Subject: Re: [OAUTH-WG] Last call for feedback on -08 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 13:23:57 -0000 > I am working on -09 which I hope will be the last major revision of > the specification. If you were planning on submitting any feedback on > draft -08 or the simplification proposal from David and me, please do > so by tomorrow to be included in the next draft. I am mostly looking for the extension mechanisms to be laid out. There are four features that I'd like to see covered by OAuth as a whole: * Token Revocation * Redelegation * Client instance information (update of xoauth_display_name) * Handling of unregistered and dynamically-registered clients Each of these could be handled by an extension and/or guideline doc, and I'm willing to try my hand at writing some of these out. Any takers for input into solutions for any of these problems? I'm also interested to see what happens with the signing proposals, because we still have use cases for the signed-fetch portion of OAuth 1 (both 2-legged and 3-legged). But I'll freely admit that I am not the one to write this. :) -- Justin From dick.hardt@gmail.com Tue Jun 22 07:17:10 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 888C63A68AC for ; Tue, 22 Jun 2010 07:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.407 X-Spam-Level: X-Spam-Status: No, score=-2.407 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WSHQLtD-CwQW for ; Tue, 22 Jun 2010 07:17:07 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id BE5F23A686E for ; Tue, 22 Jun 2010 07:17:07 -0700 (PDT) Received: by pwi6 with SMTP id 6so1878255pwi.31 for ; Tue, 22 Jun 2010 07:17:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=0Ys6s6d/cZTD/lOuJUJNtCrqLwMhszyKVrpqOyDxa7s=; b=nFIs/f6QxSfCnF7OZtXqEgD1fcCsYXQUSUI2b7flKVOp3mFb6T8cvRv7tW42Jmy/Qu LWQv6Z1spE6LXZeAuaW8cuZoqF/DBSdirms3aDmA4UH0yGpoVweqj7pBqV51ROHPneJl h8l1CbslbpYOisAAew3aHChlU/8oCTzG8MxTw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=cY/d4jgdiiHxDxgAYc0grSnuoEt3TrInxNNvy2clL3ADfG14syQaGi6iCIetWYG24f ESD5T0xUpS4UHn3dXQMSkaSVejHTOIumxW6ElPfGH2C0GTd4ZVO9Tx1Q3X1osMzvA+R3 oWs+Ubp9bFM54BwB9vwlZAkAgPPcluvIZQCNw= Received: by 10.114.214.33 with SMTP id m33mr5668391wag.107.1277216232424; Tue, 22 Jun 2010 07:17:12 -0700 (PDT) Received: from [192.168.1.5] ([24.130.32.55]) by mx.google.com with ESMTPS id r20sm87571725wam.17.2010.06.22.07.17.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 22 Jun 2010 07:17:11 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Dick Hardt In-Reply-To: Date: Tue, 22 Jun 2010 07:17:10 -0700 Content-Transfer-Encoding: 7bit Message-Id: <4C5BCAC6-713F-4C42-8696-2931D1AB3199@gmail.com> References: To: David Recordon X-Mailer: Apple Mail (2.1081) Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 14:17:10 -0000 On 2010-06-21, at 11:03 PM, David Recordon wrote: > Thanks for writing this. A few questions... > > Do we need both `issuer` and `key_id`? Shouldn't we use `client_id` > instead at least for OAuth? it is the ID of the key, not the client -- used to rollover keys > Does "websafe-base64-encoded" mean that I can't just blindly use my > languages built in base64 encode function? correct -- but a growing number of languages are supporting websafe > > Don't we still have the more fundamental question to answer about > decoupling what's being signed from the underlying HTTP request? I have no idea what you mean by this question -- Dick From beaton@google.com Tue Jun 22 09:43:30 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F8C13A68B2 for ; Tue, 22 Jun 2010 09:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.76 X-Spam-Level: X-Spam-Status: No, score=-101.76 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bCxVhCWGar+5 for ; Tue, 22 Jun 2010 09:43:28 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id D1FBC3A687A for ; Tue, 22 Jun 2010 09:43:27 -0700 (PDT) Received: from wpaz33.hot.corp.google.com (wpaz33.hot.corp.google.com [172.24.198.97]) by smtp-out.google.com with ESMTP id o5MGhWUa011487 for ; Tue, 22 Jun 2010 09:43:32 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1277225013; bh=4wvlrUvg4Yx3ED3jh+e7QMWl2N4=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=toAPfdelafum8ZCGrmQtubSijzgvMgolauqaUP9gyjAk3ADGXF9UunkpU/e3yPxnn dMfGLuYoAnFthkn4m0SQQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=hVbArQ4tV/9hebzKkCvT1J02qZed5k3HeJKw3FT897ElhZhypYCpI/KEea5P3+RZr exA7bUcA53uv43uThGspA== Received: from pwj2 (pwj2.prod.google.com [10.241.219.66]) by wpaz33.hot.corp.google.com with ESMTP id o5MGh1bO003647 for ; Tue, 22 Jun 2010 09:43:31 -0700 Received: by pwj2 with SMTP id 2so1618667pwj.39 for ; Tue, 22 Jun 2010 09:43:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.86.3 with SMTP id o3mr5451646wfl.182.1277225009926; Tue, 22 Jun 2010 09:43:29 -0700 (PDT) Received: by 10.142.209.5 with HTTP; Tue, 22 Jun 2010 09:43:29 -0700 (PDT) In-Reply-To: <4C5BCAC6-713F-4C42-8696-2931D1AB3199@gmail.com> References: <4C5BCAC6-713F-4C42-8696-2931D1AB3199@gmail.com> Date: Tue, 22 Jun 2010 09:43:29 -0700 Message-ID: From: Brian Eaton To: Dick Hardt , Hannes.Tschofenig@gmx.net Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 16:43:30 -0000 On Tue, Jun 22, 2010 at 7:17 AM, Dick Hardt wrote: >> Thanks for writing this. A few questions... >> >> Do we need both `issuer` and `key_id`? Shouldn't we use `client_id` >> instead at least for OAuth? > > it is the ID of the key, not the client -- used to rollover keys I don't think key id is necessary, but adding Hannes since he called me crazy for saying that at IIW. =) The average client is going to have very few keys. Probably just 1. 3 at the outside. If a server needs to verify, it can literally iterate over all of the keys associated with the client until it finds the right one. There is some precedent for this approach: http://support.microsoft.com/kb/906305/en-us. Cheers, Brian From wmills@yahoo-inc.com Tue Jun 22 09:50:41 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32CF43A694C for ; Tue, 22 Jun 2010 09:50:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.819 X-Spam-Level: X-Spam-Status: No, score=-16.819 tagged_above=-999 required=5 tests=[AWL=0.446, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WK1VKZe7BDBV for ; Tue, 22 Jun 2010 09:50:40 -0700 (PDT) Received: from mrout1-b.corp.re1.yahoo.com (mrout1-b.corp.re1.yahoo.com [69.147.107.20]) by core3.amsl.com (Postfix) with ESMTP id 116993A6943 for ; Tue, 22 Jun 2010 09:50:38 -0700 (PDT) Received: from SNV-EXPF01.ds.corp.yahoo.com (snv-expf01.ds.corp.yahoo.com [207.126.227.250]) by mrout1-b.corp.re1.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o5MGnVBn026083; Tue, 22 Jun 2010 09:49:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:x-mimeole:content-class:mime-version: content-type:content-transfer-encoding:subject:date:message-id: in-reply-to:x-ms-has-attach:x-ms-tnef-correlator:thread-topic: thread-index:references:from:to:cc:return-path:x-originalarrivaltime; b=d7UsLb3CTMAmKhdeA7AEcGhtXweWOb0fso/ti0AVFvRWo5wdncPe4wTgDgn1TUJk Received: from SNV-EXVS08.ds.corp.yahoo.com ([207.126.227.8]) by SNV-EXPF01.ds.corp.yahoo.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 22 Jun 2010 09:49:31 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 22 Jun 2010 09:49:05 -0700 Message-ID: <012AB2B223CB3F4BB846962876F47217057960CC@SNV-EXVS08.ds.corp.yahoo.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] proposal for signatures Thread-Index: AcsSKklc0W7b+Wd1Qn6IX1daE4AitQAAEirA References: <4C5BCAC6-713F-4C42-8696-2931D1AB3199@gmail.com> From: "William Mills" To: "Brian Eaton" , "Dick Hardt" , X-OriginalArrivalTime: 22 Jun 2010 16:49:31.0212 (UTC) FILETIME=[E2BC78C0:01CB122A] Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 16:50:41 -0000 Having a key ID is an optimization. If you're using public key signatures is having to do potentially 3x the signatures going to be a problem? =20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]=20 > On Behalf Of Brian Eaton > Sent: Tuesday, June 22, 2010 9:43 AM > To: Dick Hardt; Hannes.Tschofenig@gmx.net > Cc: OAuth WG > Subject: Re: [OAUTH-WG] proposal for signatures >=20 > On Tue, Jun 22, 2010 at 7:17 AM, Dick Hardt=20 > wrote: > >> Thanks for writing this. A few questions... > >> > >> Do we need both `issuer` and `key_id`? Shouldn't we use=20 > `client_id`=20 > >> instead at least for OAuth? > > > > it is the ID of the key, not the client -- used to rollover keys >=20 > I don't think key id is necessary, but adding Hannes since he=20 > called me crazy for saying that at IIW. =3D) >=20 > The average client is going to have very few keys. Probably just 1. > 3 at the outside. >=20 > If a server needs to verify, it can literally iterate over=20 > all of the keys associated with the client until it finds the=20 > right one. >=20 > There is some precedent for this approach: > http://support.microsoft.com/kb/906305/en-us. >=20 > Cheers, > Brian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 From jpanzer@google.com Tue Jun 22 10:07:57 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27B283A6861 for ; Tue, 22 Jun 2010 10:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.376 X-Spam-Level: X-Spam-Status: No, score=-105.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ReBv7GnRFQWn for ; Tue, 22 Jun 2010 10:07:55 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 869DE3A67D3 for ; Tue, 22 Jun 2010 10:07:55 -0700 (PDT) Received: from hpaq12.eem.corp.google.com (hpaq12.eem.corp.google.com [172.25.149.12]) by smtp-out.google.com with ESMTP id o5MH81rt009764 for ; Tue, 22 Jun 2010 10:08:02 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1277226482; bh=2qytpsxyXk/xzOjZsvNrFPRkV30=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=dW7K2kYYkazYtQQ73AHImNOrcayiXyNSo0cEhEk12pC02HOH1uZiwxPoi3epCoA/j Cf6RO5yMJLw2Xa/Eg4jsQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=m/ehjG7Hlccovo42BPWXWdCS/gB/1yEOqUxtVmV4Yi9s8BtiXtVauMTY9pfO7ZHWx NGYK+f5NAlhPMBe7IM+6A== Received: from ywh30 (ywh30.prod.google.com [10.192.8.30]) by hpaq12.eem.corp.google.com with ESMTP id o5MH7joG026254 for ; Tue, 22 Jun 2010 10:08:00 -0700 Received: by ywh30 with SMTP id 30so4171071ywh.24 for ; Tue, 22 Jun 2010 10:08:00 -0700 (PDT) Received: by 10.101.3.29 with SMTP id f29mr5226027ani.1.1277226480285; Tue, 22 Jun 2010 10:08:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.100.10 with HTTP; Tue, 22 Jun 2010 10:07:40 -0700 (PDT) In-Reply-To: References: From: John Panzer Date: Tue, 22 Jun 2010 10:07:40 -0700 Message-ID: To: Ben Laurie Content-Type: multipart/alternative; boundary=001636c595d3a7b9890489a1769b X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 17:07:57 -0000 --001636c595d3a7b9890489a1769b Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jun 22, 2010 at 2:36 AM, Ben Laurie wrote: > On 22 June 2010 07:03, David Recordon wrote: > > Thanks for writing this. A few questions... > > > > Do we need both `issuer` and `key_id`? Shouldn't we use `client_id` > > instead at least for OAuth? > > > > Can we write out algorithm instead of `alg`? > > > > How do you generate the body hash? > > > > Does "websafe-base64-encoded" mean that I can't just blindly use my > > languages built in base64 encode function? > > No, you need the websafe alphabet, which substitutes '-' and '_' for > '+' and '/' in the standard alphabet. Which reminds me, Dirk needs to > specify whether padding is used. > (Padding _is_ part of the base64 specification IIRC; I think it'd be sufficient to artfully include it in the primary example -- and have a second example crafted so that there happens to be zero padding :) ). You can construct base64url() from base64() plus a substitution pass for -+ and _/ so it doesn't seem too onerous. (Make sure to include one of these characters in the examples too.) > > > Don't we still have the more fundamental question to answer about > > decoupling what's being signed from the underlying HTTP request? > Aside/my $.02: This is a key issue which Salmon+Magic Signatures evades by essentially treating the HTTP request (the method, URL, headers, etc.) as advisory/transport hints, to be ignored when reading the data, and making sure the protocol works even if the data is sent via carrier pigeon; all important information must be contained in the signed, structured body. This is much much harder if you have to deal with totally arbitrary kinds of requests with arbitrary semantics. This also means that you're effectively using HTTP as a simple transport to move envelopes around, in much the same way you can use the ocean to transport messages in bottles around, but a bit more efficiently. I've banged my head against this a bit and have not come up with a better solution but if there is one I'd love to hear it. > > > > --David > > > > > > On Mon, Jun 21, 2010 at 12:04 AM, Dirk Balfanz > wrote: > >> Hi guys, > >> I think I owe the list a proposal for signatures. > >> I wrote something down that liberally borrows ideas from Magic > Signatures, > >> SWT, and (even the name from) JSON Web Tokens. > >> Here is a short document (called "JSON Tokens") that just explains how > to > >> sign something and verify the signature: > >> > http://docs.google.com/document/pub?id=1kv6Oz_HRnWa0DaJx_SQ5Qlk_yqs_7zNAm75-FmKwNo4 > >> > >> Here is an extension of JSON Tokens that can be used for signed OAuth > >> tokens: > >> > http://docs.google.com/document/pub?id=1JUn3Twd9nXwFDgi-fTKl-unDG_ndyowTZW8OWX9HOUU > >> Here is a different extension of JSON Tokens that can be used for > 2-legged > >> flows. The idea is that this could be used as a drop-in replacement for > SAML > >> assertions in the OAuth2 assertion flow: > >> > http://docs.google.com/document/pub?id=1s4kjRS9P0frG0ulhgP3He01ONlxeTwkFQV_pCoOowzc > >> I also have started to write some code to implement this as a > >> proof-of-concept. > >> > >> Thoughts? Comments? > >> Dirk. > >> > >> _______________________________________________ > >> OAuth mailing 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 > --001636c595d3a7b9890489a1769b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    On Tue, Jun 22, 2010 at 2:36 AM, Ben Laurie <benl@google.com>= ; wrote:
    On 22 June 2010 07:03, David Recordon <recordond@gmail.com> wrote:
    > Thanks for writing this. A few questions...
    >
    > Do we need both `issuer` and `key_id`? Shouldn't we use `client_id= `
    > instead at least for OAuth?
    >
    > Can we write out algorithm instead of `alg`?
    >
    > How do you generate the body hash?
    >
    > Does "websafe-base64-encoded" mean that I can't just bli= ndly use my
    > languages built in base64 encode function?

    No, you need the websafe alphabet, which substitutes '-' and = '_' for
    '+' and '/' in the standard alphabet. Which reminds me, Dir= k needs to
    specify whether padding is used.

    (Paddi= ng _is_ part of the base64 specification IIRC; I think it'd be sufficie= nt to artfully include it in the primary example -- and have a second examp= le crafted so that there happens to be zero padding :) ).

    You can construct base64url() from base64() plus a subs= titution pass for -+ and _/ so it doesn't seem too onerous. =A0(Make su= re to include one of these characters in the examples too.)
    =A0

    > Don't we still have the more fundamental question to answer about<= br> > decoupling what's being signed from the underlying HTTP request?

    Aside/my $.02: This is a key= issue which Salmon+Magic Signatures evades by essentially treating the HTT= P request (the method, URL, headers, etc.) as advisory/transport hints, to = be ignored when reading the data, and making sure the protocol works even i= f the data is sent via carrier pigeon; all important information must be co= ntained in the signed, structured body. =A0This is much much harder if you = have to deal with totally arbitrary kinds of requests with arbitrary semant= ics.

    This also means that you're effectively using HTTP = as a simple transport to move envelopes around, in much the same way you ca= n use the ocean to transport messages in bottles around, but a bit more eff= iciently. =A0I've banged my head against this a bit and have not come u= p with a better solution but if there is one I'd love to hear it.
    =A0
    >
    > --David
    >
    >
    > On Mon, Jun 21, 2010 at 12:04 AM, Dirk Balfanz <balfanz@google.com> wrote:
    >> Hi guys,
    >> I think I owe the list a proposal for signatures.
    >> I wrote something down that=A0liberally=A0borrows ideas from Magic= Signatures,
    >> SWT, and (even the name from) JSON Web Tokens.
    >> Here is a short document (called "JSON Tokens") that jus= t explains how to
    >> sign something and verify the signature:
    >> http://docs.google.com/do= cument/pub?id=3D1kv6Oz_HRnWa0DaJx_SQ5Qlk_yqs_7zNAm75-FmKwNo4
    >>
    >> Here is an extension of JSON Tokens that can be used for signed OA= uth
    >> tokens:
    >> http://docs.google.com/do= cument/pub?id=3D1JUn3Twd9nXwFDgi-fTKl-unDG_ndyowTZW8OWX9HOUU
    >> Here is a different extension of JSON Tokens that can be used for = 2-legged
    >> flows. The idea is that this could be used as a drop-in replacemen= t for SAML
    >> assertions in the OAuth2 assertion flow:
    >> http://docs.google.com/do= cument/pub?id=3D1s4kjRS9P0frG0ulhgP3He01ONlxeTwkFQV_pCoOowzc
    >> I also have started to write some code to implement this as a
    >> proof-of-concept.
    >>
    >> Thoughts? Comments?
    >> Dirk.
    >>
    >> _______________________________________________
    >> OAuth mailing 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

    --001636c595d3a7b9890489a1769b-- From tonynad@microsoft.com Tue Jun 22 10:31:25 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25EEC3A687A for ; Tue, 22 Jun 2010 10:31:24 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XuSjXjDp6xaC for ; Tue, 22 Jun 2010 10:31:22 -0700 (PDT) Received: from smtp.microsoft.com (mail1.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id CBDFB3A69C9 for ; Tue, 22 Jun 2010 10:30:57 -0700 (PDT) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 22 Jun 2010 10:30:49 -0700 Received: from TK5EX14MBXC101.redmond.corp.microsoft.com ([169.254.1.121]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.01.0160.007; Tue, 22 Jun 2010 10:30:48 -0700 From: Anthony Nadalin To: Brian Eaton , Dick Hardt , "Hannes.Tschofenig@gmx.net" Thread-Topic: [OAUTH-WG] proposal for signatures Thread-Index: AQHLERAtXWILywYeF0Ok0IAigd5bdZKN9G2AgACJ/wCAACjigP//l5QQ Date: Tue, 22 Jun 2010 17:30:49 +0000 Message-ID: References: <4C5BCAC6-713F-4C42-8696-2931D1AB3199@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 17:31:25 -0000 > If a server needs to verify, it can literally iterate over all of the key= s associated with the client until it finds the right one. Depends on how the server stored the keys, this can be a very expensive ope= ration w/o a key_id to match/index on -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of B= rian Eaton Sent: Tuesday, June 22, 2010 9:43 AM To: Dick Hardt; Hannes.Tschofenig@gmx.net Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for signatures On Tue, Jun 22, 2010 at 7:17 AM, Dick Hardt wrote: >> Thanks for writing this. A few questions... >> >> Do we need both `issuer` and `key_id`? Shouldn't we use `client_id`=20 >> instead at least for OAuth? > > it is the ID of the key, not the client -- used to rollover keys I don't think key id is necessary, but adding Hannes since he called me cra= zy for saying that at IIW. =3D) The average client is going to have very few keys. Probably just 1. 3 at the outside. If a server needs to verify, it can literally iterate over all of the keys = associated with the client until it finds the right one. There is some precedent for this approach: http://support.microsoft.com/kb/906305/en-us. Cheers, Brian _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From jricher@mitre.org Tue Jun 22 10:42:45 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 920133A68F1 for ; Tue, 22 Jun 2010 10:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.551 X-Spam-Level: X-Spam-Status: No, score=-4.551 tagged_above=-999 required=5 tests=[AWL=-0.411, BAYES_20=-0.74, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ZnJA+oJm-OY for ; Tue, 22 Jun 2010 10:42:44 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id A84F63A68C6 for ; Tue, 22 Jun 2010 10:42:44 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o5MHgptj001413 for ; Tue, 22 Jun 2010 13:42:51 -0400 Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o5MHgpqI001407; Tue, 22 Jun 2010 13:42:51 -0400 Received: from [129.83.50.65] (129.83.50.65) by imchub2.MITRE.ORG (129.83.29.74) with Microsoft SMTP Server id 8.2.254.0; Tue, 22 Jun 2010 13:42:51 -0400 From: Justin Richer To: John Panzer In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Tue, 22 Jun 2010 13:42:51 -0400 Message-ID: <1277228571.1814.23.camel@localhost.localdomain> MIME-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 17:42:45 -0000 > Aside/my $.02: This is a key issue which Salmon+Magic Signatures > evades by essentially treating the HTTP request (the method, URL, > headers, etc.) as advisory/transport hints, to be ignored when reading > the data, and making sure the protocol works even if the data is sent > via carrier pigeon; all important information must be contained in the > signed, structured body. This is much much harder if you have to deal > with totally arbitrary kinds of requests with arbitrary semantics. > > > This also means that you're effectively using HTTP as a simple > transport to move envelopes around, in much the same way you can use > the ocean to transport messages in bottles around, but a bit more > efficiently. I've banged my head against this a bit and have not come > up with a better solution but if there is one I'd love to hear it. > +1 From dick.hardt@gmail.com Tue Jun 22 12:14:33 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4DFE28C0DD for ; Tue, 22 Jun 2010 12:14:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTKdW84K58sv for ; Tue, 22 Jun 2010 12:14:30 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 4BDD63A68D4 for ; Tue, 22 Jun 2010 12:14:30 -0700 (PDT) Received: by gxk8 with SMTP id 8so417492gxk.31 for ; Tue, 22 Jun 2010 12:14:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=koNCI8HMS4TzPRitq4x1SsvM1ljb1iWXw1au0GoWf3M=; b=cbOegNpgXjw7tvu7I8qwkx5BnHATgvcPyVgI4r3qZaJCxEDPVofv/kb35mp0khC/aJ y+/bFz7WN33T7pB5wA/XSgRqryV+3hURsCaWC4mSOqfKL0F0nAsXarGc3rI/sT0Vqoy7 xa7eBTT97K6CGVrSbomAAqZf3Sc5513ZXtoE0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=osR8HYFrCYCCrNaFESa8Zw6JxE5N7iXWxeLW2RY6wjpfAYWfMbKXIMRNk29auOPbgE GV10TXiIIp/4qlX/JJCfmhiFUsBIcVnRJFKaq9ggvJ89kjFmRDBGrdk/4djNJakNRGnU 5wnljiXxEunW+BJP88gp94BySrMgy0bFlZoBo= MIME-Version: 1.0 Received: by 10.150.160.1 with SMTP id i1mr6358480ybe.367.1277234074257; Tue, 22 Jun 2010 12:14:34 -0700 (PDT) Received: by 10.231.34.71 with HTTP; Tue, 22 Jun 2010 12:14:34 -0700 (PDT) In-Reply-To: References: <4C5BCAC6-713F-4C42-8696-2931D1AB3199@gmail.com> Date: Tue, 22 Jun 2010 12:14:34 -0700 Message-ID: From: Dick Hardt To: Anthony Nadalin Content-Type: multipart/alternative; boundary=000e0cd755204a8eac0489a33b0a Cc: "Hannes.Tschofenig@gmx.net" , OAuth WG Subject: Re: [OAUTH-WG] proposal for signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 19:14:33 -0000 --000e0cd755204a8eac0489a33b0a Content-Type: text/plain; charset=ISO-8859-1 I could imagine an architecture striving to be efficient, scalable, distributed and secure where there are hundreds of servers each with a unique private key baked into each server. All the public keys would be in one file. Having a key id would help debugging as well as the signer is clearly indicating which key should be used. If the signing fails, it could be the key, could be signature calculation, could be ... The downside of having a key_id seems heavily outweighed by the advantages to me. On Tue, Jun 22, 2010 at 10:30 AM, Anthony Nadalin wrote: > > If a server needs to verify, it can literally iterate over all of the > keys associated with the client until it finds the right one. > > Depends on how the server stored the keys, this can be a very expensive > operation w/o a key_id to match/index on > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of > Brian Eaton > Sent: Tuesday, June 22, 2010 9:43 AM > To: Dick Hardt; Hannes.Tschofenig@gmx.net > Cc: OAuth WG > Subject: Re: [OAUTH-WG] proposal for signatures > > On Tue, Jun 22, 2010 at 7:17 AM, Dick Hardt wrote: > >> Thanks for writing this. A few questions... > >> > >> Do we need both `issuer` and `key_id`? Shouldn't we use `client_id` > >> instead at least for OAuth? > > > > it is the ID of the key, not the client -- used to rollover keys > > I don't think key id is necessary, but adding Hannes since he called me > crazy for saying that at IIW. =) > > The average client is going to have very few keys. Probably just 1. > 3 at the outside. > > If a server needs to verify, it can literally iterate over all of the keys > associated with the client until it finds the right one. > > There is some precedent for this approach: > http://support.microsoft.com/kb/906305/en-us. > > Cheers, > Brian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --000e0cd755204a8eac0489a33b0a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I could imagine an architecture striving to be efficient, scalable, distrib= uted and secure where there are hundreds of servers each with a unique priv= ate key baked into each server. All the public keys would be in one file.
    Having a key id would help debugging as well as the signer i= s clearly indicating which key should be used. If the signing fails, it cou= ld be the key, could be signature calculation, could be ...=A0

    The downside of having a key_id seems heavily=A0outweighed=A0by the ad= vantages to me.

    On Tue, Jun 22, 20= 10 at 10:30 AM, Anthony Nadalin <tonynad@microsoft.com> wrote:
    > If a server needs to= verify, it can literally iterate over all of the keys associated with the = client until it finds the right one.

    Depends on how the server stored the keys, this can be a very expensi= ve operation w/o a key_id to match/index on

    -----Original Message-----
    From: oauth-bounces@ietf.org = [mailto:oauth-bounces@ietf.org] On Behalf Of Brian Eaton
    Sent: Tuesday, June 22, 2010 9:43 AM
    To: Dick Hardt;     Hannes.Tschofe= nig@gmx.net
    Cc: OAuth WG
    Subject: Re: [OAUTH-WG] proposal for signatures

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


    --000e0cd755204a8eac0489a33b0a-- From recordond@gmail.com Tue Jun 22 12:20:41 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C56F73A68ED for ; Tue, 22 Jun 2010 12:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xzwqoz0o7+zv for ; Tue, 22 Jun 2010 12:20:40 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id AD70F3A688D for ; Tue, 22 Jun 2010 12:20:40 -0700 (PDT) Received: by iwn9 with SMTP id 9so1983909iwn.31 for ; Tue, 22 Jun 2010 12:20:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=XsFxqsa61Km/r8CzF36jQrdQbOQpEADvJl/Y/bFSXaU=; b=TL3RiihFPx0SUy0233RTGo81U66VGnyv3Wxd7sOhMVNNWq1DxzI504yZpYTUdM9n8P tjk2ip1/Yn6Js5n+mPkoVgfu8Xw5BcIw8aCTEWUAJYAE4HdmGjLmLxPJ+3WXYXSED2C1 VTG0R6bMoQfw6Sv6GvlNjrovYsdgqEfzLpnFE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=p41ztk7V69I8CNrWcAe+69oNUOQAW6wVmRcikgDa8oqdqJucvRDN0anivA8VEHR80R cQ5XXisCxjtZT/0aYoBTyOprR5sXOvMK8SumSEHm2v+Ufn0lEqMk9DMel06iZtOqdoGe A0tFvwDTt8GwM8Y2ohOU3GmDkPPQuttDOThsE= MIME-Version: 1.0 Received: by 10.231.124.229 with SMTP id v37mr7433836ibr.184.1277234445597; Tue, 22 Jun 2010 12:20:45 -0700 (PDT) Received: by 10.231.191.81 with HTTP; Tue, 22 Jun 2010 12:20:45 -0700 (PDT) In-Reply-To: References: <4C5BCAC6-713F-4C42-8696-2931D1AB3199@gmail.com> Date: Tue, 22 Jun 2010 12:20:45 -0700 Message-ID: From: David Recordon To: Dick Hardt Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Hannes.Tschofenig@gmx.net" , OAuth WG Subject: Re: [OAUTH-WG] proposal for signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 19:20:41 -0000 All of the OAuth 1.0 implementations which I'm aware of either have the server provide a shared secret to the client or the client upload their public key to the server. In the case of the server providing a shared secret to the client, what would the value of key_id be? In the case of a client uploading their public key to the server, what would the value of key_id be? Thanks, --David On Tue, Jun 22, 2010 at 12:14 PM, Dick Hardt wrote: > I could imagine an architecture striving to be efficient, scalable, > distributed and secure where there are hundreds of servers each with a > unique private key baked into each server. All the public keys would be i= n > one file. > Having a key id would help debugging as well as the signer is clearly > indicating which key should be used. If the signing fails, it could be th= e > key, could be signature calculation, could be ... > > The downside of having a key_id seems heavily=A0outweighed=A0by the advan= tages > to me. > On Tue, Jun 22, 2010 at 10:30 AM, Anthony Nadalin > wrote: >> >> > If a server needs to verify, it can literally iterate over all of the >> > keys associated with the client until it finds the right one. >> >> Depends on how the server stored the keys, this can be a very expensive >> operation w/o a key_id to match/index on >> >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf O= f >> Brian Eaton >> Sent: Tuesday, June 22, 2010 9:43 AM >> To: Dick Hardt; Hannes.Tschofenig@gmx.net >> Cc: OAuth WG >> Subject: Re: [OAUTH-WG] proposal for signatures >> >> On Tue, Jun 22, 2010 at 7:17 AM, Dick Hardt wrote= : >> >> Thanks for writing this. A few questions... >> >> >> >> Do we need both `issuer` and `key_id`? Shouldn't we use `client_id` >> >> instead at least for OAuth? >> > >> > it is the ID of the key, not the client -- used to rollover keys >> >> I don't think key id is necessary, but adding Hannes since he called me >> crazy for saying that at IIW. =3D) >> >> The average client is going to have very few keys. =A0Probably just 1. >> 3 at the outside. >> >> If a server needs to verify, it can literally iterate over all of the ke= ys >> associated with the client until it finds the right one. >> >> There is some precedent for this approach: >> http://support.microsoft.com/kb/906305/en-us. >> >> Cheers, >> Brian >> _______________________________________________ >> OAuth mailing 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 dick.hardt@gmail.com Tue Jun 22 12:59:01 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EB493A69D0 for ; Tue, 22 Jun 2010 12:59:01 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o8CozWWxLghu for ; Tue, 22 Jun 2010 12:58:59 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id A45E43A69D2 for ; Tue, 22 Jun 2010 12:58:59 -0700 (PDT) Received: by iwn9 with SMTP id 9so2016803iwn.31 for ; Tue, 22 Jun 2010 12:59:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=Svz3UWAVPYOkRlaw3T4Gf1hlRwZ0A+2zRktayBjRZcI=; b=kt6UbBA8Qa/XYsGjO5pqGskFjUU9XaW+jflzUbzKbxEsulW1Y7F2qnufbIljHaaOkq ZKZoLXCrpzZg6EW4AvDM/ZBKj+TCGZLk8LFeJgIpjJ26nm3qZWQF2kx4BaX1MMCVnht+ BiAGq4ilqZhkWqnrHlwJMDBczOEdThLSKREDc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=eczUk1+SWA5M0lleuRpFB0PiJ9yceMrak9t3OwJt1Zm7/wJE6H9sJKbK+3Sk7RZK+j vtrJhnmZ/woPHkIwKoUIUy1b0XEJkpN0FuwJX4MuPxbPmFcHIs/D5P4sw2t3b07EmlIF 5iLZucpbPzLoFre7pr4a9iiGmVVlJnw5gXh5Q= MIME-Version: 1.0 Received: by 10.231.142.158 with SMTP id q30mr7796957ibu.145.1277236743598; Tue, 22 Jun 2010 12:59:03 -0700 (PDT) Received: by 10.231.34.71 with HTTP; Tue, 22 Jun 2010 12:59:03 -0700 (PDT) In-Reply-To: References: <4C5BCAC6-713F-4C42-8696-2931D1AB3199@gmail.com> Date: Tue, 22 Jun 2010 12:59:03 -0700 Message-ID: From: Dick Hardt To: David Recordon Content-Type: multipart/alternative; boundary=0016e644dd306572c70489a3dab3 Cc: "Hannes.Tschofenig@gmx.net" , OAuth WG Subject: Re: [OAUTH-WG] proposal for signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 19:59:01 -0000 --0016e644dd306572c70489a3dab3 Content-Type: text/plain; charset=ISO-8859-1 David key_ids are used when you need to identify which key to use of all the keys you might have. If you are doing discovery of document that is bound to the identifier of the signer, this is useful. Since OAuth 1.0 did not have discovery and required an out of band key management process, key_ids have little value. To answer your question, key_ids dont' make sense if the keys are being managed how you describe them. I would suggest that key_ids are not included if public keys are managed independent from how Dirk had described them be discovered. I don't think key_ids make sense for shared secrets as they inherently have an out of band process for sharing them. If you would like to learn more about cryptography, I have found Bruce Schneier's book Applied Cryptography to be pretty educational. Here is a link to the Kindle version: http://www.amazon.com/Applied-Cryptography-Protocols-Algorithms-ebook/dp/B000SEHPK6/ref=kinw_dp_ke?ie=UTF8&m=AG56TWVU5XWC2&qid=1277236054&sr=8-1 -- Dick On Tue, Jun 22, 2010 at 12:20 PM, David Recordon wrote: > All of the OAuth 1.0 implementations which I'm aware of either have > the server provide a shared secret to the client or the client upload > their public key to the server. > > In the case of the server providing a shared secret to the client, > what would the value of key_id be? > > In the case of a client uploading their public key to the server, what > would the value of key_id be? > > Thanks, > --David > > > On Tue, Jun 22, 2010 at 12:14 PM, Dick Hardt wrote: > > I could imagine an architecture striving to be efficient, scalable, > > distributed and secure where there are hundreds of servers each with a > > unique private key baked into each server. All the public keys would be > in > > one file. > > Having a key id would help debugging as well as the signer is clearly > > indicating which key should be used. If the signing fails, it could be > the > > key, could be signature calculation, could be ... > > > > The downside of having a key_id seems heavily outweighed by the > advantages > > to me. > > On Tue, Jun 22, 2010 at 10:30 AM, Anthony Nadalin > > > wrote: > >> > >> > If a server needs to verify, it can literally iterate over all of the > >> > keys associated with the client until it finds the right one. > >> > >> Depends on how the server stored the keys, this can be a very expensive > >> operation w/o a key_id to match/index on > >> > >> -----Original Message----- > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of > >> Brian Eaton > >> Sent: Tuesday, June 22, 2010 9:43 AM > >> To: Dick Hardt; Hannes.Tschofenig@gmx.net > >> Cc: OAuth WG > >> Subject: Re: [OAUTH-WG] proposal for signatures > >> > >> On Tue, Jun 22, 2010 at 7:17 AM, Dick Hardt > wrote: > >> >> Thanks for writing this. A few questions... > >> >> > >> >> Do we need both `issuer` and `key_id`? Shouldn't we use `client_id` > >> >> instead at least for OAuth? > >> > > >> > it is the ID of the key, not the client -- used to rollover keys > >> > >> I don't think key id is necessary, but adding Hannes since he called me > >> crazy for saying that at IIW. =) > >> > >> The average client is going to have very few keys. Probably just 1. > >> 3 at the outside. > >> > >> If a server needs to verify, it can literally iterate over all of the > keys > >> associated with the client until it finds the right one. > >> > >> There is some precedent for this approach: > >> http://support.microsoft.com/kb/906305/en-us. > >> > >> Cheers, > >> Brian > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > >> > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > --0016e644dd306572c70489a3dab3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable David

    key_ids are used when you need to identify which k= ey to use of all the keys you might have. If you are doing discovery of doc= ument that is bound to the identifier of the signer, this is useful. Since = OAuth 1.0 did not have discovery and required an out of band key management= process, key_ids have little value.

    To answer your question, key_ids dont' make sense i= f the keys are being managed how you describe them. I would suggest that ke= y_ids are not included if public keys are managed=A0independent=A0from how = Dirk had described them be discovered.=A0

    I don't think key_ids make sense for shared secrets= as they inherently have an out of band process for sharing them.

    <= /div>
    If you would like to learn more about cryptography, I have found = Bruce Schneier's book Applied Cryptography to be pretty educational. He= re is a link to the Kindle version:


    -- Dick

    On Tue, = Jun 22, 2010 at 12:20 PM, David Recordon <recordond@gmail.com> wrote:
    All of the OAuth 1.0 implementations which I'm aware of either have
    the server provide a shared secret to the client or the client upload
    their public key to the server.

    In the case of the server providing a shared secret to the client,
    what would the value of key_id be?

    In the case of a client uploading their public key to the server, what
    would the value of key_id be?

    Thanks,
    --David


    On Tue, Jun 22, 2010 at 12:14 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
    > I could imagine an architecture striving to be efficient, scalable, > distributed and secure where there are hundreds of servers each with a=
    > unique private key baked into each server. All the public keys would b= e in
    > one file.
    > Having a key id would help debugging as well as the signer is clearly<= br> > indicating which key should be used. If the signing fails, it could be= the
    > key, could be signature calculation, could be ...
    >
    > The downside of having a key_id seems heavily=A0outweighed=A0by the ad= vantages
    > to me.
    > On Tue, Jun 22, 2010 at 10:30 AM, Anthony Nadalin <tonynad@microsoft.com>
    > wrote:
    >>
    >> > If a server needs to verify, it can literally iterate over al= l of the
    >> > keys associated with the client until it finds the right one.=
    >>
    >> Depends on how the server stored the keys, this can be a very expe= nsive
    >> operation w/o a key_id to match/index on
    >>
    >> -----Original Message-----
    >> From: oauth-bounces@ietf= .org [mailto:oauth-bounces@ie= tf.org] On Behalf Of
    >> Brian Eaton
    >> Sent: Tuesday, June 22, 2010 9:43 AM
    >> To: Dick Hardt; Hanne= s.Tschofenig@gmx.net
    >> Cc: OAuth WG
    >> Subject: Re: [OAUTH-WG] proposal for signatures
    >>
    >> On Tue, Jun 22, 2010 at 7:17 AM, Dick Hardt <dick.hardt@gmail.com> wrote:
    >> >> Thanks for writing this. A few questions...
    >> >>
    >> >> Do we need both `issuer` and `key_id`? Shouldn't we u= se `client_id`
    >> >> instead at least for OAuth?
    >> >
    >> > it is the ID of the key, not the client -- used to rollover k= eys
    >>
    >> I don't think key id is necessary, but adding Hannes since he = called me
    >> crazy for saying that at IIW. =3D)
    >>
    >> The average client is going to have very few keys. =A0Probably jus= t 1.
    >> 3 at the outside.
    >>
    >> If a server needs to verify, it can literally iterate over all of = the keys
    >> associated with the client until it finds the right one.
    >>
    >> There is some precedent for this approach:
    >> http://support.microsoft.com/kb/906305/en-us.
    >>
    >> Cheers,
    >> Brian
    >> _______________________________________________
    >> OAuth mailing list
    >> OAuth@ietf.org
    >> https://www.ietf.org/mailman/listinfo/oauth
    >>
    >
    >
    > _______________________________________________
    > OAuth mailing list
    > OAuth@ietf.org
    > https://www.ietf.org/mailman/listinfo/oauth
    >
    >

    --0016e644dd306572c70489a3dab3-- From mscurtescu@google.com Tue Jun 22 13:00:40 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 564A33A69D2 for ; Tue, 22 Jun 2010 13:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.448 X-Spam-Level: X-Spam-Status: No, score=-101.448 tagged_above=-999 required=5 tests=[AWL=0.529, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gl-ULbxOuMDn for ; Tue, 22 Jun 2010 13:00:39 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 3E9A43A69CD for ; Tue, 22 Jun 2010 13:00:39 -0700 (PDT) Received: from hpaq2.eem.corp.google.com (hpaq2.eem.corp.google.com [172.25.149.2]) by smtp-out.google.com with ESMTP id o5MK0jXi003957 for ; Tue, 22 Jun 2010 13:00:45 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1277236845; bh=7oV2yFbzefai9bcMdzVBehwG/xM=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=CfdEhS/ek67WNatb1d2jyvRJsJeRsskLXBgmh//zFxvnUkNqLObCvK8r1MecVsTFG 8g+KG3RxJ3WLE2hOHJG6w== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=IHyyBVVhWOakduSi71J2o3P6MfgxxelKNPKSEbKv71fJ4ArAmCmvoK/R87RvFhwfA ttmjHrND0EV7B9tG59bdQ== Received: from gyf3 (gyf3.prod.google.com [10.243.50.67]) by hpaq2.eem.corp.google.com with ESMTP id o5MK0h94009056 for ; Tue, 22 Jun 2010 13:00:44 -0700 Received: by gyf3 with SMTP id 3so3100477gyf.30 for ; Tue, 22 Jun 2010 13:00:43 -0700 (PDT) Received: by 10.101.2.30 with SMTP id e30mr5506357ani.127.1277236843228; Tue, 22 Jun 2010 13:00:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.132.22 with HTTP; Tue, 22 Jun 2010 13:00:23 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EC83F35@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EC83F35@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu Date: Tue, 22 Jun 2010 13:00:23 -0700 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Last call for feedback on -08 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 20:00:40 -0000 There was a suggestion to expand the 'error' parameter to two different parameters: - error_code - well defined list of error codes - error_description - authz server specific free form error description (for logging and troubleshooting) Not sure if you considered this. Marius On Mon, Jun 21, 2010 at 7:27 PM, Eran Hammer-Lahav wrote: > I am working on -09 which I hope will be the last major revision of the > specification. If you were planning on submitting any feedback on draft -08 > or the simplification proposal from David and me, please do so by tomorrow > to be included in the next draft. > > > > EHL > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From mscurtescu@google.com Tue Jun 22 13:02:37 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E18773A69E6 for ; Tue, 22 Jun 2010 13:02:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.73 X-Spam-Level: X-Spam-Status: No, score=-100.73 tagged_above=-999 required=5 tests=[AWL=-0.242, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oZT0zfhsx3pA for ; Tue, 22 Jun 2010 13:02:37 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id DFDA43A6858 for ; Tue, 22 Jun 2010 13:02:36 -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 o5MK2gbq017841 for ; Tue, 22 Jun 2010 13:02:43 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1277236963; bh=xoabgFtRCR70xtp0/66YCvakwMY=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=oQmaDQRQFS51s4u/SwQHnGWk1vl68tc+XYZBIwY0B+HxhA1xNusB93Qo9XHHajMss HspA+0XSCrNK2bQEbVMQw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=odSKer+/L5WAae84aLRm+1cIi6HbKE5U+4c9VQPKiTUXjjYtDUjWf06EegPw1TCjU A7Zef/sA7EDLko62m62Kw== Received: from gxk8 (gxk8.prod.google.com [10.202.11.8]) by wpaz5.hot.corp.google.com with ESMTP id o5MK2fWl025557 for ; Tue, 22 Jun 2010 13:02:41 -0700 Received: by gxk8 with SMTP id 8so437276gxk.31 for ; Tue, 22 Jun 2010 13:02:41 -0700 (PDT) Received: by 10.101.73.11 with SMTP id a11mr5538317anl.130.1277236961119; Tue, 22 Jun 2010 13:02:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.132.22 with HTTP; Tue, 22 Jun 2010 13:02:21 -0700 (PDT) In-Reply-To: References: From: Marius Scurtescu Date: Tue, 22 Jun 2010 13:02:21 -0700 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] native app support (was: Next draft) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 20:02:38 -0000 On Tue, Jun 8, 2010 at 10:46 AM, Marius Scurtescu wrote: > In order to properly support native applications I suggest the > following changes: > [...] > 2. optional redirect_uri (default result page) > > Some native apps do not have a redirect_uri, as a result two things are needed: > > 2.1 Either make redirect_uri optional or define a standard value that > signals that the client does not have such a page. > > 2.2 The authz server must supply a default result page, if there is no > redirect_uri. Also, this page should put the verification code and the > client state (code and state) in the page title in a standard way such > that the native app can extract them from the window title. WRAP > defined how the title should be formed. Should this also go to an extension? It is not introducing any new parameters, not sure if it belongs there. OAuth 1 at least defined the "oob" special value. Marius From eran@hueniverse.com Tue Jun 22 13:05:54 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18CA33A69ED for ; Tue, 22 Jun 2010 13:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.18 X-Spam-Level: X-Spam-Status: No, score=-2.18 tagged_above=-999 required=5 tests=[AWL=0.419, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XB51pHoL+fZR for ; Tue, 22 Jun 2010 13:05:53 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 0E0573A698E for ; Tue, 22 Jun 2010 13:05:53 -0700 (PDT) Received: (qmail 31511 invoked from network); 22 Jun 2010 20:06:00 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 22 Jun 2010 20:06:00 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 22 Jun 2010 13:05:55 -0700 From: Eran Hammer-Lahav To: Marius Scurtescu Date: Tue, 22 Jun 2010 13:05:52 -0700 Thread-Topic: [OAUTH-WG] Last call for feedback on -08 Thread-Index: AcsSRZ0TWZiqY/lAQGyGr698OSBcagAAKHkQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EC84124@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EC83F35@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 \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Last call for feedback on -08 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 20:05:54 -0000 There was also a suggestion by Brian to add an error_uri for additional inf= ormation. I'm happy to include all three. EHL > -----Original Message----- > From: Marius Scurtescu [mailto:mscurtescu@google.com] > Sent: Tuesday, June 22, 2010 1:00 PM > To: Eran Hammer-Lahav > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Last call for feedback on -08 >=20 > There was a suggestion to expand the 'error' parameter to two different > parameters: > - error_code - well defined list of error codes > - error_description - authz server specific free form error description (= for > logging and troubleshooting) >=20 > Not sure if you considered this. >=20 > Marius >=20 >=20 >=20 > On Mon, Jun 21, 2010 at 7:27 PM, Eran Hammer-Lahav > wrote: > > I am working on -09 which I hope will be the last major revision of > > the specification. If you were planning on submitting any feedback on > > draft -08 or the simplification proposal from David and me, please do > > so by tomorrow to be included in the next draft. > > > > > > > > EHL > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > From dick.hardt@gmail.com Tue Jun 22 13:22:30 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D22B3A698C for ; Tue, 22 Jun 2010 13:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n1QggRTTp47w for ; Tue, 22 Jun 2010 13:22:29 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 06E623A68D8 for ; Tue, 22 Jun 2010 13:22:29 -0700 (PDT) Received: by pvg2 with SMTP id 2so111430pvg.31 for ; Tue, 22 Jun 2010 13:22:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=R/Ponx1JpMDpM25h60NeBmJ4aTGGpO8vwPY0tYp5ZAo=; b=BH/hTF4IPKiQX5i6XjWKhIUZr9uOVkXxd2BEnl2ZdVCQeUVnfLHCxIXu7J7MO56IiU FFqzrufB0jI+BalmsCfhHd13gQOtNPdiFZ3mhTO83GvCKJhR0Ud0zsqAFAKDB95j3ogf oVf10qT76m7bb2CsJyKGAc0/773rijVBZet8A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=dBxl1Bfdp5FWrY22c3pphzROF44hrm3RkDzcVnGSoKvAmtVn/Vu1AU+Onn2DpUgxrV VFTN4Hbhi6MG6oSVav1qgTNpG07BYfsGjtsssA8JL8O8wIbfHzRECvQsUQqhpo4MjmP3 7Yf21ICbAsVDeCPdYSpBeDn9f4PSAQLcloPaE= MIME-Version: 1.0 Received: by 10.142.66.11 with SMTP id o11mr5863373wfa.121.1277238154152; Tue, 22 Jun 2010 13:22:34 -0700 (PDT) Received: by 10.143.164.13 with HTTP; Tue, 22 Jun 2010 13:22:34 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF76BC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3EBB66AC@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Tue, 22 Jun 2010 13:22:34 -0700 Message-ID: From: Dick Hardt To: Brian Eaton Content-Type: multipart/alternative; boundary=001636e0b9b878ca800489a42efc Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Draft -07 (major rewrite) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 20:22:30 -0000 --001636e0b9b878ca800489a42efc Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable One of the modifications I concluded to do to WRAP was to add in the type parameter. I was happy to see if in David's draft. Even though redundant in some ways, it make it very clear to both the clien= t and server what is intended. +1 for putting it back in. On Mon, Jun 14, 2010 at 11:23 AM, Brian Eaton wrote: > On Mon, Jun 14, 2010 at 9:18 AM, Eran Hammer-Lahav > wrote: > > Adding a verification code to the user-agent flow was suggested on this > list > > and received nothing but support. It was suggested as a solution to a > > Twitter use case. Once that is added in, the two flows only differ in h= ow > > the response is delivered and the presence of an access token in the > > response (which currently is a MUST NOT for web-server but I don=92t kn= ow > if > > this restriction is need). > > Yeah, this matters. If you return an access token on the web-server > flow, several things break: > - you can no longer rely on the client secret to authenticate the callbac= k > URL. > - you lose all hope of getting to LOA 2 with this protocol, because > the access token is visible to the client. > - you lose the clarity of how the web server flow is supposed to work. > > Bike-shed painting: > > The use-cases for web server and user-agent flow are also different. > I'd prefer to have the spec call out different profiles for different > use-cases, because it makes it much easier to figure out what a given > application should be doing. > > During the WRAP work I argued that we didn't need a type parameter, > and after looking at WRAP implementations I've changed my mind. > Please leave it in. > > Cheers, > Brian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001636e0b9b878ca800489a42efc Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable One of the modifications I concluded to do to WRAP was to add in the type p= arameter. I was happy to see if in David's draft.

    Ev= en though redundant in some ways, it make it very clear to both the client = and server what is intended.=A0

    +1 for putting it back in.

    On Mon, Jun 14, 2010 at 11:23 AM, Brian Eaton <<= a href=3D"mailto:beaton@google.com">beaton@google.com> wrote:=
    On Mon, Jun 14, 2010 at 9= :18 AM, Eran Hammer-Lahav <eran@h= ueniverse.com> wrote:
    > Adding a verification code to the user-agent flow was suggested on thi= s list
    > and received nothing but support. It was suggested as a solution to a<= br> > Twitter use case. Once that is added in, the two flows only differ in = how
    > the response is delivered and the presence of an access token in the > response (which currently is a MUST NOT for web-server but I don=92t k= now if
    > this restriction is need).

    Yeah, this matters. =A0If you return an access token on the web-serve= r
    flow, several things break:
    - you can no longer rely on the client secret to authenticate the callback = URL.
    - you lose all hope of getting to LOA 2 with this protocol, because
    the access token is visible to the client.
    - you lose the clarity of how the web server flow is supposed to work.

    Bike-shed painting:

    The use-cases for web server and user-agent flow are also different.
    I'd prefer to have the spec call out different profiles for different use-cases, because it makes it much easier to figure out what a given
    application should be doing.

    During the WRAP work I argued that we didn't need a type parameter,
    and after looking at WRAP implementations I've changed my mind.
    Please leave it in.

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

    --001636e0b9b878ca800489a42efc-- From dick.hardt@gmail.com Tue Jun 22 13:28:30 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFCD53A698C for ; Tue, 22 Jun 2010 13:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qM4k3DqaOD0 for ; Tue, 22 Jun 2010 13:28:29 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id DA7F13A68CF for ; Tue, 22 Jun 2010 13:28:28 -0700 (PDT) Received: by pxi5 with SMTP id 5so2297827pxi.31 for ; Tue, 22 Jun 2010 13:28:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=xC5l4eCC17HPLyVn+c7p36BX6PEaOw1GjWn1hSxcw2E=; b=hjLVypxw11Ug0tzk7d3AzIxlZaQBW5Xg3EeY9I9kFC0kKpdxoDE6mjmTKWCNpl9WXC bmqHd+bWuRaVcHUEZWQNMtf4xJ8bR2Tg2QXy6WOhVm9wmvk1LAMr+HEuoPl59GQIW0QF P7kBk9RWRUdnpWj1UGk2g1wb1kV79aeNqMqdY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=YbCysti8goeDVtjzVnbjH9FdGAFLRzt4bSnbu1054UL7PnBSc5Gkll5znEHvyT8cgK Zta8LMxT1JjXzKw9MGUcppQaWyLXWAltd/C+tvCwrGZhImntdD1szkokjP3mAcNu+B0y hGUKcTlMRJ9wldsqf5Y+wzocqps/TrbiiJ6TE= MIME-Version: 1.0 Received: by 10.142.1.40 with SMTP id 40mr5884032wfa.229.1277238513675; Tue, 22 Jun 2010 13:28:33 -0700 (PDT) Received: by 10.143.164.13 with HTTP; Tue, 22 Jun 2010 13:28:33 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF76BC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3EBB66AC@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Tue, 22 Jun 2010 13:28:33 -0700 Message-ID: From: Dick Hardt To: Brian Eaton Content-Type: multipart/alternative; boundary=00504502bb55e6af280489a44302 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Draft -07 (major rewrite) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 20:28:30 -0000 --00504502bb55e6af280489a44302 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Per an earlier comment, "type" might not be the best name for the parameter= . Perhaps "method" might work and adds a clear extension point for other type= s of calls? On Tue, Jun 22, 2010 at 1:22 PM, Dick Hardt wrote: > One of the modifications I concluded to do to WRAP was to add in the type > parameter. I was happy to see if in David's draft. > > Even though redundant in some ways, it make it very clear to both the > client and server what is intended. > > +1 for putting it back in. > > > On Mon, Jun 14, 2010 at 11:23 AM, Brian Eaton wrote: > >> On Mon, Jun 14, 2010 at 9:18 AM, Eran Hammer-Lahav >> wrote: >> > Adding a verification code to the user-agent flow was suggested on thi= s >> list >> > and received nothing but support. It was suggested as a solution to a >> > Twitter use case. Once that is added in, the two flows only differ in >> how >> > the response is delivered and the presence of an access token in the >> > response (which currently is a MUST NOT for web-server but I don=92t k= now >> if >> > this restriction is need). >> >> Yeah, this matters. If you return an access token on the web-server >> flow, several things break: >> - you can no longer rely on the client secret to authenticate the callba= ck >> URL. >> - you lose all hope of getting to LOA 2 with this protocol, because >> the access token is visible to the client. >> - you lose the clarity of how the web server flow is supposed to work. >> >> Bike-shed painting: >> >> The use-cases for web server and user-agent flow are also different. >> I'd prefer to have the spec call out different profiles for different >> use-cases, because it makes it much easier to figure out what a given >> application should be doing. >> >> During the WRAP work I argued that we didn't need a type parameter, >> and after looking at WRAP implementations I've changed my mind. >> Please leave it in. >> >> Cheers, >> Brian >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > --00504502bb55e6af280489a44302 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Per an earlier comment, "type" might not be the best name for the= parameter. Perhaps "method" might work and adds a clear extensio= n point for other types of calls?

    On Tue,= Jun 22, 2010 at 1:22 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
    One of the modifications I concluded to do = to WRAP was to add in the type parameter. I was happy to see if in David= 9;s draft.

    Even though redundant in some ways, it make it very clear to= both the client and server what is intended.=A0

    +1 for putting it back in.


    On Mon, Jun 14, 2010 at 11:23 AM, B= rian Eaton <beaton@google.com> wrote:
    On Mon, Jun 14, 2010 at 9:18 AM, Eran H= ammer-Lahav <er= an@hueniverse.com> wrote:
    > Adding a verification code to the user-agent flow was suggested on thi= s list
    > and received nothing but support. It was suggested as a solution to a<= br> > Twitter use case. Once that is added in, the two flows only differ in = how
    > the response is delivered and the presence of an access token in the > response (which currently is a MUST NOT for web-server but I don=92t k= now if
    > this restriction is need).

    Yeah, this matters. =A0If you return an access token on the web-serve= r
    flow, several things break:
    - you can no longer rely on the client secret to authenticate the callback = URL.
    - you lose all hope of getting to LOA 2 with this protocol, because
    the access token is visible to the client.
    - you lose the clarity of how the web server flow is supposed to work.

    Bike-shed painting:

    The use-cases for web server and user-agent flow are also different.
    I'd prefer to have the spec call out different profiles for different use-cases, because it makes it much easier to figure out what a given
    application should be doing.

    During the WRAP work I argued that we didn't need a type parameter,
    and after looking at WRAP implementations I've changed my mind.
    Please leave it in.

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


    --00504502bb55e6af280489a44302-- From recordond@gmail.com Tue Jun 22 13:45:15 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E84B73A6A03 for ; Tue, 22 Jun 2010 13:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.152 X-Spam-Level: X-Spam-Status: No, score=-2.152 tagged_above=-999 required=5 tests=[AWL=0.447, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G0n6AObyo0Oy for ; Tue, 22 Jun 2010 13:45:12 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id BFEFD3A69DF for ; Tue, 22 Jun 2010 13:45:11 -0700 (PDT) Received: by iwn9 with SMTP id 9so2058139iwn.31 for ; Tue, 22 Jun 2010 13:45:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=BOiZ+J5HLkaViI8TfDWT8JkZx6+14tNhHTYqtVeQLhk=; b=WHMCxfS8YomPpBKJXzX3xwOmVyPEcFL+iGIlMrF6BHVihlFOBFbGD91KCUnmkmSiPY ObyjxLZ7thsak90LygKGk7XhgnybUdBNI9Gjx5VTh455ABpeAeMgr1yvzY5EkzPjZj6e OxFy+NAQ9UKl7SjtHUkWCPHRsxGWmpo5vFqkg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=a3i4uS7AELYUpJy9uAw1qokRB0cq4WQswiaomEMbDR3moC04h3Zy2HrNQB5BmYpPeu JHA5vIrWRWToi/mqaxR5zrMk676KFETTy96YOxKyxhhIzGQJl5Y9Q0QvxS+F5JtLEllN 9pcbhWyFgBHXJ9O0+Ki8bHqZIJ8dB6/OWN8Mg= MIME-Version: 1.0 Received: by 10.231.183.19 with SMTP id ce19mr7903195ibb.35.1277239514968; Tue, 22 Jun 2010 13:45:14 -0700 (PDT) Received: by 10.231.191.81 with HTTP; Tue, 22 Jun 2010 13:45:14 -0700 (PDT) In-Reply-To: References: <4C5BCAC6-713F-4C42-8696-2931D1AB3199@gmail.com> Date: Tue, 22 Jun 2010 13:45:14 -0700 Message-ID: From: David Recordon To: Dick Hardt Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "Hannes.Tschofenig@gmx.net" , OAuth WG Subject: Re: [OAUTH-WG] proposal for signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 20:45:16 -0000 Hey Dick, in answering my questions you made my point. If keys are managed out of band =96=A0as is done in OAuth 1.0 and what was done in the OAuth 2.0 Core spec until signatures were extracted =96=A0then having a key id is not needed. I certainly understand what they're used for, but don't find them relevant as part of the OAuth conversation today. And yes, Applied Cryptography is worth reading. :) --David On Tue, Jun 22, 2010 at 12:59 PM, Dick Hardt wrote: > David > key_ids are used when you need to identify which key to use of all the ke= ys > you might have. If you are doing discovery of document that is bound to t= he > identifier of the signer, this is useful. Since OAuth 1.0 did not have > discovery and required an out of band key management process, key_ids hav= e > little value. > To answer your question, key_ids dont' make sense if the keys are being > managed how you describe them. I would suggest that key_ids are not inclu= ded > if public keys are managed=A0independent=A0from how Dirk had described th= em be > discovered. > I don't think key_ids make sense for shared secrets as they inherently ha= ve > an out of band process for sharing them. > If you would like to learn more about cryptography, I have found Bruce > Schneier's book Applied Cryptography to be pretty educational. Here is a > link to the Kindle version: > http://www.amazon.com/Applied-Cryptography-Protocols-Algorithms-ebook/dp/= B000SEHPK6/ref=3Dkinw_dp_ke?ie=3DUTF8&m=3DAG56TWVU5XWC2&qid=3D1277236054&sr= =3D8-1 > -- Dick > > On Tue, Jun 22, 2010 at 12:20 PM, David Recordon > wrote: >> >> All of the OAuth 1.0 implementations which I'm aware of either have >> the server provide a shared secret to the client or the client upload >> their public key to the server. >> >> In the case of the server providing a shared secret to the client, >> what would the value of key_id be? >> >> In the case of a client uploading their public key to the server, what >> would the value of key_id be? >> >> Thanks, >> --David >> >> >> On Tue, Jun 22, 2010 at 12:14 PM, Dick Hardt wrot= e: >> > I could imagine an architecture striving to be efficient, scalable, >> > distributed and secure where there are hundreds of servers each with a >> > unique private key baked into each server. All the public keys would b= e >> > in >> > one file. >> > Having a key id would help debugging as well as the signer is clearly >> > indicating which key should be used. If the signing fails, it could be >> > the >> > key, could be signature calculation, could be ... >> > >> > The downside of having a key_id seems heavily=A0outweighed=A0by the >> > advantages >> > to me. >> > On Tue, Jun 22, 2010 at 10:30 AM, Anthony Nadalin >> > >> > wrote: >> >> >> >> > If a server needs to verify, it can literally iterate over all of t= he >> >> > keys associated with the client until it finds the right one. >> >> >> >> Depends on how the server stored the keys, this can be a very expensi= ve >> >> operation w/o a key_id to match/index on >> >> >> >> -----Original Message----- >> >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behal= f >> >> Of >> >> Brian Eaton >> >> Sent: Tuesday, June 22, 2010 9:43 AM >> >> To: Dick Hardt; Hannes.Tschofenig@gmx.net >> >> Cc: OAuth WG >> >> Subject: Re: [OAUTH-WG] proposal for signatures >> >> >> >> On Tue, Jun 22, 2010 at 7:17 AM, Dick Hardt >> >> wrote: >> >> >> Thanks for writing this. A few questions... >> >> >> >> >> >> Do we need both `issuer` and `key_id`? Shouldn't we use `client_id= ` >> >> >> instead at least for OAuth? >> >> > >> >> > it is the ID of the key, not the client -- used to rollover keys >> >> >> >> I don't think key id is necessary, but adding Hannes since he called = me >> >> crazy for saying that at IIW. =3D) >> >> >> >> The average client is going to have very few keys. =A0Probably just 1= . >> >> 3 at the outside. >> >> >> >> If a server needs to verify, it can literally iterate over all of the >> >> keys >> >> associated with the client until it finds the right one. >> >> >> >> There is some precedent for this approach: >> >> http://support.microsoft.com/kb/906305/en-us. >> >> >> >> Cheers, >> >> Brian >> >> _______________________________________________ >> >> OAuth mailing 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 recordond@gmail.com Tue Jun 22 13:46:56 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BFAD3A69F8 for ; Tue, 22 Jun 2010 13:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.169 X-Spam-Level: X-Spam-Status: No, score=-2.169 tagged_above=-999 required=5 tests=[AWL=0.430, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AsLOhxiZbRuF for ; Tue, 22 Jun 2010 13:46:51 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 847873A68D5 for ; Tue, 22 Jun 2010 13:46:51 -0700 (PDT) Received: by iwn9 with SMTP id 9so2059621iwn.31 for ; Tue, 22 Jun 2010 13:46:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=0ckMhSRA1JpJIB9ipJmu5DAg9w/xe21hPVk5akivokU=; b=b1jML2Qm9hEe1MXKnx16gYWAe/DrvpTHkeC1RKyi6mdUlwudUEe8SZ929c3X3jfOCU osMPPvcMPCx7EtRJCK6P2Br8shrlCs8ecwjtmmIoTbndTPqgrc5Q+D3vT5riXhgGvf9q 58HNAYwH4AjPcj5Q1Dp9RFtdUFoW2LiTx5a/0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=haScIpcAHE1gbAHbWyQ7H/GlL6HtfGbft9o8IGQLN2shqTMOHp5htwnlDmo5YyE7wo iWZ/9B0zbDQoLYIj/OB+O4PVqFPeG/BgVFNfM3sSxZFSckYqaLAHGFvjfw6hPcbITC1z ETUlbWrVTNkNTft0q15fQNk2/FrrYgmH6R7p4= MIME-Version: 1.0 Received: by 10.231.169.6 with SMTP id w6mr7076664iby.5.1277239591774; Tue, 22 Jun 2010 13:46:31 -0700 (PDT) Received: by 10.231.191.81 with HTTP; Tue, 22 Jun 2010 13:46:31 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EC84124@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EC83F35@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3EC84124@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Tue, 22 Jun 2010 13:46:31 -0700 Message-ID: From: David Recordon To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Last call for feedback on -08 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 20:46:56 -0000 If we have both error_code and error_description, why is an error_uri needed? (I'm not finding anything when I search the list for 'error_uri'.) On Tue, Jun 22, 2010 at 1:05 PM, Eran Hammer-Lahav wrote: > There was also a suggestion by Brian to add an error_uri for additional information. > > I'm happy to include all three. > > EHL > >> -----Original Message----- >> From: Marius Scurtescu [mailto:mscurtescu@google.com] >> Sent: Tuesday, June 22, 2010 1:00 PM >> To: Eran Hammer-Lahav >> Cc: OAuth WG (oauth@ietf.org) >> Subject: Re: [OAUTH-WG] Last call for feedback on -08 >> >> There was a suggestion to expand the 'error' parameter to two different >> parameters: >> - error_code - well defined list of error codes >> - error_description - authz server specific free form error description (for >> logging and troubleshooting) >> >> Not sure if you considered this. >> >> Marius >> >> >> >> On Mon, Jun 21, 2010 at 7:27 PM, Eran Hammer-Lahav >> wrote: >> > I am working on -09 which I hope will be the last major revision of >> > the specification. If you were planning on submitting any feedback on >> > draft -08 or the simplification proposal from David and me, please do >> > so by tomorrow to be included in the next draft. >> > >> > >> > >> > 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 gffletch@aol.com Tue Jun 22 14:36:37 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70FF528C0F8 for ; Tue, 22 Jun 2010 14:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.078 X-Spam-Level: X-Spam-Status: No, score=-2.078 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YDMavO2vCVi3 for ; Tue, 22 Jun 2010 14:36:31 -0700 (PDT) Received: from imr-mb01.mx.aol.com (imr-mb01.mx.aol.com [64.12.207.164]) by core3.amsl.com (Postfix) with ESMTP id BC7133A69DF for ; Tue, 22 Jun 2010 14:36:30 -0700 (PDT) Received: from mtaout-ma05.r1000.mx.aol.com (mtaout-ma05.r1000.mx.aol.com [172.29.41.5]) by imr-mb01.mx.aol.com (8.14.1/8.14.1) with ESMTP id o5MLZmvo003933; Tue, 22 Jun 2010 17:35:52 -0400 Received: from palantir.local (unknown [10.172.1.96]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-ma05.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id EEFB8E0000BF; Tue, 22 Jun 2010 17:35:49 -0400 (EDT) Message-ID: <4C212CB5.6070000@aol.com> Date: Tue, 22 Jun 2010 17:35:49 -0400 From: George Fletcher Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: OAuth WG References: <4C5BCAC6-713F-4C42-8696-2931D1AB3199@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020207090007040204080403" x-aol-global-disposition: G X-AOL-SCOLL-SCORE: 0:2:443753824:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d29054c212cb520ba X-AOL-IP: 10.172.1.96 Cc: "Hannes.Tschofenig@gmx.net" Subject: Re: [OAUTH-WG] proposal for signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 21:36:37 -0000 This is a multi-part message in MIME format. --------------020207090007040204080403 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The only additional value might be during "key rotation". If key_id is removed, then both (or n) have to be checked. Probably not a huge issue. Thanks, George On 6/22/10 4:45 PM, David Recordon wrote: > Hey Dick, in answering my questions you made my point. If keys are > managed out of band -- as is done in OAuth 1.0 and what was done in the > OAuth 2.0 Core spec until signatures were extracted -- then having a > key id is not needed. I certainly understand what they're used for, > but don't find them relevant as part of the OAuth conversation today. > > And yes, Applied Cryptography is worth reading. :) > > --David > > > On Tue, Jun 22, 2010 at 12:59 PM, Dick Hardt wrote: > >> David >> key_ids are used when you need to identify which key to use of all the keys >> you might have. If you are doing discovery of document that is bound to the >> identifier of the signer, this is useful. Since OAuth 1.0 did not have >> discovery and required an out of band key management process, key_ids have >> little value. >> To answer your question, key_ids dont' make sense if the keys are being >> managed how you describe them. I would suggest that key_ids are not included >> if public keys are managed independent from how Dirk had described them be >> discovered. >> I don't think key_ids make sense for shared secrets as they inherently have >> an out of band process for sharing them. >> If you would like to learn more about cryptography, I have found Bruce >> Schneier's book Applied Cryptography to be pretty educational. Here is a >> link to the Kindle version: >> http://www.amazon.com/Applied-Cryptography-Protocols-Algorithms-ebook/dp/B000SEHPK6/ref=kinw_dp_ke?ie=UTF8&m=AG56TWVU5XWC2&qid=1277236054&sr=8-1 >> -- Dick >> >> On Tue, Jun 22, 2010 at 12:20 PM, David Recordon >> wrote: >> >>> All of the OAuth 1.0 implementations which I'm aware of either have >>> the server provide a shared secret to the client or the client upload >>> their public key to the server. >>> >>> In the case of the server providing a shared secret to the client, >>> what would the value of key_id be? >>> >>> In the case of a client uploading their public key to the server, what >>> would the value of key_id be? >>> >>> Thanks, >>> --David >>> >>> >>> On Tue, Jun 22, 2010 at 12:14 PM, Dick Hardt wrote: >>> >>>> I could imagine an architecture striving to be efficient, scalable, >>>> distributed and secure where there are hundreds of servers each with a >>>> unique private key baked into each server. All the public keys would be >>>> in >>>> one file. >>>> Having a key id would help debugging as well as the signer is clearly >>>> indicating which key should be used. If the signing fails, it could be >>>> the >>>> key, could be signature calculation, could be ... >>>> >>>> The downside of having a key_id seems heavily outweighed by the >>>> advantages >>>> to me. >>>> On Tue, Jun 22, 2010 at 10:30 AM, Anthony Nadalin >>>> >>>> wrote: >>>> >>>>> >>>>>> If a server needs to verify, it can literally iterate over all of the >>>>>> keys associated with the client until it finds the right one. >>>>>> >>>>> Depends on how the server stored the keys, this can be a very expensive >>>>> operation w/o a key_id to match/index on >>>>> >>>>> -----Original Message----- >>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >>>>> Of >>>>> Brian Eaton >>>>> Sent: Tuesday, June 22, 2010 9:43 AM >>>>> To: Dick Hardt; Hannes.Tschofenig@gmx.net >>>>> Cc: OAuth WG >>>>> Subject: Re: [OAUTH-WG] proposal for signatures >>>>> >>>>> On Tue, Jun 22, 2010 at 7:17 AM, Dick Hardt >>>>> wrote: >>>>> >>>>>>> Thanks for writing this. A few questions... >>>>>>> >>>>>>> Do we need both `issuer` and `key_id`? Shouldn't we use `client_id` >>>>>>> instead at least for OAuth? >>>>>>> >>>>>> it is the ID of the key, not the client -- used to rollover keys >>>>>> >>>>> I don't think key id is necessary, but adding Hannes since he called me >>>>> crazy for saying that at IIW. =) >>>>> >>>>> The average client is going to have very few keys. Probably just 1. >>>>> 3 at the outside. >>>>> >>>>> If a server needs to verify, it can literally iterate over all of the >>>>> keys >>>>> associated with the client until it finds the right one. >>>>> >>>>> There is some precedent for this approach: >>>>> http://support.microsoft.com/kb/906305/en-us. >>>>> >>>>> Cheers, >>>>> Brian >>>>> _______________________________________________ >>>>> OAuth mailing 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 > > --------------020207090007040204080403 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The only additional value might be during "key rotation". If key_id is removed, then both (or n) have to be checked. Probably not a huge issue.

    Thanks,
    George

    On 6/22/10 4:45 PM, David Recordon wrote: 
    Hey Dick, in answering my questions you made my point. If keys are
managed out of band – as is done in OAuth 1.0 and what was done in the
OAuth 2.0 Core spec until signatures were extracted – then having a
key id is not needed. I certainly understand what they're used for,
but don't find them relevant as part of the OAuth conversation today.

And yes, Applied Cryptography is worth reading. :)

--David


On Tue, Jun 22, 2010 at 12:59 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
  
    David
key_ids are used when you need to identify which key to use of all the keys
you might have. If you are doing discovery of document that is bound to the
identifier of the signer, this is useful. Since OAuth 1.0 did not have
discovery and required an out of band key management process, key_ids have
little value.
To answer your question, key_ids dont' make sense if the keys are being
managed how you describe them. I would suggest that key_ids are not included
if public keys are managed independent from how Dirk had described them be
discovered.
I don't think key_ids make sense for shared secrets as they inherently have
an out of band process for sharing them.
If you would like to learn more about cryptography, I have found Bruce
Schneier's book Applied Cryptography to be pretty educational. Here is a
link to the Kindle version:
http://www.amazon.com/Applied-Cryptography-Protocols-Algorithms-ebook/dp/B000SEHPK6/ref=kinw_dp_ke?ie=UTF8&m=AG56TWVU5XWC2&qid=1277236054&sr=8-1
-- Dick

On Tue, Jun 22, 2010 at 12:20 PM, David Recordon <recordond@gmail.com>
wrote:
    
    All of the OAuth 1.0 implementations which I'm aware of either have
the server provide a shared secret to the client or the client upload
their public key to the server.

In the case of the server providing a shared secret to the client,
what would the value of key_id be?

In the case of a client uploading their public key to the server, what
would the value of key_id be?

Thanks,
--David


On Tue, Jun 22, 2010 at 12:14 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
      
    I could imagine an architecture striving to be efficient, scalable,
distributed and secure where there are hundreds of servers each with a
unique private key baked into each server. All the public keys would be
in
one file.
Having a key id would help debugging as well as the signer is clearly
indicating which key should be used. If the signing fails, it could be
the
key, could be signature calculation, could be ...

The downside of having a key_id seems heavily outweighed by the
advantages
to me.
On Tue, Jun 22, 2010 at 10:30 AM, Anthony Nadalin
<tonynad@microsoft.com>
wrote:
        
              
    If a server needs to verify, it can literally iterate over all of the
keys associated with the client until it finds the right one.
            
    Depends on how the server stored the keys, this can be a very expensive
operation w/o a key_id to match/index on

-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
Of
Brian Eaton
Sent: Tuesday, June 22, 2010 9:43 AM
To: Dick Hardt; Hannes.Tschofenig@gmx.net
Cc: OAuth WG
Subject: Re: [OAUTH-WG] proposal for signatures

On Tue, Jun 22, 2010 at 7:17 AM, Dick Hardt <dick.hardt@gmail.com>
wrote:
          
    Thanks for writing this. A few questions...

Do we need both `issuer` and `key_id`? Shouldn't we use `client_id`
instead at least for OAuth?
              
    it is the ID of the key, not the client -- used to rollover keys
            
    I don't think key id is necessary, but adding Hannes since he called me
crazy for saying that at IIW. =)

The average client is going to have very few keys.  Probably just 1.
3 at the outside.

If a server needs to verify, it can literally iterate over all of the
keys
associated with the client until it finds the right one.

There is some precedent for this approach:
http://support.microsoft.com/kb/906305/en-us.

Cheers,
Brian
_______________________________________________
OAuth mailing 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
    --------------020207090007040204080403-- From eran@hueniverse.com Tue Jun 22 15:09:18 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14D3728C125 for ; Tue, 22 Jun 2010 15:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.185 X-Spam-Level: X-Spam-Status: No, score=-2.185 tagged_above=-999 required=5 tests=[AWL=0.414, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hotKIjbMjtk3 for ; Tue, 22 Jun 2010 15:09:17 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id E27CA28C124 for ; Tue, 22 Jun 2010 15:09:16 -0700 (PDT) Received: (qmail 12355 invoked from network); 22 Jun 2010 22:09:23 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 22 Jun 2010 22:09:22 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 22 Jun 2010 15:09:21 -0700 From: Eran Hammer-Lahav To: David Recordon Date: Tue, 22 Jun 2010 15:09:18 -0700 Thread-Topic: [OAUTH-WG] Last call for feedback on -08 Thread-Index: AcsSTA+JAKDzslSfTlWD++1BCY22OgAC2o8g Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EC84199@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EC83F35@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3EC84124@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 \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Last call for feedback on -08 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 22:09:18 -0000 It was proposed as part of the device or username and password flow IIRC. G= oogle has something like that when captcha breaks. EHL > -----Original Message----- > From: David Recordon [mailto:recordond@gmail.com] > Sent: Tuesday, June 22, 2010 1:47 PM > To: Eran Hammer-Lahav > Cc: Marius Scurtescu; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Last call for feedback on -08 >=20 > If we have both error_code and error_description, why is an error_uri > needed? (I'm not finding anything when I search the list for > 'error_uri'.) >=20 >=20 > On Tue, Jun 22, 2010 at 1:05 PM, Eran Hammer-Lahav > wrote: > > There was also a suggestion by Brian to add an error_uri for additional > information. > > > > I'm happy to include all three. > > > > EHL > > > >> -----Original Message----- > >> From: Marius Scurtescu [mailto:mscurtescu@google.com] > >> Sent: Tuesday, June 22, 2010 1:00 PM > >> To: Eran Hammer-Lahav > >> Cc: OAuth WG (oauth@ietf.org) > >> Subject: Re: [OAUTH-WG] Last call for feedback on -08 > >> > >> There was a suggestion to expand the 'error' parameter to two > >> different > >> parameters: > >> - error_code - well defined list of error codes > >> - error_description - authz server specific free form error > >> description (for logging and troubleshooting) > >> > >> Not sure if you considered this. > >> > >> Marius > >> > >> > >> > >> On Mon, Jun 21, 2010 at 7:27 PM, Eran Hammer-Lahav > >> wrote: > >> > I am working on -09 which I hope will be the last major revision of > >> > the specification. If you were planning on submitting any feedback > >> > on draft -08 or the simplification proposal from David and me, > >> > please do so by tomorrow to be included in the next draft. > >> > > >> > > >> > > >> > 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 Tue Jun 22 15:11:47 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA79028C11A for ; Tue, 22 Jun 2010 15:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.19 X-Spam-Level: X-Spam-Status: No, score=-2.19 tagged_above=-999 required=5 tests=[AWL=0.408, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Koz2qODYboL for ; Tue, 22 Jun 2010 15:11:41 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id D095E3A67D3 for ; Tue, 22 Jun 2010 15:11:40 -0700 (PDT) Received: (qmail 15589 invoked from network); 22 Jun 2010 22:11:48 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 22 Jun 2010 22:11:48 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 22 Jun 2010 15:11:46 -0700 From: Eran Hammer-Lahav To: Dick Hardt , Brian Eaton Date: Tue, 22 Jun 2010 15:11:43 -0700 Thread-Topic: [OAUTH-WG] Draft -07 (major rewrite) Thread-Index: AcsSSX861TPRy4K0R7SqgbKQ3cWLBgADlY1g Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EC8419C@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EAF76BC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3EBB66AC@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_90C41DD21FB7C64BB94121FBBC2E72343B3EC8419CP3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Draft -07 (major rewrite) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 22:11:47 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EC8419CP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable You are a bit behind. -08 added it back as grant_type which works better wi= th the current explanation. EHL From: Dick Hardt [mailto:dick.hardt@gmail.com] Sent: Tuesday, June 22, 2010 1:29 PM To: Brian Eaton Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Draft -07 (major rewrite) Per an earlier comment, "type" might not be the best name for the parameter= . Perhaps "method" might work and adds a clear extension point for other ty= pes of calls? On Tue, Jun 22, 2010 at 1:22 PM, Dick Hardt > wrote: One of the modifications I concluded to do to WRAP was to add in the type p= arameter. I was happy to see if in David's draft. Even though redundant in some ways, it make it very clear to both the clien= t and server what is intended. +1 for putting it back in. On Mon, Jun 14, 2010 at 11:23 AM, Brian Eaton > wrote: On Mon, Jun 14, 2010 at 9:18 AM, Eran Hammer-Lahav > wrote: > Adding a verification code to the user-agent flow was suggested on this l= ist > and received nothing but support. It was suggested as a solution to a > Twitter use case. Once that is added in, the two flows only differ in how > the response is delivered and the presence of an access token in the > response (which currently is a MUST NOT for web-server but I don't know i= f > this restriction is need). Yeah, this matters. If you return an access token on the web-server flow, several things break: - you can no longer rely on the client secret to authenticate the callback = URL. - you lose all hope of getting to LOA 2 with this protocol, because the access token is visible to the client. - you lose the clarity of how the web server flow is supposed to work. Bike-shed painting: The use-cases for web server and user-agent flow are also different. I'd prefer to have the spec call out different profiles for different use-cases, because it makes it much easier to figure out what a given application should be doing. During the WRAP work I argued that we didn't need a type parameter, and after looking at WRAP implementations I've changed my mind. Please leave it in. Cheers, Brian _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EC8419CP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    You are a= bit behind. -08 added it back as grant_type which works better with the cu= rrent explanation.

    &n= bsp;

    EHL

    <= p class=3DMsoNormal> 

    From: Dick Hardt [mailto:dick.hardt@gmail.com]
    S= ent: Tuesday, June 22, 2010 1:29 PM
    To: Brian Eaton
    Cc:= Eran Hammer-Lahav; OAuth WG (oauth@ietf.org)
    Subject: Re: [O= AUTH-WG] Draft -07 (major rewrite)

     

    Per an earlier comment, "type" might not be the best = name for the parameter. Perhaps "method" might work and adds a cl= ear extension point for other types of calls?

    On Tue, Jun 22, 2010 at 1:22 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

    One of the modifications I concluded to do to WRAP wa= s to add in the type parameter. I was happy to see if in David's draft.

     

    Even though redundant in some ways, it make it very clear to= both the client and server what is intended. 

     

    +1 for putting it back in.

     

    On Mon, Jun 14, 2010 at 11:23 AM, Brian Eaton <beaton@google.com> wrote:<= /p>

    On Mon, Jun 14,= 2010 at 9:18 AM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
    > Adding a v= erification code to the user-agent flow was suggested on this list
    > = and received nothing but support. It was suggested as a solution to a
    &g= t; Twitter use case. Once that is added in, the two flows only differ in ho= w
    > the response is delivered and the presence of an access token in = the
    > response (which currently is a MUST NOT for web-server but I do= n’t know if
    > this restriction is need).

    Yeah, this matters.  If you return an access token = on the web-server
    flow, several things break:
    - you can no longer rel= y on the client secret to authenticate the callback URL.
    - you lose all = hope of getting to LOA 2 with this protocol, because
    the access token is= visible to the client.
    - you lose the clarity of how the web server flo= w is supposed to work.

    Bike-shed painting:

    The use-cases for = web server and user-agent flow are also different.
    I'd prefer to have th= e spec call out different profiles for different
    use-cases, because it m= akes it much easier to figure out what a given
    application should be doi= ng.

    During the WRAP work I argued that we didn't need a type paramet= er,
    and after looking at WRAP implementations I've changed my mind.
    P= lease leave it in.

    Cheers,
    Brian

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

     

     <= /o:p>

    = --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EC8419CP3PW5EX1MB01E_-- From eran@hueniverse.com Tue Jun 22 15:13:58 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 833153A6A1E for ; Tue, 22 Jun 2010 15:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.195 X-Spam-Level: X-Spam-Status: No, score=-2.195 tagged_above=-999 required=5 tests=[AWL=0.404, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T51qY2p-frsH for ; Tue, 22 Jun 2010 15:13:57 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 95BB73A67D3 for ; Tue, 22 Jun 2010 15:13:57 -0700 (PDT) Received: (qmail 18258 invoked from network); 22 Jun 2010 22:14:05 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 22 Jun 2010 22:14:05 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Tue, 22 Jun 2010 15:14:05 -0700 From: Eran Hammer-Lahav To: Marius Scurtescu Date: Tue, 22 Jun 2010 15:14:03 -0700 Thread-Topic: native app support (was: Next draft) Thread-Index: AcsSReKSM0WADO/SQ+KSe405NYNINQAEi6KA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EC8419E@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 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] native app support (was: Next draft) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 22:13:58 -0000 In OAuth 1.0a, we needed it for the patch. I don't think this needs to be i= n the spec because it doesn't help interop. If the server supports such a s= cheme, it should document it. It also falls under "previously established r= edirection URI" which happens to point at the server. EHL > -----Original Message----- > From: Marius Scurtescu [mailto:mscurtescu@google.com] > Sent: Tuesday, June 22, 2010 1:02 PM > To: Eran Hammer-Lahav > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: native app support (was: Next draft) >=20 > On Tue, Jun 8, 2010 at 10:46 AM, Marius Scurtescu > wrote: > > In order to properly support native applications I suggest the > > following changes: > > [...] > > 2. optional redirect_uri (default result page) > > > > Some native apps do not have a redirect_uri, as a result two things are > needed: > > > > 2.1 Either make redirect_uri optional or define a standard value that > > signals that the client does not have such a page. > > > > 2.2 The authz server must supply a default result page, if there is no > > redirect_uri. Also, this page should put the verification code and the > > client state (code and state) in the page title in a standard way such > > that the native app can extract them from the window title. WRAP > > defined how the title should be formed. >=20 > Should this also go to an extension? It is not introducing any new parame= ters, > not sure if it belongs there. OAuth 1 at least defined the "oob" special = value. >=20 > Marius From mscurtescu@google.com Tue Jun 22 15:35:19 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 857493A6A07 for ; Tue, 22 Jun 2010 15:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.463 X-Spam-Level: X-Spam-Status: No, score=-101.463 tagged_above=-999 required=5 tests=[AWL=0.514, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7eAKsHNQyoOZ for ; Tue, 22 Jun 2010 15:35:17 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id E370D3A68A0 for ; Tue, 22 Jun 2010 15:35:14 -0700 (PDT) Received: from wpaz29.hot.corp.google.com (wpaz29.hot.corp.google.com [172.24.198.93]) by smtp-out.google.com with ESMTP id o5MMZKqG005635 for ; Tue, 22 Jun 2010 15:35:21 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1277246121; bh=SQYKYW79L2v9ZGOhQw8JJOTqllw=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=MRMijJFethiIglzb8ap4XV5RqdIryejmeoZZilwbxyC6J7McTri//G8jTxFeMCFOC 3TD8fq9owQO+syUkUkkyw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding:x-system-of-record; b=ERuoM+HRO8ms/AW0BtcyvwEqCmwZ4IIyf99iuHgvb/A0N0QQ1SC9FDMpbTvsXP/7W JE6dGIcWK5/6mZzs5pAjg== Received: from ywh16 (ywh16.prod.google.com [10.192.8.16]) by wpaz29.hot.corp.google.com with ESMTP id o5MMZJCn018087 for ; Tue, 22 Jun 2010 15:35:19 -0700 Received: by ywh16 with SMTP id 16so4020667ywh.21 for ; Tue, 22 Jun 2010 15:35:19 -0700 (PDT) Received: by 10.101.134.6 with SMTP id l6mr5783386ann.50.1277246119239; Tue, 22 Jun 2010 15:35:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.132.22 with HTTP; Tue, 22 Jun 2010 15:34:59 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EC8419E@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EC8419E@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu Date: Tue, 22 Jun 2010 15:34:59 -0700 Message-ID: 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 \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] native app support (was: Next draft) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 22:35:19 -0000 On Tue, Jun 22, 2010 at 3:14 PM, Eran Hammer-Lahav wr= ote: > In OAuth 1.0a, we needed it for the patch. I don't think this needs to be= in the spec because it doesn't help interop. If the server supports such a= scheme, it should document it. It also falls under "previously established= redirection URI" which happens to point at the server. OK, that makes sense. What about: > Also, this page should put the verification code and the > client state (code and state) in the page title in a standard way such > that the native app can extract them from the window title. WRAP > defined how the title should be formed. Extension? Marius > > EHL > >> -----Original Message----- >> From: Marius Scurtescu [mailto:mscurtescu@google.com] >> Sent: Tuesday, June 22, 2010 1:02 PM >> To: Eran Hammer-Lahav >> Cc: OAuth WG (oauth@ietf.org) >> Subject: Re: native app support (was: Next draft) >> >> On Tue, Jun 8, 2010 at 10:46 AM, Marius Scurtescu >> wrote: >> > In order to properly support native applications I suggest the >> > following changes: >> > [...] >> > 2. optional redirect_uri (default result page) >> > >> > Some native apps do not have a redirect_uri, as a result two things ar= e >> needed: >> > >> > 2.1 Either make redirect_uri optional or define a standard value that >> > signals that the client does not have such a page. >> > >> > 2.2 The authz server must supply a default result page, if there is no >> > redirect_uri. Also, this page should put the verification code and the >> > client state (code and state) in the page title in a standard way such >> > that the native app can extract them from the window title. WRAP >> > defined how the title should be formed. >> >> Should this also go to an extension? It is not introducing any new param= eters, >> not sure if it belongs there. OAuth 1 at least defined the "oob" special= value. >> >> Marius > From eran@hueniverse.com Tue Jun 22 16:07:29 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0EBE3A682B for ; Tue, 22 Jun 2010 16:07:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[AWL=0.399, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id agsReBNTNJD3 for ; Tue, 22 Jun 2010 16:07:29 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 85B653A6879 for ; Tue, 22 Jun 2010 16:07:28 -0700 (PDT) Received: (qmail 16518 invoked from network); 22 Jun 2010 23:07:30 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 22 Jun 2010 23:07:30 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 22 Jun 2010 16:07:27 -0700 From: Eran Hammer-Lahav To: Marius Scurtescu Date: Tue, 22 Jun 2010 16:07:24 -0700 Thread-Topic: native app support (was: Next draft) Thread-Index: AcsSWzQzAAmgZou7Ski3hmtuekQ08QABFx9w Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EC841C2@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EC8419E@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 \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] native app support (was: Next draft) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 23:07:30 -0000 > -----Original Message----- > From: Marius Scurtescu [mailto:mscurtescu@google.com] > Sent: Tuesday, June 22, 2010 3:35 PM > To: Eran Hammer-Lahav > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: native app support (was: Next draft) >=20 > On Tue, Jun 22, 2010 at 3:14 PM, Eran Hammer-Lahav > wrote: > > In OAuth 1.0a, we needed it for the patch. I don't think this needs to = be in > the spec because it doesn't help interop. If the server supports such a > scheme, it should document it. It also falls under "previously establishe= d > redirection URI" which happens to point at the server. >=20 > OK, that makes sense. >=20 > What about: > > Also, this page should put the verification code and the client state > > (code and state) in the page title in a standard way such that the > > native app can extract them from the window title. WRAP defined how > > the title should be formed. >=20 > Extension? I don't think this needs a spec. Just something provided by the server. Doe= s the client need any special handling? It can always just use a static web= page to do this, no? EHL >=20 > Marius >=20 > > > > EHL > > > >> -----Original Message----- > >> From: Marius Scurtescu [mailto:mscurtescu@google.com] > >> Sent: Tuesday, June 22, 2010 1:02 PM > >> To: Eran Hammer-Lahav > >> Cc: OAuth WG (oauth@ietf.org) > >> Subject: Re: native app support (was: Next draft) > >> > >> On Tue, Jun 8, 2010 at 10:46 AM, Marius Scurtescu > >> wrote: > >> > In order to properly support native applications I suggest the > >> > following changes: > >> > [...] > >> > 2. optional redirect_uri (default result page) > >> > > >> > Some native apps do not have a redirect_uri, as a result two things > >> > are > >> needed: > >> > > >> > 2.1 Either make redirect_uri optional or define a standard value > >> > that signals that the client does not have such a page. > >> > > >> > 2.2 The authz server must supply a default result page, if there is > >> > no redirect_uri. Also, this page should put the verification code > >> > and the client state (code and state) in the page title in a > >> > standard way such that the native app can extract them from the > >> > window title. WRAP defined how the title should be formed. > >> > >> Should this also go to an extension? It is not introducing any new > >> parameters, not sure if it belongs there. OAuth 1 at least defined the > "oob" special value. > >> > >> Marius > > From mscurtescu@google.com Tue Jun 22 16:17:12 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 981E33A68DA for ; Tue, 22 Jun 2010 16:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.486 X-Spam-Level: X-Spam-Status: No, score=-101.486 tagged_above=-999 required=5 tests=[AWL=0.491, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MnXr+0YuXvLk for ; Tue, 22 Jun 2010 16:17:11 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 8BB7F3A67AC for ; Tue, 22 Jun 2010 16:17:11 -0700 (PDT) Received: from hpaq2.eem.corp.google.com (hpaq2.eem.corp.google.com [172.25.149.2]) by smtp-out.google.com with ESMTP id o5MNHHRw023319 for ; Tue, 22 Jun 2010 16:17:17 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1277248637; bh=5zxfI8xwbmiu3XP6hJk9QVWcBmA=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=gdg0nn0Qm4zZ7SjYga06Qxt4+TtDAwLLg6CPVtNHmnih6+So8aONtAuYo8Mt+3NqI 9Aafch0Ozd0AT40xf+zKA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=WaOpVLSbu8Le2OU/vJxiyN33A1EIzl3FFWPjGmLneSdqlROrti18b2moID4Sil1NU mi9AN7L+xx+2Hjx2YGLoA== Received: from ywh10 (ywh10.prod.google.com [10.192.8.10]) by hpaq2.eem.corp.google.com with ESMTP id o5MNFsYT029909 for ; Tue, 22 Jun 2010 16:17:16 -0700 Received: by ywh10 with SMTP id 10so3518055ywh.18 for ; Tue, 22 Jun 2010 16:17:16 -0700 (PDT) Received: by 10.101.149.28 with SMTP id b28mr5865230ano.228.1277248636208; Tue, 22 Jun 2010 16:17:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.132.22 with HTTP; Tue, 22 Jun 2010 16:16:56 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EC841C2@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EC8419E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3EC841C2@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu Date: Tue, 22 Jun 2010 16:16:56 -0700 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] native app support (was: Next draft) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 23:17:12 -0000 On Tue, Jun 22, 2010 at 4:07 PM, Eran Hammer-Lahav wrote: > >> -----Original Message----- >> From: Marius Scurtescu [mailto:mscurtescu@google.com] >> Sent: Tuesday, June 22, 2010 3:35 PM >> To: Eran Hammer-Lahav >> Cc: OAuth WG (oauth@ietf.org) >> Subject: Re: native app support (was: Next draft) >> >> On Tue, Jun 22, 2010 at 3:14 PM, Eran Hammer-Lahav >> wrote: >> > In OAuth 1.0a, we needed it for the patch. I don't think this needs to be in >> the spec because it doesn't help interop. If the server supports such a >> scheme, it should document it. It also falls under "previously established >> redirection URI" which happens to point at the server. >> >> OK, that makes sense. >> >> What about: >> > Also, this page should put the verification code and the client state >> > (code and state) in the page title in a standard way such that the >> > native app can extract them from the window title. WRAP defined how >> > the title should be formed. >> >> Extension? > > I don't think this needs a spec. Just something provided by the server. Does the client need any special handling? It can always just use a static web page to do this, no? A spec would help so all servers provide code and state in a consistent format. Client libraries can then provide methods to parse this. Also, client apps connecting to multiple servers can expect some consistency. Marius > > EHL > >> >> Marius >> >> > >> > EHL >> > >> >> -----Original Message----- >> >> From: Marius Scurtescu [mailto:mscurtescu@google.com] >> >> Sent: Tuesday, June 22, 2010 1:02 PM >> >> To: Eran Hammer-Lahav >> >> Cc: OAuth WG (oauth@ietf.org) >> >> Subject: Re: native app support (was: Next draft) >> >> >> >> On Tue, Jun 8, 2010 at 10:46 AM, Marius Scurtescu >> >> wrote: >> >> > In order to properly support native applications I suggest the >> >> > following changes: >> >> > [...] >> >> > 2. optional redirect_uri (default result page) >> >> > >> >> > Some native apps do not have a redirect_uri, as a result two things >> >> > are >> >> needed: >> >> > >> >> > 2.1 Either make redirect_uri optional or define a standard value >> >> > that signals that the client does not have such a page. >> >> > >> >> > 2.2 The authz server must supply a default result page, if there is >> >> > no redirect_uri. Also, this page should put the verification code >> >> > and the client state (code and state) in the page title in a >> >> > standard way such that the native app can extract them from the >> >> > window title. WRAP defined how the title should be formed. >> >> >> >> Should this also go to an extension? It is not introducing any new >> >> parameters, not sure if it belongs there. OAuth 1 at least defined the >> "oob" special value. >> >> >> >> Marius >> > > From dick.hardt@gmail.com Tue Jun 22 16:17:26 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A60C03A6A2D for ; Tue, 22 Jun 2010 16:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.421 X-Spam-Level: X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XM0pT-AwKrTM for ; Tue, 22 Jun 2010 16:17:25 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 146C53A68DA for ; Tue, 22 Jun 2010 16:17:25 -0700 (PDT) Received: by pwi6 with SMTP id 6so2114494pwi.31 for ; Tue, 22 Jun 2010 16:17:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:message-id:references:to :x-mailer; bh=YtSzAF4kbC38G1R1sDXi7wF6W7yzV59w8BmhAOqDK5k=; b=pxCPh8elOwWZ23kccjc0Yf/+sw/LqliFNm6LT+dTWqzTSn78eBR5rnbv8Cpe2t0F/B PM820NuhsH7+DB7eFYBHu4x4A/Gd+zE9BwbAFEAT0hru8U2PbidQJhhLgyNf5S28rZ7c rvw4NqOCmYuMmJ3M78COm1cLiRCuH+neZ3ozM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; b=RoNjE/8/TRewOzl7zw8vzcnPc4c0uAq83J2Btf8N1cxMd1Uo9W5xOLkIY6ApS15SRI okAg76uU+Z93vUUgrZEVHs9f6a1Oe7mn1iPzsdn0D6ECBhwAVTYllzp4a8mJffFLj6qq 5cfqKRMtfTUogmQtvRMFMyHj9pxxGjo+YYXfM= Received: by 10.142.201.12 with SMTP id y12mr6092901wff.174.1277248649705; Tue, 22 Jun 2010 16:17:29 -0700 (PDT) Received: from [192.168.1.5] (c-24-130-32-55.hsd1.ca.comcast.net [24.130.32.55]) by mx.google.com with ESMTPS id u34sm3336283wfh.8.2010.06.22.16.17.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 22 Jun 2010 16:17:29 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-17-441219776 From: Dick Hardt In-Reply-To: <4C212CB5.6070000@aol.com> Date: Tue, 22 Jun 2010 16:17:26 -0700 Message-Id: <1441E245-4661-4A31-92A4-909A7C0ADD86@gmail.com> References: <4C5BCAC6-713F-4C42-8696-2931D1AB3199@gmail.com> <4C212CB5.6070000@aol.com> To: George Fletcher X-Mailer: Apple Mail (2.1081) Cc: "Hannes.Tschofenig@gmx.net" , OAuth WG Subject: Re: [OAUTH-WG] proposal for signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 23:17:26 -0000 --Apple-Mail-17-441219776 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 George: David's example is that keys are managed out of band. When you = rotate the key, you tell the other side the new key, then use it.=20 David: I would hope that we would be able to move past the horrible key = management that we have today to an architecture using published public = keys so that client and server don't need a different out of band = identity system to support this one. :) -- Dick On 2010-06-22, at 2:35 PM, George Fletcher wrote: > The only additional value might be during "key rotation". If key_id is = removed, then both (or n) have to be checked. Probably not a huge issue. >=20 > Thanks, > George >=20 > On 6/22/10 4:45 PM, David Recordon wrote: >>=20 >> Hey Dick, in answering my questions you made my point. If keys are >> managed out of band =96 as is done in OAuth 1.0 and what was done in = the >> OAuth 2.0 Core spec until signatures were extracted =96 then having a >> key id is not needed. I certainly understand what they're used for, >> but don't find them relevant as part of the OAuth conversation today. >>=20 >> And yes, Applied Cryptography is worth reading. :) >>=20 >> --David >>=20 >>=20 >> On Tue, Jun 22, 2010 at 12:59 PM, Dick Hardt = wrote: >> =20 >>> David >>> key_ids are used when you need to identify which key to use of all = the keys >>> you might have. If you are doing discovery of document that is bound = to the >>> identifier of the signer, this is useful. Since OAuth 1.0 did not = have >>> discovery and required an out of band key management process, = key_ids have >>> little value. >>> To answer your question, key_ids dont' make sense if the keys are = being >>> managed how you describe them. I would suggest that key_ids are not = included >>> if public keys are managed independent from how Dirk had described = them be >>> discovered. >>> I don't think key_ids make sense for shared secrets as they = inherently have >>> an out of band process for sharing them. >>> If you would like to learn more about cryptography, I have found = Bruce >>> Schneier's book Applied Cryptography to be pretty educational. Here = is a >>> link to the Kindle version: >>> = http://www.amazon.com/Applied-Cryptography-Protocols-Algorithms-ebook/dp/B= 000SEHPK6/ref=3Dkinw_dp_ke?ie=3DUTF8&m=3DAG56TWVU5XWC2&qid=3D1277236054&sr= =3D8-1 >>> -- Dick >>>=20 >>> On Tue, Jun 22, 2010 at 12:20 PM, David Recordon = >>> wrote: >>> =20 >>>> All of the OAuth 1.0 implementations which I'm aware of either have >>>> the server provide a shared secret to the client or the client = upload >>>> their public key to the server. >>>>=20 >>>> In the case of the server providing a shared secret to the client, >>>> what would the value of key_id be? >>>>=20 >>>> In the case of a client uploading their public key to the server, = what >>>> would the value of key_id be? >>>>=20 >>>> Thanks, >>>> --David >>>>=20 >>>>=20 >>>> On Tue, Jun 22, 2010 at 12:14 PM, Dick Hardt = wrote: >>>> =20 >>>>> I could imagine an architecture striving to be efficient, = scalable, >>>>> distributed and secure where there are hundreds of servers each = with a >>>>> unique private key baked into each server. All the public keys = would be >>>>> in >>>>> one file. >>>>> Having a key id would help debugging as well as the signer is = clearly >>>>> indicating which key should be used. If the signing fails, it = could be >>>>> the >>>>> key, could be signature calculation, could be ... >>>>>=20 >>>>> The downside of having a key_id seems heavily outweighed by the >>>>> advantages >>>>> to me. >>>>> On Tue, Jun 22, 2010 at 10:30 AM, Anthony Nadalin >>>>> >>>>> wrote: >>>>> =20 >>>>>> =20 >>>>>>> If a server needs to verify, it can literally iterate over all = of the >>>>>>> keys associated with the client until it finds the right one. >>>>>>> =20 >>>>>> Depends on how the server stored the keys, this can be a very = expensive >>>>>> operation w/o a key_id to match/index on >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf >>>>>> Of >>>>>> Brian Eaton >>>>>> Sent: Tuesday, June 22, 2010 9:43 AM >>>>>> To: Dick Hardt; Hannes.Tschofenig@gmx.net >>>>>> Cc: OAuth WG >>>>>> Subject: Re: [OAUTH-WG] proposal for signatures >>>>>>=20 >>>>>> On Tue, Jun 22, 2010 at 7:17 AM, Dick Hardt = >>>>>> wrote: >>>>>> =20 >>>>>>>> Thanks for writing this. A few questions... >>>>>>>>=20 >>>>>>>> Do we need both `issuer` and `key_id`? Shouldn't we use = `client_id` >>>>>>>> instead at least for OAuth? >>>>>>>> =20 >>>>>>> it is the ID of the key, not the client -- used to rollover keys >>>>>>> =20 >>>>>> I don't think key id is necessary, but adding Hannes since he = called me >>>>>> crazy for saying that at IIW. =3D) >>>>>>=20 >>>>>> The average client is going to have very few keys. Probably just = 1. >>>>>> 3 at the outside. >>>>>>=20 >>>>>> If a server needs to verify, it can literally iterate over all of = the >>>>>> keys >>>>>> associated with the client until it finds the right one. >>>>>>=20 >>>>>> There is some precedent for this approach: >>>>>> http://support.microsoft.com/kb/906305/en-us. >>>>>>=20 >>>>>> Cheers, >>>>>> Brian >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>=20 >>>>>> =20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>>=20 >>>>> =20 >>>=20 >>> =20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> =20 --Apple-Mail-17-441219776 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
    The only additional value might be during "key rotation". If key_id is removed, then both (or n) have to be checked. Probably not a huge issue.

    Thanks,
    George

    On 6/22/10 4:45 PM, David Recordon wrote: 
    Hey Dick, in answering my questions you made my point. =
If keys are
managed out of band =96 as is done in OAuth 1.0 and what was done =
in the
OAuth 2.0 Core spec until signatures were extracted =96 then having =
a
key id is not needed. I certainly understand what they're used for,
but don't find them relevant as part of the OAuth conversation today.

And yes, Applied Cryptography is worth reading. :)

--David


On Tue, Jun 22, 2010 at 12:59 PM, Dick Hardt <dick.hardt@gmail.com> =
wrote:
  
    David
key_ids are used when you need to identify which key to use of all the =
keys
you might have. If you are doing discovery of document that is bound to =
the
identifier of the signer, this is useful. Since OAuth 1.0 did not have
discovery and required an out of band key management process, key_ids =
have
little value.
To answer your question, key_ids dont' make sense if the keys are being
managed how you describe them. I would suggest that key_ids are not =
included
if public keys are managed independent from how Dirk had =
described them be
discovered.
I don't think key_ids make sense for shared secrets as they inherently =
have
an out of band process for sharing them.
If you would like to learn more about cryptography, I have found Bruce
Schneier's book Applied Cryptography to be pretty educational. Here is a
link to the Kindle version:
http://www.amazon.com/Applied-Cryptography-Pro=
tocols-Algorithms-ebook/dp/B000SEHPK6/ref=3Dkinw_dp_ke?ie=3DUTF8&m=3DA=
G56TWVU5XWC2&qid=3D1277236054&sr=3D8-1
-- Dick

On Tue, Jun 22, 2010 at 12:20 PM, David Recordon <recordond@gmail.com>
wrote:
    
    All of the OAuth 1.0 implementations which I'm =
aware of either have
the server provide a shared secret to the client or the client upload
their public key to the server.

In the case of the server providing a shared secret to the client,
what would the value of key_id be?

In the case of a client uploading their public key to the server, what
would the value of key_id be?

Thanks,
--David


On Tue, Jun 22, 2010 at 12:14 PM, Dick Hardt <dick.hardt@gmail.com> =
wrote:
      
    I could imagine an architecture striving to be =
efficient, scalable,
distributed and secure where there are hundreds of servers each with a
unique private key baked into each server. All the public keys would be
in
one file.
Having a key id would help debugging as well as the signer is clearly
indicating which key should be used. If the signing fails, it could be
the
key, could be signature calculation, could be ...

The downside of having a key_id seems heavily outweighed by =
the
advantages
to me.
On Tue, Jun 22, 2010 at 10:30 AM, Anthony Nadalin
<tonynad@microsoft.com>
wrote:
        
              
    If a server needs to verify, it can literally =
iterate over all of the
keys associated with the client until it finds the right one.
            
    Depends on how the server stored the keys, this =
can be a very expensive
operation w/o a key_id to match/index on

-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] =
On Behalf
Of
Brian Eaton
Sent: Tuesday, June 22, 2010 9:43 AM
To: Dick Hardt; Hannes.Tschofenig@gmx.net
Cc: OAuth WG
Subject: Re: [OAUTH-WG] proposal for signatures

On Tue, Jun 22, 2010 at 7:17 AM, Dick Hardt <dick.hardt@gmail.com>
wrote:
          
    Thanks for writing this. A few questions...

Do we need both `issuer` and `key_id`? Shouldn't we use `client_id`
instead at least for OAuth?
              
    it is the ID of the key, not the client -- =
used to rollover keys
            
    I don't think key id is necessary, but adding =
Hannes since he called me
crazy for saying that at IIW. =3D)

The average client is going to have very few keys.  Probably just =
1.
3 at the outside.

If a server needs to verify, it can literally iterate over all of the
keys
associated with the client until it finds the right one.

There is some precedent for this approach:
http://support.micro=
soft.com/kb/906305/en-us.

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

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


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

    = --Apple-Mail-17-441219776-- From eran@hueniverse.com Tue Jun 22 16:26:12 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A28F3A68D1 for ; Tue, 22 Jun 2010 16:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.205 X-Spam-Level: X-Spam-Status: No, score=-2.205 tagged_above=-999 required=5 tests=[AWL=0.394, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id By4Y+t-EajTK for ; Tue, 22 Jun 2010 16:26:11 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 670693A67AC for ; Tue, 22 Jun 2010 16:26:11 -0700 (PDT) Received: (qmail 26117 invoked from network); 22 Jun 2010 23:26:18 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 22 Jun 2010 23:26:18 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 22 Jun 2010 16:26:12 -0700 From: Eran Hammer-Lahav To: Marius Scurtescu Date: Tue, 22 Jun 2010 16:26:10 -0700 Thread-Topic: native app support (was: Next draft) Thread-Index: AcsSYRIIeo9nrbyPQBGe5oC4U5kV0QAAQv3A Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EC841C8@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EC8419E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3EC841C2@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 \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] native app support (was: Next draft) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 23:26:12 -0000 In that case, I suggest an extension. But I just don't think this needs it.= Why involve the server at all in this? The client should just host a web p= age somewhere with the format it wants or the language for the user. With $10 hosting, every client can host a web page somewhere. EHL > -----Original Message----- > From: Marius Scurtescu [mailto:mscurtescu@google.com] > Sent: Tuesday, June 22, 2010 4:17 PM > To: Eran Hammer-Lahav > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: native app support (was: Next draft) >=20 > On Tue, Jun 22, 2010 at 4:07 PM, Eran Hammer-Lahav > wrote: > > > >> -----Original Message----- > >> From: Marius Scurtescu [mailto:mscurtescu@google.com] > >> Sent: Tuesday, June 22, 2010 3:35 PM > >> To: Eran Hammer-Lahav > >> Cc: OAuth WG (oauth@ietf.org) > >> Subject: Re: native app support (was: Next draft) > >> > >> On Tue, Jun 22, 2010 at 3:14 PM, Eran Hammer-Lahav > >> wrote: > >> > In OAuth 1.0a, we needed it for the patch. I don't think this needs > >> > to be in > >> the spec because it doesn't help interop. If the server supports such > >> a scheme, it should document it. It also falls under "previously > >> established redirection URI" which happens to point at the server. > >> > >> OK, that makes sense. > >> > >> What about: > >> > Also, this page should put the verification code and the client > >> > state (code and state) in the page title in a standard way such > >> > that the native app can extract them from the window title. WRAP > >> > defined how the title should be formed. > >> > >> Extension? > > > > I don't think this needs a spec. Just something provided by the server.= Does > the client need any special handling? It can always just use a static web= page > to do this, no? >=20 > A spec would help so all servers provide code and state in a consistent > format. Client libraries can then provide methods to parse this. Also, cl= ient > apps connecting to multiple servers can expect some consistency. >=20 > Marius >=20 > > > > EHL > > > >> > >> Marius > >> > >> > > >> > EHL > >> > > >> >> -----Original Message----- > >> >> From: Marius Scurtescu [mailto:mscurtescu@google.com] > >> >> Sent: Tuesday, June 22, 2010 1:02 PM > >> >> To: Eran Hammer-Lahav > >> >> Cc: OAuth WG (oauth@ietf.org) > >> >> Subject: Re: native app support (was: Next draft) > >> >> > >> >> On Tue, Jun 8, 2010 at 10:46 AM, Marius Scurtescu > >> >> wrote: > >> >> > In order to properly support native applications I suggest the > >> >> > following changes: > >> >> > [...] > >> >> > 2. optional redirect_uri (default result page) > >> >> > > >> >> > Some native apps do not have a redirect_uri, as a result two > >> >> > things are > >> >> needed: > >> >> > > >> >> > 2.1 Either make redirect_uri optional or define a standard value > >> >> > that signals that the client does not have such a page. > >> >> > > >> >> > 2.2 The authz server must supply a default result page, if there > >> >> > is no redirect_uri. Also, this page should put the verification > >> >> > code and the client state (code and state) in the page title in > >> >> > a standard way such that the native app can extract them from > >> >> > the window title. WRAP defined how the title should be formed. > >> >> > >> >> Should this also go to an extension? It is not introducing any new > >> >> parameters, not sure if it belongs there. OAuth 1 at least defined > >> >> the > >> "oob" special value. > >> >> > >> >> Marius > >> > > > From eran@hueniverse.com Tue Jun 22 16:41:22 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BB2D3A68E1 for ; Tue, 22 Jun 2010 16:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.21 X-Spam-Level: X-Spam-Status: No, score=-2.21 tagged_above=-999 required=5 tests=[AWL=0.389, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ULNJGKR0D5ss for ; Tue, 22 Jun 2010 16:41:20 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 686AB3A6884 for ; Tue, 22 Jun 2010 16:41:20 -0700 (PDT) Received: (qmail 1635 invoked from network); 22 Jun 2010 23:41:27 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 22 Jun 2010 23:41:27 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Tue, 22 Jun 2010 16:41:26 -0700 From: Eran Hammer-Lahav To: Marius Scurtescu Date: Tue, 22 Jun 2010 16:41:25 -0700 Thread-Topic: native app support (was: Next draft) Thread-Index: AcsSYwiIysqd5dshRpC8Y1iCM/8veQAAVhig Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EC841CC@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EC8419E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3EC841C2@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3EC841C8@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 \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] native app support (was: Next draft) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 23:41:22 -0000 Write the spec then. It should be pretty short. EHL > -----Original Message----- > From: Marius Scurtescu [mailto:mscurtescu@google.com] > Sent: Tuesday, June 22, 2010 4:31 PM > To: Eran Hammer-Lahav > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: native app support (was: Next draft) >=20 > On Tue, Jun 22, 2010 at 4:26 PM, Eran Hammer-Lahav > wrote: > > In that case, I suggest an extension. But I just don't think this needs= it. Why > involve the server at all in this? The client should just host a web page > somewhere with the format it wants or the language for the user. > > > > With $10 hosting, every client can host a web page somewhere. >=20 > Hard to tell, you could be right. Keep in mind that this page has to be r= eliable > and secure, $10 will probably not give you that. An authz server can easi= ly > provide all this at almost no cost. >=20 > Marius >=20 > > > > EHL > > > >> -----Original Message----- > >> From: Marius Scurtescu [mailto:mscurtescu@google.com] > >> Sent: Tuesday, June 22, 2010 4:17 PM > >> To: Eran Hammer-Lahav > >> Cc: OAuth WG (oauth@ietf.org) > >> Subject: Re: native app support (was: Next draft) > >> > >> On Tue, Jun 22, 2010 at 4:07 PM, Eran Hammer-Lahav > >> wrote: > >> > > >> >> -----Original Message----- > >> >> From: Marius Scurtescu [mailto:mscurtescu@google.com] > >> >> Sent: Tuesday, June 22, 2010 3:35 PM > >> >> To: Eran Hammer-Lahav > >> >> Cc: OAuth WG (oauth@ietf.org) > >> >> Subject: Re: native app support (was: Next draft) > >> >> > >> >> On Tue, Jun 22, 2010 at 3:14 PM, Eran Hammer-Lahav > >> >> wrote: > >> >> > In OAuth 1.0a, we needed it for the patch. I don't think this > >> >> > needs to be in > >> >> the spec because it doesn't help interop. If the server supports > >> >> such a scheme, it should document it. It also falls under > >> >> "previously established redirection URI" which happens to point at = the > server. > >> >> > >> >> OK, that makes sense. > >> >> > >> >> What about: > >> >> > Also, this page should put the verification code and the client > >> >> > state (code and state) in the page title in a standard way such > >> >> > that the native app can extract them from the window title. WRAP > >> >> > defined how the title should be formed. > >> >> > >> >> Extension? > >> > > >> > I don't think this needs a spec. Just something provided by the > >> > server. Does > >> the client need any special handling? It can always just use a static > >> web page to do this, no? > >> > >> A spec would help so all servers provide code and state in a > >> consistent format. Client libraries can then provide methods to parse > >> this. Also, client apps connecting to multiple servers can expect some > consistency. > >> > >> Marius > >> > >> > > >> > EHL > >> > > >> >> > >> >> Marius > >> >> > >> >> > > >> >> > EHL > >> >> > > >> >> >> -----Original Message----- > >> >> >> From: Marius Scurtescu [mailto:mscurtescu@google.com] > >> >> >> Sent: Tuesday, June 22, 2010 1:02 PM > >> >> >> To: Eran Hammer-Lahav > >> >> >> Cc: OAuth WG (oauth@ietf.org) > >> >> >> Subject: Re: native app support (was: Next draft) > >> >> >> > >> >> >> On Tue, Jun 8, 2010 at 10:46 AM, Marius Scurtescu > >> >> >> wrote: > >> >> >> > In order to properly support native applications I suggest > >> >> >> > the following changes: > >> >> >> > [...] > >> >> >> > 2. optional redirect_uri (default result page) > >> >> >> > > >> >> >> > Some native apps do not have a redirect_uri, as a result two > >> >> >> > things are > >> >> >> needed: > >> >> >> > > >> >> >> > 2.1 Either make redirect_uri optional or define a standard > >> >> >> > value that signals that the client does not have such a page. > >> >> >> > > >> >> >> > 2.2 The authz server must supply a default result page, if > >> >> >> > there is no redirect_uri. Also, this page should put the > >> >> >> > verification code and the client state (code and state) in > >> >> >> > the page title in a standard way such that the native app can > >> >> >> > extract them from the window title. WRAP defined how the title > should be formed. > >> >> >> > >> >> >> Should this also go to an extension? It is not introducing any > >> >> >> new parameters, not sure if it belongs there. OAuth 1 at least > >> >> >> defined the > >> >> "oob" special value. > >> >> >> > >> >> >> Marius > >> >> > > >> > > > From mscurtescu@google.com Tue Jun 22 17:02:48 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E9EF3A68B5 for ; Tue, 22 Jun 2010 17:02:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.507 X-Spam-Level: X-Spam-Status: No, score=-101.507 tagged_above=-999 required=5 tests=[AWL=0.470, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxnvO4tkPgdo for ; Tue, 22 Jun 2010 17:02:47 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 1F9833A68A3 for ; Tue, 22 Jun 2010 17:02:46 -0700 (PDT) Received: from kpbe11.cbf.corp.google.com (kpbe11.cbf.corp.google.com [172.25.105.75]) by smtp-out.google.com with ESMTP id o5MNVDs2004661 for ; Tue, 22 Jun 2010 16:31:14 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1277249474; bh=ctZ5VgCUUVFKljbBTMOdwW65/M4=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=N7imeEF6YEByoNvewmx0CkUsQ5s0GE0KeD1pAboUZrWwKuwUCsrj8X1v/9OPMHZVD s+JcOs8G0eFuXs/GziA2g== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=Tbw1C13vdW+8PHHOi1LJ3ZX60tIwhyk6fKJjy02mvUhQOrd9R+MMBZGS31qJl/fIA PtSwTNHYPrL1moafYgylQ== Received: from gyh4 (gyh4.prod.google.com [10.243.50.196]) by kpbe11.cbf.corp.google.com with ESMTP id o5MNVCxK031137 for ; Tue, 22 Jun 2010 16:31:12 -0700 Received: by gyh4 with SMTP id 4so3424286gyh.3 for ; Tue, 22 Jun 2010 16:31:12 -0700 (PDT) Received: by 10.100.16.4 with SMTP id 4mr5820664anp.2.1277249472196; Tue, 22 Jun 2010 16:31:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.132.22 with HTTP; Tue, 22 Jun 2010 16:30:52 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EC841C8@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EC8419E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3EC841C2@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3EC841C8@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu Date: Tue, 22 Jun 2010 16:30:52 -0700 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] native app support (was: Next draft) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 00:02:48 -0000 On Tue, Jun 22, 2010 at 4:26 PM, Eran Hammer-Lahav wrote: > In that case, I suggest an extension. But I just don't think this needs it. Why involve the server at all in this? The client should just host a web page somewhere with the format it wants or the language for the user. > > With $10 hosting, every client can host a web page somewhere. Hard to tell, you could be right. Keep in mind that this page has to be reliable and secure, $10 will probably not give you that. An authz server can easily provide all this at almost no cost. Marius > > EHL > >> -----Original Message----- >> From: Marius Scurtescu [mailto:mscurtescu@google.com] >> Sent: Tuesday, June 22, 2010 4:17 PM >> To: Eran Hammer-Lahav >> Cc: OAuth WG (oauth@ietf.org) >> Subject: Re: native app support (was: Next draft) >> >> On Tue, Jun 22, 2010 at 4:07 PM, Eran Hammer-Lahav >> wrote: >> > >> >> -----Original Message----- >> >> From: Marius Scurtescu [mailto:mscurtescu@google.com] >> >> Sent: Tuesday, June 22, 2010 3:35 PM >> >> To: Eran Hammer-Lahav >> >> Cc: OAuth WG (oauth@ietf.org) >> >> Subject: Re: native app support (was: Next draft) >> >> >> >> On Tue, Jun 22, 2010 at 3:14 PM, Eran Hammer-Lahav >> >> wrote: >> >> > In OAuth 1.0a, we needed it for the patch. I don't think this needs >> >> > to be in >> >> the spec because it doesn't help interop. If the server supports such >> >> a scheme, it should document it. It also falls under "previously >> >> established redirection URI" which happens to point at the server. >> >> >> >> OK, that makes sense. >> >> >> >> What about: >> >> > Also, this page should put the verification code and the client >> >> > state (code and state) in the page title in a standard way such >> >> > that the native app can extract them from the window title. WRAP >> >> > defined how the title should be formed. >> >> >> >> Extension? >> > >> > I don't think this needs a spec. Just something provided by the server. Does >> the client need any special handling? It can always just use a static web page >> to do this, no? >> >> A spec would help so all servers provide code and state in a consistent >> format. Client libraries can then provide methods to parse this. Also, client >> apps connecting to multiple servers can expect some consistency. >> >> Marius >> >> > >> > EHL >> > >> >> >> >> Marius >> >> >> >> > >> >> > EHL >> >> > >> >> >> -----Original Message----- >> >> >> From: Marius Scurtescu [mailto:mscurtescu@google.com] >> >> >> Sent: Tuesday, June 22, 2010 1:02 PM >> >> >> To: Eran Hammer-Lahav >> >> >> Cc: OAuth WG (oauth@ietf.org) >> >> >> Subject: Re: native app support (was: Next draft) >> >> >> >> >> >> On Tue, Jun 8, 2010 at 10:46 AM, Marius Scurtescu >> >> >> wrote: >> >> >> > In order to properly support native applications I suggest the >> >> >> > following changes: >> >> >> > [...] >> >> >> > 2. optional redirect_uri (default result page) >> >> >> > >> >> >> > Some native apps do not have a redirect_uri, as a result two >> >> >> > things are >> >> >> needed: >> >> >> > >> >> >> > 2.1 Either make redirect_uri optional or define a standard value >> >> >> > that signals that the client does not have such a page. >> >> >> > >> >> >> > 2.2 The authz server must supply a default result page, if there >> >> >> > is no redirect_uri. Also, this page should put the verification >> >> >> > code and the client state (code and state) in the page title in >> >> >> > a standard way such that the native app can extract them from >> >> >> > the window title. WRAP defined how the title should be formed. >> >> >> >> >> >> Should this also go to an extension? It is not introducing any new >> >> >> parameters, not sure if it belongs there. OAuth 1 at least defined >> >> >> the >> >> "oob" special value. >> >> >> >> >> >> Marius >> >> > >> > > From mscurtescu@google.com Tue Jun 22 18:00:37 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ADF63A6852 for ; Tue, 22 Jun 2010 18:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.527 X-Spam-Level: X-Spam-Status: No, score=-101.527 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PsgrzTJTzTZg for ; Tue, 22 Jun 2010 18:00:35 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 7BA583A67EA for ; Tue, 22 Jun 2010 18:00:35 -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 o5N10eg5020431 for ; Tue, 22 Jun 2010 18:00:41 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1277254841; bh=iCmrc+o2hcxKyRxjtq3eNLtDhSw=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=XHDxIuwyaqgpMdgzmwyJNhDv3hyT2y8YPTWB4AwxpZ8w6XnG89j4l8Qbv32+AC5hk Er7UCBbLIIB6mFw1M0yYQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding:x-system-of-record; b=GarQ8muEVpXn1tEQZN+rPzwoy/MfSo9EVFjhbnwZVYTDZzU0J0LPWKU2Yj9zPTfGn cwvlDhWnLcK1gxcr+kdfw== Received: from ywh27 (ywh27.prod.google.com [10.192.8.27]) by kpbe20.cbf.corp.google.com with ESMTP id o5N10U4p011551 for ; Tue, 22 Jun 2010 18:00:39 -0700 Received: by ywh27 with SMTP id 27so3821379ywh.19 for ; Tue, 22 Jun 2010 18:00:39 -0700 (PDT) Received: by 10.100.16.4 with SMTP id 4mr5874401anp.2.1277254839368; Tue, 22 Jun 2010 18:00:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.132.22 with HTTP; Tue, 22 Jun 2010 18:00:19 -0700 (PDT) In-Reply-To: <1277213040.1814.10.camel@localhost.localdomain> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EC83F35@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1277213040.1814.10.camel@localhost.localdomain> From: Marius Scurtescu Date: Tue, 22 Jun 2010 18:00:19 -0700 Message-ID: To: Justin Richer 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] Last call for feedback on -08 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 01:00:37 -0000 On Tue, Jun 22, 2010 at 6:24 AM, Justin Richer wrote: > >> I am working on -09 which I hope will be the last major revision of >> the specification. If you were planning on submitting any feedback on >> draft -08 or the simplification proposal from David and me, please do >> so by tomorrow to be included in the next draft. > > > I am mostly looking for the extension mechanisms to be laid out. There > are four features that I'd like to see covered by OAuth as a whole: > > =A0* Token Revocation > =A0* Redelegation > =A0* Client instance information (update of xoauth_display_name) > =A0* Handling of unregistered and dynamically-registered clients > > Each of these could be handled by an extension and/or guideline doc, and > I'm willing to try my hand at writing some of these out. Any takers for > input into solutions for any of these problems? I can help you with the last two. We should start separate threads to tackle them. Marius > > I'm also interested to see what happens with the signing proposals, > because we still have use cases for the signed-fetch portion of OAuth 1 > (both 2-legged and 3-legged). But I'll freely admit that I am not the > one to write this. :) > > =A0-- Justin > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From James.H.Manger@team.telstra.com Tue Jun 22 18:37:10 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 449E628C122 for ; Tue, 22 Jun 2010 18:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.452 X-Spam-Level: * X-Spam-Status: No, score=1.452 tagged_above=-999 required=5 tests=[AWL=-0.247, BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N0a92JmXtVZu for ; Tue, 22 Jun 2010 18:37:09 -0700 (PDT) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by core3.amsl.com (Postfix) with ESMTP id 3DF2D28C11E for ; Tue, 22 Jun 2010 18:37:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,464,1272808800"; d="scan'208";a="4743457" Received: from unknown (HELO ipccni.tcif.telstra.com.au) ([10.97.216.208]) by ipocni.tcif.telstra.com.au with ESMTP; 23 Jun 2010 11:37:12 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6021"; a="3664173" Received: from wsmsg3703.srv.dir.telstra.com ([172.49.40.171]) by ipccni.tcif.telstra.com.au with ESMTP; 23 Jun 2010 11:37:14 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3703.srv.dir.telstra.com ([172.49.40.171]) with mapi; Wed, 23 Jun 2010 11:37:13 +1000 From: "Manger, James H" To: "OAuth WG (oauth@ietf.org)" Date: Wed, 23 Jun 2010 11:37:09 +1000 Thread-Topic: base64url: web-safe encoding; RFC 4648 Thread-Index: AcsSdJjHCHBhGSWXT+OyMvu37XZylw== Message-ID: <255B9BB34FB7D647A506DC292726F6E112642C69FD@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {E4DE3C00-B88A-4819-A940-AF4D543368E7} x-cr-hashedpuzzle: Bc3k DNRt DgJw EDE7 EUqz Fhg8 JPza JRCn JT+x J0R8 J9sq Kujp Kuyi LAyL LDYo LTk8; 1; bwBhAHUAdABoAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {E4DE3C00-B88A-4819-A940-AF4D543368E7}; agBhAG0AZQBzAC4AaAAuAG0AYQBuAGcAZQByAEAAdABlAGEAbQAuAHQAZQBsAHMAdAByAGEALgBjAG8AbQA=; Wed, 23 Jun 2010 01:37:09 GMT; YgBhAHMAZQA2ADQAdQByAGwAOgAgAHcAZQBiAC0AcwBhAGYAZQAgAGUAbgBjAG8AZABpAG4AZwA7ACAAUgBGAEMAIAA0ADYANAA4AA== acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [OAUTH-WG] base64url: web-safe encoding; RFC 4648 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 01:37:10 -0000 UkZDNDY0OCAiVGhlIEJhc2UxNiwgQmFzZTMyLCBhbmQgQmFzZTY0IERhdGEgRW5jb2RpbmdzIg0K ZGVmaW5lcyB3ZWItc2FmZSBiYXNlNjQgKGFuZCAibm9ybWFsIiBiYXNlNjQpDQo8aHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvcmZjNDY0OCNzZWN0aW9uLTU+Lg0KDQpUaGUgc3BlYyBzdWdnZXN0 cyBjYWxsaW5nIGl0ICJiYXNlNjR1cmwiLg0KDQpUaGUgc3BlYyBleHBsaWNpdGx5IHN0YXRlcyB0 aGF0Og0KICAiaW4gc29tZSBjaXJjdW1zdGFuY2VzLCB0aGUgdXNlIG9mIHBhZGRpbmcgKCI9IikN CiAgIGluIGJhc2UtZW5jb2RlZCBkYXRhIGlzIG5vdCByZXF1aXJlZCBvciB1c2VkIg0KdGhvdWdo IGl0IGFsc28gc2F5cyB0aGF0IGEgc3BlY2lmaWNhdGlvbiB1c2luZyBCYXNlNjQgbmVlZHMNCnRv IGV4cGxpY2l0bHkgc3RhdGUgdGhhdCBwYWRkaW5nIGlzIG9taXR0ZWQgaW4gaXRzIGNpcmN1bXN0 YW5jZXMuDQoNCkl0IG1ha2VzIHNlbnNlIHRvIG9taXQgdGhlIHBhZGRpbmcgd2hlbiB1c2luZyBi YXNlNjR1cmwsDQphcyAiPSIgaXNuJ3Qgd2ViLXNhZmUgKGl0IGlzbid0IGFuIDx1bnJlc2VydmVk PiBjaGFyKS4NCg0KUGFkZGluZyBpbiBiYXNlNjQgaXMgcG9pbnRsZXNzDQpzbyB0aGVyZSBpcyBu byB0ZWNobmljYWwgcHJvYmxlbSBpbiBvbWl0dGluZyBpdC4NCg0KTm90IHVzaW5nICJub3JtYWwi IGJhc2U2NCBpcyBhIGRpc2FkdmFudGFnZSwNCmJ1dCB3ZWxsIHdvcnRoIGl0IHRvIGF2b2lkIGEg dW5uZWNlc3NhcnkgbGF5ZXIgb2YgZXNjYXBpbmcuDQpWYXJpb3VzIEJhc2U2NCBsaWJyYXJpZXMg c3VwcG9ydCBiYXNlNjR1cmwgYW5kIG5vIHBhZGRpbmcNCndoZW4gY2FsbGVkIHdpdGggYXBwcm9w cmlhdGUgZmxhZ3MuDQoNCg0KLS0gDQpKYW1lcyBNYW5nZXINCg0K From eran@hueniverse.com Tue Jun 22 18:49:04 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4EDE28C122 for ; Tue, 22 Jun 2010 18:49:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.215 X-Spam-Level: X-Spam-Status: No, score=-2.215 tagged_above=-999 required=5 tests=[AWL=0.384, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gnvx7zj+hmiX for ; Tue, 22 Jun 2010 18:49:04 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 224A228C11E for ; Tue, 22 Jun 2010 18:49:04 -0700 (PDT) Received: (qmail 13307 invoked from network); 23 Jun 2010 01:49:10 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 23 Jun 2010 01:49:10 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 22 Jun 2010 18:49:11 -0700 From: Eran Hammer-Lahav To: Marius Scurtescu , Justin Richer Date: Tue, 22 Jun 2010 18:49:08 -0700 Thread-Topic: [OAUTH-WG] Last call for feedback on -08 Thread-Index: AcsSb4MrquCOuemIQ0+nmd8Cj9mZhgABqjZQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EC841EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EC83F35@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1277213040.1814.10.camel@localhost.localdomain> 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] Last call for feedback on -08 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 01:49:05 -0000 > > =A0* Handling of unregistered and dynamically-registered clients My discovery draft covers that, but other are free to propose alternatives = (before or after I publish my draft). EHL From bcampbell@pingidentity.com Tue Jun 22 20:01:01 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF9163A6992 for ; Tue, 22 Jun 2010 20:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.141 X-Spam-Level: X-Spam-Status: No, score=-5.141 tagged_above=-999 required=5 tests=[AWL=0.835, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BR8h3Y6g6cjT for ; Tue, 22 Jun 2010 20:01:01 -0700 (PDT) Received: from na3sys009aog109.obsmtp.com (na3sys009aog109.obsmtp.com [74.125.149.201]) by core3.amsl.com (Postfix) with SMTP id 6714D3A67F7 for ; Tue, 22 Jun 2010 20:00:58 -0700 (PDT) Received: from source ([209.85.161.42]) by na3sys009aob109.postini.com ([74.125.148.12]) with SMTP ID DSNKTCF48av9MOsURItAJm7u3bKaMoZIRodH@postini.com; Tue, 22 Jun 2010 20:01:06 PDT Received: by mail-fx0-f42.google.com with SMTP id 4so626624fxm.15 for ; Tue, 22 Jun 2010 20:01:05 -0700 (PDT) Received: by 10.223.45.200 with SMTP id g8mr6967253faf.67.1277262065175; Tue, 22 Jun 2010 20:01:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.122.81 with HTTP; Tue, 22 Jun 2010 20:00:35 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E72343B3EC83F35@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Brian Campbell Date: Tue, 22 Jun 2010 21:00:35 -0600 Message-ID: To: "OAuth WG (oauth@ietf.org)" Content-Type: multipart/alternative; boundary=0015174482ceae0c9c0489a9bf7b Subject: Re: [OAUTH-WG] Last call for feedback on -08 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 03:01:01 -0000 --0015174482ceae0c9c0489a9bf7b Content-Type: text/plain; charset=ISO-8859-1 Sounds like it's already in for -09 but I'd still like to voice my support for some kind of optional parameter like error_description. I'm working on a draft profiling a specific use of SAML in the assertion grant_type flow (coming soon to this list I hope) and added in an error_detail parameter for exactly the same purpose that Marius describes. I'm sure it would be useful in many other contexts, however, and it'd be good to have it in the core spec - giving the client side some ability to troubleshoot without having to directly involve people on the authz server side will be, IMHO, very valuable. -Brian On Tue, Jun 22, 2010 at 2:00 PM, Marius Scurtescu wrote: > There was a suggestion to expand the 'error' parameter to two > different parameters: > - error_code - well defined list of error codes > - error_description - authz server specific free form error > description (for logging and troubleshooting) > > Not sure if you considered this. > > Marius > > > > On Mon, Jun 21, 2010 at 7:27 PM, Eran Hammer-Lahav > wrote: > > I am working on -09 which I hope will be the last major revision of the > > specification. If you were planning on submitting any feedback on draft > -08 > > or the simplification proposal from David and me, please do so by > tomorrow > > to be included in the next draft. > > > > > > > > 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 > --0015174482ceae0c9c0489a9bf7b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sounds like it's already in for -09 but I'd still like to voice my = support for some kind of optional parameter like error_description.

    = I'm working on a draft profiling a specific use of SAML in the assertio= n grant_type flow (coming soon to this list I hope) and added in an error_de= tail parameter for exactly the same purpose that Marius describes.=A0=A0 I&= #39;m sure it would be useful in many other contexts, however, and it'd= be good to have it in the core spec - giving the client side some ability = to troubleshoot without having to=20 directly involve people on the authz server side will be, IMHO, very valuab= le.

    -Brian

    On Tue, Jun 22, 2010 a= t 2:00 PM, Marius Scurtescu <mscurtescu@google.com> wrote:
    There was a sugge= stion to expand the 'error' parameter to two
    different parameters:
    - error_code - well defined list of error codes
    - error_description - authz server specific free form error
    description (for logging and troubleshooting)

    Not sure if you considered this.

    Marius



    On Mon, Jun 21, 2010 at 7:27 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
    > I am working on -09 which I hope will be the last major revision of th= e
    > specification. If you were planning on submitting any feedback on draf= t -08
    > or the simplification proposal from David and me, please do so by tomo= rrow
    > to be included in the next draft.
    >
    >
    >
    > EHL
    >
    > ________________________= _______________________
    > 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

    --0015174482ceae0c9c0489a9bf7b-- From balfanz@google.com Tue Jun 22 22:57:54 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 161843A63CB for ; Tue, 22 Jun 2010 22:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.095 X-Spam-Level: X-Spam-Status: No, score=-104.095 tagged_above=-999 required=5 tests=[AWL=-0.608, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_BACKHAIR_42=1, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FBMGc5qk0iv8 for ; Tue, 22 Jun 2010 22:57:52 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 56F1F3A6876 for ; Tue, 22 Jun 2010 22:57:52 -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 o5N5vw9R008287 for ; Tue, 22 Jun 2010 22:57:59 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1277272679; bh=RdzH6dTKpJHQJAA+rtYUr+vTHns=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=dzGMpoQ6yN3VVe+2dgTLBfP8Ce+UNZJ4lB62klnDFJh50apYmoN8u39lC3ummBvHr 1oYiWUPll7z5q9b+iOCXQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=X9UwTB4XSgWOqx7AwrAC6J82sZheNC0N9hdkO6HhYHEJASJn1xdr4tyIjOuQG4wvB 4nnq2ya4knjPhOKGRCnyg== Received: from iwn39 (iwn39.prod.google.com [10.241.68.103]) by hpaq14.eem.corp.google.com with ESMTP id o5N5vtrX002326 for ; Tue, 22 Jun 2010 22:57:56 -0700 Received: by iwn39 with SMTP id 39so3965912iwn.14 for ; Tue, 22 Jun 2010 22:57:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.193.93 with SMTP id dt29mr8587979ibb.71.1277272675450; Tue, 22 Jun 2010 22:57:55 -0700 (PDT) Received: by 10.231.139.231 with HTTP; Tue, 22 Jun 2010 22:57:55 -0700 (PDT) In-Reply-To: References: Date: Tue, 22 Jun 2010 22:57:55 -0700 Message-ID: From: Dirk Balfanz To: Dick Hardt Content-Type: multipart/alternative; boundary=00504502c1af1a11210489ac3867 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] proposal for signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 05:57:54 -0000 --00504502c1af1a11210489ac3867 Content-Type: text/plain; charset=ISO-8859-1 Hi Dick, interesting point about encrypted payloads. People more cryptographically-inclined than me might want to chime in, but I do seem to remember that there is a "correct" choice among the "encrypt-then-sign" and "sign-then-encrypt" alternatives. A quick search seems to suggest that the latter is what you want: https://www.pluralsight-training.net/community/blogs/craig/archive/2003/06/30/837.aspx . So I would suggest that encrypted payloads are implemented as an encryption of a JSON Token, as in: encrypted_token = encryption(JSON_Token) || "." || envelope envelope = base64(JSON(everything you need to know to decrypt)) What do you think? Dirk. On Mon, Jun 21, 2010 at 7:43 AM, Dick Hardt wrote: > Thanks for writing this up Dirk. > > I would suggest that the token be: > > payload "." envelope "." signature > > This enables the payload to be encrypted and independent from the > envelope. > > Token signing, verification, encryption and decryption code can then be > generic and not understand the payload of the token. > > I would only include issuer, key_id and alg in the envelope. > > Audience, scope, nonce, and validation time information etc. would be in > the payload. > > -- Dick > > On 2010-06-21, at 12:04 AM, Dirk Balfanz wrote: > > Hi guys, > > I think I owe the list a proposal for signatures. > > I wrote something down that liberally borrows ideas from Magic Signatures, > SWT , and (even the name > from) JSON Web Tokens > . > > Here is a short document (called "JSON Tokens") that just explains how to > sign something and verify the signature: > > http://docs.google.com/document/pub?id=1kv6Oz_HRnWa0DaJx_SQ5Qlk_yqs_7zNAm75-FmKwNo4 > > Here is an extension of JSON Tokens that can be used for signed OAuth > tokens: > > http://docs.google.com/document/pub?id=1JUn3Twd9nXwFDgi-fTKl-unDG_ndyowTZW8OWX9HOUU > > Here is a different extension of JSON Tokens that can be used for 2-legged > flows. The idea is that this could be used as a drop-in replacement for SAML > assertions in the OAuth2 assertion flow: > > http://docs.google.com/document/pub?id=1s4kjRS9P0frG0ulhgP3He01ONlxeTwkFQV_pCoOowzc > > I also have started to write some codeto implement this as a proof-of-concept. > > Thoughts? Comments? > > Dirk. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --00504502c1af1a11210489ac3867 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Dick,=A0

    interesting point about encrypted payloads.= =A0

    People more cryptographically-inclined than me= might want to chime in, but I do seem to remember that there is a "co= rrect" choice among the "encrypt-then-sign" and "sign-t= hen-encrypt" alternatives. A quick search seems to suggest that the la= tter is what you want:=A0https://www.pluralsight-tr= aining.net/community/blogs/craig/archive/2003/06/30/837.aspx.=A0

    So I would suggest that encrypted payloads are implemen= ted as an encryption of a JSON Token, as in:

    encry= pted_token =3D encryption(JSON_Token) || "." || envelope=A0
    envelope =3D base64(JSON(everything you need to know to decrypt))

    What do you think?

    Dirk.


    On Mon, Jun 21, 2010 at= 7:43 AM, Dick Hardt <dick.hardt@gmail.com> wrote:
    Thanks = for writing this up Dirk.

    I would suggest that the token= be:

    payload ".= " envelope "." signature

    This enabl= es the payload to be encrypted and independent from the envelope.=A0
    <= div>
    Token signing, verification, encryption and decryption code = can then be generic and not understand the payload of the token.=A0

    I would only include issuer, key_id and alg in the envelo= pe.=A0

    Audience, scope, nonce, and validation time information= etc. would be in the payload.

    -- Dick
    <= br>
    On 2010-06-21, at 12:04 AM, = Dirk Balfanz wrote:

    Hi guys,= =A0

    I think I owe the list a proposal for signatures.

    I wrote something down that=A0liberally= =A0borrows ideas from Ma= gic Signatures, SWT, and (even the name from) JSON = Web Tokens.=A0

    Here is a short document (called &quo= t;JSON Tokens") that just explains how to sign something and verify th= e signature:
    http://docs.google.com/document/pub?id=3D1kv6Oz_HRnWa0Da= Jx_SQ5Qlk_yqs_7zNAm75-FmKwNo4

    Here is an extension of JSON Tokens= that can be used for signed OAuth tokens:

    Here is a different extension of JSON Tokens= that can be used for 2-legged flows. The idea is that this could be used a= s a drop-in replacement for SAML assertions in the OAuth2 assertion flow:
    http://docs.google.com/document/pub?id=3D1s4kjRS9P0frG0u= lhgP3He01ONlxeTwkFQV_pCoOowzc

    I also have started to write some code to implement this as a proof-of-conce= pt.=A0

    Thoughts? Comments?

    Dirk.

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


    --00504502c1af1a11210489ac3867-- From lshepard@facebook.com Tue Jun 22 23:00:50 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2820B3A6960 for ; Tue, 22 Jun 2010 23:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.019 X-Spam-Level: X-Spam-Status: No, score=-0.019 tagged_above=-999 required=5 tests=[AWL=-2.178, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OBuk0c4x7ReD for ; Tue, 22 Jun 2010 23:00:49 -0700 (PDT) Received: from mx-out.facebook.com (outmail025.snc1.tfbnw.net [69.63.178.184]) by core3.amsl.com (Postfix) with ESMTP id EB3003A6876 for ; Tue, 22 Jun 2010 23:00:48 -0700 (PDT) Received: from [10.18.255.126] ([10.18.255.126:27337] helo=mail.thefacebook.com) by mta027.snc1.facebook.com (envelope-from ) (ecelerity 2.2.2.45 r(34067)) with ESMTP id 2C/54-23619-613A12C4; Tue, 22 Jun 2010 23:00:54 -0700 Received: from sc-hub01.TheFacebook.com (192.168.18.104) by sc-hub04.TheFacebook.com (192.168.18.212) with Microsoft SMTP Server (TLS) id 14.0.694.1; Tue, 22 Jun 2010 23:00:54 -0700 Received: from SC-MBXC1.TheFacebook.com ([192.168.18.100]) by sc-hub01.TheFacebook.com ([192.168.18.104]) with mapi; Tue, 22 Jun 2010 23:00:53 -0700 From: Luke Shepard To: Marius Scurtescu Date: Tue, 22 Jun 2010 23:00:53 -0700 Thread-Topic: [OAUTH-WG] native app support (was: Next draft) Thread-Index: AcsSmXA6JLaSlGOBSIGLgbl/gDbGLA== Message-ID: <39DE4E99-6DB3-4FBA-B78C-B2AB2B162221@facebook.com> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EC8419E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3EC841C2@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3EC841C8@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 \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] native app support (was: Next draft) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 06:00:50 -0000 Two points: 1/ I agree that it can be onerous for clients to host web pages. It's not a= matter of expense but of complexity. BUT 2/ As we discussed previously in our in-person meeting, this should be hand= led by a different endpoint, and not be the responsibility for the provider= . If Google wishes to support this for their desktop apps, then it should p= rovide an endpoint that handles the OAuth response and puts it in the . I can say that Facebook has no interest in supporting this hack on the = server side, but clients that want it can use their own html file that does= it for them. For example, for Javascript web apps it is a pain to host a cross-domain re= ceiver file. So we host one on behalf of developers (called xd_proxy.php). = But it is not part of our server-side logic. If you want to write a spec for that, then great, but the hack does= not belong in the main spec. On Jun 22, 2010, at 4:30 PM, Marius Scurtescu wrote: > On Tue, Jun 22, 2010 at 4:26 PM, Eran Hammer-Lahav <eran@hueniverse.com> = wrote: >> In that case, I suggest an extension. But I just don't think this needs = it. Why involve the server at all in this? The client should just host a we= b page somewhere with the format it wants or the language for the user. >>=20 >> With $10 hosting, every client can host a web page somewhere. >=20 > Hard to tell, you could be right. Keep in mind that this page has to > be reliable and secure, $10 will probably not give you that. An authz > server can easily provide all this at almost no cost. >=20 > Marius >=20 >>=20 >> EHL >>=20 >>> -----Original Message----- >>> From: Marius Scurtescu [mailto:mscurtescu@google.com] >>> Sent: Tuesday, June 22, 2010 4:17 PM >>> To: Eran Hammer-Lahav >>> Cc: OAuth WG (oauth@ietf.org) >>> Subject: Re: native app support (was: Next draft) >>>=20 >>> On Tue, Jun 22, 2010 at 4:07 PM, Eran Hammer-Lahav >>> <eran@hueniverse.com> wrote: >>>>=20 >>>>> -----Original Message----- >>>>> From: Marius Scurtescu [mailto:mscurtescu@google.com] >>>>> Sent: Tuesday, June 22, 2010 3:35 PM >>>>> To: Eran Hammer-Lahav >>>>> Cc: OAuth WG (oauth@ietf.org) >>>>> Subject: Re: native app support (was: Next draft) >>>>>=20 >>>>> On Tue, Jun 22, 2010 at 3:14 PM, Eran Hammer-Lahav >>>>> <eran@hueniverse.com> wrote: >>>>>> In OAuth 1.0a, we needed it for the patch. I don't think this needs >>>>>> to be in >>>>> the spec because it doesn't help interop. If the server supports such >>>>> a scheme, it should document it. It also falls under "previously >>>>> established redirection URI" which happens to point at the server. >>>>>=20 >>>>> OK, that makes sense. >>>>>=20 >>>>> What about: >>>>>> Also, this page should put the verification code and the client >>>>>> state (code and state) in the page title in a standard way such >>>>>> that the native app can extract them from the window title. WRAP >>>>>> defined how the title should be formed. >>>>>=20 >>>>> Extension? >>>>=20 >>>> I don't think this needs a spec. Just something provided by the server= . Does >>> the client need any special handling? It can always just use a static w= eb page >>> to do this, no? >>>=20 >>> A spec would help so all servers provide code and state in a consistent >>> format. Client libraries can then provide methods to parse this. Also, = client >>> apps connecting to multiple servers can expect some consistency. >>>=20 >>> Marius >>>=20 >>>>=20 >>>> EHL >>>>=20 >>>>>=20 >>>>> Marius >>>>>=20 >>>>>>=20 >>>>>> EHL >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Marius Scurtescu [mailto:mscurtescu@google.com] >>>>>>> Sent: Tuesday, June 22, 2010 1:02 PM >>>>>>> To: Eran Hammer-Lahav >>>>>>> Cc: OAuth WG (oauth@ietf.org) >>>>>>> Subject: Re: native app support (was: Next draft) >>>>>>>=20 >>>>>>> On Tue, Jun 8, 2010 at 10:46 AM, Marius Scurtescu >>>>>>> <mscurtescu@google.com> wrote: >>>>>>>> In order to properly support native applications I suggest the >>>>>>>> following changes: >>>>>>>> [...] >>>>>>>> 2. optional redirect_uri (default result page) >>>>>>>>=20 >>>>>>>> Some native apps do not have a redirect_uri, as a result two >>>>>>>> things are >>>>>>> needed: >>>>>>>>=20 >>>>>>>> 2.1 Either make redirect_uri optional or define a standard value >>>>>>>> that signals that the client does not have such a page. >>>>>>>>=20 >>>>>>>> 2.2 The authz server must supply a default result page, if there >>>>>>>> is no redirect_uri. Also, this page should put the verification >>>>>>>> code and the client state (code and state) in the page title in >>>>>>>> a standard way such that the native app can extract them from >>>>>>>> the window title. WRAP defined how the title should be formed. >>>>>>>=20 >>>>>>> Should this also go to an extension? It is not introducing any new >>>>>>> parameters, not sure if it belongs there. OAuth 1 at least defined >>>>>>> the >>>>> "oob" special value. >>>>>>>=20 >>>>>>> Marius >>>>>>=20 >>>>=20 >>=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From hannes.tschofenig@nsn.com Tue Jun 22 23:07:16 2010 Return-Path: <hannes.tschofenig@nsn.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CA813A6A4A for <oauth@core3.amsl.com>; Tue, 22 Jun 2010 23:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.353 X-Spam-Level: X-Spam-Status: No, score=-0.353 tagged_above=-999 required=5 tests=[AWL=-0.354, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qkVneSPjb5g for <oauth@core3.amsl.com>; Tue, 22 Jun 2010 23:07:15 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id B43AB3A6A49 for <oauth@ietf.org>; Tue, 22 Jun 2010 23:07:14 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o5N67J3B019448 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <oauth@ietf.org>; Wed, 23 Jun 2010 08:07:19 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o5N67IOw030824 for <oauth@ietf.org>; Wed, 23 Jun 2010 08:07:19 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 23 Jun 2010 08:07:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 23 Jun 2010 09:07:41 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4502BE07CC@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Extensibility for OAuth? Thread-Index: AcsSmmOz8+Jt3DWXRJyOV1i4UkJelA== From: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com> To: "OAuth WG" <oauth@ietf.org> X-OriginalArrivalTime: 23 Jun 2010 06:07:18.0136 (UTC) FILETIME=[55A56F80:01CB129A] Subject: [OAUTH-WG] Extensibility for OAuth? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 23 Jun 2010 06:07:16 -0000 Hi Eran,=20 Hi all,=20 I briefly browsed through the -08 version of the draft to figure out what could be written about extensibility. Here are a few thoughts: - Client Profiles=20 This is probably the most important item were people will want to write extensions for. Currently, we have the following onces in the document:=20 1) Web Server 2) User Agent 3) Native Application 4) Autonomous Note that the actual profile identifiers aren't clearly listed in the document at the moment (or are inconsistent, such as "user_agent" and "user-agent" for the user agent profile).=20 We would want IANA to register them and then we need to list under what conditions new profiles can be added, or existing onces updated/deleted. RFC 5226 defines some typical policies, see http://tools.ietf.org/html/rfc5226.=20 We probably want the policy "RFC Required". When people write new profiles we want them to provide a description about the use case, maybe an example, we want them to discuss security, and we definitely want to ensure that the overall write is consistent with the base specification (such as with the registry parameters it defines). The reviews would ensure that existing profile do not in fact already provide the functionality of the newly defined profile. Note that "RFC Required" does not require a Standards Track RFC; an Informational or an Experimental RFC is already sufficient. Those are less difficult to get published but they still provide a stable reference.=20 I would argue that we do not want new profiles to update existing onces (unless they just informative changes or clarifications), in the sense that they use the same profile name but with a modified semantic. Instead, an updated profile would still define a new profile name and would as such be different. I believe depreciating an existing entry makes sense while deleting one does not.=20 An open question might be whether there is a possibility for an extension (other than a new profile) to define an optional parameter that may get used with an existing profile. Note that at the moment there is no registry for parameters. - Scope=20 The scope parameter is used in various places throught the document, such as Section 3. Currently, the description does not indicate whether there is a plan to have some standardized parameters with well-defined semantic. Here is the current text for the scope parameter:=20 " scope OPTIONAL. The scope of the access request expressed as a list of space-delimited strings. The value of the "scope" parameter is defined by the authorization server. If the value contains multiple space-delimited strings, their order does not matter, and each string adds an additional access range to the requested scope. " Do folks think it would be useful to have standardized values?=20 If the answer is "yes", then it would be useful to differentiate the standardized values from those values that are purely defined locally by the authorization server.=20 - Error Codes=20 The document lists error codes in Section 3.1 and Section 4.3. I suspect that they are not from the same pool of error codes. =20 My question is whether some of the error codes are very specific to the profiles themselves or rather generic in nature. - Grant Type The Grant Type (grant_type) is described in Section 4. Currently, there are 5 values defines ("authorization_code", "user_basic_credentials", "assertion", "refresh_token", "none") and I assume that the list should be extensible (even though the text currently says something else at the moment).=20 Are there specific requirements that must be met in order to register new grant types?=20 - Assertion Type=20 Section 4.1.3 defines the assertion type ("assertion_type"). The text indicates that the content is an absolute URI and as such it is a bit different to the other value encodings we have seen previously. Nevertheless, the question is whether some folks want to write standardized templates for assertions, such as a specific form of SAML assertion. This could help interoperability a lot, I believe. The solution is still to have a URI but to define an IANA managed space for IETF standardized assertion types. Such a style is btw common. Do I miss something else?=20 Ciao Hannes From balfanz@google.com Tue Jun 22 23:09:45 2010 Return-Path: <balfanz@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AFDB3A6A4C for <oauth@core3.amsl.com>; Tue, 22 Jun 2010 23:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.218 X-Spam-Level: X-Spam-Status: No, score=-105.218 tagged_above=-999 required=5 tests=[AWL=0.758, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TvmfYNmrEJa9 for <oauth@core3.amsl.com>; Tue, 22 Jun 2010 23:09:43 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 369333A684F for <oauth@ietf.org>; Tue, 22 Jun 2010 23:09:43 -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 o5N69nW6024426 for <oauth@ietf.org>; Tue, 22 Jun 2010 23:09:50 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1277273390; bh=IC9g+NUzyFTmzjM7RO3rjd79lXo=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=hvZL+JkAVEJYQDlIMsTJWI4SOx9PNN/9GxTguNdGjQbMiiElE41+mXrBEUh7w2LGo qz7Om0tGudnbvcFqm2W5g== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=JlbmE/2M/4Eug74m0h8wa0iB/DciAKCGvEWSbBW0jMvPR1fFB5EYSTx//ZPpoQ9zm 642rST4H+awGjG/W7zMeg== Received: from iwn2 (iwn2.prod.google.com [10.241.68.66]) by hpaq14.eem.corp.google.com with ESMTP id o5N69l9c012697 for <oauth@ietf.org>; Tue, 22 Jun 2010 23:09:48 -0700 Received: by iwn2 with SMTP id 2so1885396iwn.25 for <oauth@ietf.org>; Tue, 22 Jun 2010 23:09:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.152.71 with SMTP id f7mr8643766ibw.128.1277273387371; Tue, 22 Jun 2010 23:09:47 -0700 (PDT) Received: by 10.231.139.231 with HTTP; Tue, 22 Jun 2010 23:09:47 -0700 (PDT) In-Reply-To: <AANLkTinSdgV1Xq5X7O6KIjMBxw7G66vUf8A-XZxWPZ1s@mail.gmail.com> References: <AANLkTingCgO-o3XRZbxYoD8U2rRTO-EgWcfg2hBlbQHm@mail.gmail.com> <AANLkTil-O1RAIuk2Pl4Jl6N2TzN6RRp8imMIffbx18Z4@mail.gmail.com> <AANLkTin1wx42Ziz8yXWLjKRoB9bA0UGOYteAw1xPLHhE@mail.gmail.com> <AANLkTinSdgV1Xq5X7O6KIjMBxw7G66vUf8A-XZxWPZ1s@mail.gmail.com> Date: Tue, 22 Jun 2010 23:09:47 -0700 Message-ID: <AANLkTinQ6bOanAB6Ri1Oil0k1dejLk4Tz1WxVHVJJPrR@mail.gmail.com> From: Dirk Balfanz <balfanz@google.com> To: Ben Laurie <benl@google.com> Content-Type: multipart/alternative; boundary=001636e1f0b6890be80489ac62a0 X-System-Of-Record: true Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] proposal for signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 23 Jun 2010 06:09:45 -0000 --001636e1f0b6890be80489ac62a0 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jun 22, 2010 at 2:28 AM, Ben Laurie <benl@google.com> wrote: > On 22 June 2010 02:14, Dirk Balfanz <balfanz@google.com> wrote: > > > > > > On Mon, Jun 21, 2010 at 4:18 AM, Ben Laurie <benl@google.com> wrote: > >> > >> On 21 June 2010 08:04, Dirk Balfanz <balfanz@google.com> wrote: > >> > Hi guys, > >> > I think I owe the list a proposal for signatures. > >> > I wrote something down that liberally borrows ideas from Magic > >> > Signatures, > >> > SWT, and (even the name from) JSON Web Tokens. > >> > Here is a short document (called "JSON Tokens") that just explains how > >> > to > >> > sign something and verify the signature: > >> > > >> > > http://docs.google.com/document/pub?id=1kv6Oz_HRnWa0DaJx_SQ5Qlk_yqs_7zNAm75-FmKwNo4 > >> > >> "signature is a base64-encoded string of the signature bits." should > >> be websafe-base64? > > > > Yes. > > I think there are a couple of other places that also need this change. > > >> "the current time is not after the expiration time of the token > >> (defined as not_before + session_length)" should be not_before + > >> token_lifetime, right? > > > > Yes. > > > >> > >> But I'd prefer a not_after instead. > > > > Either way is fine with me. I picked token_lifetime b/c it tends to take > up > > a little less space than a not_after, but I don't feel strongly about it. > > not_after is in line with X.509, and also means implementations are a > few characters shorter :-) > > >> What is a Service Descriptor? Is this something to do with webfinger, > >> or something else? > > > > Something else. I'm proposing that an OAuth Client be identifiable by a > URL. > > You resolve the URL, you get everything you need to know about that > Client. > > Simpler than webfinger. > > Why? What's wrong with webfinger? > webfinger is for resolving email-like identifiers. Sometimes, that's all you have (e.g., when you have a login box and users insist on typing email addresses into that login box). But we can make things much simpler if the identifiers that need to be resolved are already http(s) URLs (and we don't assume that they need to resolve to display-able HTML). If we're in that situation (and I'm arguing that here we can be if we want to) then "discovery" basically disappears as a problem - you simply fetch the URL and you have the information you want right there. Dirk. > > >> In the HMAC keys section you describe the keys as symmetric, which is > >> strictly accurate, but more normally called shared keys for this use. > >> > >> Obviously you'll need to be a bit more specific about what you mean by > >> "RSA-SHA256". > > > > Right. Any suggestions what RSA-SHA256 should specifically refer to? If I > > stick that into a Signature.getInstance() call in Java, it returns > > _something_. Any idea what that is? I'd like say that whatever that is is > > what I mean by RSA-SHA256. > > RSA in Java Signature means a PKCS#1 signature (see > > http://java.sun.com/javase/6/docs/technotes/guides/security/StandardNames.html#Signature > ). > Of course, there are actually two PKCS#1 signature schemes, and the > Java docs are quite unclear about which they use, but reading between > the lines, I'd say that "SHA256withRSA" (presumably what you meant by > "RSA-SHA256"?) yields a PKCS1_v1_5 signature (what they call > RSASSA-PKCS1_v1_5) and "SHA256withRSAandMGF1" yields an RSASSA-PSS > signature, which is recommended for new applications. > > >> > Here is an extension of JSON Tokens that can be used for signed OAuth > >> > tokens: > >> > > >> > > http://docs.google.com/document/pub?id=1JUn3Twd9nXwFDgi-fTKl-unDG_ndyowTZW8OWX9HOUU > >> > >> As you know, I hate the term "non-repudation". Can't you just call it > >> "signing"? > > > > What would you say is the advantage of public-key signatures over > shared-key > > signatures? I do want to point out that this proposal includes public-key > > signatures, and therefore brings to advantages to the table. > > Well, the advantages are that > > a) the signature cannot be forged by the verifier (assuming no key > leakage). > > b) verifying key distribution is easier (since it is public). > > I don't know of a short way to describe this other than "public key" > or "asymmetric". > > >> "Protection against leaked authentication tokens: Protocols such as > >> OAuth2 use bearer tokens, which may leak when used over non-SSL. > >> Signing requests when using bearer tokens lets the recipient of such a > >> request verify that the issuer of the request was a legitimate holder > >> of the bearer token." - only true if you make the checking of the > >> nonce a MUST instead of "may". And even then, MitM wins, of course. > > > > MITM wins while the token is valid as per not_before and token_lifetime > (or > > not_after). > > Right. > > >> Why is body_hash optional? > > > > Maybe some Clients/PRs don't care? I remember that in OAuth 1, we > couldn't > > ever get agreement on what to do about POST body signing, so I made it > > optional. I'm not going to stand in the way if people want this to be > > required. > > > >> > >> > Here is a different extension of JSON Tokens that can be used for > >> > 2-legged > >> > flows. The idea is that this could be used as a drop-in replacement > for > >> > SAML > >> > assertions in the OAuth2 assertion flow: > >> > > >> > > http://docs.google.com/document/pub?id=1s4kjRS9P0frG0ulhgP3He01ONlxeTwkFQV_pCoOowzc > >> > >> You use the abbreviation AS before the full name Authorization Server. > > > > Oops - sorry. :-) I'll try to do a revision later tonight... > > > > Thanks for the feedback! > > Dirk. > >> > >> > I also have started to write some code to implement this as a> > >> > proof-of-concept. > >> > > >> > Thoughts? Comments? > >> > >> Nice. > >> > >> > Dirk. > >> > > >> > _______________________________________________ > >> > OAuth mailing list > >> > OAuth@ietf.org > >> > https://www.ietf.org/mailman/listinfo/oauth > >> > > >> > > > > > > --001636e1f0b6890be80489ac62a0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <br><br><div class=3D"gmail_quote">On Tue, Jun 22, 2010 at 2:28 AM, Ben Lau= rie <span dir=3D"ltr"><<a href=3D"mailto:benl@google.com">benl@google.co= m</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi= n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div class=3D"im">On 22 June 2010 02:14, Dirk Balfanz <<a href=3D"mailto= :balfanz@google.com">balfanz@google.com</a>> wrote:<br> ><br> ><br> > On Mon, Jun 21, 2010 at 4:18 AM, Ben Laurie <<a href=3D"mailto:benl= @google.com">benl@google.com</a>> wrote:<br> >><br> >> On 21 June 2010 08:04, Dirk Balfanz <<a href=3D"mailto:balfanz@= google.com">balfanz@google.com</a>> wrote:<br> >> > Hi guys,<br> >> > I think I owe the list a proposal for signatures.<br> >> > I wrote something down that=A0liberally=A0borrows ideas from = Magic<br> >> > Signatures,<br> >> > SWT, and (even the name from) JSON Web Tokens.<br> >> > Here is a short document (called "JSON Tokens") tha= t just explains how<br> >> > to<br> >> > sign something and verify the signature:<br> >> ><br> >> > <a href=3D"http://docs.google.com/document/pub?id=3D1kv6Oz_HR= nWa0DaJx_SQ5Qlk_yqs_7zNAm75-FmKwNo4" target=3D"_blank">http://docs.google.c= om/document/pub?id=3D1kv6Oz_HRnWa0DaJx_SQ5Qlk_yqs_7zNAm75-FmKwNo4</a><br> >><br> >> "signature is a base64-encoded string of the signature bits.&= quot; should<br> >> be websafe-base64?<br> ><br> > Yes.<br> <br> </div>I think there are a couple of other places that also need this change= .<br> <div class=3D"im"><br> >> "the current time is not after the expiration time of the tok= en<br> >> (defined as not_before + session_length)" should be not_befor= e +<br> >> token_lifetime, right?<br> ><br> > Yes.<br> ><br> >><br> >> But I'd prefer a not_after instead.<br> ><br> > Either way is fine with me. I picked token_lifetime b/c it tends to ta= ke up<br> > a little less space than a not_after, but I don't feel strongly ab= out it.<br> <br> </div>not_after is in line with X.509, and also means implementations are a= <br> few characters shorter :-)<br> <div class=3D"im"><br> >> What is a Service Descriptor? Is this something to do with webfing= er,<br> >> or something else?<br> ><br> > Something else. I'm proposing that an OAuth Client be identifiable= by a URL.<br> > You resolve the URL, you get everything you need to know about that Cl= ient.<br> > Simpler than webfinger.<br> <br> </div>Why? What's wrong with webfinger?<br></blockquote><div><br></div>= <div>webfinger is for resolving email-like identifiers. Sometimes, that'= ;s all you have (e.g., when you have a login box and users insist on typing= email addresses into that login box). But we can make things much simpler = if the identifiers that need to be resolved are already http(s) URLs (and w= e don't assume that they need to resolve to display-able HTML). If we&#= 39;re in that situation (and I'm arguing that here we can be if we want= to) then "discovery" basically disappears as a problem - you sim= ply fetch the URL and you have the information you want right there.</div> <div><br>Dirk.</div><div><br></div><div>=A0</div><blockquote class=3D"gmail= _quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:= 1ex;"> <div class=3D"im"><br> >> In the HMAC keys section you describe the keys as symmetric, which= is<br> >> strictly accurate, but more normally called shared keys for this u= se.<br> >><br> >> Obviously you'll need to be a bit more specific about what you= mean by<br> >> "RSA-SHA256".<br> ><br> > Right. Any suggestions what RSA-SHA256 should specifically refer to? I= f I<br> > stick that into a Signature.getInstance() call in Java, it returns<br> > _something_. Any idea what that is? I'd like say that whatever tha= t is is<br> > what I mean by RSA-SHA256.<br> <br> </div>RSA in Java Signature means a PKCS#1 signature (see<br> <a href=3D"http://java.sun.com/javase/6/docs/technotes/guides/security/Stan= dardNames.html#Signature" target=3D"_blank">http://java.sun.com/javase/6/do= cs/technotes/guides/security/StandardNames.html#Signature</a>).<br> Of course, there are actually two PKCS#1 signature schemes, and the<br> Java docs are quite unclear about which they use, but reading between<br> the lines, I'd say that "SHA256withRSA" (presumably what you = meant by<br> "RSA-SHA256"?) yields a PKCS1_v1_5 signature (what they call<br> RSASSA-PKCS1_v1_5) and "SHA256withRSAandMGF1" yields an RSASSA-PS= S<br> signature, which is recommended for new applications.<br> <div class=3D"im"><br> >> > Here is an extension of JSON Tokens that can be used for sign= ed OAuth<br> >> > tokens:<br> >> ><br> >> > <a href=3D"http://docs.google.com/document/pub?id=3D1JUn3Twd9= nXwFDgi-fTKl-unDG_ndyowTZW8OWX9HOUU" target=3D"_blank">http://docs.google.c= om/document/pub?id=3D1JUn3Twd9nXwFDgi-fTKl-unDG_ndyowTZW8OWX9HOUU</a><br> >><br> >> As you know, I hate the term "non-repudation". Can't= you just call it<br> >> "signing"?<br> ><br> > What would you say is the advantage of public-key signatures over shar= ed-key<br> > signatures? I do want to point out that this proposal includes public-= key<br> > signatures, and therefore brings to advantages to the table.<br> <br> </div>Well, the advantages are that<br> <br> a) the signature cannot be forged by the verifier (assuming no key leakage)= .<br> <br> b) verifying key distribution is easier (since it is public).<br> <br> I don't know of a short way to describe this other than "public ke= y"<br> or "asymmetric".<br> <div class=3D"im"><br> >> "Protection against leaked authentication tokens: Protocols s= uch as<br> >> OAuth2 use bearer tokens, which may leak when used over non-SSL.<b= r> >> Signing requests when using bearer tokens lets the recipient of su= ch a<br> >> request verify that the issuer of the request was a legitimate hol= der<br> >> of the bearer token." - only true if you make the checking of= the<br> >> nonce a MUST instead of "may". And even then, MitM wins,= of course.<br> ><br> > MITM wins while the token is valid as per not_before and token_lifetim= e (or<br> > not_after).<br> <br> </div>Right.<br> <div><div></div><div class=3D"h5"><br> >> Why is body_hash optional?<br> ><br> > Maybe some Clients/PRs don't care? I remember that in OAuth 1, we = couldn't<br> > ever get agreement on what to do about POST body signing, so I made it= <br> > optional. I'm not going to stand in the way if people want this to= be<br> > required.<br> ><br> >><br> >> > Here is a different extension of JSON Tokens that can be used= for<br> >> > 2-legged<br> >> > flows. The idea is that this could be used as a drop-in repla= cement for<br> >> > SAML<br> >> > assertions in the OAuth2 assertion flow:<br> >> ><br> >> > <a href=3D"http://docs.google.com/document/pub?id=3D1s4kjRS9P= 0frG0ulhgP3He01ONlxeTwkFQV_pCoOowzc" target=3D"_blank">http://docs.google.c= om/document/pub?id=3D1s4kjRS9P0frG0ulhgP3He01ONlxeTwkFQV_pCoOowzc</a><br> >><br> >> You use the abbreviation AS before the full name Authorization Ser= ver.<br> ><br> > Oops - sorry. :-) I'll try to do a revision later tonight...<br> ><br> > Thanks for the feedback!<br> > Dirk.<br> >><br> >> > I also have started to write some code to implement this as a= ><br> >> > proof-of-concept.<br> >> ><br> >> > Thoughts? Comments?<br> >><br> >> Nice.<br> >><br> >> > Dirk.<br> >> ><br> >> > _______________________________________________<br> >> > OAuth mailing list<br> >> > <a href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a><br> >> > <a href=3D"https://www.ietf.org/mailman/listinfo/oauth" targe= t=3D"_blank">https://www.ietf.org/mailman/listinfo/oauth</a><br> >> ><br> >> ><br> ><br> ><br> </div></div></blockquote></div><br> --001636e1f0b6890be80489ac62a0-- From balfanz@google.com Tue Jun 22 23:17:28 2010 Return-Path: <balfanz@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A62493A6853 for <oauth@core3.amsl.com>; Tue, 22 Jun 2010 23:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.344 X-Spam-Level: X-Spam-Status: No, score=-105.344 tagged_above=-999 required=5 tests=[AWL=0.631, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UxaK2Pb-yAvq for <oauth@core3.amsl.com>; Tue, 22 Jun 2010 23:17:26 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 6F7BC3A63CB for <oauth@ietf.org>; Tue, 22 Jun 2010 23:17:26 -0700 (PDT) Received: from hpaq3.eem.corp.google.com (hpaq3.eem.corp.google.com [172.25.149.3]) by smtp-out.google.com with ESMTP id o5N6HXHA001212 for <oauth@ietf.org>; Tue, 22 Jun 2010 23:17:33 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1277273853; bh=YhbA65Gv2Okixe9jiVjV0ZqEzSE=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=TI/S2ZJcdBKa7MMPgBlmuOs+NUYBfcDpqQTFiwiASa2LMdHF10cXuwBiY/NtH/f8t R8XS3vvRh8wToC4jiI0pw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=pkkhU0TQV+6Q2JDnjSmsui8M90GXNGolnGj9L/b6pHXK/MbubOYvskNXtvI8f8X0V N4/Y/FSSYTQF629xdK3Gw== Received: from iwn35 (iwn35.prod.google.com [10.241.68.99]) by hpaq3.eem.corp.google.com with ESMTP id o5N6HVP6024239 for <oauth@ietf.org>; Tue, 22 Jun 2010 23:17:31 -0700 Received: by iwn35 with SMTP id 35so3079848iwn.15 for <oauth@ietf.org>; Tue, 22 Jun 2010 23:17:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.155.18 with SMTP id q18mr8119558ibw.44.1277273850378; Tue, 22 Jun 2010 23:17:30 -0700 (PDT) Received: by 10.231.139.231 with HTTP; Tue, 22 Jun 2010 23:17:30 -0700 (PDT) In-Reply-To: <AANLkTilRUQiD5oRyxUZXmPs2skCY8zAmc1Vl--8pEblS@mail.gmail.com> References: <AANLkTingCgO-o3XRZbxYoD8U2rRTO-EgWcfg2hBlbQHm@mail.gmail.com> <AANLkTinZ1XIFO25mcgoiDV-V0Blvv8ZC6kV_F3fca3dC@mail.gmail.com> <4C5BCAC6-713F-4C42-8696-2931D1AB3199@gmail.com> <AANLkTinlATNBEQsmFJIxv_cgqfI_tsoGfTMy6OXN6F_B@mail.gmail.com> <A08279DC79B11C48AD587060CD9397712735068D@TK5EX14MBXC101.redmond.corp.microsoft.com> <AANLkTimLrZzwDW9rMtGjD9k6ZtXc_oDXIIIYWOMw-NCi@mail.gmail.com> <AANLkTilcn_qQLgriJEdPk95f2Zliyk0QXGvU6t77Aa7G@mail.gmail.com> <AANLkTinEjidY_HmcGHPTus7P1snjCl9DPL4dX-Sz_mTQ@mail.gmail.com> <AANLkTilRUQiD5oRyxUZXmPs2skCY8zAmc1Vl--8pEblS@mail.gmail.com> Date: Tue, 22 Jun 2010 23:17:30 -0700 Message-ID: <AANLkTilgHznT8ni2SyzbZ4vSKQ9KiFP2bmTR8YxeE3vB@mail.gmail.com> From: Dirk Balfanz <balfanz@google.com> To: David Recordon <recordond@gmail.com> Content-Type: multipart/alternative; boundary=001636d3425521f9930489ac7e2a X-System-Of-Record: true Cc: "Hannes.Tschofenig@gmx.net" <Hannes.Tschofenig@gmx.net>, OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] proposal for signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 23 Jun 2010 06:17:28 -0000 --001636d3425521f9930489ac7e2a Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable In my write-up, I'm saying that if you provide the shared key and you don't care about rotating it, then the verifier can ignore the key_id (the issuer would presumable not include the key_id). Same for public keys - if you upload them out of band and you don't think you'll ever change them, then the key_id is not necessary. I would argue that either of those practices i= s not advisable (despite the fact that we've all been doing it for OAuth 1), so I think the key_id is useful. Dirk. On Tue, Jun 22, 2010 at 1:45 PM, David Recordon <recordond@gmail.com> wrote= : > Hey Dick, in answering my questions you made my point. If keys are > managed out of band =96 as is done in OAuth 1.0 and what was done in the > OAuth 2.0 Core spec until signatures were extracted =96 then having a > key id is not needed. I certainly understand what they're used for, > but don't find them relevant as part of the OAuth conversation today. > > And yes, Applied Cryptography is worth reading. :) > > --David > > > On Tue, Jun 22, 2010 at 12:59 PM, Dick Hardt <dick.hardt@gmail.com> wrote= : > > David > > key_ids are used when you need to identify which key to use of all the > keys > > you might have. If you are doing discovery of document that is bound to > the > > identifier of the signer, this is useful. Since OAuth 1.0 did not have > > discovery and required an out of band key management process, key_ids > have > > little value. > > To answer your question, key_ids dont' make sense if the keys are being > > managed how you describe them. I would suggest that key_ids are not > included > > if public keys are managed independent from how Dirk had described them > be > > discovered. > > I don't think key_ids make sense for shared secrets as they inherently > have > > an out of band process for sharing them. > > If you would like to learn more about cryptography, I have found Bruce > > Schneier's book Applied Cryptography to be pretty educational. Here is = a > > link to the Kindle version: > > > http://www.amazon.com/Applied-Cryptography-Protocols-Algorithms-ebook/dp/= B000SEHPK6/ref=3Dkinw_dp_ke?ie=3DUTF8&m=3DAG56TWVU5XWC2&qid=3D1277236054&sr= =3D8-1 > > -- Dick > > > > On Tue, Jun 22, 2010 at 12:20 PM, David Recordon <recordond@gmail.com> > > wrote: > >> > >> All of the OAuth 1.0 implementations which I'm aware of either have > >> the server provide a shared secret to the client or the client upload > >> their public key to the server. > >> > >> In the case of the server providing a shared secret to the client, > >> what would the value of key_id be? > >> > >> In the case of a client uploading their public key to the server, what > >> would the value of key_id be? > >> > >> Thanks, > >> --David > >> > >> > >> On Tue, Jun 22, 2010 at 12:14 PM, Dick Hardt <dick.hardt@gmail.com> > wrote: > >> > I could imagine an architecture striving to be efficient, scalable, > >> > distributed and secure where there are hundreds of servers each with= a > >> > unique private key baked into each server. All the public keys would > be > >> > in > >> > one file. > >> > Having a key id would help debugging as well as the signer is clearl= y > >> > indicating which key should be used. If the signing fails, it could = be > >> > the > >> > key, could be signature calculation, could be ... > >> > > >> > The downside of having a key_id seems heavily outweighed by the > >> > advantages > >> > to me. > >> > On Tue, Jun 22, 2010 at 10:30 AM, Anthony Nadalin > >> > <tonynad@microsoft.com> > >> > wrote: > >> >> > >> >> > If a server needs to verify, it can literally iterate over all of > the > >> >> > keys associated with the client until it finds the right one. > >> >> > >> >> Depends on how the server stored the keys, this can be a very > expensive > >> >> operation w/o a key_id to match/index on > >> >> > >> >> -----Original Message----- > >> >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > Behalf > >> >> Of > >> >> Brian Eaton > >> >> Sent: Tuesday, June 22, 2010 9:43 AM > >> >> To: Dick Hardt; Hannes.Tschofenig@gmx.net > >> >> Cc: OAuth WG > >> >> Subject: Re: [OAUTH-WG] proposal for signatures > >> >> > >> >> On Tue, Jun 22, 2010 at 7:17 AM, Dick Hardt <dick.hardt@gmail.com> > >> >> wrote: > >> >> >> Thanks for writing this. A few questions... > >> >> >> > >> >> >> Do we need both `issuer` and `key_id`? Shouldn't we use > `client_id` > >> >> >> instead at least for OAuth? > >> >> > > >> >> > it is the ID of the key, not the client -- used to rollover keys > >> >> > >> >> I don't think key id is necessary, but adding Hannes since he calle= d > me > >> >> crazy for saying that at IIW. =3D) > >> >> > >> >> The average client is going to have very few keys. Probably just 1= . > >> >> 3 at the outside. > >> >> > >> >> If a server needs to verify, it can literally iterate over all of t= he > >> >> keys > >> >> associated with the client until it finds the right one. > >> >> > >> >> There is some precedent for this approach: > >> >> http://support.microsoft.com/kb/906305/en-us. > >> >> > >> >> Cheers, > >> >> Brian > >> >> _______________________________________________ > >> >> OAuth mailing 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 > --001636d3425521f9930489ac7e2a Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable In my write-up, I'm saying that if you provide the shared key and you d= on't care about rotating it, then the verifier can ignore the key_id (t= he issuer would presumable not include the key_id). Same for public keys - = if you upload them out of band and you don't think you'll ever chan= ge them, then the key_id is not necessary. I would argue that either of tho= se practices is not advisable (despite the fact that we've all been doi= ng it for OAuth 1), so I think the key_id is useful.<div> <br></div><div>Dirk.<br><br><div class=3D"gmail_quote">On Tue, Jun 22, 2010= at 1:45 PM, David Recordon <span dir=3D"ltr"><<a href=3D"mailto:recordo= nd@gmail.com">recordond@gmail.com</a>></span> wrote:<br><blockquote clas= s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad= ding-left:1ex;"> Hey Dick, in answering my questions you made my point. If keys are<br> managed out of band =96=A0as is done in OAuth 1.0 and what was done in the<= br> OAuth 2.0 Core spec until signatures were extracted =96=A0then having a<br> key id is not needed. I certainly understand what they're used for,<br> but don't find them relevant as part of the OAuth conversation today.<b= r> <br> And yes, Applied Cryptography is worth reading. :)<br> <font color=3D"#888888"><br> --David<br> </font><div><div></div><div class=3D"h5"><br> <br> On Tue, Jun 22, 2010 at 12:59 PM, Dick Hardt <<a href=3D"mailto:dick.har= dt@gmail.com">dick.hardt@gmail.com</a>> wrote:<br> > David<br> > key_ids are used when you need to identify which key to use of all the= keys<br> > you might have. If you are doing discovery of document that is bound t= o the<br> > identifier of the signer, this is useful. Since OAuth 1.0 did not have= <br> > discovery and required an out of band key management process, key_ids = have<br> > little value.<br> > To answer your question, key_ids dont' make sense if the keys are = being<br> > managed how you describe them. I would suggest that key_ids are not in= cluded<br> > if public keys are managed=A0independent=A0from how Dirk had described= them be<br> > discovered.<br> > I don't think key_ids make sense for shared secrets as they inhere= ntly have<br> > an out of band process for sharing them.<br> > If you would like to learn more about cryptography, I have found Bruce= <br> > Schneier's book Applied Cryptography to be pretty educational. Her= e is a<br> > link to the Kindle version:<br> > <a href=3D"http://www.amazon.com/Applied-Cryptography-Protocols-Algori= thms-ebook/dp/B000SEHPK6/ref=3Dkinw_dp_ke?ie=3DUTF8&m=3DAG56TWVU5XWC2&a= mp;qid=3D1277236054&sr=3D8-1" target=3D"_blank">http://www.amazon.com/A= pplied-Cryptography-Protocols-Algorithms-ebook/dp/B000SEHPK6/ref=3Dkinw_dp_= ke?ie=3DUTF8&m=3DAG56TWVU5XWC2&qid=3D1277236054&sr=3D8-1</a><br= > > -- Dick<br> ><br> > On Tue, Jun 22, 2010 at 12:20 PM, David Recordon <<a href=3D"mailto= :recordond@gmail.com">recordond@gmail.com</a>><br> > wrote:<br> >><br> >> All of the OAuth 1.0 implementations which I'm aware of either= have<br> >> the server provide a shared secret to the client or the client upl= oad<br> >> their public key to the server.<br> >><br> >> In the case of the server providing a shared secret to the client,= <br> >> what would the value of key_id be?<br> >><br> >> In the case of a client uploading their public key to the server, = what<br> >> would the value of key_id be?<br> >><br> >> Thanks,<br> >> --David<br> >><br> >><br> >> On Tue, Jun 22, 2010 at 12:14 PM, Dick Hardt <<a href=3D"mailto= :dick.hardt@gmail.com">dick.hardt@gmail.com</a>> wrote:<br> >> > I could imagine an architecture striving to be efficient, sca= lable,<br> >> > distributed and secure where there are hundreds of servers ea= ch with a<br> >> > unique private key baked into each server. All the public key= s would be<br> >> > in<br> >> > one file.<br> >> > Having a key id would help debugging as well as the signer is= clearly<br> >> > indicating which key should be used. If the signing fails, it= could be<br> >> > the<br> >> > key, could be signature calculation, could be ...<br> >> ><br> >> > The downside of having a key_id seems heavily=A0outweighed=A0= by the<br> >> > advantages<br> >> > to me.<br> >> > On Tue, Jun 22, 2010 at 10:30 AM, Anthony Nadalin<br> >> > <<a href=3D"mailto:tonynad@microsoft.com">tonynad@microsof= t.com</a>><br> >> > wrote:<br> >> >><br> >> >> > If a server needs to verify, it can literally iterat= e over all of the<br> >> >> > keys associated with the client until it finds the r= ight one.<br> >> >><br> >> >> Depends on how the server stored the keys, this can be a = very expensive<br> >> >> operation w/o a key_id to match/index on<br> >> >><br> >> >> -----Original Message-----<br> >> >> From: <a href=3D"mailto:oauth-bounces@ietf.org">oauth-bou= nces@ietf.org</a> [mailto:<a href=3D"mailto:oauth-bounces@ietf.org">oauth-b= ounces@ietf.org</a>] On Behalf<br> >> >> Of<br> >> >> Brian Eaton<br> >> >> Sent: Tuesday, June 22, 2010 9:43 AM<br> >> >> To: Dick Hardt; <a href=3D"mailto:Hannes.Tschofenig@gmx.n= et">Hannes.Tschofenig@gmx.net</a><br> >> >> Cc: OAuth WG<br> >> >> Subject: Re: [OAUTH-WG] proposal for signatures<br> >> >><br> >> >> On Tue, Jun 22, 2010 at 7:17 AM, Dick Hardt <<a href= =3D"mailto:dick.hardt@gmail.com">dick.hardt@gmail.com</a>><br> >> >> wrote:<br> >> >> >> Thanks for writing this. A few questions...<br> >> >> >><br> >> >> >> Do we need both `issuer` and `key_id`? Shouldn&#= 39;t we use `client_id`<br> >> >> >> instead at least for OAuth?<br> >> >> ><br> >> >> > it is the ID of the key, not the client -- used to r= ollover keys<br> >> >><br> >> >> I don't think key id is necessary, but adding Hannes = since he called me<br> >> >> crazy for saying that at IIW. =3D)<br> >> >><br> >> >> The average client is going to have very few keys. =A0Pro= bably just 1.<br> >> >> 3 at the outside.<br> >> >><br> >> >> If a server needs to verify, it can literally iterate ove= r all of the<br> >> >> keys<br> >> >> associated with the client until it finds the right one.<= br> >> >><br> >> >> There is some precedent for this approach:<br> >> >> <a href=3D"http://support.microsoft.com/kb/906305/en-us" = target=3D"_blank">http://support.microsoft.com/kb/906305/en-us</a>.<br> >> >><br> >> >> Cheers,<br> >> >> Brian<br> >> >> _______________________________________________<br> >> >> OAuth mailing list<br> >> >> <a href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a><br> >> >> <a href=3D"https://www.ietf.org/mailman/listinfo/oauth" t= arget=3D"_blank">https://www.ietf.org/mailman/listinfo/oauth</a><br> >> >><br> >> ><br> >> ><br> >> > _______________________________________________<br> >> > OAuth mailing list<br> >> > <a href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a><br> >> > <a href=3D"https://www.ietf.org/mailman/listinfo/oauth" targe= t=3D"_blank">https://www.ietf.org/mailman/listinfo/oauth</a><br> >> ><br> >> ><br> ><br> ><br> _______________________________________________<br> OAuth mailing list<br> <a href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_blank">h= ttps://www.ietf.org/mailman/listinfo/oauth</a><br> </div></div></blockquote></div><br></div> --001636d3425521f9930489ac7e2a-- From lshepard@facebook.com Wed Jun 23 00:37:20 2010 Return-Path: <lshepard@facebook.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 186193A6A40 for <oauth@core3.amsl.com>; Wed, 23 Jun 2010 00:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.563 X-Spam-Level: X-Spam-Status: No, score=-0.563 tagged_above=-999 required=5 tests=[AWL=-0.762, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EOW2Hnb6cYxH for <oauth@core3.amsl.com>; Wed, 23 Jun 2010 00:37:18 -0700 (PDT) Received: from mx-out.facebook.com (outmail021.snc1.tfbnw.net [69.63.178.180]) by core3.amsl.com (Postfix) with ESMTP id 8B7613A67C0 for <oauth@ietf.org>; Wed, 23 Jun 2010 00:37:18 -0700 (PDT) Received: from [10.18.255.134] ([10.18.255.134:54013] helo=mail.thefacebook.com) by mta011.snc1.facebook.com (envelope-from <lshepard@facebook.com>) (ecelerity 2.2.2.45 r(34067)) with ESMTP id D3/81-30982-6B9B12C4; Wed, 23 Jun 2010 00:37:26 -0700 Received: from sc-hub05.TheFacebook.com (192.168.18.82) by sc-hub04.TheFacebook.com (192.168.18.212) with Microsoft SMTP Server (TLS) id 14.0.694.1; Wed, 23 Jun 2010 00:37:26 -0700 Received: from SC-MBXC1.TheFacebook.com ([192.168.18.100]) by sc-hub05.TheFacebook.com ([192.168.18.82]) with mapi; Wed, 23 Jun 2010 00:37:25 -0700 From: Luke Shepard <lshepard@facebook.com> To: Luke Shepard <lshepard@facebook.com> Date: Wed, 23 Jun 2010 00:37:24 -0700 Thread-Topic: [OAUTH-WG] native app support (was: Next draft) Thread-Index: AcsSpux3AcwTsZR4R5CILuvGMUe6Cg== Message-ID: <29F569B4-C107-4204-9790-44FCE1364CB5@facebook.com> References: <AANLkTikkG3T_DYKhjMbyYayi7SzZel3RJXFSguxq7SSZ@mail.gmail.com> <AANLkTilycD2urJZqbP8HaRcqUQ6bM30WAzy4c4VOmLql@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3EC8419E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTinj6wsniocBB45Ul0P5WNsAjktz-p0antXpkyUX@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3EC841C2@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTilM3NSD0BLQk5rz5UWxsudTHSBmMbDcwmcztcVb@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3EC841C8@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTimykXBFhoAW4A3CY_GEc-v3I21SvKGKP08MjsX3@mail.gmail.com> <39DE4E99-6DB3-4FBA-B78C-B2AB2B162221@facebook.com> In-Reply-To: <39DE4E99-6DB3-4FBA-B78C-B2AB2B162221@facebook.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 \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] native app support (was: Next draft) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 23 Jun 2010 07:37:20 -0000 One more question - is the <title> technique used in production? I think yo= u'd mentioned that it was ... if so, can you point me to the docs where it'= s currently used? On Jun 22, 2010, at 11:00 PM, Luke Shepard wrote: > Two points: >=20 > 1/ I agree that it can be onerous for clients to host web pages. It's not= a matter of expense but of complexity. >=20 > BUT >=20 > 2/ As we discussed previously in our in-person meeting, this should be ha= ndled by a different endpoint, and not be the responsibility for the provid= er. If Google wishes to support this for their desktop apps, then it should= provide an endpoint that handles the OAuth response and puts it in the <ti= tle>. I can say that Facebook has no interest in supporting this hack on th= e server side, but clients that want it can use their own html file that do= es it for them. >=20 > For example, for Javascript web apps it is a pain to host a cross-domain = receiver file. So we host one on behalf of developers (called xd_proxy.php)= . But it is not part of our server-side logic. >=20 > If you want to write a spec for that, then great, but the <title> hack do= es not belong in the main spec. >=20 > On Jun 22, 2010, at 4:30 PM, Marius Scurtescu wrote: >=20 >> On Tue, Jun 22, 2010 at 4:26 PM, Eran Hammer-Lahav <eran@hueniverse.com>= wrote: >>> In that case, I suggest an extension. But I just don't think this needs= it. Why involve the server at all in this? The client should just host a w= eb page somewhere with the format it wants or the language for the user. >>>=20 >>> With $10 hosting, every client can host a web page somewhere. >>=20 >> Hard to tell, you could be right. Keep in mind that this page has to >> be reliable and secure, $10 will probably not give you that. An authz >> server can easily provide all this at almost no cost. >>=20 >> Marius >>=20 >>>=20 >>> EHL >>>=20 >>>> -----Original Message----- >>>> From: Marius Scurtescu [mailto:mscurtescu@google.com] >>>> Sent: Tuesday, June 22, 2010 4:17 PM >>>> To: Eran Hammer-Lahav >>>> Cc: OAuth WG (oauth@ietf.org) >>>> Subject: Re: native app support (was: Next draft) >>>>=20 >>>> On Tue, Jun 22, 2010 at 4:07 PM, Eran Hammer-Lahav >>>> <eran@hueniverse.com> wrote: >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Marius Scurtescu [mailto:mscurtescu@google.com] >>>>>> Sent: Tuesday, June 22, 2010 3:35 PM >>>>>> To: Eran Hammer-Lahav >>>>>> Cc: OAuth WG (oauth@ietf.org) >>>>>> Subject: Re: native app support (was: Next draft) >>>>>>=20 >>>>>> On Tue, Jun 22, 2010 at 3:14 PM, Eran Hammer-Lahav >>>>>> <eran@hueniverse.com> wrote: >>>>>>> In OAuth 1.0a, we needed it for the patch. I don't think this needs >>>>>>> to be in >>>>>> the spec because it doesn't help interop. If the server supports suc= h >>>>>> a scheme, it should document it. It also falls under "previously >>>>>> established redirection URI" which happens to point at the server. >>>>>>=20 >>>>>> OK, that makes sense. >>>>>>=20 >>>>>> What about: >>>>>>> Also, this page should put the verification code and the client >>>>>>> state (code and state) in the page title in a standard way such >>>>>>> that the native app can extract them from the window title. WRAP >>>>>>> defined how the title should be formed. >>>>>>=20 >>>>>> Extension? >>>>>=20 >>>>> I don't think this needs a spec. Just something provided by the serve= r. Does >>>> the client need any special handling? It can always just use a static = web page >>>> to do this, no? >>>>=20 >>>> A spec would help so all servers provide code and state in a consisten= t >>>> format. Client libraries can then provide methods to parse this. Also,= client >>>> apps connecting to multiple servers can expect some consistency. >>>>=20 >>>> Marius >>>>=20 >>>>>=20 >>>>> EHL >>>>>=20 >>>>>>=20 >>>>>> Marius >>>>>>=20 >>>>>>>=20 >>>>>>> EHL >>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: Marius Scurtescu [mailto:mscurtescu@google.com] >>>>>>>> Sent: Tuesday, June 22, 2010 1:02 PM >>>>>>>> To: Eran Hammer-Lahav >>>>>>>> Cc: OAuth WG (oauth@ietf.org) >>>>>>>> Subject: Re: native app support (was: Next draft) >>>>>>>>=20 >>>>>>>> On Tue, Jun 8, 2010 at 10:46 AM, Marius Scurtescu >>>>>>>> <mscurtescu@google.com> wrote: >>>>>>>>> In order to properly support native applications I suggest the >>>>>>>>> following changes: >>>>>>>>> [...] >>>>>>>>> 2. optional redirect_uri (default result page) >>>>>>>>>=20 >>>>>>>>> Some native apps do not have a redirect_uri, as a result two >>>>>>>>> things are >>>>>>>> needed: >>>>>>>>>=20 >>>>>>>>> 2.1 Either make redirect_uri optional or define a standard value >>>>>>>>> that signals that the client does not have such a page. >>>>>>>>>=20 >>>>>>>>> 2.2 The authz server must supply a default result page, if there >>>>>>>>> is no redirect_uri. Also, this page should put the verification >>>>>>>>> code and the client state (code and state) in the page title in >>>>>>>>> a standard way such that the native app can extract them from >>>>>>>>> the window title. WRAP defined how the title should be formed. >>>>>>>>=20 >>>>>>>> Should this also go to an extension? It is not introducing any new >>>>>>>> parameters, not sure if it belongs there. OAuth 1 at least defined >>>>>>>> the >>>>>> "oob" special value. >>>>>>>>=20 >>>>>>>> Marius >>>>>>>=20 >>>>>=20 >>>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From benl@google.com Wed Jun 23 02:56:35 2010 Return-Path: <benl@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B57C3A67B7 for <oauth@core3.amsl.com>; Wed, 23 Jun 2010 02:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.777 X-Spam-Level: X-Spam-Status: No, score=-105.777 tagged_above=-999 required=5 tests=[AWL=0.200, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y0uprVkbps1z for <oauth@core3.amsl.com>; Wed, 23 Jun 2010 02:56:34 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 21DF83A696A for <oauth@ietf.org>; Wed, 23 Jun 2010 02:56:34 -0700 (PDT) Received: from kpbe18.cbf.corp.google.com (kpbe18.cbf.corp.google.com [172.25.105.82]) by smtp-out.google.com with ESMTP id o5N9ufjY003869 for <oauth@ietf.org>; Wed, 23 Jun 2010 02:56:41 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1277287001; bh=luj/T1HmO8byZzELBGzYQtVwwns=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=c/cQ+1Y1BfRvyHKuHDgH3DSZsuVlleFM3Je8kTon9ouS5NkQ9r78EOPdBxVddGWeC EbirZFP723NMwo7tW2bVg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=mp3ue9spmKrlSTxaLQ3b36AE/s2+BWSOXIRLz5MxsjInPybLJHnas34WUVYB7El4R JCtuiZv3eZ+U83xtHVYgQ== Received: from vws1 (vws1.prod.google.com [10.241.21.129]) by kpbe18.cbf.corp.google.com with ESMTP id o5N9udOp004638 for <oauth@ietf.org>; Wed, 23 Jun 2010 02:56:40 -0700 Received: by vws1 with SMTP id 1so624885vws.22 for <oauth@ietf.org>; Wed, 23 Jun 2010 02:56:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.80.96 with SMTP id s32mr3829859vck.197.1277286996522; Wed, 23 Jun 2010 02:56:36 -0700 (PDT) Received: by 10.220.57.205 with HTTP; Wed, 23 Jun 2010 02:56:36 -0700 (PDT) In-Reply-To: <AANLkTilRUQiD5oRyxUZXmPs2skCY8zAmc1Vl--8pEblS@mail.gmail.com> References: <AANLkTingCgO-o3XRZbxYoD8U2rRTO-EgWcfg2hBlbQHm@mail.gmail.com> <AANLkTinZ1XIFO25mcgoiDV-V0Blvv8ZC6kV_F3fca3dC@mail.gmail.com> <4C5BCAC6-713F-4C42-8696-2931D1AB3199@gmail.com> <AANLkTinlATNBEQsmFJIxv_cgqfI_tsoGfTMy6OXN6F_B@mail.gmail.com> <A08279DC79B11C48AD587060CD9397712735068D@TK5EX14MBXC101.redmond.corp.microsoft.com> <AANLkTimLrZzwDW9rMtGjD9k6ZtXc_oDXIIIYWOMw-NCi@mail.gmail.com> <AANLkTilcn_qQLgriJEdPk95f2Zliyk0QXGvU6t77Aa7G@mail.gmail.com> <AANLkTinEjidY_HmcGHPTus7P1snjCl9DPL4dX-Sz_mTQ@mail.gmail.com> <AANLkTilRUQiD5oRyxUZXmPs2skCY8zAmc1Vl--8pEblS@mail.gmail.com> Date: Wed, 23 Jun 2010 10:56:36 +0100 Message-ID: <AANLkTilAjh9Jl0__9jksh3eY7giVR6Wtr0NYNoFfYHZX@mail.gmail.com> From: Ben Laurie <benl@google.com> To: David Recordon <recordond@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "Hannes.Tschofenig@gmx.net" <Hannes.Tschofenig@gmx.net>, OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] proposal for signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 23 Jun 2010 09:56:35 -0000 On 22 June 2010 21:45, David Recordon <recordond@gmail.com> wrote: > Hey Dick, in answering my questions you made my point. If keys are > managed out of band =96=A0as is done in OAuth 1.0 and what was done in th= e > OAuth 2.0 Core spec until signatures were extracted =96=A0then having a > key id is not needed. I certainly understand what they're used for, > but don't find them relevant as part of the OAuth conversation today. I don't understand why they are unnecessary no matter how keys are managed: if there's ever a possibility that you might have more than one key for someone, then key IDs are a useful optimisation. Put it another way: what's the purpose of leaving out the key ID? > And yes, Applied Cryptography is worth reading. :) > > --David > > > On Tue, Jun 22, 2010 at 12:59 PM, Dick Hardt <dick.hardt@gmail.com> wrote= : >> David >> key_ids are used when you need to identify which key to use of all the k= eys >> you might have. If you are doing discovery of document that is bound to = the >> identifier of the signer, this is useful. Since OAuth 1.0 did not have >> discovery and required an out of band key management process, key_ids ha= ve >> little value. >> To answer your question, key_ids dont' make sense if the keys are being >> managed how you describe them. I would suggest that key_ids are not incl= uded >> if public keys are managed=A0independent=A0from how Dirk had described t= hem be >> discovered. >> I don't think key_ids make sense for shared secrets as they inherently h= ave >> an out of band process for sharing them. >> If you would like to learn more about cryptography, I have found Bruce >> Schneier's book Applied Cryptography to be pretty educational. Here is a >> link to the Kindle version: >> http://www.amazon.com/Applied-Cryptography-Protocols-Algorithms-ebook/dp= /B000SEHPK6/ref=3Dkinw_dp_ke?ie=3DUTF8&m=3DAG56TWVU5XWC2&qid=3D1277236054&s= r=3D8-1 >> -- Dick >> >> On Tue, Jun 22, 2010 at 12:20 PM, David Recordon <recordond@gmail.com> >> wrote: >>> >>> All of the OAuth 1.0 implementations which I'm aware of either have >>> the server provide a shared secret to the client or the client upload >>> their public key to the server. >>> >>> In the case of the server providing a shared secret to the client, >>> what would the value of key_id be? >>> >>> In the case of a client uploading their public key to the server, what >>> would the value of key_id be? >>> >>> Thanks, >>> --David >>> >>> >>> On Tue, Jun 22, 2010 at 12:14 PM, Dick Hardt <dick.hardt@gmail.com> wro= te: >>> > I could imagine an architecture striving to be efficient, scalable, >>> > distributed and secure where there are hundreds of servers each with = a >>> > unique private key baked into each server. All the public keys would = be >>> > in >>> > one file. >>> > Having a key id would help debugging as well as the signer is clearly >>> > indicating which key should be used. If the signing fails, it could b= e >>> > the >>> > key, could be signature calculation, could be ... >>> > >>> > The downside of having a key_id seems heavily=A0outweighed=A0by the >>> > advantages >>> > to me. >>> > On Tue, Jun 22, 2010 at 10:30 AM, Anthony Nadalin >>> > <tonynad@microsoft.com> >>> > wrote: >>> >> >>> >> > If a server needs to verify, it can literally iterate over all of = the >>> >> > keys associated with the client until it finds the right one. >>> >> >>> >> Depends on how the server stored the keys, this can be a very expens= ive >>> >> operation w/o a key_id to match/index on >>> >> >>> >> -----Original Message----- >>> >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Beha= lf >>> >> Of >>> >> Brian Eaton >>> >> Sent: Tuesday, June 22, 2010 9:43 AM >>> >> To: Dick Hardt; Hannes.Tschofenig@gmx.net >>> >> Cc: OAuth WG >>> >> Subject: Re: [OAUTH-WG] proposal for signatures >>> >> >>> >> On Tue, Jun 22, 2010 at 7:17 AM, Dick Hardt <dick.hardt@gmail.com> >>> >> wrote: >>> >> >> Thanks for writing this. A few questions... >>> >> >> >>> >> >> Do we need both `issuer` and `key_id`? Shouldn't we use `client_i= d` >>> >> >> instead at least for OAuth? >>> >> > >>> >> > it is the ID of the key, not the client -- used to rollover keys >>> >> >>> >> I don't think key id is necessary, but adding Hannes since he called= me >>> >> crazy for saying that at IIW. =3D) >>> >> >>> >> The average client is going to have very few keys. =A0Probably just = 1. >>> >> 3 at the outside. >>> >> >>> >> If a server needs to verify, it can literally iterate over all of th= e >>> >> keys >>> >> associated with the client until it finds the right one. >>> >> >>> >> There is some precedent for this approach: >>> >> http://support.microsoft.com/kb/906305/en-us. >>> >> >>> >> Cheers, >>> >> Brian >>> >> _______________________________________________ >>> >> OAuth mailing list >>> >> OAuth@ietf.org >>> >> https://www.ietf.org/mailman/listinfo/oauth >>> >> >>> > >>> > >>> > _______________________________________________ >>> > OAuth mailing list >>> > OAuth@ietf.org >>> > https://www.ietf.org/mailman/listinfo/oauth >>> > >>> > >> >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From dick.hardt@gmail.com Wed Jun 23 09:02:26 2010 Return-Path: <dick.hardt@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 223F83A6874 for <oauth@core3.amsl.com>; Wed, 23 Jun 2010 09:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.433 X-Spam-Level: X-Spam-Status: No, score=-2.433 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mq0e5hC1Gon6 for <oauth@core3.amsl.com>; Wed, 23 Jun 2010 09:02:25 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 41A5B3A682E for <oauth@ietf.org>; Wed, 23 Jun 2010 09:02:25 -0700 (PDT) Received: by pvc21 with SMTP id 21so310154pvc.31 for <oauth@ietf.org>; Wed, 23 Jun 2010 09:02:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=voUetqjIcG13pf34hPm9EWSQYXsdf3zzQMM78gnSPDM=; b=RxsUrPhv0OemoQr45rp7SyQTXsQKGa1XihZjo63ylnEhh5iM5yScYjMlogAB490dNX lH1tf2n5ht0BrRQcEmitI4IYSQ9kzC+2oGvVZW16RK8NdpaNAWyGaWx4NK0viaPJd3Ak rF5tg3QAIiZ74JSKO0+AWwALSFNbrgpNtm79g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=WUrX5+3P2FTIq13qj/ox4ACxgXdaXa310y4J0ExLYueDw+HsuD9wzWHZvSiWgC1mOb yDGWumGpid+c+idBrpusF2qnEfpXwZo8YS75PL64N+B8prwVad/qgHcaL+4AQiftttCH 8X02/2vI5wmDYoQj4UhhiWuOlG/yOdj9Jp3tY= Received: by 10.115.114.34 with SMTP id r34mr7842795wam.64.1277308950635; Wed, 23 Jun 2010 09:02:30 -0700 (PDT) Received: from [192.168.1.5] (c-24-130-32-55.hsd1.ca.comcast.net [24.130.32.55]) by mx.google.com with ESMTPS id c14sm71659505waa.1.2010.06.23.09.02.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 23 Jun 2010 09:02:29 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Dick Hardt <dick.hardt@gmail.com> In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B4502BE07CC@FIESEXC015.nsn-intra.net> Date: Wed, 23 Jun 2010 09:02:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <E7A7F197-3BBC-43F2-8242-D0164057A39A@gmail.com> References: <3D3C75174CB95F42AD6BCC56E5555B4502BE07CC@FIESEXC015.nsn-intra.net> To: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com> X-Mailer: Apple Mail (2.1081) Cc: OAuth WG <oauth@ietf.org> Subject: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 23 Jun 2010 16:02:26 -0000 On 2010-06-22, at 11:07 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > " > scope > OPTIONAL. The scope of the access request expressed as a list > of space-delimited strings. The value of the "scope" = parameter > is defined by the authorization server. If the value contains > multiple space-delimited strings, their order does not matter, > and each string adds an additional access range to the > requested scope. > " >=20 > Do folks think it would be useful to have standardized values?=20 Not at this time. The semantics of scope are all over the place. If = standardized, people will feel they need to pick one that is close to = what they want, but is not exactly what they mean. I think it is better = for the AS to define what they mean by a scope and give it a name that = makes sense in that context. >=20 > If the answer is "yes", then it would be useful to differentiate the > standardized values from those values that are purely defined locally = by > the authorization server.=20 From yarong@microsoft.com Wed Jun 23 11:00:18 2010 Return-Path: <yarong@microsoft.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B96393A6AED for <oauth@core3.amsl.com>; Wed, 23 Jun 2010 11:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.999 X-Spam-Level: X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7RLIbthUdeIL for <oauth@core3.amsl.com>; Wed, 23 Jun 2010 11:00:17 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 80D853A6AEC for <oauth@ietf.org>; Wed, 23 Jun 2010 11:00:17 -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; Wed, 23 Jun 2010 11:00:24 -0700 Received: from TK5EX14MBXC117.redmond.corp.microsoft.com ([169.254.8.23]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.01.0160.007; Wed, 23 Jun 2010 11:00:24 -0700 From: Yaron Goland <yarong@microsoft.com> To: Eran Hammer-Lahav <eran@hueniverse.com>, "Manger, James H" <James.H.Manger@team.telstra.com>, "OAuth WG (oauth@ietf.org)" <oauth@ietf.org> Thread-Topic: OAuth discovery draft? Thread-Index: AQHLEbd88ANnc80E8EanM4mdFaHtZpKN3qcAgAH2zrA= Date: Wed, 23 Jun 2010 18:00:21 +0000 Message-ID: <7C01E631FF4B654FA1E783F1C0265F8C579C6DC3@TK5EX14MBXC117.redmond.corp.microsoft.com> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB68D9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1126427308C@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343B3EC83F46@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EC83F46@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [OAUTH-WG] OAuth discovery draft? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 23 Jun 2010 18:00:18 -0000 SSd2ZSBiZWVuIG5vb2RsaW5nIFsxXSBhIGxvdCBhYm91dCBmdWxsIGRlbGVnYXRpb24gaW4gT0F1 dGggWzJdIGFuZCBvbmUgb2YgdGhlIGlzc3VlcyB0aGF0IGNhbWUgb3V0IG9mIHRoYXQgd2FzIHRo ZSBuZWVkIGZvciBkaXNjb3ZlcmluZyBib3RoIHRoZSBsb2NhdGlvbiBhbmQgcmVhbG0gb2YgYW4g ZW5kcG9pbnQncyB0b2tlbiBzZXJ2ZXIuIEJ1dCBhdCBsZWFzdCBmb3IgbXkgdXNlIGNhc2VzICh3 aGljaCBjb25zaXN0IG9mIHdhbGtpbmcgdXAgdG8gYSBzZXJ2aWNlIGFuZCBtYWtpbmcgYW4gb3B0 aW9ucyByZXF1ZXN0IGFuZCBnZXR0aW5nIGJhY2sgYSB3d3ctYXV0aGVudGljYXRlIGhlYWRlcikg YWxsIEkgbmVlZCBiYWNrIGlzIGEgcmVhbG0gYW5kIGEgdG9rZW4gc2VydmVyIFVSTC4gSW4gb3Ro ZXIgd29yZHMganVzdCBoYXZpbmcgb25lIGFyZ3VtZW50IGFkZGVkIHRvIG91ciB3d3ctYXV0aGVu dGljYXRlIGhlYWRlciB3b3VsZCBiZSBlbm91Z2ggdG8gc29sdmUgdGhlIGNhc2Ugd2hlcmUgc29t ZW9uZSB3YW50cyB0byB3YWxrIHVwIHRvIGEgc2VydmljZSBhbmQgZmluZCBvdXQgd2hlcmUgaXRz IHRva2VuIHNlcnZlciBpcy4gRG9lcyB0aGF0IHJlYWxseSBuZWVkIGl0cyBvd24gc3BlYz8gT3Ig Y2FuIHdlIGp1c3QgYWRkIGFuIGFyZ3VtZW50IHRvIHd3dy1hdXRoZW50aWNhdGUgaW4gdGhlIGN1 cnJlbnQgc3BlYz8NCglUaGFua3MsDQoJCVlhcm9uDQoNClsxXSBTZWUgaHR0cDovL3d3dy5nb2xh bmQub3JnL29hdXRoZ2VuZXJpY2RlbGVnYXRpb24vIGZvciBhbiBvdmVydmlldyBvZiBteSB0aGlu a2luZyBvbiBmdWxsIGRlbGVnYXRpb24gaW4gT0F1dGguIEF0IHRoZSB2ZXJ5IGVuZCBhcmUgbGlu a3MgdG8gYSBidW5jaCBvZiBvdGhlciBtdWNoIG1vcmUgaW4tZGVwdGggYXJ0aWNsZXMgb24gcGFy dGljdWxhciBzdWJqZWN0cyB0b3VjaGVkIG9uIGluIHRoZSBtYWluIGFydGljbGUuDQoNClsyXSBJ IGRlZmluZSAnZnVsbCBkZWxlZ2F0aW9uJyBhcyAiVXNlciBYIG9mIFNlcnZpY2UgWSBncmFudHMg cGVybWlzc2lvbiBaIHRvIFVzZXIgQSBvZiBTZXJ2aWNlIEIiLiBDdXJyZW50bHkgT0F1dGggcmVx dWlyZXMgWCA9PSBBLiBJbiB0aGUgZnV0dXJlIEkgaG9wZSB0byBzZWUgZXh0ZW5zaW9ucyB0byBP QXV0aCB0aGF0IGVuYWJsZSB3aGF0IEknbSB0ZXJtaW5nICdmdWxsIGRlbGVnYXRpb24nLiBCdXQg cGVyc29uYWxseSBJJ20gcmVhbGx5IGhhcHB5IHRoYXQgT0F1dGggaGFzIHRoZSBYPT1BIHJlc3Ry aWN0aW9uLiBJdCBzaW1wbGlmaWVzIGEgd2hvbGUgaG9zdCBvZiBpc3N1ZXMgYW5kIHNhdGlzZmll cyBhIHJlYWxseSBpbXBvcnRhbnQgdXNlIGNhc2UuDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gRnJvbTogb2F1dGgtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm9hdXRoLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KPiBPZiBFcmFuIEhhbW1lci1MYWhhdg0KPiBTZW50OiBN b25kYXksIEp1bmUgMjEsIDIwMTAgOTo1MCBQTQ0KPiBUbzogTWFuZ2VyLCBKYW1lcyBIOyBPQXV0 aCBXRyAob2F1dGhAaWV0Zi5vcmcpDQo+IFN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE9BdXRoIGRp c2NvdmVyeSBkcmFmdD8NCj4gDQo+IFllcywgaXQncyBvbiBteSBkZXNrIGFuZCBub3QgeWV0IHJl YWR5LCBidXQgSSBhbSB3b3JraW5nIG9uIG9uZS4gSXQgaW5jbHVkZXMNCj4geW91ciBzaXRlcyBw cm9wb3NhbCBhbW9uZyBvdGhlciB0aGluZ3MuIEkgYW0gdHJ5aW5nIHRvIGdldCB0aGUgY29yZSBz cGVjDQo+IHN0YWJsZSB0aGlzIHdlZWsgYW5kIGZvY3VzIG9uIHRoYXQgbmV4dC4NCj4gDQo+IEVI TA0KPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IE1hbmdlciwg SmFtZXMgSCBbbWFpbHRvOkphbWVzLkguTWFuZ2VyQHRlYW0udGVsc3RyYS5jb21dDQo+ID4gU2Vu dDogTW9uZGF5LCBKdW5lIDIxLCAyMDEwIDg6MDMgUE0NCj4gPiBUbzogRXJhbiBIYW1tZXItTGFo YXY7IE9BdXRoIFdHIChvYXV0aEBpZXRmLm9yZykNCj4gPiBTdWJqZWN0OiBPQXV0aCBkaXNjb3Zl cnkgZHJhZnQ/DQo+ID4NCj4gPiBFcmFuLA0KPiA+DQo+ID4gVGhlcmUgaGF2ZSBiZWVuIGEgZmV3 IG1lbnRpb25zIHJlY2VudGx5IG9mIGFuIE9BdXRoIGRpc2NvdmVyeSBkcmFmdC4NCj4gPiBJcyB0 aGVyZSBhbnkgc3VjaCBkcmFmdCB5ZXQsIG9yIGlzIHRoaXMganVzdCBhIHBhcnQgdGhhdCB3ZSBr bm93IG5lZWRzDQo+ID4gdG8gYmUgZG9uZT8NCj4gPg0KPiA+IFRoZSBlbWFpbCBvbiAiT0F1dGgg bWVldGluZyBub3RlcyBvbiAtMDUgKHdpdGggdXBkYXRlcykiIHNhaWQ6DQo+ID4NCj4gPiA+PiA2 LjEuMS4gLSBkZXNjcmliaW5nIHRoZSBXV1ctQXV0aGVudGljYXRlIHJlc3BvbnNlIGhlYWRlcg0K PiA+ID4+DQo+ID4gPj4gLSBEaXNjb3ZlcnkgbmVlZGVkIGZvciB2YXJpb3VzIGVsZW1lbnRzDQo+ ID4gPg0KPiA+ID4gWWVzLiBUaGF0J3MgZm9yIHRoZSBkaXNjb3ZlcnkgZHJhZnQuDQo+ID4NCj4g Pg0KPiA+IEEgd2lraSBwYWdlIG9uICJGdXR1cmUgT3BlbklEIFRlY2huaWNhbCBSZXF1aXJlbWVu dHMiDQo+ID4gPGh0dHA6Ly93aWtpLm9wZW5pZC5uZXQvRnV0dXJlLU9wZW5JRC1UZWNobmljYWwt UmVxdWlyZW1lbnRzPiBzYXlzOg0KPiA+DQo+ID4gPiA2KSBJZFAgRGlzY292ZXJ5DQo+ID4gPg0K PiA+ID4gICAgKiBNdWNoIG9mIHRoaXMgd2lsbCBiZSBjb3ZlcmVkIGJ5IE9BdXRoMiBEaXNjb3Zl cnksDQo+ID4gPiAgICAgIGhvd2V2ZXIgT0lDIG1heSBuZWVkIHRvIGRlZmluZSBPcGVuSUQgc3Bl Y2lmaWMgZmVhdHVyZXMuDQo+ID4gPuKApg0KPiA+ID4gMTcpIFNpbXBsZXIgZGlzY292ZXJ5DQo+ ID4gPg0KPiA+ID4gICAgKiBTZWUgRXJhbidzIE9BdXRoIERpc2NvdmVyeSBwcm9wb3NhbA0KPiA+ DQo+ID4NCj4gPiBUaGVyZSB3YXMgYW4gT0F1dGggMS4wIERpc2NvdmVyeSBkcmFmdCBvdmVyIDIg eWVhcnMgYWdvLCBidXQgdGhhdCBpcyB0YWdnZWQ6DQo+ID4gImV4cGlyZWQiLCAibWFya2VkIGFz IG9ic29sZXRlIGJ5IGl0cyBhdXRob3IiLCAiZGlzY291cmFnZWQgZnJvbQ0KPiA+IGltcGxlbWVu dGluZyIsICJubyB1cGRhdGUgaXMgZXhwZWN0ZWQiLCAicmVwbGFjZWQgYnkgdGhlIE9BdXRoIDIu MA0KPiBlZmZvcnQiLg0KPiA+DQo+ID4gSSBrbm93IEkgc2hvdWxkIHdyaXRlIGEgZGlzY292ZXJ5 IGRyYWZ0IG15c2VsZi4NCj4gPg0KPiA+IC0tDQo+ID4gSmFtZXMgTWFuZ2VyDQo+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IE9BdXRoIG1haWxpbmcg bGlzdA0KPiBPQXV0aEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL29hdXRoDQo= From eran@hueniverse.com Wed Jun 23 11:04:00 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A0ED3A67EF for <oauth@core3.amsl.com>; Wed, 23 Jun 2010 11:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[AWL=0.379, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ibt+C6iIDCEc for <oauth@core3.amsl.com>; Wed, 23 Jun 2010 11:03:54 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id AA1E228C131 for <oauth@ietf.org>; Wed, 23 Jun 2010 11:03:54 -0700 (PDT) Received: (qmail 27364 invoked from network); 23 Jun 2010 18:04:01 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 23 Jun 2010 18:03:59 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 23 Jun 2010 11:03:54 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: Yaron Goland <yarong@microsoft.com>, James Manger <James.H.Manger@team.telstra.com>, OAuth WG <oauth@ietf.org> Date: Wed, 23 Jun 2010 11:03:48 -0700 Thread-Topic: OAuth discovery draft? Thread-Index: AQHLEbd88ANnc80E8EanM4mdFaHtZpKN3qcAgAH2zrCAAAP3tQ== Message-ID: <C8479A94.363F3%eran@hueniverse.com> In-Reply-To: <7C01E631FF4B654FA1E783F1C0265F8C579C6DC3@TK5EX14MBXC117.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C8479A94363F3eranhueniversecom_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] OAuth discovery draft? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 23 Jun 2010 18:04:00 -0000 --_000_C8479A94363F3eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think the core work is pretty stable now, unlike the discovery bits which= (while simple) are not enjoying the same level of consensus. I think it is= much more practical to propose them as a separate document and perhaps con= sider merging them later on when they reach an equal level of stability. Bu= t overall, I'm not too worries about multiple documents. EHL On 6/23/10 11:00 AM, "Yaron Goland" <yarong@microsoft.com> wrote: I've been noodling [1] a lot about full delegation in OAuth [2] and one of = the issues that came out of that was the need for discovering both the loca= tion and realm of an endpoint's token server. But at least for my use cases= (which consist of walking up to a service and making an options request an= d getting back a www-authenticate header) all I need back is a realm and a = token server URL. In other words just having one argument added to our www-= authenticate header would be enough to solve the case where someone wants t= o walk up to a service and find out where its token server is. Does that re= ally need its own spec? Or can we just add an argument to www-authenticate = in the current spec? Thanks, Yaron [1] See http://www.goland.org/oauthgenericdelegation/ for an overview of my= thinking on full delegation in OAuth. At the very end are links to a bunch= of other much more in-depth articles on particular subjects touched on in = the main article. [2] I define 'full delegation' as "User X of Service Y grants permission Z = to User A of Service B". Currently OAuth requires X =3D=3D A. In the future= I hope to see extensions to OAuth that enable what I'm terming 'full deleg= ation'. But personally I'm really happy that OAuth has the X=3D=3DA restric= tion. It simplifies a whole host of issues and satisfies a really important= use case. > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Eran Hammer-Lahav > Sent: Monday, June 21, 2010 9:50 PM > To: Manger, James H; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] OAuth discovery draft? > > Yes, it's on my desk and not yet ready, but I am working on one. It inclu= des > your sites proposal among other things. I am trying to get the core spec > stable this week and focus on that next. > > EHL > > > -----Original Message----- > > From: Manger, James H [mailto:James.H.Manger@team.telstra.com] > > Sent: Monday, June 21, 2010 8:03 PM > > To: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org) > > Subject: OAuth discovery draft? > > > > Eran, > > > > There have been a few mentions recently of an OAuth discovery draft. > > Is there any such draft yet, or is this just a part that we know needs > > to be done? > > > > The email on "OAuth meeting notes on -05 (with updates)" said: > > > > >> 6.1.1. - describing the WWW-Authenticate response header > > >> > > >> - Discovery needed for various elements > > > > > > Yes. That's for the discovery draft. > > > > > > A wiki page on "Future OpenID Technical Requirements" > > <http://wiki.openid.net/Future-OpenID-Technical-Requirements> says: > > > > > 6) IdP Discovery > > > > > > * Much of this will be covered by OAuth2 Discovery, > > > however OIC may need to define OpenID specific features. > > >... > > > 17) Simpler discovery > > > > > > * See Eran's OAuth Discovery proposal > > > > > > There was an OAuth 1.0 Discovery draft over 2 years ago, but that is ta= gged: > > "expired", "marked as obsolete by its author", "discouraged from > > implementing", "no update is expected", "replaced by the OAuth 2.0 > effort". > > > > I know I should write a discovery draft myself. > > > > -- > > James Manger > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --_000_C8479A94363F3eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <HTML> <HEAD> <TITLE>Re: OAuth discovery draft? I think the core work is pretty stable now, unlike the discovery bits= which (while simple) are not enjoying the same level of consensus. I think= it is much more practical to propose them as a separate document and perha= ps consider merging them later on when they reach an equal level of stabili= ty. But overall, I’m not too worries about multiple documents.

    EHL


    On 6/23/10 11:00 AM, "Yaron Goland" <yarong@microsoft.com> wrote:

    I've been noodling [1] a lot about full del= egation in OAuth [2] and one of the issues that came out of that was the ne= ed for discovering both the location and realm of an endpoint's token serve= r. But at least for my use cases (which consist of walking up to a service = and making an options request and getting back a www-authenticate header) a= ll I need back is a realm and a token server URL. In other words just havin= g one argument added to our www-authenticate header would be enough to solv= e the case where someone wants to walk up to a service and find out where i= ts token server is. Does that really need its own spec? Or can we just add = an argument to www-authenticate in the current spec?
            Thanks,
                &nb= sp;   Yaron

    [1] See http://ww= w.goland.org/oauthgenericdelegation/ for an overview of my thinking on = full delegation in OAuth. At the very end are links to a bunch of other muc= h more in-depth articles on particular subjects touched on in the main arti= cle.

    [2] I define 'full delegation' as "User X of Service Y grants permissi= on Z to User A of Service B". Currently OAuth requires X =3D=3D A. In = the future I hope to see extensions to OAuth that enable what I'm terming '= full delegation'. But personally I'm really happy that OAuth has the X=3D= =3DA restriction. It simplifies a whole host of issues and satisfies a real= ly important use case.

    > -----Original Message-----
    > From: oauth-bounces@ietf.org [<= a href=3D"mailto:oauth-bounces@ietf.org">mailto:oauth-bounces@ietf.org]= On Behalf
    > Of Eran Hammer-Lahav
    > Sent: Monday, June 21, 2010 9:50 PM
    > To: Manger, James H; OAuth WG (oauth@ietf.o= rg)
    > Subject: Re: [OAUTH-WG] OAuth discovery draft?
    >
    > Yes, it's on my desk and not yet ready, but I am working on one. It in= cludes
    > your sites proposal among other things. I am trying to get the core sp= ec
    > stable this week and focus on that next.
    >
    > EHL
    >
    > > -----Original Message-----
    > > From: Manger, James H [mailto:James.H.Manger@team.telstra.com]
    > > Sent: Monday, June 21, 2010 8:03 PM
    > > To: Eran Hammer-Lahav; OAuth WG (oauth= @ietf.org)
    > > Subject: OAuth discovery draft?
    > >
    > > Eran,
    > >
    > > There have been a few mentions recently of an OAuth discovery dra= ft.
    > > Is there any such draft yet, or is this just a part that we know = needs
    > > to be done?
    > >
    > > The email on "OAuth meeting notes on -05 (with updates)"= ; said:
    > >
    > > >> 6.1.1. - describing the WWW-Authenticate response header=
    > > >>
    > > >> - Discovery needed for various elements
    > > >
    > > > Yes. That's for the discovery draft.
    > >
    > >
    > > A wiki page on "Future OpenID Technical Requirements" > > <http://wiki.openid.net/Future-OpenID-Technical-Requirements&= gt; says:
    > >
    > > > 6) IdP Discovery
    > > >
    > > >    * Much of this will be covered by OAuth2 D= iscovery,
    > > >      however OIC may need to define= OpenID specific features.
    > > >…
    > > > 17) Simpler discovery
    > > >
    > > >    * See Eran's OAuth Discovery proposal
    > >
    > >
    > > There was an OAuth 1.0 Discovery draft over 2 years ago, but that= is tagged:
    > > "expired", "marked as obsolete by its author"= , "discouraged from
    > > implementing", "no update is expected", "repl= aced by the OAuth 2.0
    > effort".
    > >
    > > I know I should write a discovery draft myself.
    > >
    > > --
    > > James Manger
    > _______________________________________________
    > OAuth mailing list
    > OAuth@ietf.org
    > https://www.ie= tf.org/mailman/listinfo/oauth

    --_000_C8479A94363F3eranhueniversecom_-- From yarong@microsoft.com Wed Jun 23 11:20:41 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95F4128C154 for ; Wed, 23 Jun 2010 11:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.299 X-Spam-Level: X-Spam-Status: No, score=-9.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQwA6Sye8J9I for ; Wed, 23 Jun 2010 11:20:29 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 0D9EB28C151 for ; Wed, 23 Jun 2010 11:20:28 -0700 (PDT) Received: from TK5EX14CASC131.redmond.corp.microsoft.com (157.54.52.38) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 23 Jun 2010 11:20:31 -0700 Received: from TK5EX14MBXC117.redmond.corp.microsoft.com ([169.254.8.23]) by TK5EX14CASC131.redmond.corp.microsoft.com ([157.54.52.38]) with mapi id 14.01.0160.007; Wed, 23 Jun 2010 11:20:33 -0700 From: Yaron Goland To: Eran Hammer-Lahav , James Manger , OAuth WG Thread-Topic: OAuth discovery draft? Thread-Index: AQHLEbd88ANnc80E8EanM4mdFaHtZpKN3qcAgAH2zrCAAAP3tYAAAdRg Date: Wed, 23 Jun 2010 18:20:27 +0000 Message-ID: <7C01E631FF4B654FA1E783F1C0265F8C579C6E52@TK5EX14MBXC117.redmond.corp.microsoft.com> References: <7C01E631FF4B654FA1E783F1C0265F8C579C6DC3@TK5EX14MBXC117.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7C01E631FF4B654FA1E783F1C0265F8C579C6E52TK5EX14MBXC117r_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] OAuth discovery draft? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 18:20:42 -0000 --_000_7C01E631FF4B654FA1E783F1C0265F8C579C6E52TK5EX14MBXC117r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable No objections on my part. I would rather have a smaller core spec with feat= ures that everyone agrees on. BTW, a thought for the discovery draft - RFC 2616/2617 only defines www-aut= henticate's semantics in the context of a 401. It's unclear from the draft = what it would mean to return a www-authenticate header on a 200 response. T= he reason I care about this is that I think it makes sense that if someone = wants to talk to an endpoint they know supports OAuth and need to know wher= e their token issuer location is they would want to fire off an OPTIONS req= uest to the resource and find out from the response where the issuer is and= what realm is being used. It seems to me that the simplest way to solve th= is problem is to just return www-authenticate on a 200 response to an OPTIO= NS request. Thoughts? Thanks, Yaron From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Wednesday, June 23, 2010 11:04 AM To: Yaron Goland; James Manger; OAuth WG Subject: Re: OAuth discovery draft? I think the core work is pretty stable now, unlike the discovery bits which= (while simple) are not enjoying the same level of consensus. I think it is= much more practical to propose them as a separate document and perhaps con= sider merging them later on when they reach an equal level of stability. Bu= t overall, I'm not too worries about multiple documents. EHL On 6/23/10 11:00 AM, "Yaron Goland" wrote: I've been noodling [1] a lot about full delegation in OAuth [2] and one of = the issues that came out of that was the need for discovering both the loca= tion and realm of an endpoint's token server. But at least for my use cases= (which consist of walking up to a service and making an options request an= d getting back a www-authenticate header) all I need back is a realm and a = token server URL. In other words just having one argument added to our www-= authenticate header would be enough to solve the case where someone wants t= o walk up to a service and find out where its token server is. Does that re= ally need its own spec? Or can we just add an argument to www-authenticate = in the current spec? Thanks, Yaron [1] See http://www.goland.org/oauthgenericdelegation/ for an overview of my= thinking on full delegation in OAuth. At the very end are links to a bunch= of other much more in-depth articles on particular subjects touched on in = the main article. [2] I define 'full delegation' as "User X of Service Y grants permission Z = to User A of Service B". Currently OAuth requires X =3D=3D A. In the future= I hope to see extensions to OAuth that enable what I'm terming 'full deleg= ation'. But personally I'm really happy that OAuth has the X=3D=3DA restric= tion. It simplifies a whole host of issues and satisfies a really important= use case. > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Eran Hammer-Lahav > Sent: Monday, June 21, 2010 9:50 PM > To: Manger, James H; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] OAuth discovery draft? > > Yes, it's on my desk and not yet ready, but I am working on one. It inclu= des > your sites proposal among other things. I am trying to get the core spec > stable this week and focus on that next. > > EHL > > > -----Original Message----- > > From: Manger, James H [mailto:James.H.Manger@team.telstra.com] > > Sent: Monday, June 21, 2010 8:03 PM > > To: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org) > > Subject: OAuth discovery draft? > > > > Eran, > > > > There have been a few mentions recently of an OAuth discovery draft. > > Is there any such draft yet, or is this just a part that we know needs > > to be done? > > > > The email on "OAuth meeting notes on -05 (with updates)" said: > > > > >> 6.1.1. - describing the WWW-Authenticate response header > > >> > > >> - Discovery needed for various elements > > > > > > Yes. That's for the discovery draft. > > > > > > A wiki page on "Future OpenID Technical Requirements" > > says: > > > > > 6) IdP Discovery > > > > > > * Much of this will be covered by OAuth2 Discovery, > > > however OIC may need to define OpenID specific features. > > >... > > > 17) Simpler discovery > > > > > > * See Eran's OAuth Discovery proposal > > > > > > There was an OAuth 1.0 Discovery draft over 2 years ago, but that is ta= gged: > > "expired", "marked as obsolete by its author", "discouraged from > > implementing", "no update is expected", "replaced by the OAuth 2.0 > effort". > > > > I know I should write a discovery draft myself. > > > > -- > > James Manger > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --_000_7C01E631FF4B654FA1E783F1C0265F8C579C6E52TK5EX14MBXC117r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: OAuth discovery draft?

    No objections on my part.= I would rather have a smaller core spec with features that everyone agrees= on.

     <= /p>

    BTW, a thought for the di= scovery draft – RFC 2616/2617 only defines www-authenticate’s s= emantics in the context of a 401. It’s unclear from the draft what it would mean to return a www-authenticate header on a 200 response. The reas= on I care about this is that I think it makes sense that if someone wants t= o talk to an endpoint they know supports OAuth and need to know where their= token issuer location is they would want to fire off an OPTIONS request to the resource and find out from the = response where the issuer is and what realm is being used. It seems to me t= hat the simplest way to solve this problem is to just return www-authentica= te on a 200 response to an OPTIONS request.

     <= /p>

        &= nbsp;           Thoughts?=

     <= /p>

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

     <= /p>

        &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;      Yaron

     <= /p>

    From: Eran Ham= mer-Lahav [mailto:eran@hueniverse.com]
    Sent: Wednesday, June 23, 2010 11:04 AM
    To: Yaron Goland; James Manger; OAuth WG
    Subject: Re: OAuth discovery draft?

     

    I think = the core work is pretty stable now, unlike the discovery bits which (while = simple) are not enjoying the same level of consensus. I think it is much more practical to propose them as a separate document and perha= ps consider merging them later on when they reach an equal level of stabili= ty. But overall, I’m not too worries about multiple documents.

    EHL


    On 6/23/10 11:00 AM, "Yaron Goland" <yarong@microsoft.com> wrote:

    I've bee= n noodling [1] a lot about full delegation in OAuth [2] and one of the issu= es that came out of that was the need for discovering both the location and realm of an endpoint's token server. But at least for my = use cases (which consist of walking up to a service and making an options r= equest and getting back a www-authenticate header) all I need back is a rea= lm and a token server URL. In other words just having one argument added to our www-authenticate header would = be enough to solve the case where someone wants to walk up to a service and= find out where its token server is. Does that really need its own spec? Or= can we just add an argument to www-authenticate in the current spec?
            Thanks,
                &nb= sp;   Yaron

    [1] See http://ww= w.goland.org/oauthgenericdelegation/ for an overview of my thinking on = full delegation in OAuth. At the very end are links to a bunch of other muc= h more in-depth articles on particular subjects touched on in the main article.

    [2] I define 'full delegation' as "User X of Service Y grants permissi= on Z to User A of Service B". Currently OAuth requires X =3D=3D A. In = the future I hope to see extensions to OAuth that enable what I'm terming '= full delegation'. But personally I'm really happy that OAuth has the X=3D=3DA restriction. It simplifies a whole host of iss= ues and satisfies a really important use case.

    > -----Original Message-----
    > From: oauth-bounces@ietf.org [<= a href=3D"mailto:oauth-bounces@ietf.org">mailto:oauth-bounces@ietf.org]= On Behalf
    > Of Eran Hammer-Lahav
    > Sent: Monday, June 21, 2010 9:50 PM
    > To: Manger, James H; OAuth WG (oauth@ietf.o= rg)
    > Subject: Re: [OAUTH-WG] OAuth discovery draft?
    >
    > Yes, it's on my desk and not yet ready, but I am working on one. It in= cludes
    > your sites proposal among other things. I am trying to get the core sp= ec
    > stable this week and focus on that next.
    >
    > EHL
    >
    > > -----Original Message-----
    > > From: Manger, James H [mailto:James.H.Manger@team.telstra.com]
    > > Sent: Monday, June 21, 2010 8:03 PM
    > > To: Eran Hammer-Lahav; OAuth WG (oauth= @ietf.org)
    > > Subject: OAuth discovery draft?
    > >
    > > Eran,
    > >
    > > There have been a few mentions recently of an OAuth discovery dra= ft.
    > > Is there any such draft yet, or is this just a part that we know = needs
    > > to be done?
    > >
    > > The email on "OAuth meeting notes on -05 (with updates)"= ; said:
    > >
    > > >> 6.1.1. - describing the WWW-Authenticate response header=
    > > >>
    > > >> - Discovery needed for various elements
    > > >
    > > > Yes. That's for the discovery draft.
    > >
    > >
    > > A wiki page on "Future OpenID Technical Requirements" > > <http://wiki.openid.net/Future-OpenID-Technical-Requirements&= gt; says:
    > >
    > > > 6) IdP Discovery
    > > >
    > > >    * Much of this will be covered by OAuth2 D= iscovery,
    > > >      however OIC may need to define= OpenID specific features.
    > > >…
    > > > 17) Simpler discovery
    > > >
    > > >    * See Eran's OAuth Discovery proposal
    > >
    > >
    > > There was an OAuth 1.0 Discovery draft over 2 years ago, but that= is tagged:
    > > "expired", "marked as obsolete by its author"= , "discouraged from
    > > implementing", "no update is expected", "repl= aced by the OAuth 2.0
    > effort".
    > >
    > > I know I should write a discovery draft myself.
    > >
    > > --
    > > James Manger
    > _______________________________________________
    > OAuth mailing list
    > OAuth@ietf.org
    > https://www.ie= tf.org/mailman/listinfo/oauth

    --_000_7C01E631FF4B654FA1E783F1C0265F8C579C6E52TK5EX14MBXC117r_-- From hardjono@mit.edu Wed Jun 23 11:26:54 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC0D63A6AF4 for ; Wed, 23 Jun 2010 11:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.579 X-Spam-Level: X-Spam-Status: No, score=-0.579 tagged_above=-999 required=5 tests=[AWL=-0.580, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZcDktA7qWmN for ; Wed, 23 Jun 2010 11:26:54 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (DMZ-MAILSEC-SCANNER-5.MIT.EDU [18.7.68.34]) by core3.amsl.com (Postfix) with ESMTP id CE2E43A6AE7 for ; Wed, 23 Jun 2010 11:26:53 -0700 (PDT) X-AuditID: 12074422-b7b3aae000000a51-ba-4c2251f56eb4 Received: from mailhub-auth-1.mit.edu (MAILHUB-AUTH-1.MIT.EDU [18.9.21.35]) by dmz-mailsec-scanner-5.mit.edu (Symantec Brightmail Gateway) with SMTP id F6.07.02641.5F1522C4; Wed, 23 Jun 2010 14:27:01 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-EXCHANGE-1.MIT.EDU [18.9.28.15]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id o5NIR0Vb020811; Wed, 23 Jun 2010 14:27:00 -0400 Received: from oc11exedge2.exchange.mit.edu (OC11EXEDGE2.EXCHANGE.MIT.EDU [18.9.3.18]) ) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id o5NIQwpn017095; Wed, 23 Jun 2010 14:26:59 -0400 Received: from w92exhub10.exchange.mit.edu (18.7.73.18) by oc11exedge2.exchange.mit.edu (18.9.3.18) with Microsoft SMTP Server (TLS) id 8.1.393.1; Wed, 23 Jun 2010 14:26:10 -0400 Received: from EXPO10.exchange.mit.edu ([18.9.4.15]) by w92exhub10.exchange.mit.edu ([18.7.73.18]) with mapi; Wed, 23 Jun 2010 14:26:58 -0400 From: Thomas Hardjono To: "Tschofenig, Hannes (NSN - FI/Espoo)" , "OAuth WG" Date: Wed, 23 Jun 2010 14:26:54 -0400 Thread-Topic: Extensibility for OAuth? Thread-Index: AcsSmmOz8+Jt3DWXRJyOV1i4UkJelAAZPRCA Message-ID: References: <3D3C75174CB95F42AD6BCC56E5555B4502BE07CC@FIESEXC015.nsn-intra.net> In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B4502BE07CC@FIESEXC015.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_005F_01CB12E0.21309F40" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [OAUTH-WG] Extensibility for OAuth? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 18:26:55 -0000 ------=_NextPart_000_005F_01CB12E0.21309F40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thanks Hannes. Great list of to-do items for the WG :) > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Tschofenig, Hannes (NSN - FI/Espoo) > Sent: Wednesday, June 23, 2010 2:08 AM > > This is probably the most important item were people will want to > write > extensions for. Currently, we have the following onces in the > document: > 1) Web Server > 2) User Agent > 3) Native Application > 4) Autonomous > Note that the actual profile identifiers aren't clearly listed in > the > document at the moment (or are inconsistent, such as "user_agent" and > "user-agent" for the user agent profile). Is the plan to have a separate document for each profile? I'm assuming that we are all waiting for the draft-oath-v2 to stabilize (ps. it's gone from version 05 to 08 in a matter of 2-3 weeks, and now going to 09). We need to lock-down, I think. Need to distinguish between major/significant changes to minor/typo fixes. > An open question might be whether there is a possibility for an > extension (other than a new profile) to define an optional parameter > that may get used with an existing profile. Note that at the moment > there is no registry for parameters. It depends on what meaning of "profile" and "extension". If the optional parameter is used in one of the profiles (use-cases) only, then it should not be place into the core draft-oauth-v2. If the optional parameter ends-up being used in all the profiles (use-cases), then add it to the core. I think this is where you draw the line (otherwise all sorts of weird and wonderful parameters ends-up in the core draft). /thomas/ ------=_NextPart_000_005F_01CB12E0.21309F40 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILazCCAj0w ggGmAhEAzbp/VvDf5LxU/iKss3KqVTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMjgwODAxMjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBAOUZv22jVmEtmUhx9mfeuY3rt56GgAqRDvo4Ja9GiILlc6igmyRdDR/MZW4MsNBWhBiH mgabEKFz37RYOWtuwfYV1aioP6oSBo0xrH+wNNePNGeICc0UEeJORVZpH3gCgNrcR5EpuzbJY1zF 4Ncth3uhtzKwezC6Ki8xqu6jZ9rbAgMBAAEwDQYJKoZIhvcNAQECBQADgYEATD+4i8Zo3+5DMw5d 6abLB4RNejP/khv0Nq3YlSI2aBFsfELM85wuxAc/FLAPT/+Qknb54rxK6Y/NoIAK98Up8YIiXbix 3YEjo3slFUYweRb46gVLlH8dwhzI47f0EEA8E8NfH1PoSOSGtHuhNbB7Jbq4046rPzidADQAmPPR cZQwggRGMIIDr6ADAgECAhBm/Ufjwhnk6JrNmd31OsskMA0GCSqGSIb3DQEBBQUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNTEwMjgwMDAwMDBaFw0xNTEwMjcy MzU5NTlaMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g RzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDJ36zn6vj4AxTEAJLVwX42wjzvfHIV y8CrjD0clc5vHhAsPwDtlybmtsfmrUMdP6SHR0dMPlT4bPjH/LGevTBwvJexAwXqlfGtQMVEeksF ovJg/Nc6ZWLv/xB7ola7xU5wLdaiHzztsELoXo1XIaymmdkR6dIaB8B0R0IL/MU06v3muiTRHQgV N6LXc88BQS9jsjo/vqUabvTJSls9laYVuzUCGfnU77yPDnF2WbtLtj7W/FoW9NYOifJJ/mwM7RXp 2Yh1nHnOYCfdua11zi9zlXpAOoV1SbC432i8q80TgoURUKPgPAuuwApTzdcwb4UyRhvkSRDCbOKv H3n/27S1AgMBAAGjgf8wgfwwEgYDVR0TAQH/BAgwBgEB/wIBADBEBgNVHSAEPTA7MDkGC2CGSAGG +EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0P BAQDAgEGMBEGCWCGSAGG+EIBAQQEAwIBBjAuBgNVHREEJzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0 ZUxhYmVsMy0yMDQ4LTE1NTAdBgNVHQ4EFgQUEX1eGX08BN9qbNaiiho/Mdg7lFIwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwDQYJKoZIhvcNAQEFBQAD gYEAPKPaAmM6xJOqq3LT3K1QOB4MnhZKiLfu69n/D42VoNa7+moLrmGE2GhHie9PrLIfSUGbSTN2 k4uebrlDHGC9wtyKLYfBRcARcgQaayQqbG/n/AcTKdB3OiPn9cGFaBm/xgFUIBmuNYLMYjxhCcb0 1euwD6afM4Wa03GOUI+Z3WIwggTcMIIDxKADAgECAhAdbJ7qJ1t3pQoJyWI9GoXNMA0GCSqGSIb3 DQEBBQUAMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g RzIwHhcNMTAwMjE3MDAwMDAwWhcNMTEwMzA2MjM1OTU5WjCCARMxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4w HAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQgQ2xhc3Mg MSAtIE1pY3Jvc29mdCBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD1Rob21hcyBIYXJkam9ubzEfMB0G CSqGSIb3DQEJARYQaGFyZGpvbm9AbWl0LmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 5IPN5gsvYs8ugsfq1ndIZqRJXlbGSKsX+IH45pbnLeWPFWzfG7mxch4QhqOD0RUs2GCI1YNHPS8C sFyj1V05XnT0p/1eHa8eHOV2V3RVljq3P5R2+vhskoGE2Nwm1wi8YP9ce0Cs2Qf4wiPm9oL2ls5M yvOCR0aWfBkXD231vBUCAwEAAaOB4jCB3zAJBgNVHRMEAjAAMEQGA1UdIAQ9MDswOQYLYIZIAYb4 RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBQGCmCGSAGG+EUBBgcEBhYETm9u ZTBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlzaWduLmNv bS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAJrdkpPOIr2sXpSrE9hlj36x FOukzUivx4QwmsyLSFvMrkSQ/7NCGQ73O6DMlmJZbtQPMdIpqc9ZwPYhOkyQ9AaKz10yHVO8TkW2 CAN0Atk1ZfAF78C1h/jch429nYmjADnDZyDuyRUi2yW4ouJkX84Suj1SYaC5ptZVmmMUyRwcNV6/ iHewW8wsIf0mOqtP79RMAJ6oGh0XlUmzlahqtMbi3JX02D9gAVW9j8zXqtI0pHSpMNkNzkFp8GRd 5bxaCdQzszNIPfQGNIM0x7w97ZbF8z+F2yCRSL0+4G9kQxGRpxkd1OWjov5OJfmPvOyTZkkX9cmd Sivi3+fEDBgv0kIxggS4MIIEtAIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1 YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAdbJ7qJ1t3pQoJyWI9GoXNMAkGBSsOAwIaBQCgggMbMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDYyMzE4MjY1NFowIwYJ KoZIhvcNAQkEMRYEFEBM+86vozwhJFU9WluFuE9POIaZMIGrBgkqhkiG9w0BCQ8xgZ0wgZowCwYJ YIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcN AwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAsG CWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIIBAwYJKwYBBAGCNxAEMYH1MIHy MIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52 ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1 BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzICEB1s nuonW3elCgnJYj0ahc0wggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTsw OQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw NTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAdbJ7qJ1t3pQoJyWI9GoXNMA0GCSqG SIb3DQEBAQUABIGAusB+E5zangxIRVDc47JfXNiAu+FvS/yUTKG72USSx0AzzpYOz8NsqXVC367q B5tsX8lbTeT8uhuEhScL9KbQNsOZOxu6aJG3cQboLzNfnQ8HxloTubbnAgFLetGJz3hZ82TG/gN0 Ao9eSYyJ0NYKhRed+PioQ3oOqG84VgCtEdQAAAAAAAA= ------=_NextPart_000_005F_01CB12E0.21309F40-- From hardjono@mit.edu Wed Jun 23 11:39:59 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3801D3A6A01 for ; Wed, 23 Jun 2010 11:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.814 X-Spam-Level: X-Spam-Status: No, score=-1.814 tagged_above=-999 required=5 tests=[AWL=0.785, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2FvVgW-Fx567 for ; Wed, 23 Jun 2010 11:39:57 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (DMZ-MAILSEC-SCANNER-5.MIT.EDU [18.7.68.34]) by core3.amsl.com (Postfix) with ESMTP id 014BF3A6AF4 for ; Wed, 23 Jun 2010 11:39:55 -0700 (PDT) X-AuditID: 12074422-b7b3aae000000a51-07-4c2255035d41 Received: from mailhub-auth-3.mit.edu (MAILHUB-AUTH-3.MIT.EDU [18.9.21.43]) by dmz-mailsec-scanner-5.mit.edu (Symantec Brightmail Gateway) with SMTP id 96.A7.02641.305522C4; Wed, 23 Jun 2010 14:40:03 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-EXCHANGE-1.MIT.EDU [18.9.28.15]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id o5NIe3bY015641; Wed, 23 Jun 2010 14:40:03 -0400 Received: from oc11exedge1.exchange.mit.edu (OC11EXEDGE1.EXCHANGE.MIT.EDU [18.9.3.17]) ) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id o5NIe2GR019034; Wed, 23 Jun 2010 14:40:02 -0400 Received: from oc11exhub3.exchange.mit.edu (18.9.3.13) by oc11exedge1.exchange.mit.edu (18.9.3.17) with Microsoft SMTP Server (TLS) id 8.1.393.1; Wed, 23 Jun 2010 14:39:10 -0400 Received: from EXPO10.exchange.mit.edu ([18.9.4.15]) by oc11exhub3.exchange.mit.edu ([18.9.3.13]) with mapi; Wed, 23 Jun 2010 14:40:02 -0400 From: Thomas Hardjono To: Yaron Goland , "OAuth WG (oauth@ietf.org)" Date: Wed, 23 Jun 2010 14:39:59 -0400 Thread-Topic: OAuth discovery draft? Thread-Index: AQHLEbd88ANnc80E8EanM4mdFaHtZpKN3qcAgAH2zrCAAAvTUA== Message-ID: References: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB68D9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1126427308C@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343B3EC83F46@P3PW5EX1MB01.EX1.SECURESERVER.NET> <7C01E631FF4B654FA1E783F1C0265F8C579C6DC3@TK5EX14MBXC117.redmond.corp.microsoft.com> In-Reply-To: <7C01E631FF4B654FA1E783F1C0265F8C579C6DC3@TK5EX14MBXC117.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_006D_01CB12E1.F51B26D0" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAARTaEVM= Subject: Re: [OAUTH-WG] OAuth discovery draft? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 18:39:59 -0000 ------=_NextPart_000_006D_01CB12E1.F51B26D0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Yaron, I think delegation is a great idea/feature that should be added or OAuth = (as I suggested in the kerberos-oauth draft). In the Kerberos world, it = has been a very important feature (a life saver). In your example, when Yochi wants to terminate the delegation she gave = to Leon, how does Yochi do this? Also, would it be possible for Yochi to delegate to another system (not = a human user) to do things for her. For example, give delegation to a = 3rd party service/system to (a) regularly fetch Yochi's Saturday/Sunday = schedule from Yahoo Calendar, and then (b) publish it to FaceBook say. /thomas/ > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Yaron Goland > Sent: Wednesday, June 23, 2010 2:00 PM > To: Eran Hammer-Lahav; Manger, James H; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] OAuth discovery draft? >=20 > I've been noodling [1] a lot about full delegation in OAuth [2] and = one > of the issues that came out of that was the need for discovering both > the location and realm of an endpoint's token server. But at least for > my use cases (which consist of walking up to a service and making an > options request and getting back a www-authenticate header) all I need > back is a realm and a token server URL. In other words just having one > argument added to our www-authenticate header would be enough to solve > the case where someone wants to walk up to a service and find out = where > its token server is. Does that really need its own spec? Or can we = just > add an argument to www-authenticate in the current spec? > Thanks, > Yaron >=20 > [1] See http://www.goland.org/oauthgenericdelegation/ for an overview > of my thinking on full delegation in OAuth. At the very end are links > to a bunch of other much more in-depth articles on particular subjects > touched on in the main article. >=20 > [2] I define 'full delegation' as "User X of Service Y grants > permission Z to User A of Service B". Currently OAuth requires X = =3D=3D A. > In the future I hope to see extensions to OAuth that enable what I'm > terming 'full delegation'. But personally I'm really happy that OAuth > has the X=3D=3DA restriction. It simplifies a whole host of issues and > satisfies a really important use case. >=20 > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > Behalf > > Of Eran Hammer-Lahav > > Sent: Monday, June 21, 2010 9:50 PM > > To: Manger, James H; OAuth WG (oauth@ietf.org) > > Subject: Re: [OAUTH-WG] OAuth discovery draft? > > > > Yes, it's on my desk and not yet ready, but I am working on one. It > > includes your sites proposal among other things. I am trying to get > > the core spec stable this week and focus on that next. > > > > EHL > > > > > -----Original Message----- > > > From: Manger, James H [mailto:James.H.Manger@team.telstra.com] > > > Sent: Monday, June 21, 2010 8:03 PM > > > To: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org) > > > Subject: OAuth discovery draft? > > > > > > Eran, > > > > > > There have been a few mentions recently of an OAuth discovery > draft. > > > Is there any such draft yet, or is this just a part that we know > > > needs to be done? > > > > > > The email on "OAuth meeting notes on -05 (with updates)" said: > > > > > > >> 6.1.1. - describing the WWW-Authenticate response header > > > >> > > > >> - Discovery needed for various elements > > > > > > > > Yes. That's for the discovery draft. > > > > > > > > > A wiki page on "Future OpenID Technical Requirements" > > > = says: > > > > > > > 6) IdP Discovery > > > > > > > > * Much of this will be covered by OAuth2 Discovery, > > > > however OIC may need to define OpenID specific features. > > > >=E2=80=A6 > > > > 17) Simpler discovery > > > > > > > > * See Eran's OAuth Discovery proposal > > > > > > > > > There was an OAuth 1.0 Discovery draft over 2 years ago, but that > is tagged: > > > "expired", "marked as obsolete by its author", "discouraged from > > > implementing", "no update is expected", "replaced by the OAuth 2.0 > > effort". > > > > > > I know I should write a discovery draft myself. > > > > > > -- > > > James Manger > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth ------=_NextPart_000_006D_01CB12E1.F51B26D0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILazCCAj0w ggGmAhEAzbp/VvDf5LxU/iKss3KqVTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMjgwODAxMjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBAOUZv22jVmEtmUhx9mfeuY3rt56GgAqRDvo4Ja9GiILlc6igmyRdDR/MZW4MsNBWhBiH mgabEKFz37RYOWtuwfYV1aioP6oSBo0xrH+wNNePNGeICc0UEeJORVZpH3gCgNrcR5EpuzbJY1zF 4Ncth3uhtzKwezC6Ki8xqu6jZ9rbAgMBAAEwDQYJKoZIhvcNAQECBQADgYEATD+4i8Zo3+5DMw5d 6abLB4RNejP/khv0Nq3YlSI2aBFsfELM85wuxAc/FLAPT/+Qknb54rxK6Y/NoIAK98Up8YIiXbix 3YEjo3slFUYweRb46gVLlH8dwhzI47f0EEA8E8NfH1PoSOSGtHuhNbB7Jbq4046rPzidADQAmPPR cZQwggRGMIIDr6ADAgECAhBm/Ufjwhnk6JrNmd31OsskMA0GCSqGSIb3DQEBBQUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNTEwMjgwMDAwMDBaFw0xNTEwMjcy MzU5NTlaMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g RzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDJ36zn6vj4AxTEAJLVwX42wjzvfHIV y8CrjD0clc5vHhAsPwDtlybmtsfmrUMdP6SHR0dMPlT4bPjH/LGevTBwvJexAwXqlfGtQMVEeksF ovJg/Nc6ZWLv/xB7ola7xU5wLdaiHzztsELoXo1XIaymmdkR6dIaB8B0R0IL/MU06v3muiTRHQgV N6LXc88BQS9jsjo/vqUabvTJSls9laYVuzUCGfnU77yPDnF2WbtLtj7W/FoW9NYOifJJ/mwM7RXp 2Yh1nHnOYCfdua11zi9zlXpAOoV1SbC432i8q80TgoURUKPgPAuuwApTzdcwb4UyRhvkSRDCbOKv H3n/27S1AgMBAAGjgf8wgfwwEgYDVR0TAQH/BAgwBgEB/wIBADBEBgNVHSAEPTA7MDkGC2CGSAGG +EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0P BAQDAgEGMBEGCWCGSAGG+EIBAQQEAwIBBjAuBgNVHREEJzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0 ZUxhYmVsMy0yMDQ4LTE1NTAdBgNVHQ4EFgQUEX1eGX08BN9qbNaiiho/Mdg7lFIwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwDQYJKoZIhvcNAQEFBQAD gYEAPKPaAmM6xJOqq3LT3K1QOB4MnhZKiLfu69n/D42VoNa7+moLrmGE2GhHie9PrLIfSUGbSTN2 k4uebrlDHGC9wtyKLYfBRcARcgQaayQqbG/n/AcTKdB3OiPn9cGFaBm/xgFUIBmuNYLMYjxhCcb0 1euwD6afM4Wa03GOUI+Z3WIwggTcMIIDxKADAgECAhAdbJ7qJ1t3pQoJyWI9GoXNMA0GCSqGSIb3 DQEBBQUAMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g RzIwHhcNMTAwMjE3MDAwMDAwWhcNMTEwMzA2MjM1OTU5WjCCARMxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4w HAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQgQ2xhc3Mg MSAtIE1pY3Jvc29mdCBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD1Rob21hcyBIYXJkam9ubzEfMB0G CSqGSIb3DQEJARYQaGFyZGpvbm9AbWl0LmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 5IPN5gsvYs8ugsfq1ndIZqRJXlbGSKsX+IH45pbnLeWPFWzfG7mxch4QhqOD0RUs2GCI1YNHPS8C sFyj1V05XnT0p/1eHa8eHOV2V3RVljq3P5R2+vhskoGE2Nwm1wi8YP9ce0Cs2Qf4wiPm9oL2ls5M yvOCR0aWfBkXD231vBUCAwEAAaOB4jCB3zAJBgNVHRMEAjAAMEQGA1UdIAQ9MDswOQYLYIZIAYb4 RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBQGCmCGSAGG+EUBBgcEBhYETm9u ZTBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlzaWduLmNv bS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAJrdkpPOIr2sXpSrE9hlj36x FOukzUivx4QwmsyLSFvMrkSQ/7NCGQ73O6DMlmJZbtQPMdIpqc9ZwPYhOkyQ9AaKz10yHVO8TkW2 CAN0Atk1ZfAF78C1h/jch429nYmjADnDZyDuyRUi2yW4ouJkX84Suj1SYaC5ptZVmmMUyRwcNV6/ iHewW8wsIf0mOqtP79RMAJ6oGh0XlUmzlahqtMbi3JX02D9gAVW9j8zXqtI0pHSpMNkNzkFp8GRd 5bxaCdQzszNIPfQGNIM0x7w97ZbF8z+F2yCRSL0+4G9kQxGRpxkd1OWjov5OJfmPvOyTZkkX9cmd Sivi3+fEDBgv0kIxggS4MIIEtAIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1 YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAdbJ7qJ1t3pQoJyWI9GoXNMAkGBSsOAwIaBQCgggMbMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDYyMzE4Mzk1OVowIwYJ KoZIhvcNAQkEMRYEFDHO8DLqV/JY8dYm+GoyJWkWBr98MIGrBgkqhkiG9w0BCQ8xgZ0wgZowCwYJ YIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcN AwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAsG CWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIIBAwYJKwYBBAGCNxAEMYH1MIHy MIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52 ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1 BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzICEB1s nuonW3elCgnJYj0ahc0wggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTsw OQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw NTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAdbJ7qJ1t3pQoJyWI9GoXNMA0GCSqG SIb3DQEBAQUABIGADLJvygf1DIZYzXf0Cy+2r4GW2qyJeQgfnEHNkl04s/89p7/CGL5uJUWksxLw 8WFdduTjcMhIwiKjmVQ0nXFMMT9bbmr22KE+92y4BV/dZV/mO/eT0Nbtf55lE2yCpyXWw9wCY+2q s8KHjOq36WVvVt6BmBJ2cAZBZ2PAvf2M4F4AAAAAAAA= ------=_NextPart_000_006D_01CB12E1.F51B26D0-- From lr@lukasrosenstock.net Thu Jun 24 00:49:01 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7475B3A6A47 for ; Thu, 24 Jun 2010 00:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.488 X-Spam-Level: X-Spam-Status: No, score=-0.488 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7-7a6+0rP8F for ; Thu, 24 Jun 2010 00:49:00 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 3FB903A67F0 for ; Thu, 24 Jun 2010 00:48:59 -0700 (PDT) Received: by vws14 with SMTP id 14so1611171vws.31 for ; Thu, 24 Jun 2010 00:49:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.214.77 with SMTP id gz13mr5166573qcb.168.1277365745297; Thu, 24 Jun 2010 00:49:05 -0700 (PDT) Received: by 10.229.236.130 with HTTP; Thu, 24 Jun 2010 00:49:05 -0700 (PDT) In-Reply-To: References: <3D3C75174CB95F42AD6BCC56E5555B4502BE07CC@FIESEXC015.nsn-intra.net> Date: Thu, 24 Jun 2010 09:49:05 +0200 Message-ID: From: Lukas Rosenstock To: Dick Hardt Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , OAuth WG Subject: Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 07:49:01 -0000 Wasn't there some concensus that URIs would be good for scope? They have "in-built namespacing" ... Lukas 2010/6/23 Dick Hardt : > > On 2010-06-22, at 11:07 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > >> " >> =A0 scope >> =A0 =A0 =A0 =A0 OPTIONAL. =A0The scope of the access request expressed a= s a list >> =A0 =A0 =A0 =A0 of space-delimited strings. =A0The value of the "scope" = parameter >> =A0 =A0 =A0 =A0 is defined by the authorization server. =A0If the value = contains >> =A0 =A0 =A0 =A0 multiple space-delimited strings, their order does not m= atter, >> =A0 =A0 =A0 =A0 and each string adds an additional access range to the >> =A0 =A0 =A0 =A0 requested scope. >> " >> >> Do folks think it would be useful to have standardized values? > > Not at this time. The semantics of scope are all over the place. If stand= ardized, people will feel they need to pick one that is close to what they = want, but is not exactly what they mean. I think it is better for the AS to= define what they mean by a scope and give it a name that makes sense in th= at context. > >> >> If the answer is "yes", then it would be useful to differentiate the >> standardized values from those values that are purely defined locally by >> the authorization server. From hannes.tschofenig@nsn.com Thu Jun 24 03:58:49 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40E8C3A6875 for ; Thu, 24 Jun 2010 03:58:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.709 X-Spam-Level: X-Spam-Status: No, score=-0.709 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bEAqn8W5xEQQ for ; Thu, 24 Jun 2010 03:58:48 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 17CC73A6784 for ; Thu, 24 Jun 2010 03:58:47 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o5OAwrD2001396 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 24 Jun 2010 12:58:53 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o5OAwq9N026192; Thu, 24 Jun 2010 12:58:52 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 24 Jun 2010 12:58:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 24 Jun 2010 13:58:09 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4502869858@FIESEXC015.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? Thread-Index: AcsTcbz92OrLiBAWTqqVkquX92WR0QAGETTQ References: <3D3C75174CB95F42AD6BCC56E5555B4502BE07CC@FIESEXC015.nsn-intra.net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Lukas Rosenstock" , "Dick Hardt" X-OriginalArrivalTime: 24 Jun 2010 10:58:51.0750 (UTC) FILETIME=[3B10D860:01CB138C] Cc: OAuth WG Subject: Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 10:58:49 -0000 The question is whether one would ever want to have a standardized = semantic for the scope parameter.=20 If the answer to that question is "no" then it does not matter what the = format is. It can well be a list of space-delimited strings (as it is = currently defined).=20 An evironment specific semantic works well in cases where entity X sets = the value and later it receives the value again. Only entity X needs to = understand what it means. In some environments the use case is slightly different, namely entity X = and entity Y are from the same organization and agree on the semantic. = Usage of OAuth within an enterprise might be such a case.=20 Now, the usage of the scope parameter is, however, a bit different in = the spec. Section 4, for example, describes how a client obtains an = access token. How does the client know what scope parameters to set and = what the semantic is? Ciao Hannes > -----Original Message----- > From: ext Lukas Rosenstock [mailto:lr@lukasrosenstock.net]=20 > Sent: Thursday, June 24, 2010 10:49 AM > To: Dick Hardt > Cc: Tschofenig, Hannes (NSN - FI/Espoo); OAuth WG > Subject: Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? >=20 > Wasn't there some concensus that URIs would be good for scope? They > have "in-built namespacing" ... >=20 > Lukas >=20 > 2010/6/23 Dick Hardt : > > > > On 2010-06-22, at 11:07 PM, Tschofenig, Hannes (NSN -=20 > FI/Espoo) wrote: > > > >> " > >> =A0 scope > >> =A0 =A0 =A0 =A0 OPTIONAL. =A0The scope of the access request=20 > expressed as a list > >> =A0 =A0 =A0 =A0 of space-delimited strings. =A0The value of the=20 > "scope" parameter > >> =A0 =A0 =A0 =A0 is defined by the authorization server. =A0If the=20 > value contains > >> =A0 =A0 =A0 =A0 multiple space-delimited strings, their order does=20 > not matter, > >> =A0 =A0 =A0 =A0 and each string adds an additional access range to = the > >> =A0 =A0 =A0 =A0 requested scope. > >> " > >> > >> Do folks think it would be useful to have standardized values? > > > > Not at this time. The semantics of scope are all over the=20 > place. If standardized, people will feel they need to pick=20 > one that is close to what they want, but is not exactly what=20 > they mean. I think it is better for the AS to define what=20 > they mean by a scope and give it a name that makes sense in=20 > that context. > > > >> > >> If the answer is "yes", then it would be useful to=20 > differentiate the > >> standardized values from those values that are purely=20 > defined locally by > >> the authorization server. >=20 From jricher@mitre.org Thu Jun 24 07:02:07 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5649A3A67A3 for ; Thu, 24 Jun 2010 07:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.751 X-Spam-Level: X-Spam-Status: No, score=-5.751 tagged_above=-999 required=5 tests=[AWL=0.848, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6NX6HQy369cH for ; Thu, 24 Jun 2010 07:02:06 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 507083A6949 for ; Thu, 24 Jun 2010 07:02:06 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o5OE2DNr015205 for ; Thu, 24 Jun 2010 10:02:14 -0400 Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o5OE2D4K015195; Thu, 24 Jun 2010 10:02:13 -0400 Received: from [129.83.50.65] (129.83.50.65) by imchub2.MITRE.ORG (129.83.29.74) with Microsoft SMTP Server id 8.2.254.0; Thu, 24 Jun 2010 10:02:13 -0400 From: Justin Richer To: Lukas Rosenstock In-Reply-To: References: <3D3C75174CB95F42AD6BCC56E5555B4502BE07CC@FIESEXC015.nsn-intra.net> Content-Type: text/plain; charset="UTF-8" Date: Thu, 24 Jun 2010 10:02:12 -0400 Message-ID: <1277388132.28743.24.camel@localhost.localdomain> MIME-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , OAuth WG Subject: Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 14:02:07 -0000 I recall there being consensus on the space delimiter to make it so that URIs could be used easily as scope parameters. I know that I, personally, would rather have keywords in our implementation than URIs, so I'm very much in favor of keeping it unspecified. -- justin On Thu, 2010-06-24 at 03:49 -0400, Lukas Rosenstock wrote: > Wasn't there some concensus that URIs would be good for scope? They > have "in-built namespacing" ... > > Lukas > > 2010/6/23 Dick Hardt : > > > > On 2010-06-22, at 11:07 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > > > >> " > >> scope > >> OPTIONAL. The scope of the access request expressed as a list > >> of space-delimited strings. The value of the "scope" parameter > >> is defined by the authorization server. If the value contains > >> multiple space-delimited strings, their order does not matter, > >> and each string adds an additional access range to the > >> requested scope. > >> " > >> > >> Do folks think it would be useful to have standardized values? > > > > Not at this time. The semantics of scope are all over the place. If standardized, people will feel they need to pick one that is close to what they want, but is not exactly what they mean. I think it is better for the AS to define what they mean by a scope and give it a name that makes sense in that context. > > > >> > >> If the answer is "yes", then it would be useful to differentiate the > >> standardized values from those values that are purely defined locally by > >> the authorization server. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From dick.hardt@gmail.com Thu Jun 24 09:31:44 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5804728C0E3 for ; Thu, 24 Jun 2010 09:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.443 X-Spam-Level: X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YZbxIyvHFClq for ; Thu, 24 Jun 2010 09:31:42 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id 90F863A6878 for ; Thu, 24 Jun 2010 09:30:59 -0700 (PDT) Received: by pzk36 with SMTP id 36so416404pzk.31 for ; Thu, 24 Jun 2010 09:31:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=3Da478n26nZh8npjJwZOEGMDXU/Xe/EgjQ5bJFP1BXE=; b=gVFPU9llXlbcJkBv1IvnrclaRnK/PPv0iP9vOcCXvAtK1TSKDCZqELSmkN/LphK1Ob /wE/QuB91JLdbHRmhCKNhB5M9RX5T+Sxwb0+PhBP1TNnKjSLOfw+ecWkvnPLOT1QF2vb 3kQIewemSRDAz880V34bLNbLBOriNbHvqI5sc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=AEYMndzdF76FYOP2s5nE9wPH4GnNLicKG0uilF9/tS2CF6F3lu6zJ2JpdC+OFf0Bib +IE5syhwo+8stxuRbBLllgbBli/b+ctcAR58vKzoTGDq9vLcNEyx0SzI5PhiyS/I0njK eVgvA0nHweJTocT30CLjsDcBnrA7daJT3varg= Received: by 10.143.27.3 with SMTP id e3mr9383293wfj.224.1277397065126; Thu, 24 Jun 2010 09:31:05 -0700 (PDT) Received: from [192.168.1.5] ([24.130.32.55]) by mx.google.com with ESMTPS id w39sm5405477wfh.3.2010.06.24.09.31.03 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 24 Jun 2010 09:31:03 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Dick Hardt In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B4502869858@FIESEXC015.nsn-intra.net> Date: Thu, 24 Jun 2010 09:31:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3D3C75174CB95F42AD6BCC56E5555B4502BE07CC@FIESEXC015.nsn-intra.net> <3D3C75174CB95F42AD6BCC56E5555B4502869858@FIESEXC015.nsn-intra.net> To: "Tschofenig, Hannes (NSN - FI/Espoo)" X-Mailer: Apple Mail (2.1081) Cc: OAuth WG Subject: Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 16:31:44 -0000 When the API is standardized, it makes sense for the scope parameter to = be standardized. If the API is unique to the PR, then the scope will = also be unique. There may be concepts that are similar across unique = APIs, but there will be nuances that are important to be aware of. To answer your question about where the scope parameter come from, = documentation for the API. -- Dick On 2010-06-24, at 3:58 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > The question is whether one would ever want to have a standardized = semantic for the scope parameter.=20 > If the answer to that question is "no" then it does not matter what = the format is. It can well be a list of space-delimited strings (as it = is currently defined).=20 >=20 > An evironment specific semantic works well in cases where entity X = sets the value and later it receives the value again. Only entity X = needs to understand what it means. >=20 > In some environments the use case is slightly different, namely entity = X and entity Y are from the same organization and agree on the semantic. = Usage of OAuth within an enterprise might be such a case.=20 >=20 > Now, the usage of the scope parameter is, however, a bit different in = the spec. Section 4, for example, describes how a client obtains an = access token. How does the client know what scope parameters to set and = what the semantic is? >=20 > Ciao > Hannes >=20 >> -----Original Message----- >> From: ext Lukas Rosenstock [mailto:lr@lukasrosenstock.net]=20 >> Sent: Thursday, June 24, 2010 10:49 AM >> To: Dick Hardt >> Cc: Tschofenig, Hannes (NSN - FI/Espoo); OAuth WG >> Subject: Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? >>=20 >> Wasn't there some concensus that URIs would be good for scope? They >> have "in-built namespacing" ... >>=20 >> Lukas >>=20 >> 2010/6/23 Dick Hardt : >>>=20 >>> On 2010-06-22, at 11:07 PM, Tschofenig, Hannes (NSN -=20 >> FI/Espoo) wrote: >>>=20 >>>> " >>>> scope >>>> OPTIONAL. The scope of the access request=20 >> expressed as a list >>>> of space-delimited strings. The value of the=20 >> "scope" parameter >>>> is defined by the authorization server. If the=20 >> value contains >>>> multiple space-delimited strings, their order does=20 >> not matter, >>>> and each string adds an additional access range to the >>>> requested scope. >>>> " >>>>=20 >>>> Do folks think it would be useful to have standardized values? >>>=20 >>> Not at this time. The semantics of scope are all over the=20 >> place. If standardized, people will feel they need to pick=20 >> one that is close to what they want, but is not exactly what=20 >> they mean. I think it is better for the AS to define what=20 >> they mean by a scope and give it a name that makes sense in=20 >> that context. >>>=20 >>>>=20 >>>> If the answer is "yes", then it would be useful to=20 >> differentiate the >>>> standardized values from those values that are purely=20 >> defined locally by >>>> the authorization server. >>=20 From wmills@yahoo-inc.com Thu Jun 24 10:17:17 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA11E3A69DE for ; Thu, 24 Jun 2010 10:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.075 X-Spam-Level: X-Spam-Status: No, score=-17.075 tagged_above=-999 required=5 tests=[AWL=0.524, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yWHXiyq7iLcs for ; Thu, 24 Jun 2010 10:17:16 -0700 (PDT) Received: from mrout1.yahoo.com (mrout1.yahoo.com [216.145.54.171]) by core3.amsl.com (Postfix) with ESMTP id 7669D3A6A26 for ; Thu, 24 Jun 2010 10:17:13 -0700 (PDT) Received: from SNV-EXBH01.ds.corp.yahoo.com (snv-exbh01.ds.corp.yahoo.com [207.126.227.249]) by mrout1.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o5OHFe90044892; Thu, 24 Jun 2010 10:15:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:x-mimeole:content-class:mime-version: content-type:content-transfer-encoding:subject:date:message-id: in-reply-to:x-ms-has-attach:x-ms-tnef-correlator:thread-topic: thread-index:references:from:to:cc:return-path:x-originalarrivaltime; b=rWgFOD2W6AcrDt63iCZ/f9/oHxgMgP1k+xL3+m/C/FWgYOjM+kzlSZQd0UIZaW4z Received: from SNV-EXVS08.ds.corp.yahoo.com ([207.126.227.8]) by SNV-EXBH01.ds.corp.yahoo.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 24 Jun 2010 10:15:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 24 Jun 2010 10:15:06 -0700 Message-ID: <012AB2B223CB3F4BB846962876F47217059B663D@SNV-EXVS08.ds.corp.yahoo.com> In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B4502869858@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? Thread-Index: AcsTcbz92OrLiBAWTqqVkquX92WR0QAGETTQAA1kINA= References: <3D3C75174CB95F42AD6BCC56E5555B4502BE07CC@FIESEXC015.nsn-intra.net> <3D3C75174CB95F42AD6BCC56E5555B4502869858@FIESEXC015.nsn-intra.net> From: "William Mills" To: "Tschofenig, Hannes (NSN - FI/Espoo)" , "ext Lukas Rosenstock" , "Dick Hardt" X-OriginalArrivalTime: 24 Jun 2010 17:15:40.0455 (UTC) FILETIME=[DEE77370:01CB13C0] Cc: OAuth WG Subject: Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 17:17:17 -0000 I'm in favor of having a spaces separated list of tokens. The only case = I can think of where the client needs to handle the scope as anything = other than opaque is when it is accessing multiple services. To reduce = the numebr of login events the client will have to poll all the = endpoints it wants to access and get all the scopes advertized by them = and submit them all, and once it has them it needs to submit all of them = in it's auth request, so we need something that's easy for the client to = put together. -bill > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]=20 > On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) > Sent: Thursday, June 24, 2010 3:58 AM > To: ext Lukas Rosenstock; Dick Hardt > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? >=20 > The question is whether one would ever want to have a=20 > standardized semantic for the scope parameter.=20 > If the answer to that question is "no" then it does not=20 > matter what the format is. It can well be a list of =20 > space-delimited strings (as it is currently defined).=20 >=20 > An evironment specific semantic works well in cases where=20 > entity X sets the value and later it receives the value=20 > again. Only entity X needs to understand what it means. >=20 > In some environments the use case is slightly different,=20 > namely entity X and entity Y are from the same organization=20 > and agree on the semantic. Usage of OAuth within an=20 > enterprise might be such a case.=20 >=20 > Now, the usage of the scope parameter is, however, a bit=20 > different in the spec. Section 4, for example, describes how=20 > a client obtains an access token. How does the client know=20 > what scope parameters to set and what the semantic is? >=20 > Ciao > Hannes >=20 > > -----Original Message----- > > From: ext Lukas Rosenstock [mailto:lr@lukasrosenstock.net] > > Sent: Thursday, June 24, 2010 10:49 AM > > To: Dick Hardt > > Cc: Tschofenig, Hannes (NSN - FI/Espoo); OAuth WG > > Subject: Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? > >=20 > > Wasn't there some concensus that URIs would be good for scope? They=20 > > have "in-built namespacing" ... > >=20 > > Lukas > >=20 > > 2010/6/23 Dick Hardt : > > > > > > On 2010-06-22, at 11:07 PM, Tschofenig, Hannes (NSN - > > FI/Espoo) wrote: > > > > > >> " > > >> =A0 scope > > >> =A0 =A0 =A0 =A0 OPTIONAL. =A0The scope of the access request > > expressed as a list > > >> =A0 =A0 =A0 =A0 of space-delimited strings. =A0The value of the > > "scope" parameter > > >> =A0 =A0 =A0 =A0 is defined by the authorization server. =A0If the > > value contains > > >> =A0 =A0 =A0 =A0 multiple space-delimited strings, their order = does > > not matter, > > >> =A0 =A0 =A0 =A0 and each string adds an additional access range = to the > > >> =A0 =A0 =A0 =A0 requested scope. > > >> " > > >> > > >> Do folks think it would be useful to have standardized values? > > > > > > Not at this time. The semantics of scope are all over the > > place. If standardized, people will feel they need to pick=20 > one that is=20 > > close to what they want, but is not exactly what they mean.=20 > I think it=20 > > is better for the AS to define what they mean by a scope=20 > and give it a=20 > > name that makes sense in that context. > > > > > >> > > >> If the answer is "yes", then it would be useful to > > differentiate the > > >> standardized values from those values that are purely > > defined locally by > > >> the authorization server. > >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 From naitiks@gmail.com Thu Jun 24 11:34:30 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13B0F3A6407 for ; Thu, 24 Jun 2010 11:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YX3qTvr7qH0A for ; Thu, 24 Jun 2010 11:34:23 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id B08DA3A683E for ; Thu, 24 Jun 2010 11:34:17 -0700 (PDT) Received: by iwn37 with SMTP id 37so193960iwn.31 for ; Thu, 24 Jun 2010 11:34:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=nyslubFxqF0SlGsZe2mxo/Y9DNJjIhRUlx/G/EN41LQ=; b=POUqw4oXRFWKmjksQIHLIGNMOwuJN33wU16VdbHKmRGlw7pfO+oop3aACskNUTKT7X 95sNFclyi5vcmdmttC8/DKuqlQqtafLCJj77tK4mZWLrlNli/d26IHuqudPiiK9nJfL/ AT6XPsv82e1Ms2Y3pbcbpf7pQgslBgL+n+Uvw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type; b=W6UXF6IGzkIBheMYXcID1aHWA7A3Z6cg2XM2HdUyhc6CpY65PYZWbJewUzKLJf1Bak igSTlYz60C5o3TIoj1Hb8bOK/u6A+flaOymA1tnszsdWACms1VS9kPyEIT1x5M3RD6Vm iVHySEkyTUAmlB8TS3DeDJiMAtPHYWlnTwn9Q= Received: by 10.231.170.201 with SMTP id e9mr10495947ibz.119.1277404460332; Thu, 24 Jun 2010 11:34:20 -0700 (PDT) MIME-Version: 1.0 Sender: naitiks@gmail.com Received: by 10.231.170.9 with HTTP; Thu, 24 Jun 2010 11:33:59 -0700 (PDT) From: Naitik Shah Date: Thu, 24 Jun 2010 11:33:59 -0700 X-Google-Sender-Auth: 4IIJAZRr7CJnJhYHLm36qiIS1NY Message-ID: To: OAuth WG Content-Type: multipart/alternative; boundary=00504501810217b4dc0489cae703 Subject: [OAUTH-WG] Understanding the reasoning for Base64 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 18:34:30 -0000 --00504501810217b4dc0489cae703 Content-Type: text/plain; charset=UTF-8 I've been following some of the discussions wrt the new Signature proposal, and I think I get the reason for needing Base64, but wasn't quite sure if I understood it correctly (allows the use of a separator?). Would someone mind elaborating? The payload looks is urlencode(web_base64(json_encode(data))) -- and the urlencode in this case should be an identity function. I'm wondering if urlencode(json_encode(data)) would be acceptable. Thanks, -Naitik --00504501810217b4dc0489cae703 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I've been following some of the discussions wrt the new Signature propo= sal, and I think I get the reason for needing Base64, but wasn't quite = sure if I understood it correctly (allows the use of a separator?). Would s= omeone mind=C2=A0elaborating?

    The payload looks is urlencode(web_base64(json_encode(data))= ) -- and the urlencode in this case should be an identity function.

    I'm wondering if urlencode(json_encode(data)) would b= e acceptable.


    Thanks,
    -Naitik
    --00504501810217b4dc0489cae703-- From mscurtescu@google.com Thu Jun 24 13:20:15 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E63E73A687F for ; Thu, 24 Jun 2010 13:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.019 X-Spam-Level: X-Spam-Status: No, score=-104.019 tagged_above=-999 required=5 tests=[AWL=-0.642, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0W-xwwYM9dOP for ; Thu, 24 Jun 2010 13:20:14 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 3B0B03A6885 for ; Thu, 24 Jun 2010 13:20:12 -0700 (PDT) Received: from kpbe17.cbf.corp.google.com (kpbe17.cbf.corp.google.com [172.25.105.81]) by smtp-out.google.com with ESMTP id o5OKKJmE004609 for ; Thu, 24 Jun 2010 13:20:19 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1277410819; bh=w8aM7Ee/emPUzVOET801nZZOjK8=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=SEWr8Rbiyx+j4qRnE5+ho/+h4BH7jVWxRV38nuUJn0PFl29fJPMIWEDYbc7DzLGj9 o9Adf+3mwifg7ohiC9Pww== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding:x-system-of-record; b=Kbju8GMW4Rt0++qkbLine/9HjoNQUWPxzSxFhqIwKDPqVUpbKk/4XNReyinG0oyA8 DNU0+ZrZ7E+EdjdP6dBUw== Received: from vws18 (vws18.prod.google.com [10.241.21.146]) by kpbe17.cbf.corp.google.com with ESMTP id o5OKJvvC019843 for ; Thu, 24 Jun 2010 13:20:18 -0700 Received: by vws18 with SMTP id 18so1474674vws.26 for ; Thu, 24 Jun 2010 13:20:18 -0700 (PDT) Received: by 10.220.48.141 with SMTP id r13mr5380335vcf.75.1277410818241; Thu, 24 Jun 2010 13:20:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.182.131 with HTTP; Thu, 24 Jun 2010 13:19:58 -0700 (PDT) In-Reply-To: <29F569B4-C107-4204-9790-44FCE1364CB5@facebook.com> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EC8419E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3EC841C2@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3EC841C8@P3PW5EX1MB01.EX1.SECURESERVER.NET> <39DE4E99-6DB3-4FBA-B78C-B2AB2B162221@facebook.com> <29F569B4-C107-4204-9790-44FCE1364CB5@facebook.com> From: Marius Scurtescu Date: Thu, 24 Jun 2010 13:19:58 -0700 Message-ID: To: Luke Shepard 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] native app support (was: Next draft) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 20:20:16 -0000 On Wed, Jun 23, 2010 at 12:37 AM, Luke Shepard wrot= e: > One more question - is the technique used in production? I think = you'd mentioned that it was ... if so, can you point me to the docs where i= t's currently used? Google has several Windows desktop apps that use this technique. There is an Outlook integration app called Glook and probably some versions of Picasa and SketchUp. Marius > > On Jun 22, 2010, at 11:00 PM, Luke Shepard wrote: > >> Two points: >> >> 1/ I agree that it can be onerous for clients to host web pages. It's no= t a matter of expense but of complexity. >> >> BUT >> >> 2/ As we discussed previously in our in-person meeting, this should be h= andled by a different endpoint, and not be the responsibility for the provi= der. If Google wishes to support this for their desktop apps, then it shoul= d provide an endpoint that handles the OAuth response and puts it in the <t= itle>. I can say that Facebook has no interest in supporting this hack on t= he server side, but clients that want it can use their own html file that d= oes it for them. >> >> For example, for Javascript web apps it is a pain to host a cross-domain= receiver file. So we host one on behalf of developers (called xd_proxy.php= ). But it is not part of our server-side logic. >> >> If you want to write a spec for that, then great, but the <title> hack d= oes not belong in the main spec. >> >> On Jun 22, 2010, at 4:30 PM, Marius Scurtescu wrote: >> >>> On Tue, Jun 22, 2010 at 4:26 PM, Eran Hammer-Lahav <eran@hueniverse.com= > wrote: >>>> In that case, I suggest an extension. But I just don't think this need= s it. Why involve the server at all in this? The client should just host a = web page somewhere with the format it wants or the language for the user. >>>> >>>> With $10 hosting, every client can host a web page somewhere. >>> >>> Hard to tell, you could be right. Keep in mind that this page has to >>> be reliable and secure, $10 will probably not give you that. An authz >>> server can easily provide all this at almost no cost. >>> >>> Marius >>> >>>> >>>> EHL >>>> >>>>> -----Original Message----- >>>>> From: Marius Scurtescu [mailto:mscurtescu@google.com] >>>>> Sent: Tuesday, June 22, 2010 4:17 PM >>>>> To: Eran Hammer-Lahav >>>>> Cc: OAuth WG (oauth@ietf.org) >>>>> Subject: Re: native app support (was: Next draft) >>>>> >>>>> On Tue, Jun 22, 2010 at 4:07 PM, Eran Hammer-Lahav >>>>> <eran@hueniverse.com> wrote: >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Marius Scurtescu [mailto:mscurtescu@google.com] >>>>>>> Sent: Tuesday, June 22, 2010 3:35 PM >>>>>>> To: Eran Hammer-Lahav >>>>>>> Cc: OAuth WG (oauth@ietf.org) >>>>>>> Subject: Re: native app support (was: Next draft) >>>>>>> >>>>>>> On Tue, Jun 22, 2010 at 3:14 PM, Eran Hammer-Lahav >>>>>>> <eran@hueniverse.com> wrote: >>>>>>>> In OAuth 1.0a, we needed it for the patch. I don't think this need= s >>>>>>>> to be in >>>>>>> the spec because it doesn't help interop. If the server supports su= ch >>>>>>> a scheme, it should document it. It also falls under "previously >>>>>>> established redirection URI" which happens to point at the server. >>>>>>> >>>>>>> OK, that makes sense. >>>>>>> >>>>>>> What about: >>>>>>>> Also, this page should put the verification code and the client >>>>>>>> state (code and state) in the page title in a standard way such >>>>>>>> that the native app can extract them from the window title. WRAP >>>>>>>> defined how the title should be formed. >>>>>>> >>>>>>> Extension? >>>>>> >>>>>> I don't think this needs a spec. Just something provided by the serv= er. Does >>>>> the client need any special handling? It can always just use a static= web page >>>>> to do this, no? >>>>> >>>>> A spec would help so all servers provide code and state in a consiste= nt >>>>> format. Client libraries can then provide methods to parse this. Also= , client >>>>> apps connecting to multiple servers can expect some consistency. >>>>> >>>>> Marius >>>>> >>>>>> >>>>>> EHL >>>>>> >>>>>>> >>>>>>> Marius >>>>>>> >>>>>>>> >>>>>>>> EHL >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Marius Scurtescu [mailto:mscurtescu@google.com] >>>>>>>>> Sent: Tuesday, June 22, 2010 1:02 PM >>>>>>>>> To: Eran Hammer-Lahav >>>>>>>>> Cc: OAuth WG (oauth@ietf.org) >>>>>>>>> Subject: Re: native app support (was: Next draft) >>>>>>>>> >>>>>>>>> On Tue, Jun 8, 2010 at 10:46 AM, Marius Scurtescu >>>>>>>>> <mscurtescu@google.com> wrote: >>>>>>>>>> In order to properly support native applications I suggest the >>>>>>>>>> following changes: >>>>>>>>>> [...] >>>>>>>>>> 2. optional redirect_uri (default result page) >>>>>>>>>> >>>>>>>>>> Some native apps do not have a redirect_uri, as a result two >>>>>>>>>> things are >>>>>>>>> needed: >>>>>>>>>> >>>>>>>>>> 2.1 Either make redirect_uri optional or define a standard value >>>>>>>>>> that signals that the client does not have such a page. >>>>>>>>>> >>>>>>>>>> 2.2 The authz server must supply a default result page, if there >>>>>>>>>> is no redirect_uri. Also, this page should put the verification >>>>>>>>>> code and the client state (code and state) in the page title in >>>>>>>>>> a standard way such that the native app can extract them from >>>>>>>>>> the window title. WRAP defined how the title should be formed. >>>>>>>>> >>>>>>>>> Should this also go to an extension? It is not introducing any ne= w >>>>>>>>> parameters, not sure if it belongs there. OAuth 1 at least define= d >>>>>>>>> the >>>>>>> "oob" special value. >>>>>>>>> >>>>>>>>> Marius >>>>>>>> >>>>>> >>>> >>> _______________________________________________ >>> OAuth mailing 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 briandunnington@gmail.com Thu Jun 24 18:50:36 2010 Return-Path: <briandunnington@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72E303A6A0C for <oauth@core3.amsl.com>; Thu, 24 Jun 2010 18:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id earIcu91XbgT for <oauth@core3.amsl.com>; Thu, 24 Jun 2010 18:50:35 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 94BA93A6A03 for <oauth@ietf.org>; Thu, 24 Jun 2010 18:50:35 -0700 (PDT) Received: by iwn37 with SMTP id 37so551288iwn.31 for <oauth@ietf.org>; Thu, 24 Jun 2010 18:50:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=LAEXSoq7GjE3yvkTOIH7h13fpjmaEohU+X+VpAk/0YQ=; b=MNm+2M3oxIu6lH3IhLoFFSmpIZzGqtIUqKggUIbA8Lhr85wnlrMFqTAKVH7e/Epkv3 GtGIboGXOzDQNN27JkHGr/iHF1wXfGnlHY4miwwTPIhj9waoCO+pvjwXSxilkJ82Xc7b 5jZfdndR1RTHjEzBkz2oCKPSyqNO4AbTHdRGs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=x2e2wTmZLEuRD+pLgpDH4pRCjK/O+5fowOEjCX8M7dVWDlb3mULl6bj3m3zV8NWluX eZBiYNqGIfXQ4HVam3u4HrRoPWAJ7wUgVEt4ut4hWZYZNEbpsL5N5visET0BZXxFRVad 06w3BYafq6ykIXnzXr+Tq7RvI1fk/YjyVTbSI= MIME-Version: 1.0 Received: by 10.231.114.144 with SMTP id e16mr11823212ibq.188.1277430644162; Thu, 24 Jun 2010 18:50:44 -0700 (PDT) Received: by 10.231.152.15 with HTTP; Thu, 24 Jun 2010 18:50:44 -0700 (PDT) Date: Thu, 24 Jun 2010 18:50:44 -0700 Message-ID: <AANLkTikbz5zmILsegGXoj6YjdC8h4TPfscqDMqFCB7l-@mail.gmail.com> From: Brian Dunnington <briandunnington@gmail.com> To: oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [OAUTH-WG] client secret used in Native App profile X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 25 Jun 2010 01:58:29 -0000 In the 'User-Agent' profile, it says: "This user-agent profile does not utilize the client secret since the client executables reside on the end-user's computer or device which makes the client secret accessible and exploitable" However, the 'Native Apps' profile does not include such verbiage and in fact specifically requires the use of the client secret. Native apps' executables also reside on the end-user's computer or device, making the client secret just as accessible and exploitable, so why the difference? Specifically, as a native app developer, there is no good (secure) way to distribute the client secret without it being compromised. Any open-source application would have even more problems keeping their secret secure, but even complied apps are easily exploitable. in this scenario, there is no single, secure repository to keep the client secret safe, so I would expect that the requirement of the client secret for native apps be removed and made conformant with the user-agent profile. From ietf.org@zetafleet.com Thu Jun 24 21:07:23 2010 Return-Path: <ietf.org@zetafleet.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEE8D3A67E2 for <oauth@core3.amsl.com>; Thu, 24 Jun 2010 21:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kxj3dlb-IBuC for <oauth@core3.amsl.com>; Thu, 24 Jun 2010 21:07:22 -0700 (PDT) Received: from one.acitia.com (one.acitia.com [66.135.55.251]) by core3.amsl.com (Postfix) with ESMTP id C317C3A676A for <oauth@ietf.org>; Thu, 24 Jun 2010 21:07:22 -0700 (PDT) Received: from c-75-73-43-136.hsd1.mn.comcast.net ([75.73.43.136] helo=Trillian.hsd1.mn.comcast.net) by one.acitia.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from <ietf.org@zetafleet.com>) id 1OS0Oq-00019I-BS for oauth@ietf.org; Fri, 25 Jun 2010 04:20:20 +0000 Message-ID: <4C242B7C.7040002@zetafleet.com> Date: Thu, 24 Jun 2010 23:07:24 -0500 From: Colin Snover <ietf.org@zetafleet.com> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: oauth@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: [OAUTH-WG] Add an option to authorization endpoint to force end-user re-authentication X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 25 Jun 2010 04:08:40 -0000 Hi everyone, I apologise if this has been discussed previously; I searched the list and did not see anything about it. I have been working extensively with OAuth as a client author. A big limitation that we are consistently running into with the way OAuth currently works is that there is no way to tell the authorization server that it needs to ask which end-user is requesting access. In instances where an end-user may have more than one account on a single provider, or where multiple end-users share the same computer, a problem occurs when the provider assumes that the account currently logged-in in the user-agent is the one that the end-user wants to connect. This assumption, while useful in most cases, causes major problems and a very frustrating user experience when the client has previously been authorised for the logged-in account and the provider immediately redirects back with an access token. In these cases, the user has no ability to choose to authorize a different account unless they manually log out of the provider’s site first or revoke authorization from the provider’s site. We need a way for the client to tell the authorization server “please do not automatically assume that the account currently logged-in is the account that we are requesting access forâ€. I would propose adding a new optional query component to the end-user authorization endpoint, force_auth. When this query component exists and is equal to 1, a provider MUST ask for the user’s credentials before either automatically redirecting back (if the client is already authorized) or presenting them with the prompt for authorization. Thank you for your time and consideration of this matter. I hope this feature or something similar can make it into OAuth 2, since otherwise we are going to have huge headaches and may end up needing to resort to cross-site request forgery to force user-agents to log out of provider sites. If I have been unclear at all, please let me know and I will be happy to clarify. Regards, -- Colin Snover http://zetafleet.com From lshepard@facebook.com Thu Jun 24 21:30:00 2010 Return-Path: <lshepard@facebook.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAC123A67E2 for <oauth@core3.amsl.com>; Thu, 24 Jun 2010 21:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.286 X-Spam-Level: X-Spam-Status: No, score=-0.286 tagged_above=-999 required=5 tests=[AWL=-0.785, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1, SARE_WEOFFER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dIlDOG3aK0T6 for <oauth@core3.amsl.com>; Thu, 24 Jun 2010 21:29:58 -0700 (PDT) Received: from mx-out.facebook.com (outmail005.ash1.tfbnw.net [69.63.184.105]) by core3.amsl.com (Postfix) with ESMTP id AF7DE3A6768 for <oauth@ietf.org>; Thu, 24 Jun 2010 21:29:57 -0700 (PDT) Received: from [10.18.255.121] ([10.18.255.121:53229] helo=mail.thefacebook.com) by mta004.ash1.facebook.com (envelope-from <lshepard@facebook.com>) (ecelerity 2.2.2.45 r(34067)) with ESMTP id 37/90-26055-DC0342C4; Thu, 24 Jun 2010 21:30:06 -0700 Received: from sc-hub06.TheFacebook.com (192.168.18.83) by sc-hub04.TheFacebook.com (192.168.18.212) with Microsoft SMTP Server (TLS) id 14.0.694.1; Thu, 24 Jun 2010 21:30:03 -0700 Received: from SC-MBXC1.TheFacebook.com ([192.168.18.100]) by sc-hub06.TheFacebook.com ([192.168.18.83]) with mapi; Thu, 24 Jun 2010 21:30:02 -0700 From: Luke Shepard <lshepard@facebook.com> To: Colin Snover <ietf.org@zetafleet.com> Date: Thu, 24 Jun 2010 21:30:01 -0700 Thread-Topic: [OAUTH-WG] Add an option to authorization endpoint to force end-user re-authentication Thread-Index: AcsUHxPzPIejIM2JRpWB8TxKZ1Dxyw== Message-ID: <DFE12F2D-8F71-497A-B7F5-7E69F857E3F8@facebook.com> References: <4C242B7C.7040002@zetafleet.com> In-Reply-To: <4C242B7C.7040002@zetafleet.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="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Add an option to authorization endpoint to force end-user re-authentication X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 25 Jun 2010 04:30:00 -0000 Hey Colin You're right; this can be an interesting issue. It's very tied up in identi= ty - if you are talking about connecting accounts (like you would with Face= book) then there's a layer missing from OAuth that provides the identity on= top of it. At the moment, there are a few proposals (for instance, OpenID = Connect) which distinguish between an immediate request (which returns imme= diately) vs a regular request (which does not).=20 For now, I think the right behavior is for the client to give the user a ch= ance to switch accounts. That means the identity layer needs to offer a way= to log out as well as authorize ( see http://www.sociallipstick.com/?p=3D1= 89 for more thoughts on this). If you are using Facebook, we offer a custom= way to log the user out (http://developers.facebook.com/docs/reference/jav= ascript/FB.logout ). In any case, Facebook will likely add this layer on top of OAuth once it be= comes a little more settled. There has been a lot of discussion on this lis= t lately about exactly what form that should take. Does that answer the question? On Jun 24, 2010, at 9:07 PM, Colin Snover wrote: > Hi everyone, >=20 > I apologise if this has been discussed previously; I searched the list=20 > and did not see anything about it. >=20 > I have been working extensively with OAuth as a client author. A big=20 > limitation that we are consistently running into with the way OAuth=20 > currently works is that there is no way to tell the authorization server= =20 > that it needs to ask which end-user is requesting access. >=20 > In instances where an end-user may have more than one account on a=20 > single provider, or where multiple end-users share the same computer, a=20 > problem occurs when the provider assumes that the account currently=20 > logged-in in the user-agent is the one that the end-user wants to=20 > connect. This assumption, while useful in most cases, causes major=20 > problems and a very frustrating user experience when the client has=20 > previously been authorised for the logged-in account and the provider=20 > immediately redirects back with an access token. In these cases, the=20 > user has no ability to choose to authorize a different account unless=20 > they manually log out of the provider=92s site first or revoke=20 > authorization from the provider=92s site. >=20 > We need a way for the client to tell the authorization server =93please d= o=20 > not automatically assume that the account currently logged-in is the=20 > account that we are requesting access for=94. I would propose adding a ne= w=20 > optional query component to the end-user authorization endpoint,=20 > force_auth. When this query component exists and is equal to 1, a=20 > provider MUST ask for the user=92s credentials before either automaticall= y=20 > redirecting back (if the client is already authorized) or presenting=20 > them with the prompt for authorization. >=20 > Thank you for your time and consideration of this matter. I hope this=20 > feature or something similar can make it into OAuth 2, since otherwise=20 > we are going to have huge headaches and may end up needing to resort to=20 > cross-site request forgery to force user-agents to log out of provider=20 > sites. If I have been unclear at all, please let me know and I will be=20 > happy to clarify. >=20 > Regards, >=20 > --=20 > Colin Snover > http://zetafleet.com >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From mscurtescu@google.com Fri Jun 25 00:22:52 2010 Return-Path: <mscurtescu@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02CBA3A6915 for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 00:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.276 X-Spam-Level: X-Spam-Status: No, score=-105.276 tagged_above=-999 required=5 tests=[AWL=0.701, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBfAYBwlZNws for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 00:22:51 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 0F9D23A6846 for <oauth@ietf.org>; Fri, 25 Jun 2010 00:22:50 -0700 (PDT) Received: from wpaz21.hot.corp.google.com (wpaz21.hot.corp.google.com [172.24.198.85]) by smtp-out.google.com with ESMTP id o5P7MxcX003206 for <oauth@ietf.org>; Fri, 25 Jun 2010 00:22:59 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1277450579; bh=kUZz0unrRF+eBWtyYlHH0XWHt3k=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=wpLzVjwywgvxPjsCuChqIaI9wM07yjtVCRMhq+ArvLV2P/pELtu5Zeru+59Eq+iLz HrcNdgK6Tv6DfTVfevkDw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding:x-system-of-record; b=oWgngC3U327j0llyPDf8Yhd/GbvjYFQqL3mYFLhEC5wpSjvDCoOphDFw1qtu3GnT4 8IwCwYRhjY0ldc5clBgEg== Received: from gwj21 (gwj21.prod.google.com [10.200.10.21]) by wpaz21.hot.corp.google.com with ESMTP id o5P7MvZj020496 for <oauth@ietf.org>; Fri, 25 Jun 2010 00:22:58 -0700 Received: by gwj21 with SMTP id 21so2843944gwj.22 for <oauth@ietf.org>; Fri, 25 Jun 2010 00:22:57 -0700 (PDT) Received: by 10.100.16.4 with SMTP id 4mr448503anp.2.1277450576232; Fri, 25 Jun 2010 00:22:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.132.22 with HTTP; Fri, 25 Jun 2010 00:22:35 -0700 (PDT) In-Reply-To: <AANLkTikbz5zmILsegGXoj6YjdC8h4TPfscqDMqFCB7l-@mail.gmail.com> References: <AANLkTikbz5zmILsegGXoj6YjdC8h4TPfscqDMqFCB7l-@mail.gmail.com> From: Marius Scurtescu <mscurtescu@google.com> Date: Fri, 25 Jun 2010 00:22:35 -0700 Message-ID: <AANLkTimvvwzUhCBS3Nlq6Q5odfGTJkv-AYGoUGfS47SJ@mail.gmail.com> To: Brian Dunnington <briandunnington@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] client secret used in Native App profile X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 25 Jun 2010 07:22:52 -0000 I think the main difference is that User-Agent clients (aka JavaScript clients) cannot store a secret while Native Apps can safely store a secret, but the secret cannot be distributed (or, even if it can be distributed, it may not have much value). The difference is important. Each native app instance could require a registration phase that would provide a unique secret and possibly Id. This registration phase could be completely automatic or could involve the end user. There have been proposals for both. How much value there is in such a registration is not clear to me. Marius On Thu, Jun 24, 2010 at 6:50 PM, Brian Dunnington <briandunnington@gmail.com> wrote: > In the 'User-Agent' profile, it says: > > "This user-agent profile does not utilize the client secret since the > =A0 client executables reside on the end-user's computer or device which > =A0 makes the client secret accessible and exploitable" > > However, the 'Native Apps' profile does not include such verbiage and > in fact specifically requires the use of the client secret. Native > apps' executables also reside on the end-user's computer or device, > making the client secret just as accessible and exploitable, so why > the difference? > > Specifically, as a native app developer, there is no good (secure) way > to distribute the client secret without it being compromised. Any > open-source application would have even more problems keeping their > secret secure, but even complied apps are easily exploitable. in this > scenario, there is no single, secure repository to keep the client > secret safe, so I would expect that the requirement of the client > secret for native apps be removed and made conformant with the > user-agent profile. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From ietf.org@zetafleet.com Fri Jun 25 00:30:28 2010 Return-Path: <ietf.org@zetafleet.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 552493A699C for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 00:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_50=0.001, SARE_WEOFFER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DwFUMZL39XyK for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 00:30:23 -0700 (PDT) Received: from one.acitia.com (one.acitia.com [66.135.55.251]) by core3.amsl.com (Postfix) with ESMTP id 57D5E3A6846 for <oauth@ietf.org>; Fri, 25 Jun 2010 00:30:12 -0700 (PDT) Received: from c-75-73-43-136.hsd1.mn.comcast.net ([75.73.43.136] helo=Trillian.hsd1.mn.comcast.net) by one.acitia.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from <ietf.org@zetafleet.com>) id 1OS3Z4-00041l-B1; Fri, 25 Jun 2010 07:43:07 +0000 Message-ID: <4C245B02.2060306@zetafleet.com> Date: Fri, 25 Jun 2010 02:30:10 -0500 From: Colin Snover <ietf.org@zetafleet.com> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Luke Shepard <lshepard@facebook.com> References: <4C242B7C.7040002@zetafleet.com> <DFE12F2D-8F71-497A-B7F5-7E69F857E3F8@facebook.com> In-Reply-To: <DFE12F2D-8F71-497A-B7F5-7E69F857E3F8@facebook.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "oauth@ietf.org" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Add an option to authorization endpoint to force end-user re-authentication X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 25 Jun 2010 07:30:28 -0000 On 24/06/2010 23:30, Luke Shepard wrote: > You're right; this can be an interesting issue. It's very tied up in identity - if you are talking about connecting accounts (like you would with Facebook) then there's a layer missing from OAuth that provides the identity on top of it. At the moment, there are a few proposals (for instance, OpenID Connect) which distinguish between an immediate request (which returns immediately) vs a regular request (which does not). > > For now, I think the right behavior is for the client to give the user a chance to switch accounts. That means the identity layer needs to offer a way to log out as well as authorize ( see http://www.sociallipstick.com/?p=189 for more thoughts on this). If you are using Facebook, we offer a custom way to log the user out (http://developers.facebook.com/docs/reference/javascript/FB.logout ). > > In any case, Facebook will likely add this layer on top of OAuth once it becomes a little more settled. There has been a lot of discussion on this list lately about exactly what form that should take. > > Does that answer the question? > Hi Luke, Thanks for writing. I’m obviously flying a little blind in regards to what’s already been proposed, so I appreciate the links. I took a brief look at OpenID Connect. If I am reading this correctly, it would resolve our issue since the client would collect and pass the desired user_id to the authorization server, right? I guess the biggest problem I see here is that unless OIDC support is mandated in the OAuth spec, implicit authorisation will probably continue to happen with providers that don’t want to support it—and I’m guessing there would be a fair amount of opposition to any sort of strong coupling between OAuth and OIDC? I also did a little more digging through the mailing list while investigating what you said and saw that there was a suggestion earlier for an “immediate” parameter, which appears to address the opposite of the situation I’ve raised and was added in draft 2 (but removed in draft 7). Notes on draft 7 don’t seem to mention its removal, so I’m not entirely sure why it is gone now (because it would mean that OAuth would need to become an identity layer?), but it sounds like there is a desire for /three/ different modes of OAuth operation: an “immediate” mode, a “default” or “hybrid” mode (like OAuth 1.0a), and an “always-reauthenticate” mode. Is that accurate? Unless I’m misinterpreting what is being suggested, I don’t think that an option to provide a “Log out” link to end-users from within clients is the right way to solve this problem. The ability to authorise multiple accounts from one provider at the same time is essential to what we are trying to do; switching only makes sense if the client can only handle one account at a time. Beyond that, there are a few other issues I can think of with this proposal, which I hope have been raised before: 1. Logging a user-agent out of a provider’s site isn’t really what we want to do here; we just want to provide the end-user an opportunity to authorise an account that happens to /not/ be the account their user-agent is already logged into. Maybe the provider decides that this needs to cause a log out, but OAuth ideally shouldn’t /require/ the interruption of another existing session just because we happen to be using the same user-agent for authorisation. 2. If a programmatic method for logging out was required to solve this problem, it would be wide open to abuse by people that want to be annoying and force people to get logged out of their providers’ sites. (This isn’t terribly uncommon, of course, since most log-outs are simple GET requests, but it seems like something that would be good to avoid perpetuating. I don’t know how Facebook deals with this.) 3. It also seems like a fairly bad idea from a privacy standpoint to provide a mechanism that allows an unauthorised client to determine whether or not a visitor is already logged in on a particular provider’s site, since it opens up a new avenue for history sniffing, etc. In order to resolve the issue I have raised through the use of a “log out” button in the client, this would seem to be necessary without compromising look-and-feel through the use of an iframe. (I seem to have inadvertently neglected to mention in my original message what happens when an end-user’s UA is already logged in to a provider, but the client is /not/ yet authorised: if they want to pick a different account to authorise instead of the already logged-in account, they have to log out of the provider, optionally log in with the correct credentials, then go back to the client and restart the OAuth request from the beginning. That sucks too!) Anyway, TL;DR: Being able to pre-provide information as to which account is being requested, à la OpenID Connect, is one potential solution, but unless it’s mandated along with OAuth 2, the implicit authorisation problem will still exist for providers that opt out of OIDC. Without turning OAuth into an identity layer, it would seem that a flag to force reauthentication à la my original proposal would be necessary. Of course, this would not solve the “immediate” problem, but it sounds like that’s not safely solvable without identity anyway. Maybe there is another option, but I’m not able to think of one. Regards, -- Colin Snover http://zetafleet.com From hannes.tschofenig@nsn.com Fri Jun 25 01:04:12 2010 Return-Path: <hannes.tschofenig@nsn.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 633163A68A9 for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 01:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.683 X-Spam-Level: X-Spam-Status: No, score=-1.683 tagged_above=-999 required=5 tests=[AWL=0.916, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v2g1+L0yRfwE for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 01:04:11 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 2A6A03A6846 for <oauth@ietf.org>; Fri, 25 Jun 2010 01:04:10 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o5P84HS0005717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <oauth@ietf.org>; Fri, 25 Jun 2010 10:04:17 +0200 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o5P84EEL009258 for <oauth@ietf.org>; Fri, 25 Jun 2010 10:04:17 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 25 Jun 2010 10:04:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 25 Jun 2010 11:04:04 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B450286986C@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 78th IETF DRAFT Agenda Thread-Index: AcsT9QfxWAKFUpouT8Kr2j/I34VLIgAR4Adg From: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com> To: "OAuth WG" <oauth@ietf.org> X-OriginalArrivalTime: 25 Jun 2010 08:04:14.0766 (UTC) FILETIME=[00B5B4E0:01CB143D] Subject: [OAUTH-WG] 78th IETF DRAFT Agenda X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 25 Jun 2010 08:04:12 -0000 Hi all,=20 An early version of the agenda is available and indicates that the Oauth WG session is scheduled for Tuesday, July 27, 2010.=20 The agenda is still subject to change.=20 The final agenda will be published on July 2, 2010.=20 Ciao Hannes From hannes.tschofenig@nsn.com Fri Jun 25 01:04:16 2010 Return-Path: <hannes.tschofenig@nsn.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 334513A69D1 for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 01:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.716 X-Spam-Level: X-Spam-Status: No, score=-1.716 tagged_above=-999 required=5 tests=[AWL=0.883, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aaBJP8EyXAoT for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 01:04:14 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 164443A69AA for <oauth@ietf.org>; Fri, 25 Jun 2010 01:04:13 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o5P84Hgt012627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 25 Jun 2010 10:04:17 +0200 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o5P84EEJ009258; Fri, 25 Jun 2010 10:04:17 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 25 Jun 2010 10:04:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 25 Jun 2010 10:59:50 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B450286986B@FIESEXC015.nsn-intra.net> In-Reply-To: <012AB2B223CB3F4BB846962876F47217059B663D@SNV-EXVS08.ds.corp.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? Thread-Index: AcsTcbz92OrLiBAWTqqVkquX92WR0QAGETTQAA1kINAAHvAggA== References: <3D3C75174CB95F42AD6BCC56E5555B4502BE07CC@FIESEXC015.nsn-intra.net><E7A7F197-3BBC-43F2-8242-D0164057A39A@gmail.com><AANLkTild51WHVcXxYFCygL8sGSGiN3HILDFwIbym6Lfi@mail.gmail.com> <3D3C75174CB95F42AD6BCC56E5555B4502869858@FIESEXC015.nsn-intra.net> <012AB2B223CB3F4BB846962876F47217059B663D@SNV-EXVS08.ds.corp.yahoo.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com> To: "ext William Mills" <wmills@yahoo-inc.com>, "ext Lukas Rosenstock" <lr@lukasrosenstock.net>, "Dick Hardt" <dick.hardt@gmail.com> X-OriginalArrivalTime: 25 Jun 2010 08:04:14.0203 (UTC) FILETIME=[005FCCB0:01CB143D] Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 25 Jun 2010 08:04:16 -0000 Dick pointed me to the Facebook API on how scope is used.=20 The main page is here:=20 http://developers.facebook.com/docs/authentication/ It describes the basic functionality and also lists an example:=20 " https://graph.facebook.com/oauth/authorize? client_id=3D...& redirect_uri=3Dhttp://www.example.com/callback& scope=3Duser_photos,user_videos,publish_stream " The values of the scope parameter are then explained here:=20 http://developers.facebook.com/docs/authentication/permissions Example: user_photos ... Provides access to the photos the user has = uploaded I think it provides a good example that the scope values are not opaque. = =20 Opaque (in this context) means that only the entity creating it needs to = understand it and nobody else. Here the client needs to understand and = set them.=20 However, one could argue that the scope values are already bound to the = specific entity the client requests to obtain the assertion from. In = this specific case it would be "https://graph.facebook.com".=20 To respond to the statement Dick made about having standardized values = later there would still be the need to decide about the structure of the = values now. One possibility is to just add a prefix for standardized = values that are not allowed to be used in other cases, such as "std:".=20 Ciao Hannes > -----Original Message----- > From: ext William Mills [mailto:wmills@yahoo-inc.com]=20 > Sent: Thursday, June 24, 2010 8:15 PM > To: Tschofenig, Hannes (NSN - FI/Espoo); ext Lukas=20 > Rosenstock; Dick Hardt > Cc: OAuth WG > Subject: RE: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? >=20 > I'm in favor of having a spaces separated list of tokens. =20 > The only case I can think of where the client needs to handle=20 > the scope as anything other than opaque is when it is=20 > accessing multiple services. To reduce the numebr of login=20 > events the client will have to poll all the endpoints it=20 > wants to access and get all the scopes advertized by them and=20 > submit them all, and once it has them it needs to submit all=20 > of them in it's auth request, so we need something that's=20 > easy for the client to put together. >=20 >=20 > -bill >=20 > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]=20 > > On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) > > Sent: Thursday, June 24, 2010 3:58 AM > > To: ext Lukas Rosenstock; Dick Hardt > > Cc: OAuth WG > > Subject: Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? > >=20 > > The question is whether one would ever want to have a=20 > > standardized semantic for the scope parameter.=20 > > If the answer to that question is "no" then it does not=20 > > matter what the format is. It can well be a list of =20 > > space-delimited strings (as it is currently defined).=20 > >=20 > > An evironment specific semantic works well in cases where=20 > > entity X sets the value and later it receives the value=20 > > again. Only entity X needs to understand what it means. > >=20 > > In some environments the use case is slightly different,=20 > > namely entity X and entity Y are from the same organization=20 > > and agree on the semantic. Usage of OAuth within an=20 > > enterprise might be such a case.=20 > >=20 > > Now, the usage of the scope parameter is, however, a bit=20 > > different in the spec. Section 4, for example, describes how=20 > > a client obtains an access token. How does the client know=20 > > what scope parameters to set and what the semantic is? > >=20 > > Ciao > > Hannes > >=20 > > > -----Original Message----- > > > From: ext Lukas Rosenstock [mailto:lr@lukasrosenstock.net] > > > Sent: Thursday, June 24, 2010 10:49 AM > > > To: Dick Hardt > > > Cc: Tschofenig, Hannes (NSN - FI/Espoo); OAuth WG > > > Subject: Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? > > >=20 > > > Wasn't there some concensus that URIs would be good for=20 > scope? They=20 > > > have "in-built namespacing" ... > > >=20 > > > Lukas > > >=20 > > > 2010/6/23 Dick Hardt <dick.hardt@gmail.com>: > > > > > > > > On 2010-06-22, at 11:07 PM, Tschofenig, Hannes (NSN - > > > FI/Espoo) wrote: > > > > > > > >> " > > > >> =A0 scope > > > >> =A0 =A0 =A0 =A0 OPTIONAL. =A0The scope of the access request > > > expressed as a list > > > >> =A0 =A0 =A0 =A0 of space-delimited strings. =A0The value of the > > > "scope" parameter > > > >> =A0 =A0 =A0 =A0 is defined by the authorization server. =A0If = the > > > value contains > > > >> =A0 =A0 =A0 =A0 multiple space-delimited strings, their order = does > > > not matter, > > > >> =A0 =A0 =A0 =A0 and each string adds an additional access range = to the > > > >> =A0 =A0 =A0 =A0 requested scope. > > > >> " > > > >> > > > >> Do folks think it would be useful to have standardized values? > > > > > > > > Not at this time. The semantics of scope are all over the > > > place. If standardized, people will feel they need to pick=20 > > one that is=20 > > > close to what they want, but is not exactly what they mean.=20 > > I think it=20 > > > is better for the AS to define what they mean by a scope=20 > > and give it a=20 > > > name that makes sense in that context. > > > > > > > >> > > > >> If the answer is "yes", then it would be useful to > > > differentiate the > > > >> standardized values from those values that are purely > > > defined locally by > > > >> the authorization server. > > >=20 > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > >=20 >=20 From bouiaw@gmail.com Fri Jun 25 07:16:01 2010 Return-Path: <bouiaw@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A02D3A6A28 for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 07:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.321 X-Spam-Level: X-Spam-Status: No, score=-2.321 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IOprPeJC6Zn3 for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 07:15:57 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id AA23728B797 for <oauth@ietf.org>; Fri, 25 Jun 2010 07:15:51 -0700 (PDT) Received: by wye20 with SMTP id 20so2376799wye.31 for <oauth@ietf.org>; Fri, 25 Jun 2010 07:15:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=NlyOva4+ta1H2QDXTR1m7I6wRDWUoNxpzMitCzdLvn4=; b=JwdQDFf44WDyrH2195sErU/FrtzStcwPSzFIO8bF/r1gk3+3h9gGFYIy0rKBDJrI/T SyoJSLtu95azDGt5JcSmgBrJJQfj4FtNtcJen5LNeqheKKEWNMCZKZmFu7/tGIe+BQlx 28oCtkUh6L+Zq+CLE7JgzPhz39av7K6/dCjVE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ZEpdg4yStCZb/yfQkJhZZXl1TVAPhbjUtlZO5udgeuvmLagBk7o6KbIs4bBi6fNXaO JE9ayzO6nIc2wGW7MAPmWqb3DRxV5RALjzOcKqXV6UuOKVxCsEDjgZQUslubn3e+50XW XkMnZataOsXsyb3aReXTB2CjpTUIvoM33mYP0= MIME-Version: 1.0 Received: by 10.216.154.210 with SMTP id h60mr5161287wek.50.1277474904398; Fri, 25 Jun 2010 07:08:24 -0700 (PDT) Received: by 10.216.181.78 with HTTP; Fri, 25 Jun 2010 07:08:24 -0700 (PDT) In-Reply-To: <AANLkTimvvwzUhCBS3Nlq6Q5odfGTJkv-AYGoUGfS47SJ@mail.gmail.com> References: <AANLkTikbz5zmILsegGXoj6YjdC8h4TPfscqDMqFCB7l-@mail.gmail.com> <AANLkTimvvwzUhCBS3Nlq6Q5odfGTJkv-AYGoUGfS47SJ@mail.gmail.com> Date: Fri, 25 Jun 2010 16:08:24 +0200 Message-ID: <AANLkTinzJdhKYYyD77ueXrePoLtz6czFkjsyUNAi6hbC@mail.gmail.com> From: Bouiaw <bouiaw@gmail.com> To: Marius Scurtescu <mscurtescu@google.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Brian Dunnington <briandunnington@gmail.com>, oauth@ietf.org Subject: Re: [OAUTH-WG] client secret used in Native App profile X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 25 Jun 2010 14:16:01 -0000 If we consider HTML5 browser, I am not sure there is a clear separation betweeen native apps and user agent clients. What is the technical difference between a native app and a browser that support HTML 5 localStorage ? On Fri, Jun 25, 2010 at 9:22 AM, Marius Scurtescu <mscurtescu@google.com> w= rote: > I think the main difference is that User-Agent clients (aka JavaScript > clients) cannot store a secret while Native Apps can safely store a > secret, but the secret cannot be distributed (or, even if it can be > distributed, it may not have much value). > > The difference is important. Each native app instance could require a > registration phase that would provide a unique secret and possibly Id. > This registration phase could be completely automatic or could involve > the end user. There have been proposals for both. How much value there > is in such a registration is not clear to me. > > Marius > > > > On Thu, Jun 24, 2010 at 6:50 PM, Brian Dunnington > <briandunnington@gmail.com> wrote: >> In the 'User-Agent' profile, it says: >> >> "This user-agent profile does not utilize the client secret since the >> =A0 client executables reside on the end-user's computer or device which >> =A0 makes the client secret accessible and exploitable" >> >> However, the 'Native Apps' profile does not include such verbiage and >> in fact specifically requires the use of the client secret. Native >> apps' executables also reside on the end-user's computer or device, >> making the client secret just as accessible and exploitable, so why >> the difference? >> >> Specifically, as a native app developer, there is no good (secure) way >> to distribute the client secret without it being compromised. Any >> open-source application would have even more problems keeping their >> secret secure, but even complied apps are easily exploitable. in this >> scenario, there is no single, secure repository to keep the client >> secret safe, so I would expect that the requirement of the client >> secret for native apps be removed and made conformant with the >> user-agent profile. >> _______________________________________________ >> OAuth mailing 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 jricher@mitre.org Fri Jun 25 07:26:44 2010 Return-Path: <jricher@mitre.org> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDA683A699F for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 07:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.807 X-Spam-Level: X-Spam-Status: No, score=-5.807 tagged_above=-999 required=5 tests=[AWL=0.792, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yp3KrrJPctio for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 07:26:43 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id E4B8B3A697A for <oauth@ietf.org>; Fri, 25 Jun 2010 07:26:42 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o5PEQpLr032516 for <oauth@ietf.org>; Fri, 25 Jun 2010 10:26:51 -0400 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o5PEQplk032511; Fri, 25 Jun 2010 10:26:51 -0400 Received: from [129.83.50.65] (129.83.50.65) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server id 8.2.254.0; Fri, 25 Jun 2010 10:26:50 -0400 From: Justin Richer <jricher@mitre.org> To: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com> In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B450286986B@FIESEXC015.nsn-intra.net> References: <3D3C75174CB95F42AD6BCC56E5555B4502BE07CC@FIESEXC015.nsn-intra.net> <E7A7F197-3BBC-43F2-8242-D0164057A39A@gmail.com> <AANLkTild51WHVcXxYFCygL8sGSGiN3HILDFwIbym6Lfi@mail.gmail.com> <3D3C75174CB95F42AD6BCC56E5555B4502869858@FIESEXC015.nsn-intra.net> <012AB2B223CB3F4BB846962876F47217059B663D@SNV-EXVS08.ds.corp.yahoo.com> <3D3C75174CB95F42AD6BCC56E5555B450286986B@FIESEXC015.nsn-intra.net> Content-Type: text/plain; charset="UTF-8" Date: Fri, 25 Jun 2010 10:26:50 -0400 Message-ID: <1277476010.28743.55.camel@localhost.localdomain> MIME-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 25 Jun 2010 14:26:45 -0000 I don't agree: these values are still opaque to OAuth. They're not opaque to the client and server, they're part of the API. But the client -- and by "client" here I mean the whole client application, not just the OAuth client -- needs to know what they're for. In the same fashion, the client needs to know where to send the tokens to get user photos. What's more important is that the functionality around the OAuth transaction be transparent to any OAuth implementation or library. I should be able to build a Facebook client on top of any compliant OAuth library. Well, once Facebook is compliant of course. ;) But that client should be able to call oauthReq.setScopes("user_photos", "user_videos", "publish_stream") from a library and have it passed through the system as expected. -- Justin On Fri, 2010-06-25 at 03:59 -0400, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > Dick pointed me to the Facebook API on how scope is used. > The main page is here: > http://developers.facebook.com/docs/authentication/ > > It describes the basic functionality and also lists an example: > > " > https://graph.facebook.com/oauth/authorize? > client_id=...& > redirect_uri=http://www.example.com/callback& > scope=user_photos,user_videos,publish_stream > " > > The values of the scope parameter are then explained here: > http://developers.facebook.com/docs/authentication/permissions > > Example: user_photos ... Provides access to the photos the user has uploaded > > I think it provides a good example that the scope values are not opaque. > Opaque (in this context) means that only the entity creating it needs to understand it and nobody else. Here the client needs to understand and set them. > > However, one could argue that the scope values are already bound to the specific entity the client requests to obtain the assertion from. In this specific case it would be "https://graph.facebook.com". > > To respond to the statement Dick made about having standardized values later there would still be the need to decide about the structure of the values now. One possibility is to just add a prefix for standardized values that are not allowed to be used in other cases, such as "std:". > > Ciao > Hannes > > > > -----Original Message----- > > From: ext William Mills [mailto:wmills@yahoo-inc.com] > > Sent: Thursday, June 24, 2010 8:15 PM > > To: Tschofenig, Hannes (NSN - FI/Espoo); ext Lukas > > Rosenstock; Dick Hardt > > Cc: OAuth WG > > Subject: RE: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? > > > > I'm in favor of having a spaces separated list of tokens. > > The only case I can think of where the client needs to handle > > the scope as anything other than opaque is when it is > > accessing multiple services. To reduce the numebr of login > > events the client will have to poll all the endpoints it > > wants to access and get all the scopes advertized by them and > > submit them all, and once it has them it needs to submit all > > of them in it's auth request, so we need something that's > > easy for the client to put together. > > > > > > -bill > > > > > -----Original Message----- > > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] > > > On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) > > > Sent: Thursday, June 24, 2010 3:58 AM > > > To: ext Lukas Rosenstock; Dick Hardt > > > Cc: OAuth WG > > > Subject: Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? > > > > > > The question is whether one would ever want to have a > > > standardized semantic for the scope parameter. > > > If the answer to that question is "no" then it does not > > > matter what the format is. It can well be a list of > > > space-delimited strings (as it is currently defined). > > > > > > An evironment specific semantic works well in cases where > > > entity X sets the value and later it receives the value > > > again. Only entity X needs to understand what it means. > > > > > > In some environments the use case is slightly different, > > > namely entity X and entity Y are from the same organization > > > and agree on the semantic. Usage of OAuth within an > > > enterprise might be such a case. > > > > > > Now, the usage of the scope parameter is, however, a bit > > > different in the spec. Section 4, for example, describes how > > > a client obtains an access token. How does the client know > > > what scope parameters to set and what the semantic is? > > > > > > Ciao > > > Hannes > > > > > > > -----Original Message----- > > > > From: ext Lukas Rosenstock [mailto:lr@lukasrosenstock.net] > > > > Sent: Thursday, June 24, 2010 10:49 AM > > > > To: Dick Hardt > > > > Cc: Tschofenig, Hannes (NSN - FI/Espoo); OAuth WG > > > > Subject: Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? > > > > > > > > Wasn't there some concensus that URIs would be good for > > scope? They > > > > have "in-built namespacing" ... > > > > > > > > Lukas > > > > > > > > 2010/6/23 Dick Hardt <dick.hardt@gmail.com>: > > > > > > > > > > On 2010-06-22, at 11:07 PM, Tschofenig, Hannes (NSN - > > > > FI/Espoo) wrote: > > > > > > > > > >> " > > > > >> scope > > > > >> OPTIONAL. The scope of the access request > > > > expressed as a list > > > > >> of space-delimited strings. The value of the > > > > "scope" parameter > > > > >> is defined by the authorization server. If the > > > > value contains > > > > >> multiple space-delimited strings, their order does > > > > not matter, > > > > >> and each string adds an additional access range to the > > > > >> requested scope. > > > > >> " > > > > >> > > > > >> Do folks think it would be useful to have standardized values? > > > > > > > > > > Not at this time. The semantics of scope are all over the > > > > place. If standardized, people will feel they need to pick > > > one that is > > > > close to what they want, but is not exactly what they mean. > > > I think it > > > > is better for the AS to define what they mean by a scope > > > and give it a > > > > name that makes sense in that context. > > > > > > > > > >> > > > > >> If the answer is "yes", then it would be useful to > > > > differentiate the > > > > >> standardized values from those values that are purely > > > > defined locally by > > > > >> the authorization server. > > > > > > > _______________________________________________ > > > OAuth mailing 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 breno.demedeiros@gmail.com Fri Jun 25 07:40:37 2010 Return-Path: <breno.demedeiros@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A958F3A694A for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 07:40:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3OlXUcy4H3KJ for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 07:40:34 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id F120D3A689F for <oauth@ietf.org>; Fri, 25 Jun 2010 07:40:32 -0700 (PDT) Received: by gyh4 with SMTP id 4so5381894gyh.31 for <oauth@ietf.org>; Fri, 25 Jun 2010 07:40:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:received :in-reply-to:references:date:message-id:subject:from:to:cc :content-type; bh=M2GiEjMtTTbZ37b5Qy/vCx2svsDY5NAgI17ze1oMv10=; b=SRY1blI8376vI3HP745DdrdNkrBHf3QUFQjWHXMRCSxm/U1N9eYpb4Fq+EVhogbpVD t44YXWSFYOmG2LGDNQDhvjjgsYDH69DU/6qRhffrGUcM5/vfzGJpb5v9hL8qHrGofrjb 4MSa+uABaxT4irUO7diOBVPsu3DGlb4xTUsKY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=iMXlztJkzG0lYWfK7w5YpWb4X6VwarHUwD83qSqcNwuMvROTjIldPEHvhchxFLOOmS qCFZXZ++a7RbIjBpAapD0vTXQYOJLIVechGYoiVOqSXUeVfa/xgcbBL3tS4dv1Hp6gC7 iVXGRAu5/Vqyya3mTA4nJTRn3nFXCFegqUbFk= MIME-Version: 1.0 Received: by 10.100.189.5 with SMTP id m5mr1068595anf.257.1277476837690; Fri, 25 Jun 2010 07:40:37 -0700 (PDT) Received: by 10.100.225.19 with HTTP; Fri, 25 Jun 2010 07:40:36 -0700 (PDT) Received: by 10.100.225.19 with HTTP; Fri, 25 Jun 2010 07:40:36 -0700 (PDT) In-Reply-To: <AANLkTilAjh9Jl0__9jksh3eY7giVR6Wtr0NYNoFfYHZX@mail.gmail.com> References: <AANLkTingCgO-o3XRZbxYoD8U2rRTO-EgWcfg2hBlbQHm@mail.gmail.com> <AANLkTinZ1XIFO25mcgoiDV-V0Blvv8ZC6kV_F3fca3dC@mail.gmail.com> <4C5BCAC6-713F-4C42-8696-2931D1AB3199@gmail.com> <AANLkTinlATNBEQsmFJIxv_cgqfI_tsoGfTMy6OXN6F_B@mail.gmail.com> <A08279DC79B11C48AD587060CD9397712735068D@TK5EX14MBXC101.redmond.corp.microsoft.com> <AANLkTimLrZzwDW9rMtGjD9k6ZtXc_oDXIIIYWOMw-NCi@mail.gmail.com> <AANLkTilcn_qQLgriJEdPk95f2Zliyk0QXGvU6t77Aa7G@mail.gmail.com> <AANLkTinEjidY_HmcGHPTus7P1snjCl9DPL4dX-Sz_mTQ@mail.gmail.com> <AANLkTilRUQiD5oRyxUZXmPs2skCY8zAmc1Vl--8pEblS@mail.gmail.com> <AANLkTilAjh9Jl0__9jksh3eY7giVR6Wtr0NYNoFfYHZX@mail.gmail.com> Date: Fri, 25 Jun 2010 07:40:36 -0700 Message-ID: <AANLkTil3NxM_TmrusslVpCTqwqA8AEtH_vPsHnxkrcE3@mail.gmail.com> From: Breno <breno.demedeiros@gmail.com> To: Ben Laurie <benl@google.com> Content-Type: multipart/alternative; boundary=001485f91f061e8e5b0489dbc1b8 Cc: "Hannes.Tschofenig@gmx.net" <Hannes.Tschofenig@gmx.net>, OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] proposal for signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 25 Jun 2010 14:40:38 -0000 --001485f91f061e8e5b0489dbc1b8 Content-Type: text/plain; charset=ISO-8859-1 Key ids are an optimization in the case of rotating public keys, but pretty much an operational requirement if you wish to support automatic rotation of shared keys. On Jun 23, 2010 2:56 AM, "Ben Laurie" <benl@google.com> wrote: On 22 June 2010 21:45, David Recordon <recordond@gmail.com> wrote: > Hey Dick, in answering my quest... I don't understand why they are unnecessary no matter how keys are managed: if there's ever a possibility that you might have more than one key for someone, then key IDs are a useful optimisation. Put it another way: what's the purpose of leaving out the key ID? > And yes, Applied Cryptography is worth reading. :) > > --David > > > On Tue, Jun 22, 2010 at 12:5... --001485f91f061e8e5b0489dbc1b8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <p>Key ids are an optimization in the case of rotating public keys, but pre= tty much an operational requirement if you wish to support automatic rotati= on of shared keys. </p> <p><blockquote type=3D"cite">On Jun 23, 2010 2:56 AM, "Ben Laurie"= ; <<a href=3D"mailto:benl@google.com">benl@google.com</a>> wrote:<br>= <br><p><font color=3D"#500050">On 22 June 2010 21:45, David Recordon <<a= href=3D"mailto:recordond@gmail.com">recordond@gmail.com</a>> wrote:<br> > Hey Dick, in answering my quest...</font></p>I don't understand wh= y they are unnecessary no matter how keys are<br> managed: if there's ever a possibility that you might have more than<br= > one key for someone, then key IDs are a useful optimisation.<br> <br> Put it another way: what's the purpose of leaving out the key ID?<br> <p><font color=3D"#500050"><br>> And yes, Applied Cryptography is worth = reading. :)<br>><br>> --David<br>><br>><br>> On Tue, Jun 22,= 2010 at 12:5...</font></p></blockquote></p> --001485f91f061e8e5b0489dbc1b8-- From romeda@gmail.com Fri Jun 25 07:53:02 2010 Return-Path: <romeda@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9163F3A6956 for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 07:53:02 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M36WfhPnOHv8 for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 07:52:59 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 98D063A6832 for <oauth@ietf.org>; Fri, 25 Jun 2010 07:52:59 -0700 (PDT) Received: by pvc21 with SMTP id 21so1300231pvc.31 for <oauth@ietf.org>; Fri, 25 Jun 2010 07:53:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=pQL7NfqJ3BlUnmyF1e+W/X63Pj1VMG10Em6haeMiVGo=; b=u4+IUGgkZ6oIuTR1Vt8IiD4WFh5sOMTekpBYmvzgdtHDaHjGAwPKWsRfcjBPOUUpDL vYjnlDqe/f1TrjOGU61V/2a7RuAp6ra6C7zbbfAlidj0X5xM4XppWJwODnZuPe8uj+h3 9qTOY0+EJf0hx/wzvf/JMOxuv5eca/idu9nes= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=J3I76lmO97+2P1GfFUcUKTSm6mj3dVULULA7gHVRJFkUn8r7AVA3Nhv7RWHovkyZCJ YSZ5rWFhW3k0l2tDDgop5hCJbVZWZSpBrQWnt1VKTfpJnqDvA2BNNOG0X96xcmvfpPTb eJg7scOdginT7X9f8NyFQYtl4Bw8mZxU40MAw= Received: by 10.143.26.19 with SMTP id d19mr1012285wfj.160.1277477584505; Fri, 25 Jun 2010 07:53:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.41.11 with HTTP; Fri, 25 Jun 2010 07:52:44 -0700 (PDT) In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B450286986B@FIESEXC015.nsn-intra.net> References: <3D3C75174CB95F42AD6BCC56E5555B4502BE07CC@FIESEXC015.nsn-intra.net> <E7A7F197-3BBC-43F2-8242-D0164057A39A@gmail.com> <AANLkTild51WHVcXxYFCygL8sGSGiN3HILDFwIbym6Lfi@mail.gmail.com> <3D3C75174CB95F42AD6BCC56E5555B4502869858@FIESEXC015.nsn-intra.net> <012AB2B223CB3F4BB846962876F47217059B663D@SNV-EXVS08.ds.corp.yahoo.com> <3D3C75174CB95F42AD6BCC56E5555B450286986B@FIESEXC015.nsn-intra.net> From: Blaine Cook <romeda@gmail.com> Date: Fri, 25 Jun 2010 15:52:44 +0100 Message-ID: <AANLkTinOJ-t3XLweZpcWbgtKKGlCfVD_-Md08hVsCXM9@mail.gmail.com> To: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 25 Jun 2010 14:53:02 -0000 I agree with Dick that the scope should remain out of scope for OAuth. ;-) Having a shared parameter here gives the illusion of interoperability, but because there's no common understanding of permissible scopes, there's no way to guarantee that any given client-server pair could expect to produce predictable outcomes. Furthermore, limiting the format of the scope prematurely means that we give up on a whole set of possibilities before we've even had a chance to see what those possibilities are. For example, YQL might want to allow a scope to be defined like "SELECT * FROM flickr" or something similar. Maybe scope is implicit in assertions, or even explicit. Scope might be tied to the degree to which the requesting and/or granting parties are trusted by the service provider. If there were a compelling story about how scope is supposed to realistically achieve greater interoperability, it might be worthwhile for us to consider it. In the meantime, though, I think it just represents the same featuritis drive that got us an under-specified (and more harmful than helpful) version parameter in OAuth 1.0. b. On 25 June 2010 08:59, Tschofenig, Hannes (NSN - FI/Espoo) <hannes.tschofenig@nsn.com> wrote: > Dick pointed me to the Facebook API on how scope is used. > The main page is here: > http://developers.facebook.com/docs/authentication/ > > It describes the basic functionality and also lists an example: > > " > https://graph.facebook.com/oauth/authorize? > =C2=A0 =C2=A0client_id=3D...& > =C2=A0 =C2=A0redirect_uri=3Dhttp://www.example.com/callback& > =C2=A0 =C2=A0scope=3Duser_photos,user_videos,publish_stream > " > > The values of the scope parameter are then explained here: > http://developers.facebook.com/docs/authentication/permissions > > Example: user_photos ... Provides access to the photos the user has uploa= ded > > I think it provides a good example that the scope values are not opaque. > Opaque (in this context) means that only the entity creating it needs to = understand it and nobody else. Here the client needs to understand and set = them. > > However, one could argue that the scope values are already bound to the s= pecific entity the client requests to obtain the assertion from. In this sp= ecific case it would be "https://graph.facebook.com". > > To respond to the statement Dick made about having standardized values la= ter there would still be the need to decide about the structure of the valu= es now. One possibility is to just add a prefix for standardized values tha= t are not allowed to be used in other cases, such as "std:". > > Ciao > Hannes > > >> -----Original Message----- >> From: ext William Mills [mailto:wmills@yahoo-inc.com] >> Sent: Thursday, June 24, 2010 8:15 PM >> To: Tschofenig, Hannes (NSN - FI/Espoo); ext Lukas >> Rosenstock; Dick Hardt >> Cc: OAuth WG >> Subject: RE: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? >> >> I'm in favor of having a spaces separated list of tokens. >> The only case I can think of where the client needs to handle >> the scope as anything other than opaque is when it is >> accessing multiple services. =C2=A0To reduce the numebr of login >> events the client will have to poll all the endpoints it >> wants to access and get all the scopes advertized by them and >> submit them all, and once it has them it needs to submit all >> of them in it's auth request, so we need something that's >> easy for the client to put together. >> >> >> -bill >> >> > -----Original Message----- >> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] >> > On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) >> > Sent: Thursday, June 24, 2010 3:58 AM >> > To: ext Lukas Rosenstock; Dick Hardt >> > Cc: OAuth WG >> > Subject: Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? >> > >> > The question is whether one would ever want to have a >> > standardized semantic for the scope parameter. >> > If the answer to that question is "no" then it does not >> > matter what the format is. It can well be a list of >> > space-delimited strings (as it is currently defined). >> > >> > An evironment specific semantic works well in cases where >> > entity X sets the value and later it receives the value >> > again. Only entity X needs to understand what it means. >> > >> > In some environments the use case is slightly different, >> > namely entity X and entity Y are from the same organization >> > and agree on the semantic. Usage of OAuth within an >> > enterprise might be such a case. >> > >> > Now, the usage of the scope parameter is, however, a bit >> > different in the spec. Section 4, for example, describes how >> > a client obtains an access token. How does the client know >> > what scope parameters to set and what the semantic is? >> > >> > Ciao >> > Hannes >> > >> > > -----Original Message----- >> > > From: ext Lukas Rosenstock [mailto:lr@lukasrosenstock.net] >> > > Sent: Thursday, June 24, 2010 10:49 AM >> > > To: Dick Hardt >> > > Cc: Tschofenig, Hannes (NSN - FI/Espoo); OAuth WG >> > > Subject: Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? >> > > >> > > Wasn't there some concensus that URIs would be good for >> scope? They >> > > have "in-built namespacing" ... >> > > >> > > Lukas >> > > >> > > 2010/6/23 Dick Hardt <dick.hardt@gmail.com>: >> > > > >> > > > On 2010-06-22, at 11:07 PM, Tschofenig, Hannes (NSN - >> > > FI/Espoo) wrote: >> > > > >> > > >> " >> > > >> =C2=A0 scope >> > > >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 OPTIONAL. =C2=A0The scope of the acce= ss request >> > > expressed as a list >> > > >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 of space-delimited strings. =C2=A0The= value of the >> > > "scope" parameter >> > > >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 is defined by the authorization serve= r. =C2=A0If the >> > > value contains >> > > >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 multiple space-delimited strings, the= ir order does >> > > not matter, >> > > >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 and each string adds an additional ac= cess range to the >> > > >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 requested scope. >> > > >> " >> > > >> >> > > >> Do folks think it would be useful to have standardized values? >> > > > >> > > > Not at this time. The semantics of scope are all over the >> > > place. If standardized, people will feel they need to pick >> > one that is >> > > close to what they want, but is not exactly what they mean. >> > I think it >> > > is better for the AS to define what they mean by a scope >> > and give it a >> > > name that makes sense in that context. >> > > > >> > > >> >> > > >> If the answer is "yes", then it would be useful to >> > > differentiate the >> > > >> standardized values from those values that are purely >> > > defined locally by >> > > >> the authorization server. >> > > >> > _______________________________________________ >> > OAuth mailing 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 dick.hardt@gmail.com Fri Jun 25 08:49:50 2010 Return-Path: <dick.hardt@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3D2C3A6802 for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 08:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.453 X-Spam-Level: X-Spam-Status: No, score=-2.453 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tsFkSPzPokkO for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 08:49:49 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id 374EF3A67CC for <oauth@ietf.org>; Fri, 25 Jun 2010 08:49:49 -0700 (PDT) Received: by pxi16 with SMTP id 16so144931pxi.31 for <oauth@ietf.org>; Fri, 25 Jun 2010 08:49:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=7my05152UXODuUHyRAevVV4DNHGaayuLdL5HcXgzdCo=; b=VBBIMBNjSLLXOykftTQFP7gdR2ZpuIR4e+i7kFU4lAscEpCQfmIf7FO2KN4j6ZZMvi YoqfJaZ+t30x/0Ym5uJBB2+S6PvCsEnMNU2TcxbL3GOpoF0q7nF6/O2OWzAYHTtL4H5K G2/uYkOp1KUlbXsZyuZKQ4UXq6rgQiU1dIvGU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=domfo4RVO3ajFs1wtpHhyyTIDYIz8h0OOdGr1R/RSPdXnM8fnWEVd4igno9oY/HVYf e7a+xaimZH538ofqKC9dL7c/UL50moB9PBm7UipD9dR7doSkfaO15omsbc5ArAdzTQHE Xw0fg9Q51axyWxJvNaUDxwdi/qDJs2VBc9eVk= Received: by 10.143.26.21 with SMTP id d21mr1109056wfj.225.1277480993217; Fri, 25 Jun 2010 08:49:53 -0700 (PDT) Received: from [192.168.1.2] ([24.130.32.55]) by mx.google.com with ESMTPS id x35sm4083672wfh.6.2010.06.25.08.49.51 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 25 Jun 2010 08:49:52 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Dick Hardt <dick.hardt@gmail.com> In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B450286986B@FIESEXC015.nsn-intra.net> Date: Fri, 25 Jun 2010 08:49:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9BBAE9AB-A0CD-448F-B817-21389C1BBCAF@gmail.com> References: <3D3C75174CB95F42AD6BCC56E5555B4502BE07CC@FIESEXC015.nsn-intra.net><E7A7F197-3BBC-43F2-8242-D0164057A39A@gmail.com><AANLkTild51WHVcXxYFCygL8sGSGiN3HILDFwIbym6Lfi@mail.gmail.com> <3D3C75174CB95F42AD6BCC56E5555B4502869858@FIESEXC015.nsn-intra.net> <012AB2B223CB3F4BB846962876F47217059B663D@SNV-EXVS08.ds.corp.yahoo.com> <3D3C75174CB95F42AD6BCC56E5555B450286986B@FIESEXC015.nsn-intra.net> To: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com> X-Mailer: Apple Mail (2.1078) Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 25 Jun 2010 15:49:51 -0000 To clarify, the goal is to reserve a namespace for future use so that = near term implementations won't collide? I expect the standardization of scope values to not be in OAuth, but in = standardized APIs that use OAuth, so a namespace mechanism that = differentiates between a standardized scope and an implementation = specific scope may be useful. =46rom what I have gathered, implementors are leaning towards simple = strings rather than URIs to declare scope. Perhaps reserving the ":" = character from being in a scope string unless the scope prefix has been = registered with IANA? -- Dick On 2010-06-25, at 12:59 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > Dick pointed me to the Facebook API on how scope is used.=20 > The main page is here:=20 > http://developers.facebook.com/docs/authentication/ >=20 > It describes the basic functionality and also lists an example:=20 >=20 > " > https://graph.facebook.com/oauth/authorize? > client_id=3D...& > redirect_uri=3Dhttp://www.example.com/callback& > scope=3Duser_photos,user_videos,publish_stream > " >=20 > The values of the scope parameter are then explained here:=20 > http://developers.facebook.com/docs/authentication/permissions >=20 > Example: user_photos ... Provides access to the photos the user has = uploaded >=20 > I think it provides a good example that the scope values are not = opaque. =20 > Opaque (in this context) means that only the entity creating it needs = to understand it and nobody else. Here the client needs to understand = and set them.=20 >=20 > However, one could argue that the scope values are already bound to = the specific entity the client requests to obtain the assertion from. In = this specific case it would be "https://graph.facebook.com".=20 >=20 > To respond to the statement Dick made about having standardized values = later there would still be the need to decide about the structure of the = values now. One possibility is to just add a prefix for standardized = values that are not allowed to be used in other cases, such as "std:".=20= >=20 > Ciao > Hannes >=20 >=20 >> -----Original Message----- >> From: ext William Mills [mailto:wmills@yahoo-inc.com]=20 >> Sent: Thursday, June 24, 2010 8:15 PM >> To: Tschofenig, Hannes (NSN - FI/Espoo); ext Lukas=20 >> Rosenstock; Dick Hardt >> Cc: OAuth WG >> Subject: RE: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? >>=20 >> I'm in favor of having a spaces separated list of tokens. =20 >> The only case I can think of where the client needs to handle=20 >> the scope as anything other than opaque is when it is=20 >> accessing multiple services. To reduce the numebr of login=20 >> events the client will have to poll all the endpoints it=20 >> wants to access and get all the scopes advertized by them and=20 >> submit them all, and once it has them it needs to submit all=20 >> of them in it's auth request, so we need something that's=20 >> easy for the client to put together. >>=20 >>=20 >> -bill >>=20 >>> -----Original Message----- >>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]=20 >>> On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) >>> Sent: Thursday, June 24, 2010 3:58 AM >>> To: ext Lukas Rosenstock; Dick Hardt >>> Cc: OAuth WG >>> Subject: Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? >>>=20 >>> The question is whether one would ever want to have a=20 >>> standardized semantic for the scope parameter.=20 >>> If the answer to that question is "no" then it does not=20 >>> matter what the format is. It can well be a list of =20 >>> space-delimited strings (as it is currently defined).=20 >>>=20 >>> An evironment specific semantic works well in cases where=20 >>> entity X sets the value and later it receives the value=20 >>> again. Only entity X needs to understand what it means. >>>=20 >>> In some environments the use case is slightly different,=20 >>> namely entity X and entity Y are from the same organization=20 >>> and agree on the semantic. Usage of OAuth within an=20 >>> enterprise might be such a case.=20 >>>=20 >>> Now, the usage of the scope parameter is, however, a bit=20 >>> different in the spec. Section 4, for example, describes how=20 >>> a client obtains an access token. How does the client know=20 >>> what scope parameters to set and what the semantic is? >>>=20 >>> Ciao >>> Hannes >>>=20 >>>> -----Original Message----- >>>> From: ext Lukas Rosenstock [mailto:lr@lukasrosenstock.net] >>>> Sent: Thursday, June 24, 2010 10:49 AM >>>> To: Dick Hardt >>>> Cc: Tschofenig, Hannes (NSN - FI/Espoo); OAuth WG >>>> Subject: Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? >>>>=20 >>>> Wasn't there some concensus that URIs would be good for=20 >> scope? They=20 >>>> have "in-built namespacing" ... >>>>=20 >>>> Lukas >>>>=20 >>>> 2010/6/23 Dick Hardt <dick.hardt@gmail.com>: >>>>>=20 >>>>> On 2010-06-22, at 11:07 PM, Tschofenig, Hannes (NSN - >>>> FI/Espoo) wrote: >>>>>=20 >>>>>> " >>>>>> scope >>>>>> OPTIONAL. The scope of the access request >>>> expressed as a list >>>>>> of space-delimited strings. The value of the >>>> "scope" parameter >>>>>> is defined by the authorization server. If the >>>> value contains >>>>>> multiple space-delimited strings, their order does >>>> not matter, >>>>>> and each string adds an additional access range to the >>>>>> requested scope. >>>>>> " >>>>>>=20 >>>>>> Do folks think it would be useful to have standardized values? >>>>>=20 >>>>> Not at this time. The semantics of scope are all over the >>>> place. If standardized, people will feel they need to pick=20 >>> one that is=20 >>>> close to what they want, but is not exactly what they mean.=20 >>> I think it=20 >>>> is better for the AS to define what they mean by a scope=20 >>> and give it a=20 >>>> name that makes sense in that context. >>>>>=20 >>>>>>=20 >>>>>> If the answer is "yes", then it would be useful to >>>> differentiate the >>>>>> standardized values from those values that are purely >>>> defined locally by >>>>>> the authorization server. >>>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>=20 From dick.hardt@gmail.com Fri Jun 25 08:54:29 2010 Return-Path: <dick.hardt@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A78793A67CC for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 08:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.461 X-Spam-Level: X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WDGnAP3XIVMN for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 08:54:28 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id 4F9553A689D for <oauth@ietf.org>; Fri, 25 Jun 2010 08:54:28 -0700 (PDT) Received: by pxi16 with SMTP id 16so147077pxi.31 for <oauth@ietf.org>; Fri, 25 Jun 2010 08:54:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=gYQbeFfV6DGQKI8eDosXsobpXiIebVttqBkWRhyhEic=; b=KKThWxvw4hAcGVmw+5j/gKxTkRVWmswgV6xhjGS+yPlfYMbsxo8peLk1iYuMksrLHx lie+qxhq6XhR+mCihjuvLxR5tDl45rTq1f4THZ2ZIvNXOlDq3lPje6EAZzmQuOGXlaus D54Hs3eYeTdXVTi5HIo5+B7oU3ifIpf9Ka4eU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=MDjRtevZQLROsn9PD6L7khou20PTUXNW6Hmgzjr5xECBykeSaO7x7UbonUN0x3Kpdh u+yt4f9d37JIa+4Yn3WySO+cuxpfcz3Cz9jlXUHDJwMdL28mLiHba4wsx/tnhYq7JkxO 3R6ypgawO48htfnpW6YsLA9F4i821+h/9COxc= Received: by 10.143.24.11 with SMTP id b11mr1175950wfj.215.1277481274412; Fri, 25 Jun 2010 08:54:34 -0700 (PDT) Received: from [192.168.1.2] (c-24-130-32-55.hsd1.ca.comcast.net [24.130.32.55]) by mx.google.com with ESMTPS id h11sm664619rvm.8.2010.06.25.08.54.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 25 Jun 2010 08:54:33 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Dick Hardt <dick.hardt@gmail.com> In-Reply-To: <AANLkTinOJ-t3XLweZpcWbgtKKGlCfVD_-Md08hVsCXM9@mail.gmail.com> Date: Fri, 25 Jun 2010 08:54:31 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <C3ADC775-EC87-42FE-95F1-F96E11094FB1@gmail.com> References: <3D3C75174CB95F42AD6BCC56E5555B4502BE07CC@FIESEXC015.nsn-intra.net> <E7A7F197-3BBC-43F2-8242-D0164057A39A@gmail.com> <AANLkTild51WHVcXxYFCygL8sGSGiN3HILDFwIbym6Lfi@mail.gmail.com> <3D3C75174CB95F42AD6BCC56E5555B4502869858@FIESEXC015.nsn-intra.net> <012AB2B223CB3F4BB846962876F47217059B663D@SNV-EXVS08.ds.corp.yahoo.com> <3D3C75174CB95F42AD6BCC56E5555B450286986B@FIESEXC015.nsn-intra.net> <AANLkTinOJ-t3XLweZpcWbgtKKGlCfVD_-Md08hVsCXM9@mail.gmail.com> To: Blaine Cook <romeda@gmail.com> X-Mailer: Apple Mail (2.1078) Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <hannes.tschofenig@nsn.com>, OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 25 Jun 2010 15:54:29 -0000 Glad to see people agreeing with me. I don't think Hannes was = disagreeing with me though. :) Per my response to Hannes, I think there is value in a small restriction = on scope strings so that we have a reserved format for the future. -- Dick On 2010-06-25, at 7:52 AM, Blaine Cook wrote: > I agree with Dick that the scope should remain out of scope for OAuth. > ;-) Having a shared parameter here gives the illusion of > interoperability, but because there's no common understanding of > permissible scopes, there's no way to guarantee that any given > client-server pair could expect to produce predictable outcomes. >=20 > Furthermore, limiting the format of the scope prematurely means that > we give up on a whole set of possibilities before we've even had a > chance to see what those possibilities are. For example, YQL might > want to allow a scope to be defined like "SELECT * FROM flickr" or > something similar. Maybe scope is implicit in assertions, or even > explicit. Scope might be tied to the degree to which the requesting > and/or granting parties are trusted by the service provider. >=20 > If there were a compelling story about how scope is supposed to > realistically achieve greater interoperability, it might be worthwhile > for us to consider it. In the meantime, though, I think it just > represents the same featuritis drive that got us an under-specified > (and more harmful than helpful) version parameter in OAuth 1.0. >=20 > b. >=20 > On 25 June 2010 08:59, Tschofenig, Hannes (NSN - FI/Espoo) > <hannes.tschofenig@nsn.com> wrote: >> Dick pointed me to the Facebook API on how scope is used. >> The main page is here: >> http://developers.facebook.com/docs/authentication/ >>=20 >> It describes the basic functionality and also lists an example: >>=20 >> " >> https://graph.facebook.com/oauth/authorize? >> client_id=3D...& >> redirect_uri=3Dhttp://www.example.com/callback& >> scope=3Duser_photos,user_videos,publish_stream >> " >>=20 >> The values of the scope parameter are then explained here: >> http://developers.facebook.com/docs/authentication/permissions >>=20 >> Example: user_photos ... Provides access to the photos the user has = uploaded >>=20 >> I think it provides a good example that the scope values are not = opaque. >> Opaque (in this context) means that only the entity creating it needs = to understand it and nobody else. Here the client needs to understand = and set them. >>=20 >> However, one could argue that the scope values are already bound to = the specific entity the client requests to obtain the assertion from. In = this specific case it would be "https://graph.facebook.com". >>=20 >> To respond to the statement Dick made about having standardized = values later there would still be the need to decide about the structure = of the values now. One possibility is to just add a prefix for = standardized values that are not allowed to be used in other cases, such = as "std:". >>=20 >> Ciao >> Hannes >>=20 >>=20 >>> -----Original Message----- >>> From: ext William Mills [mailto:wmills@yahoo-inc.com] >>> Sent: Thursday, June 24, 2010 8:15 PM >>> To: Tschofenig, Hannes (NSN - FI/Espoo); ext Lukas >>> Rosenstock; Dick Hardt >>> Cc: OAuth WG >>> Subject: RE: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? >>>=20 >>> I'm in favor of having a spaces separated list of tokens. >>> The only case I can think of where the client needs to handle >>> the scope as anything other than opaque is when it is >>> accessing multiple services. To reduce the numebr of login >>> events the client will have to poll all the endpoints it >>> wants to access and get all the scopes advertized by them and >>> submit them all, and once it has them it needs to submit all >>> of them in it's auth request, so we need something that's >>> easy for the client to put together. >>>=20 >>>=20 >>> -bill >>>=20 >>>> -----Original Message----- >>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] >>>> On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) >>>> Sent: Thursday, June 24, 2010 3:58 AM >>>> To: ext Lukas Rosenstock; Dick Hardt >>>> Cc: OAuth WG >>>> Subject: Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? >>>>=20 >>>> The question is whether one would ever want to have a >>>> standardized semantic for the scope parameter. >>>> If the answer to that question is "no" then it does not >>>> matter what the format is. It can well be a list of >>>> space-delimited strings (as it is currently defined). >>>>=20 >>>> An evironment specific semantic works well in cases where >>>> entity X sets the value and later it receives the value >>>> again. Only entity X needs to understand what it means. >>>>=20 >>>> In some environments the use case is slightly different, >>>> namely entity X and entity Y are from the same organization >>>> and agree on the semantic. Usage of OAuth within an >>>> enterprise might be such a case. >>>>=20 >>>> Now, the usage of the scope parameter is, however, a bit >>>> different in the spec. Section 4, for example, describes how >>>> a client obtains an access token. How does the client know >>>> what scope parameters to set and what the semantic is? >>>>=20 >>>> Ciao >>>> Hannes >>>>=20 >>>>> -----Original Message----- >>>>> From: ext Lukas Rosenstock [mailto:lr@lukasrosenstock.net] >>>>> Sent: Thursday, June 24, 2010 10:49 AM >>>>> To: Dick Hardt >>>>> Cc: Tschofenig, Hannes (NSN - FI/Espoo); OAuth WG >>>>> Subject: Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? >>>>>=20 >>>>> Wasn't there some concensus that URIs would be good for >>> scope? They >>>>> have "in-built namespacing" ... >>>>>=20 >>>>> Lukas >>>>>=20 >>>>> 2010/6/23 Dick Hardt <dick.hardt@gmail.com>: >>>>>>=20 >>>>>> On 2010-06-22, at 11:07 PM, Tschofenig, Hannes (NSN - >>>>> FI/Espoo) wrote: >>>>>>=20 >>>>>>> " >>>>>>> scope >>>>>>> OPTIONAL. The scope of the access request >>>>> expressed as a list >>>>>>> of space-delimited strings. The value of the >>>>> "scope" parameter >>>>>>> is defined by the authorization server. If the >>>>> value contains >>>>>>> multiple space-delimited strings, their order does >>>>> not matter, >>>>>>> and each string adds an additional access range to the >>>>>>> requested scope. >>>>>>> " >>>>>>>=20 >>>>>>> Do folks think it would be useful to have standardized values? >>>>>>=20 >>>>>> Not at this time. The semantics of scope are all over the >>>>> place. If standardized, people will feel they need to pick >>>> one that is >>>>> close to what they want, but is not exactly what they mean. >>>> I think it >>>>> is better for the AS to define what they mean by a scope >>>> and give it a >>>>> name that makes sense in that context. >>>>>>=20 >>>>>>>=20 >>>>>>> If the answer is "yes", then it would be useful to >>>>> differentiate the >>>>>>> standardized values from those values that are purely >>>>> defined locally by >>>>>>> the authorization server. >>>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 From eran@hueniverse.com Fri Jun 25 09:45:23 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A11528C0F7 for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 09:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.923 X-Spam-Level: X-Spam-Status: No, score=-0.923 tagged_above=-999 required=5 tests=[AWL=-0.924, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fcwrgJx-3sRR for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 09:45:21 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 18BD33A69FE for <oauth@ietf.org>; Fri, 25 Jun 2010 09:45:21 -0700 (PDT) Received: (qmail 25000 invoked from network); 25 Jun 2010 16:45:29 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 25 Jun 2010 16:45:29 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Fri, 25 Jun 2010 09:45:18 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org> Date: Fri, 25 Jun 2010 09:45:01 -0700 Thread-Topic: OAuth meeting notes on -05 (with updates) Thread-Index: AcsMLfi0k1bL/UTuTyKlbQqO9cCDCgIV5u6Q Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EC8492C@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB68D9@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB68D9@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [OAUTH-WG] OAuth meeting notes on -05 (with updates) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 25 Jun 2010 16:45:23 -0000 SSBoYXZlIGNvbXBsZXRlZCBhbGwgbXkgYWN0aW9uIGl0ZW1zLiBJIGhhdmUgbm90IHNlZW4gYW55 IHJlc3BvbnNlcyB0byB0aGlzIGxpc3QgKGluIHR3byB3ZWVrcykgYW5kIHdpbGwgYmUgY2xvc2lu ZyB0aGVzZSBpc3N1ZXMgb24gbXkgZW5kIChlZGl0b3IncyBxdWV1ZSkuIElmIHlvdSBzdGlsbCB3 YW50IHRvIGRpc2N1c3MgdGhpcywgcGxlYXNlIGJyaW5nIGl0IHVwIGFnYWluLg0KDQpFSEwNCg0K PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBvYXV0aC1ib3VuY2VzQGlldGYu b3JnIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmDQo+IE9mIEVyYW4g SGFtbWVyLUxhaGF2DQo+IFNlbnQ6IE1vbmRheSwgSnVuZSAxNCwgMjAxMCAxMTozNSBQTQ0KPiBU bzogT0F1dGggV0cgKG9hdXRoQGlldGYub3JnKQ0KPiBTdWJqZWN0OiBbT0FVVEgtV0ddIE9BdXRo IG1lZXRpbmcgbm90ZXMgb24gLTA1ICh3aXRoIHVwZGF0ZXMpDQo+IA0KPiBEdXJpbmcgdGhlIE9B dXRoIFdHIGludGVyaW0gbWVldGluZywgdGhlIGdyb3VwIHNwZW50IGEgY29uc2lkZXJhYmxlDQo+ IGFtb3VudCBvZiB0aW1lIGdvaW5nIG92ZXIgZHJhZnQgLTA1IGFuZCBsaXN0aW5nIGlzc3VlcyB3 aXRoIHRoZSB0ZXh0IGFuZA0KPiBwcm90b2NvbC4gU2luY2UgdGhlIGRyYWZ0IGlzIG5vdyBzaWdu aWZpY2FudGx5IGRpZmZlcmVudCwgSSB3YW50IHRvIGdvIG92ZXIgdGhpcw0KPiBhbmQgaWRlbnRp ZnkgdGhlIGlzc3VlcyByZXNvbHZlZCBhbmQgdGhvc2Ugc3RpbGwgb3BlbiAoYmVmb3JlIGl0IGlz IHRvbyBsYXRlKS4NCj4gDQo+IFRoZXNlIGNvbW1lbnRzIGFyZSBiYXNlZCBvbiBCcmlhbiBFYXRv bidzIGRldGFpbGVkIG5vdGVzICh0aGFua3MhKSB3aXRoIG15DQo+IGVkaXRzLiBJIHJlbW92ZWQg Y29tbWVudHMgdGhhdCB3ZXJlIG5vdCBhY3Rpb25hYmxlLiBJIGtlcHQgdGhlIG5hbWVzIG5leHQN Cj4gdG8gY29tbWVudHMgd2hlcmUgYWRkaXRpb25hbCBjbGFyaWZpY2F0aW9ucyBhcmUgbmVlZGVk LiBJZiB0aGUgbm90ZXMgYXJlDQo+IHdyb25nLCBibGFtZSBtZSBmb3IgbWVzc2luZyB3aXRoIHRo ZSBCcmlhbidzIGNvcHkuDQo+IA0KPiBBY3Rpb24gaXRlbXMgYXJlIG1hcmtlZCB3aXRoICoqKi4N Cj4gDQo+IE92ZXJhbGwsIEkgdGhpbmsgYnkgLTA5IHdlIHdpbGwgYmUgZG9uZSB3aXRoIG1vc3Qg b2YgdGhlIGNvbW1lbnRzIChyZWFkeSBmb3INCj4gYW5vdGhlciBiYXRjaCkuDQo+IA0KPiBFSEwN Cj4gDQo+IC0tLQ0KPiANCj4gPiBJbnRyb2R1Y3Rpb246DQo+ID4NCj4gPiAtIEFkZCBwdXJwb3Nl cyAvIHVzZSBjYXNlcw0KPiA+IC0gRGVzY3JpYmUgaG93IGl0IHJlbGF0ZXMgdG8gb3RoZXIgYXV0 aGVudGljYXRpb24gc2NoZW1lcyAoT3BlbklELA0KPiA+IEhUVFAgQXV0aCkNCj4gPiAtIE1vdmUg cmVxdWlyZW1lbnRzIG91dCBvZiB0aGUgaW50cm9kdWN0aW9uDQo+ID4gLSBEZXNjcmliZSBnb2Fs cyBhbmQgcG9zc2liaWxpdGllcw0KPiA+IC0gQ2xhcmlmeSB0aGF0IHRoZSBsaXN0ZWQgcmVxdWly ZW1lbnRzIGFyZSBub3QgdGhlIG9ubHkgb25lcw0KPiANCj4gSSdtIGdlbmVyYWxseSBoYXBweSB3 aXRoIHRoZSBjdXJyZW50IG91dGxpbmUgZm9yIHRoZSBpbnRyb2R1Y3Rpb24uIFRob3NlDQo+IGxv b2tpbmcgdG8gYWRkcmVzcyB0aGVzZSBwb2ludHMgc2hvdWxkIHN1Ym1pdCB0ZXh0IHByb3Bvc2Fs cy4NCj4gDQo+ID4gVGVybWlub2xvZ3k6DQo+ID4NCj4gPiAtIERlZmluZSBjbGllbnQgc2VjcmV0 DQo+IA0KPiBDbGllbnQgc2VjcmV0IGlzbid0IGEgdGVybSBidXQgYSBkZXRhaWwgb2YgdGhlIGNs aWVudCBhdXRoZW50aWNhdGlvbiBwcm9jZXNzLA0KPiBlc3BlY2lhbGx5IHdpdGggdGhlIHdheSBp dCBpcyBkZWZpbmVkIG5vdy4NCj4gDQo+ID4gLSBEZXNjcmliZSByZWxhdGlvbnNoaXAgYmV0d2Vl biB0ZXJtcw0KPiANCj4gVGhlIHNlY3Rpb24gaGFzIGJlZW4gcmVzdHJ1Y3R1cmVkIHRvIGFkZCB0 d28gbGV2ZWxzIG9mIHRlcm1zIHRvIHNob3cNCj4gcmVsYXRpb25zaGlwcy4NCj4gDQo+ID4gLSBB ZGQgdmVyaWZpY2F0aW9uIGNvZGUNCj4gDQo+IFRoZSB2ZXJpZmljYXRpb24gY29kZSB3YXMgcmVu YW1lZCB0byBhdXRob3JpemF0aW9uIGNvZGUgYW5kIGFkZGVkLg0KPiANCj4gPiAtIFJlbW92ZSB0 ZXJtaW5vbG9neSByZWZlcmVuY2VzIHRvIEhUVFAgdGVybXMNCj4gDQo+IFJlbW92ZWQgcmVsaWFu Y2Ugb24gSFRUUCB0ZXJtaW5vbG9neS4NCj4gDQo+ID4gLSBBZGQgY3J5cHRvZ3JhcGhpYyB0ZXJt cw0KPiA+IC0gVXNlciB0aGUgdGVybSAnY2FwYWJpbGl0eScgd2hlbiB0YWxraW5nIGFib3V0IGJl YXJlciB0b2tlbnMNCj4gDQo+IFNpbmNlIHRoZSBzaWduYXR1cmUgYW5kIGNyeXB0b2dyYXBoeSB3 YXMgcmVtb3ZlZCwgdGhlc2UgY29tbWVudHMgYXJlIG5vDQo+IGxvbmdlciByZWxldmFudCBmb3Ig dGhpcyBkcmFmdC4NCj4gDQo+ID4gT3ZlcnZpZXc6DQo+ID4NCj4gPiAtIERvZXMgbm90IHJlbGF0 ZWQgdG8gdGhlIGludHJvZHVjdGlvbiAoY29uZnVzaW5nKQ0KPiANCj4gVGhlIG92ZXJ2aWV3IHNl Y3Rpb24gd2FzIHdyaXR0ZW4gZnJvbSBzY3JhdGNoIHNvIGhvcGVmdWxseSBpdCBpcyBsZXNzDQo+ IGNvbmZ1c2luZy4NCj4gDQo+ID4gLSBTdGFuZGFyZGl6YXRpb24gb2YgdG9rZW5zIHNob3VsZCBi ZSBjYWxsZWQgb3V0IGFzIGRlZmluZWQgZWxzZXdoZXJlDQo+ID4gLSBFeHBsYWluIHRoYXQgdGhl IHNlcGFyYXRpb24gYmV0d2VlbiB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYW5kDQo+ID4gcmVz b3VyY2Ugc2VydmVyIGlzIG91dCBvZiBzY29wZQ0KPiANCj4gQm90aCB3aWxsIGJlIGNsYXJpZmll ZCBpbiAtMDkuDQo+IA0KPiA+IC0gRmxvdyBncm91cGluZyBpcyBjb25mdXNpbmcNCj4gDQo+IFNp bmNlIHRoZSBmbG93cyBoYXZlIGJlZW4gaW5jb3Jwb3JhdGVkIGludG8gdGhlIGludHJvZHVjdGlv biwgYW5kIHRoZQ0KPiBncm91cGluZyByZW1vdmVkLCB0aGUgY29uZnVzaW9uIHNob3VsZCBiZSBy ZXNvbHZlZC4NCj4gDQo+ID4gMy4yIEVuZC11c2VyIGVuZHBvaW50Og0KPiA+DQo+ID4gLSBSZW5h bWUgJ2VuZC11c2VyIGVuZHBvaW50JyB0byAnYXBwcm92YWwgdXJsJw0KPiANCj4gUmVuYW1lZCB0 byAnZW5kLXVzZXIgYXV0aG9yaXphdGlvbiBlbmRwb2ludCcuDQo+IA0KPiA+IC0gTm8gbWFuZGF0 b3J5IHRvIGltcGxlbWVudCBsYW5ndWFnZSAtIGludGVyb3AgcHJvYmxlbSAoUGV0ZXIgU3QuDQo+ ID4gQW5kcmUpDQo+IA0KPiAqKiogUGxlYXNlIGNsYXJpZnkgd2hhdCBzaG91bGQgYmUgcmVxdWly ZWQuDQo+IA0KPiA+IC0gRG9lcyBub3QgbWVudGlvbiB1c2VyIGlkZW50aXR5IChob3cgdG8gdmVy aWZ5KQ0KPiANCj4gVXNlciBpZGVudGl0eSBpcyBvdXQgb2Ygc2NvcGUuIFNob3VsZCBiZSBhZGRy ZXNzZWQgYnkgdGhlIHByb3Bvc2VkIE9wZW5JRA0KPiBDb25uZWN0IHdvcmsuDQo+IA0KPiA+IC0g V2hlbiB1c2luZyBUTFMsIG1ha2Ugc3VyZSBpdCdzIHNlcnZlciBhdXRoZW50aWNhdGlvbiwgbm90 IGNsaWVudA0KPiA+IGNlcnRpZmljYXRlcyAoRXZlIE1hbGVyKQ0KPiANCj4gKioqIFBsZWFzZSBw cm9wb3NlIGxhbmd1YWdlLg0KPiANCj4gPiAtICd1c2VyLXVyaScgYXR0cmlidXRlIGlzIHRvbyBl eHBlcmltZW50YWwgdG8gYmUgaW5jbHVkZWQNCj4gDQo+IE1vdmVkIHRvIGRpc2NvdmVyeSBkcmFm dC4NCj4gDQo+ID4gLSBFeHBsYWluIHRoYXQgdGhlIGVuZC11c2VyIGVuZHBvaW50IGlzIG9ubHkg cmVsZXZhbnQgdG8gc29tZSBmbG93cw0KPiANCj4gSSB0aGluayAtMDggbWFrZXMgdGhpcyBjbGVh ci4NCj4gDQo+ID4gLSBTaG91bGQgc3RhbmRhcmRpemUgZXhpc3Rpbmcgc2VydmljZSBwcm92aWRl ciBzcGVjaWZpYyBwYXJhbWV0ZXJzIGZvcg0KPiA+IFVJLCBlLmcuIGxhbmd1YWdlLCBkaXNwbGF5 IHR5cGUsIHVzZXIgaGludA0KPiANCj4gUHVibGlzaGVkIGluIGEgc2VwYXJhdGUgVVggZHJhZnQu DQo+IA0KPiA+IDMuMyBUb2tlbiBlbmRwb2ludDoNCj4gPg0KPiA+IC0gRmlyc3Qgc2VudGVuY2Ug KCJBZnRlciBvYnRhaW5pbmcgYXV0aG9yaXphdGlvbiBmcm9tIHRoZSByZXNvdXJjZQ0KPiA+IG93 bmVyIikgaXMgbm90IHRydWUgZm9yIGFsbCBmbG93cw0KPiANCj4gSSB0aGluayB0aGUgc2FtZSBp c3N1ZSBleGlzdHMgaW4gLTA4IGJ1dCBJJ20gbm90IHN1cmUgaG93IHRvIGFkZHJlc3MgaXQuIElz IGl0DQo+IHJlYWxseSBhIHByb2JsZW0/DQo+IA0KPiA+IC0gTWF5YmUgY2hhbmdlIG5hbWUgdG8g J1Rva2VuIGlzc3VpbmcgZW5kcG9pbnQnDQo+IA0KPiBJIHRoaW5rIHRva2VuIGVuZHBvaW50IGlz IG5pY2UgYW5kIHNob3J0Lg0KPiANCj4gPiAtIE1VU1QgdXNlIFNTTD8NCj4gDQo+IENoYW5nZWQg dG8gIlNlcnZlcnMgTVVTVCBzdXBwb3J0IFRMUyAxLjIiIGFuZCBtYXkgc3VwcG9ydCBvdGhlciBz dHVmZg0KPiAoZXF1YWxseSBzdHJvbmcpIGFzIHdlbGwuDQo+IA0KPiA+IC0gTWFuZGF0ZSBQT1NU Pw0KPiANCj4gWWVzLiBPdGhlcndpc2Ugc2VjcmV0cyBsZWFrIGludG8gbG9nIGZpbGVzLg0KPiAN Cj4gPiAzLjMuMSBDbGllbnQgQXV0aGVudGljYXRpb246DQo+ID4NCj4gPiAtIE5lZWQgbmV3IHRl eHQgZm9yIGNlcnRpZmljYXRlIGF1dGhlbnRpY2F0aW9uDQo+ID4gLSBOZWVkIG1vcmUgZmxleGli bGUgbGFuZ3VhZ2UNCj4gDQo+IFRoZSBsYXRlc3QgZHJhZnQgZml4ZXMgdGhpcyBieSBtb3Zpbmcg dGhlIGNsaWVudCBhdXRoZW50aWNhdGlvbiBvdXQgb2YgdGhlDQo+IGVuZHBvaW50cyBhbmQgaW50 byBpdHMgb3duIHNlY3Rpb24uIEluIGFkZGl0aW9uLCB0aGUgY2xpZW50IGlkZW50aWZpZXIgYW5k DQo+IHNlY3JldCBhcmUgZ2l2ZW4gYSBuYW1lIChiYXNpYyBjbGllbnQgY3JlZGVudGlhbHMpIHRv IG1ha2UgaXQgZWFzaWVyIHRvIHNwZWNpZnkNCj4gb3RoZXIgd2F5cyB0byBhdXRoZW50aWNhdGUg dGhlIGNsaWVudC4NCj4gDQo+ID4gMy4zLjIgUmVzcG9uc2UgRm9ybWF0Og0KPiA+DQo+ID4gLSBE byB3ZSBuZWVkIHNvIG1hbnkgZm9ybWF0cz8NCj4gPiAtIEFyZSBhbGwgZm9ybWF0cyBuZWVkZWQg b24gYm90aCBzaWRlcz8NCj4gDQo+IFNvbHZlZCBieSB1c2luZyBqdXN0IEpTT04gZm9yIHRva2Vu IGVuZHBvaW50IHJlc3BvbnNlcy4NCj4gDQo+ID4gLSBJcyBuby1zdG9yZSBlbm91Z2ggb2YgYSBj YWNoZS1jb250cm9sIGhlYWRlcj8gKENodWNrIE1vcnRpbW9yZSkNCj4gDQo+ICoqKiBObyBpZGVh LiBJcyBpdD8NCj4gDQo+ID4gMy4zLjIuMSBBY2Nlc3MgVG9rZW4gUmVzcG9uc2U6DQo+ID4NCj4g PiAtIERlZmluZSBzY29wZSBvbmNlLCBpbmNsdWRlIGJ5IHJlZmVyZW5jZQ0KPiANCj4gRG9uJ3Qg ZXZlbiBuZWVkIHRvIHJlZmVyZW5jZSBhbnltb3JlLiBEZWZpbmVkIGluIGEgc2luZ2xlIHBsYWNl Lg0KPiANCj4gPiAtIE5lZWQg4oCcc2NvcGXigJ0gZXhhbXBsZSAoSGFubmVzKQ0KPiANCj4gKioq IEl0IGlzIGhhcmQgdG8gcHJvdmlkZSBzY29wZSBleGFtcGxlcy4gQXJlIHRoZXJlIGFueSBzY29w ZXMgY29tbW9uIGluDQo+IG1vcmUgdGhhbiBvbmUgT0F1dGggMS4wIGltcGxlbWVudGF0aW9uPw0K PiANCj4gPiAtIFNjb3BlIGlzIHVuZGVyc3BlY2lmaWVkDQo+IA0KPiBJdCBpcyBhcyBzcGVjaWZp ZWQgYXMgd2UgaGF2ZSBjb25zZW5zdXMgZm9yIChldmVuIHRoaXMgd2FzIHBhaW5mdWwpLg0KPiAN Cj4gPiAtIEF1dGhvcml6YXRpb24gc2VydmVyIE1VU1QgaG9ub3IgY2xpZW50IHJlcXVlc3QgZm9y IHRva2VuIHNlY3JldD8NCj4gDQo+IFNpbmNlIHRoaXMgaXMgbW92ZWQgdG8gYW4gZXh0ZW5zaW9u LCB0aGUgYW5zd2VyIGlzIG5vLg0KPiANCj4gPiAtIFNlbWFudGljcyBvZiDigJxleHBpcmVzX2lu 4oCdIGFyZSB1bmRlcnNwZWNpZmllZA0KPiANCj4gQWRkZWQgZXhhbXBsZSBpbiAtMDkuDQo+IA0K PiA+IDMuMy4yLjIgRXJyb3IgcmVzcG9uc2U6DQo+ID4NCj4gPiAtIERhdGEgZm9ybWF0IG5lZWRz IHRvIGJlIGluIHN5bmMgYWNyb3NzIGVudGlyZSBzcGVjDQo+IA0KPiBOb3cgdXNlcyBKU09OIGxp a2UgYSBzdWNjZXNzZnVsIHJlc3BvbnNlLg0KPiANCj4gPiAtIEFkZCBkZWJ1Z2dpbmcgbWVzc2Fn ZSBmaWVsZCB0byBKU09ODQo+IA0KPiBEZWJ1Z2dpbmcgaXMgb3V0IG9mIHNjb3BlLCBidXQgZmVl bCBmcmVlIHRvIHdyaXRlIGEgcHJvcG9zYWwuDQo+IA0KPiA+IC0gUHJlZGVmaW5lZCBsaXN0IG9m IGVycm9yIHJlc3BvbnNlcz8NCj4gDQo+IE5ldyBzZWN0aW9uIGFkZGVkIGluIC0wNy4gU3RpbGwg bmVlZHMgdG8gYWRkIHRleHQgdG8gZGVzY3JpYmUgZWFjaCBlcnJvcg0KPiBtZXNzYWdlLCBhcyB3 ZWxsIGFzIG1ha2UgdGhlIGxpc3QgY29tcGxldGUuDQo+IA0KPiA+IDMuNCBGbG93IFBhcmFtZXRl cnM6DQo+ID4NCj4gPiAtIE1vcmUgb24gZXJyb3IgaGFuZGxpbmc/IChQZXRlciBTdC4gQW5kcmUp DQo+IA0KPiAqKiogTm90IHN1cmUgd2hhdCB0aGlzIGlzIGFib3V0Lg0KPiANCj4gPiAzLjUgVXNl ci1BZ2VudCBGbG93Og0KPiA+DQo+ID4gLSBJZiByZWZyZXNoIHRva2VuIGxlYWtzLCB5b3UgY2Fu 4oCZdCByZWNvdmVyLiDCoENoYW5naW5nIGNsaWVudCBzZWNyZXQgaXMgbm90DQo+IGVub3VnaC4N Cj4gDQo+IE5vIGxvbmdlciBpc3N1aW5nIHJlZnJlc2ggdG9rZW4gaW4gdXNlci1hZ2VudCBmbG93 Lg0KPiANCj4gPiAtIENhbiB3ZSBjaGFuZ2Ugb3JkZXIgb2YgdXNlci1hZ2VudCBhbmQgd2ViIGFw cCBmbG93IGluIHNwZWM/DQo+IA0KPiBEb25lLg0KPiANCj4gPiAtIFdSQVAgd2ViIHNlcnZlciBm bG93IHdhcyBtb3JlIHNlY3VyZSBmb3IgcmljaC1jbGllbnQgYXBwcywgYmVjYXVzZQ0KPiA+IHdl YiBzaXRlcyBjYW5ub3QgcHJldGVuZCB0byBiZSByaWNoIGNsaWVudHMuIMKgVXNlci1BZ2VudCBm bG93IGRvZXMgbm90DQo+ID4gYWxsb3cgdGhpcy4gKFNhcmFoIEZhdWxrbmVyKQ0KPiANCj4gKioq IFBsZWFzZSBzdGFydCBhIG5ldyB0aHJlYWQgdG8gZGlzY3Vzcy4NCj4gDQo+ID4gLSBXaGVyZSBk byB3ZSBoYW5kbGUgY3VzdG9tIHByb3RvY29sIHNjaGVtZXMgaW4gcmVkaXJlY3QgVVJJcz8NCj4g DQo+ICoqKiBDdXJyZW50bHkgbWVudGlvbmVkIGluIG5hdGl2ZSBhcHBsaWNhdGlvbiBzZWN0aW9u LiBOZWVkIGd1aWRhbmNlIGZyb20NCj4gSUVTRyBvbiBob3cgdG8gaGFuZGxlIHRoaXMgc28gaXQg d2lsbCBub3QgYmVjb21lIGEgYmxvY2tpbmcgaXNzdWUuDQo+IA0KPiA+IC0gTW92ZSBpbnN0YWxs ZWQgYXBwbGljYXRpb25zIHRvIGEgc2VwYXJhdGUgc2VjdGlvbg0KPiANCj4gRG9uZS4NCj4gDQo+ ID4gLSBOZWVkIHRvIGdpdmUgaW5zdGFsbGVkIGFwcCBkZXZlbG9wZXJzIGEgd2F5IHRvIHNwZWNp ZnkgZGV2aWNlIG5hbWUNCj4gPiAoQnJpYW4gRWF0b24pDQo+IA0KPiAqKiogUGxlYXNlIHByb3Bv c2UgdGV4dC4NCj4gDQo+ID4gLSBDYW7CoG1vYmlsZSBkZXZlbG9wZXJzIHVzZSBIVFRQIFVSTCBk aXNjb3ZlcnkgZnJvbSBzbGlkZSBkZWNrDQo+ID4gaW5zdGVhZD8gKEJpbGwgS2VlbmFuKQ0KPiAN Cj4gKioqIE5lZWQgY2xhcmlmaWNhdGlvbi4NCj4gDQo+ID4gLSBFeHBsYWluIGhvdyB0byBhdXRo ZW50aWNhdGUgdGhlIGNsaWVudC4NCj4gDQo+IEkgdGhpbmsgdGhlIG5ldyB0ZXh0IGlzIHByZXR0 eSBjbGVhciwgdXNpbmcgYSByZWZlcmVuY2UgdG8gdGhlIGNsaWVudA0KPiBhdXRoZW50aWNhdGlv biBzZWN0aW9uLg0KPiANCj4gPiAzLjUuMSBDbGllbnQgUmVxdWVzdHMgQXV0aG9yaXphdGlvbjoN Cj4gPg0KPiA+IC0gV2hhdCBpZiBtYWxpY2lvdXMgYWN0b3IgKGVpdGhlciBhIHVzZXIgb3Ig4oCc bWFuIGluIHRoZSBicm93c2Vy4oCdKQ0KPiA+IHRhbXBlcnMgd2l0aCDigJxzY29wZeKAnSBvciDi gJxzdGF0ZeKAnSBwYXJhbWV0ZXI/IChFdmUgTWFsZXIpDQo+IA0KPiBTaW5jZSB0aGUgZW5kLXVz ZXIgZ2V0cyB0byBhdXRob3JpemUgdGhlIHJlcXVlc3QsIHNjb3BlIHRlbXBlcmluZyBzaG91bGRu J3QNCj4gYmUgYSBwcm9ibGVtLiBBcyBmb3Igc3RhdGUsIEknbSBub3Qgc3VyZS4NCj4gDQo+ID4g LSBTaG91bGQgd2UgYWRkIGFuIGV4dGVuc2lvbiBzbyB0aGF0IHVzZXJzIGNhbiBzZWxmLWlkZW50 aWZ5IHRoZWlyDQo+ID4gZGV2aWNlPyAoQmlsbCBTbWl0aCkNCj4gDQo+ICoqKiBQbGVhc2UgcHJv cG9zZSB0ZXh0IG9yIHN0YXJ0IGEgZGlzY3Vzc2lvbi4NCj4gDQo+ID4gLSBBdXRob3JpemF0aW9u IHNlcnZlcnMgTUFZIHJlc3RyaWN0IHRoZSByZWRpcmVjdGlvbiBVUkkgdG8gbm90DQo+ID4gaW5j bHVkZSBhIHF1ZXJ5IGNvbXBvbmVudC4gVGhpcyB3aWxsIGJyZWFrIFBIUCBjbGllbnRzDQo+IA0K PiBUaGlzIGlzIHBhcnQgb2YgdGhlIHVuZGVyc3BlY2lmaWVkIG1hdGNoaW5nIHJ1bGVzLiBJJ2xs IGRyb3AgaXQgZm9yIG5vdy4NCj4gDQo+ID4gMy41LjEuMSBFbmQtdXNlciBncmFudHMgYXV0aG9y aXphdGlvbjoNCj4gPg0KPiA+IC0gc2VlbXMgb2RkIHRoYXQgY2xpZW50IGlzIHJlcXVlc3Rpbmcg dGhlIHRva2VuIHNlY3JldC4NCj4gPiAtIHdoYXQgaGFwcGVucyBpZiBzZXJ2ZXIgZG9lc27igJl0 IHdhbnQgdG8gaXNzdWUgdG9rZW4gc2VjcmV0Pw0KPiANCj4gUmVtb3ZlZC4gU3RpbGwgYW4gb3Bl biBxdWVzdGlvbiBmb3IgdGhlIHNpZ25hdHVyZSBzcGVjLg0KPiANCj4gPiAtIHNob3VsZCB3ZSBt YWtlIGV4YW1wbGUgaHR0cHM/DQo+IA0KPiBJIGRvbid0IHRoaW5rIHRoaXMgaXMgbmVjZXNzYXJ5 IHNpbmNlIHRoZSBmcmFnbWVudCBpcyBub3QgdHJhbnNtaXR0ZWQuDQo+IA0KPiA+IDMuNS4xLjIg RW5kLXVzZXIgZGVuaWVzIGF1dGhvcml6YXRpb246DQo+ID4NCj4gPiAtIE1vcmUgZXJyb3IgY29k ZXMgbmVlZGVkIChTYXJhaCBGYXVsa25lciBhbmQgTWFyaXVzIFNjdXJ0ZXNjdSkNCj4gDQo+ICoq KiBQbGVhc2UgcHJvdmlkZSB0ZXh0Lg0KPiANCj4gPiAtIEltbWVkaWF0ZSBtb2RlIGZhaWx1cmUg bmVlZHMgYW4gZXJyb3IgY29kZQ0KPiANCj4gUmVtb3ZlZC4gTm90ZWQgZm9yIHdoZW4gdGhlIHBh cmFtZXRlciBhcHBlYXJzIG9uIGFub3RoZXIgZHJhZnQuDQo+IA0KPiA+IDMuNS4yIENsaWVudCBl eHRyYWN0cyBhY2Nlc3MgdG9rZW46DQo+ID4NCj4gPiAtIENhbiB3ZSB0ZWxsIHVzZXItYWdlbnRz IG5vdCB0byBzZW5kIGZyYWdtZW50IGluIEhUVFAgcmVxdWVzdD8gwqBJRQ0KPiA+IGRvZXMgdGhp cyBpbiBjZXJ0YWluIGNpcmN1bXN0YW5jZXMuDQo+IA0KPiBIVFRQIHRlbGxzIHRoYXQuIEl0IHdh cyBtYWRlIG1vcmUgZXhwbGljaXQgaW4gdGhlIG5ldyBIVFRQYmlzIHdvcmsuIEJleW9uZA0KPiB0 aGF0LCBub3Qgc3VyZSB3aGF0IHdlIGNhbiBkby4NCj4gDQo+ID4gMy42LjEgQ2xpZW50IFJlcXVl c3RzIEF1dGhvcml6YXRpb246DQo+ID4NCj4gPiAtIHJlZGlyZWN0X3VyaSB2YWxpZGF0aW9uIHN0 cmF0ZWd5IHNob3VsZCBiZSBkZXNjcmliZWQgb25jZSBpbiB0aGUgc3BlYywgYW5kDQo+IHRoZW4g aW5jbHVkZWQgYnkgcmVmZXJlbmNlLg0KPiANCj4gRG9uZS4NCj4gDQo+ID4gLSBTb21lIG9mIHRo ZSByZXF1aXJlZCBwYXJhbWV0ZXJzIGRvbuKAmXQgbWFrZSBzZW5zZSBpZiBhdXRoZW50aWNhdGlv bg0KPiA+IG9mIHVzZXIgaXMgb3V0IG9mIGJhbmQuIChFdmUgTWFsZXIpDQo+IA0KPiBUaGUgb25s eSByZXF1aXJlZCBwYXJhbWV0ZXIgdGhlcmUgd2VyZSAnY2xpZW50X2lkJywgJ3R5cGUnLCBhbmQg J3JlZGlyZWN0X3VyaScuDQo+IFdoaWNoIG9uZSBhcmUgeW91IHJlZmVycmluZyB0bz8NCj4gDQo+ ID4gMy42LjEuMSAtIEVuZC11c2VyIGdyYW50cyBhdXRob3JpemF0aW9uOg0KPiA+DQo+ID4gLSBX aGF0IGRvZXMgdGhlIHZlcmlmaWNhdGlvbiBjb2RlIHByb3ZpZGU/DQo+IA0KPiBJIHRoaW5rIHRo ZSBuZXcgdGV4dCBleHBsYWlucyB0aGlzIChwYXJ0IG9mIHRoZSBhYnN0cmFjdGlvbiBsYXllciBw cm92aWRlZCBieQ0KPiB0aGUgYWNjZXNzIGdyYW50KS4gTGV0IG1lIGtub3cgaWYgaXQgc3RpbGwg bmVlZHMgdG8gYmUgY2xhcmlmaWVkLg0KPiANCj4gPiAtIEhvdyBkbyBwZW9wbGUga2VlcCB2ZXJp ZmljYXRpb24gY29kZSBmcm9tIGxlYWtpbmcgaW4gcmVmZXJyZXINCj4gPiBoZWFkZXI/IChTYXJh aCBGYXVsa25lcikNCj4gDQo+ICoqKiBJcyB0aGlzIGFuIGlzc3VlPyBDYW4geW91IHN0YXJ0IGEg dGhyZWFkIHRvIGRpc2N1c3M/DQo+IA0KPiA+IC0gU2hvdWxkIHdlIGRlZmluZSB0aW1lLWxpbWl0 IGZvciB2ZXJpZmljYXRpb24gY29kZT8gwqA1IG1pbnV0ZXM/DQo+ID4gKFBldGVyIFN0LiBBbmRy ZSkNCj4gDQo+ICoqKiBPcGVuIGlzc3VlLg0KPiANCj4gPiAtIFNwZWNpZnkgdGhhdCB2ZXJpZmlj YXRpb24gY29kZSBzaG91bGQgYmUgdXNlZCBvbmx5IG9uY2UNCj4gDQo+IE1hZGUgZXZlbiBjbGVh cmVyIGluIC0wOS4NCj4gDQo+ID4gMy42LjIgLSBDbGllbnQgcmVxdWVzdHMgYWNjZXNzIHRva2Vu Og0KPiA+DQo+ID4gLSBzaG91bGQgbWVudGlvbiBodHRwcw0KPiANCj4gRG9uZS4NCj4gDQo+IFtE ZXZpY2UgZmxvdyBmZWVkYmFjayByZW1vdmVkXQ0KPiANCj4gPiAzLjggLSBVc2VybmFtZSBhbmQg cGFzc3dvcmQgZmxvdzoNCj4gPg0KPiA+IC0gbmVlZCB0byByZXR1cm4gZXJyb3IgVVJMIGZyb20g dGhpcyBmbG93LCBzbyB0aGF0IHVzZXJzIGNhbiBnZXQgdGhlaXINCj4gPiBhY2NvdW50IHVuYmxv Y2tlZCBpZiB0aGV5IGFyZSBvbiB0aGUgc2FtZSBJUCByYW5nZSBhcyBhIGJvdG5ldCAoQnJpYW4N Cj4gPiBFYXRvbikNCj4gDQo+ICoqKiBQbGVhc2Ugc3VnZ2VzdCB0ZXh0Lg0KPiANCj4gPiAzLjEw IC0gQXNzZXJ0aW9uIEZsb3c6DQo+ID4NCj4gPiAtIHdlIG5lZWQgYW4gZXhhbXBsZQ0KPiANCj4g RG9uZS4NCj4gDQo+ID4gLSBUd28gZm9ybWF0IHBhcmFtZXRlcnMNCj4gDQo+IEZpeGVkLg0KPiAN Cj4gPiA0IC0gUmVmcmVzaCBUb2tlbjoNCj4gPg0KPiA+IC0gc2hvdWxkIHdlIGFsd2F5IHRlbGwg Y2xpZW50cyB0byB1c2UgYSBzZWNyZXQsIGUuZy4g4oCcYW5vbnltb3Vz4oCdIG9yDQo+ID4g4oCc b3BlbnNlY3JldOKAnT8gwqBBYnNlbnQgc2VjcmV0IG1pZ2h0IGJlIGNvbmZ1c2luZz8gKEJyaWFu IEVhdG9uKQ0KPiANCj4gKioqIFBsZWFzZSBjbGFyaWZ5Lg0KPiANCj4gPiAtIFNob3VsZCB3ZSBh bGxvdyBkb3duLXNjb3Bpbmcgb24gdGhpcyBlbmRwb2ludD8NCj4gDQo+IC0wOCBhZGRzIHN1cHBv cnQgZm9yIGRvd24tc2NvcGluZy4NCj4gDQo+ID4gLSBTY29wZSBuZWVkcyB0byBiZSBmaWd1cmVk IG91dCB0aHJvdWdoIGVudGlyZSBmbG93IChFdmUgTWFsZXIpDQo+IA0KPiAqKiogLTA4IHRyaWVz IHRvIGNsZWFuIHVwIHNjb3BlIGhhbmRsaW5nLiBQbGVhc2UgcmV2aWV3Lg0KPiANCj4gPiA1IC0g QWNjZXNzaW5nIGEgcHJvdGVjdGVkIHJlc291cmNlOg0KPiA+DQo+ID4gLSBObyBjbGVhciBlcnJv ciBwYXRoDQo+IA0KPiBOb3RlZC4gVG8gYmUgYWRkcmVzc2VkIGluIC0wOS4NCj4gDQo+ID4gLSBT aG91bGQgdGhlIGF1dGhlbnRpY2F0aW9uIHNjaGVtZSBuYW1lIGJlIGNhbGxlZCAnVG9rZW4nPw0K PiANCj4gSSB0aGluayBzby4gVGhvc2Ugd2hvIGRpc2FncmVlIGFyZSB3ZWxjb21lIHRvIHN0YXJ0 IGEgZGlzY3Vzc2lvbi4NCj4gDQo+ID4gLSBDYW4gd2Ugc2F5IOKAnGJlYXJlciB0b2tlbnPigJ0g TVVTVCBOT1QgYmUgc2VudCBvdmVyIHNlY3VyZSBjaGFubmVscz8NCj4gPiAoSmltIEZlbnRvbikN Cj4gDQo+IEkgd291bGQgbGlrZSB0aGF0IGJ1dCBjb25zZW5zdXMgd2FzIHRoYXQgU0hPVUxEIE5P VCBpcyB0aGUgc3Ryb25nZXN0IHdlIGNhbg0KPiBzcGVjaWZ5Lg0KPiANCj4gPiAtIENhbiB3ZSB3 cml0ZSBhIHNwZWMgdGhhdCByZWZsZWN0cyBzZWN1cml0eSByZWFsaXR5IC0gcGVvcGxlIGRvIHNl bmQNCj4gPiBiZWFyZXIgdG9rZW5zIG92ZXIgSFRUUCBjb25uZWN0aW9ucw0KPiANCj4gV2UgZGlk IDotKA0KPiANCj4gPiAtIENhbiB3ZSBzYXkgTVVTVCBOT1Qgc2VuZCBiZWFyZXIgdG9rZW5zIHRv IHVuZmFtaWxpYXIgc2l0ZXM/DQo+IA0KPiBEb25lIGluIC0wOS4NCj4gDQo+ID4gLSBJcyDigJx1 bmZhbWlsaWFy4oCdIHdlbGwtZGVmaW5lZD8NCj4gDQo+IEkgdGhpbmsgaXQgaXMgaW4gdGhlIGNv bnRleHQgb2YgdGhlIHNwZWMgLSBub3QgaGFyZGNvZGVkIGludG8gdGhlIGNsaWVudC4NCj4gDQo+ ID4gLSBDYW4gd2UgaGF2ZSBhIHNhbWUtb3JpZ2luIHBvbGljeT8NCj4gDQo+IFRoaXMgbmVlZHMg dG8gYmUgYWRkcmVzc2VkIGluIHRoZSBkaXNjb3Zlcnkgc3BlYy4gSmFtZXMnIHByb3Bvc2UgJ3Np dGVzJw0KPiBwYXJhbWV0ZXIgaXMgb25lIGFwcHJvYWNoLg0KPiANCj4gPiA1LjIgLSBCZWFyZXIg VG9rZW4gUmVxdWVzdHM6DQo+ID4NCj4gPiAtIFdlIHNob3VsZCBkcm9wIHJlYWxtLCBpdCBoYXMg bm8gbWVhbmluZ2Z1bCBzZW1hbnRpY3MgaGVyZQ0KPiANCj4gKioqIEkgd2lsbCBmbG9hdCB0aGlz IHBhc3QgdGhlIEhUVFAgZm9sa3MgdG8gZ2FnZSB0aGVpciByZWFjdGlvbi4NCj4gDQo+ID4gNi4x IC0gV1dXLUF1dGhlbnRpY2F0ZSBSZXNwb25zZSBoZWFkZXI6DQo+ID4NCj4gPiAtIHdoYXQgYWJv dXQgcmVzb3VyY2VzIHRoYXQgcmV0dXJuIHB1YmxpYyBkYXRhIGlmIHJlcXVlc3QgaXMNCj4gdW5h dXRoZW50aWNhdGVkPyBQT1NUIHZzIEdFVCBtaWdodCBoYXZlIGRpZmZlcmVudCBzZWN1cml0eSBw b2xpY3kuDQo+IA0KPiAqKiogTmVlZCB0byBsb29rIGludG8gdGhpcy4NCj4gDQo+ID4gNi4xLjEu IC0gZGVzY3JpYmluZyB0aGUgV1dXLUF1dGhlbnRpY2F0ZSByZXNwb25zZSBoZWFkZXINCj4gPg0K PiA+IC0gRGlzY292ZXJ5IG5lZWRlZCBmb3IgdmFyaW91cyBlbGVtZW50cw0KPiANCj4gWWVzLiBU aGF0J3MgZm9yIHRoZSBkaXNjb3ZlcnkgZHJhZnQuDQo+IA0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4gT0F1 dGhAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0 aA0K From lshepard@facebook.com Fri Jun 25 10:49:53 2010 Return-Path: <lshepard@facebook.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3BDB28C15B for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 10:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.417 X-Spam-Level: X-Spam-Status: No, score=-0.417 tagged_above=-999 required=5 tests=[AWL=-0.430, BAYES_40=-0.185, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vqIAwsqPTFQ4 for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 10:49:52 -0700 (PDT) Received: from mx-out.facebook.com (outmail002.ash1.tfbnw.net [69.63.184.102]) by core3.amsl.com (Postfix) with ESMTP id 3733628C164 for <oauth@ietf.org>; Fri, 25 Jun 2010 10:49:13 -0700 (PDT) Received: from [10.18.255.140] ([10.18.255.140:11400] helo=mail.thefacebook.com) by mta004.ash1.facebook.com (envelope-from <lshepard@facebook.com>) (ecelerity 2.2.2.45 r(34067)) with ESMTP id B2/42-26055-12CE42C4; Fri, 25 Jun 2010 10:49:21 -0700 Received: from sc-hub02.TheFacebook.com (192.168.18.105) by sc-hub03.TheFacebook.com (192.168.18.198) with Microsoft SMTP Server (TLS) id 14.0.694.1; Fri, 25 Jun 2010 10:49:21 -0700 Received: from SC-MBXC1.TheFacebook.com ([192.168.18.100]) by sc-hub02.TheFacebook.com ([192.168.18.105]) with mapi; Fri, 25 Jun 2010 10:49:20 -0700 From: Luke Shepard <lshepard@facebook.com> To: Naitik Shah <n@daaku.org>, Brian Eaton <beaton@google.com>, Dirk Balfanz <balfanz@google.com> Date: Fri, 25 Jun 2010 10:49:05 -0700 Thread-Topic: [OAUTH-WG] Understanding the reasoning for Base64 Thread-Index: AcsUjr1oQQNJN0qJSHqGj9LvRu8BcQ== Message-ID: <2625894F-2979-40BD-81E1-05A6EB8723CD@facebook.com> References: <AANLkTimMruKyblUWROkPMDapFKtTztOXqL64PpQxCmKO@mail.gmail.com> In-Reply-To: <AANLkTimMruKyblUWROkPMDapFKtTztOXqL64PpQxCmKO@mail.gmail.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 <oauth@ietf.org> Subject: Re: [OAUTH-WG] Understanding the reasoning for Base64 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 25 Jun 2010 17:49:53 -0000 Brian, Dirk - just wondering if you had thoughts here?=20 The only strong reason I can think of for base64 encoding is that it allows= for a delimiter between the body and the signature. Is there any other rea= son? On Jun 24, 2010, at 11:33 AM, Naitik Shah wrote: > I've been following some of the discussions wrt the new Signature proposa= l, and I think I get the reason for needing Base64, but wasn't quite sure i= f I understood it correctly (allows the use of a separator?). Would someone= mind elaborating? >=20 > The payload looks is urlencode(web_base64(json_encode(data))) -- and the = urlencode in this case should be an identity function. >=20 > I'm wondering if urlencode(json_encode(data)) would be acceptable. >=20 >=20 > Thanks, > -Naitik > <ATT00001..txt> From lshepard@facebook.com Fri Jun 25 10:51:45 2010 Return-Path: <lshepard@facebook.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA98528C159 for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 10:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.71 X-Spam-Level: X-Spam-Status: No, score=0.71 tagged_above=-999 required=5 tests=[AWL=-1.450, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5jxrZsnHHZXX for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 10:51:43 -0700 (PDT) Received: from mx-out.facebook.com (outmail010.snc1.tfbnw.net [69.63.178.169]) by core3.amsl.com (Postfix) with ESMTP id 2F69F3A6A0D for <oauth@ietf.org>; Fri, 25 Jun 2010 10:51:40 -0700 (PDT) Received: from [10.18.255.129] ([10.18.255.129:15366] helo=mail.thefacebook.com) by mta006.snc1.facebook.com (envelope-from <lshepard@facebook.com>) (ecelerity 2.2.2.45 r(34067)) with ESMTP id EE/BA-31995-5BCE42C4; Fri, 25 Jun 2010 10:51:49 -0700 Received: from sc-hub05.TheFacebook.com (192.168.18.82) by sc-hub04.TheFacebook.com (192.168.18.212) with Microsoft SMTP Server (TLS) id 14.0.694.1; Fri, 25 Jun 2010 10:51:48 -0700 Received: from SC-MBXC1.TheFacebook.com ([192.168.18.100]) by sc-hub05.TheFacebook.com ([192.168.18.82]) with mapi; Fri, 25 Jun 2010 10:51:48 -0700 From: Luke Shepard <lshepard@facebook.com> To: Breno <breno.demedeiros@gmail.com> Date: Fri, 25 Jun 2010 10:51:28 -0700 Thread-Topic: [OAUTH-WG] proposal for signatures Thread-Index: AcsUjxU5XpTRni6qSferhsq4b6T07g== Message-ID: <CFA39B76-586F-443B-81F2-AC65FC6361FC@facebook.com> References: <AANLkTingCgO-o3XRZbxYoD8U2rRTO-EgWcfg2hBlbQHm@mail.gmail.com> <AANLkTinZ1XIFO25mcgoiDV-V0Blvv8ZC6kV_F3fca3dC@mail.gmail.com> <4C5BCAC6-713F-4C42-8696-2931D1AB3199@gmail.com> <AANLkTinlATNBEQsmFJIxv_cgqfI_tsoGfTMy6OXN6F_B@mail.gmail.com> <A08279DC79B11C48AD587060CD9397712735068D@TK5EX14MBXC101.redmond.corp.microsoft.com> <AANLkTimLrZzwDW9rMtGjD9k6ZtXc_oDXIIIYWOMw-NCi@mail.gmail.com> <AANLkTilcn_qQLgriJEdPk95f2Zliyk0QXGvU6t77Aa7G@mail.gmail.com> <AANLkTinEjidY_HmcGHPTus7P1snjCl9DPL4dX-Sz_mTQ@mail.gmail.com> <AANLkTilRUQiD5oRyxUZXmPs2skCY8zAmc1Vl--8pEblS@mail.gmail.com> <AANLkTilAjh9Jl0__9jksh3eY7giVR6Wtr0NYNoFfYHZX@mail.gmail.com> <AANLkTil3NxM_TmrusslVpCTqwqA8AEtH_vPsHnxkrcE3@mail.gmail.com> In-Reply-To: <AANLkTil3NxM_TmrusslVpCTqwqA8AEtH_vPsHnxkrcE3@mail.gmail.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_CFA39B76586F443B81F2AC65FC6361FCfacebookcom_" MIME-Version: 1.0 Cc: "Hannes.Tschofenig@gmx.net" <Hannes.Tschofenig@gmx.net>, OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] proposal for signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 25 Jun 2010 17:51:46 -0000 --_000_CFA39B76586F443B81F2AC65FC6361FCfacebookcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > What's the purpose of leaving out the key ID? It's one more field that developers have to learn and configure and type in= . We should keep the simple case simple, while allowing for more complex ca= ses. I think the fact that many providers now offer only a single, shared s= ecret is an indication that the key ID is not required. On Jun 25, 2010, at 7:40 AM, Breno wrote: Key ids are an optimization in the case of rotating public keys, but pretty= much an operational requirement if you wish to support automatic rotation = of shared keys. On Jun 23, 2010 2:56 AM, "Ben Laurie" <benl@google.com<mailto:benl@google.c= om>> wrote: On 22 June 2010 21:45, David Recordon <recordond@gmail.com<mailto:recordond= @gmail.com>> wrote: > Hey Dick, in answering my quest... I don't understand why they are unnecessary no matter how keys are managed: if there's ever a possibility that you might have more than one key for someone, then key IDs are a useful optimisation. Put it another way: what's the purpose of leaving out the key ID? > And yes, Applied Cryptography is worth reading. :) > > --David > > > On Tue, Jun 22, 2010 at 12:5... <ATT00001..txt> --_000_CFA39B76586F443B81F2AC65FC6361FCfacebookcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html><head></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode:= space; -webkit-line-break: after-white-space; ">> What's the purpose of= leaving out the key ID?<div><br></div><div>It's one more field that develo= pers have to learn and configure and type in. We should keep the simple cas= e simple, while allowing for more complex cases. I think the fact that many= providers now offer only a single, shared secret is an indication that the= key ID is not required.</div><div><br><div><div>On Jun 25, 2010, at 7:40 A= M, Breno wrote:</div><br class=3D"Apple-interchange-newline"><blockquote ty= pe=3D"cite"><p>Key ids are an optimization in the case of rotating public k= eys, but pretty much an operational requirement if you wish to support auto= matic rotation of shared keys. </p><div><br class=3D"webkit-block-placehold= er"></div><blockquote type=3D"cite">On Jun 23, 2010 2:56 AM, "Ben Laurie" &= lt;<a href=3D"mailto:benl@google.com">benl@google.com</a>> wrote:<br><br= ><p><font color=3D"#500050">On 22 June 2010 21:45, David Recordon <<a hr= ef=3D"mailto:recordond@gmail.com">recordond@gmail.com</a>> wrote:<br> > Hey Dick, in answering my quest...</font></p>I don't understand why th= ey are unnecessary no matter how keys are<br> managed: if there's ever a possibility that you might have more than<br> one key for someone, then key IDs are a useful optimisation.<br> <br> Put it another way: what's the purpose of leaving out the key ID?<br><p><fo= nt color=3D"#500050"><br>> And yes, Applied Cryptography is worth readin= g. :)<br>><br>> --David<br>><br>><br>> On Tue, Jun 22, 2010 = at 12:5...</font></p></blockquote><div><br class=3D"webkit-block-placeholde= r"></div> <span><ATT00001..txt></span></blockquote></div><br></div></body></htm= l>= --_000_CFA39B76586F443B81F2AC65FC6361FCfacebookcom_-- From lshepard@facebook.com Fri Jun 25 10:54:20 2010 Return-Path: <lshepard@facebook.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C4C13A683A for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 10:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.409 X-Spam-Level: X-Spam-Status: No, score=-1.409 tagged_above=-999 required=5 tests=[AWL=0.992, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-MyyFHONqEN for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 10:54:19 -0700 (PDT) Received: from mx-out.facebook.com (outmail012.snc1.tfbnw.net [69.63.178.171]) by core3.amsl.com (Postfix) with ESMTP id 452F23A6359 for <oauth@ietf.org>; Fri, 25 Jun 2010 10:54:19 -0700 (PDT) Received: from [10.18.255.126] ([10.18.255.126:11698] helo=mail.thefacebook.com) by mta006.snc1.facebook.com (envelope-from <lshepard@facebook.com>) (ecelerity 2.2.2.45 r(34067)) with ESMTP id 1D/95-31995-45DE42C4; Fri, 25 Jun 2010 10:54:28 -0700 Received: from sc-hub05.TheFacebook.com (192.168.18.82) by sc-hub03.TheFacebook.com (192.168.18.198) with Microsoft SMTP Server (TLS) id 14.0.694.1; Fri, 25 Jun 2010 10:54:28 -0700 Received: from SC-MBXC1.TheFacebook.com ([192.168.18.100]) by sc-hub05.TheFacebook.com ([192.168.18.82]) with mapi; Fri, 25 Jun 2010 10:54:27 -0700 From: Luke Shepard <lshepard@facebook.com> To: Dick Hardt <dick.hardt@gmail.com> Date: Fri, 25 Jun 2010 10:53:52 -0700 Thread-Topic: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? Thread-Index: AcsUj3R2QFugZhzoSDyef41mKDuudA== Message-ID: <366C55E9-1BAA-4796-937C-D4A98E83B450@facebook.com> References: <3D3C75174CB95F42AD6BCC56E5555B4502BE07CC@FIESEXC015.nsn-intra.net> <E7A7F197-3BBC-43F2-8242-D0164057A39A@gmail.com> <AANLkTild51WHVcXxYFCygL8sGSGiN3HILDFwIbym6Lfi@mail.gmail.com> <3D3C75174CB95F42AD6BCC56E5555B4502869858@FIESEXC015.nsn-intra.net> <012AB2B223CB3F4BB846962876F47217059B663D@SNV-EXVS08.ds.corp.yahoo.com> <3D3C75174CB95F42AD6BCC56E5555B450286986B@FIESEXC015.nsn-intra.net> <AANLkTinOJ-t3XLweZpcWbgtKKGlCfVD_-Md08hVsCXM9@mail.gmail.com> <C3ADC775-EC87-42FE-95F1-F96E11094FB1@gmail.com> In-Reply-To: <C3ADC775-EC87-42FE-95F1-F96E11094FB1@gmail.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: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <hannes.tschofenig@nsn.com>, OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 25 Jun 2010 17:54:20 -0000 Agree. Dick- just to clarify, you mean a restriction that they be space-delimited = opaque strings as defined in the latest draft? Or something different? On Jun 25, 2010, at 8:54 AM, Dick Hardt wrote: > Glad to see people agreeing with me. I don't think Hannes was disagreeing= with me though. :) >=20 > Per my response to Hannes, I think there is value in a small restriction = on scope strings so that we have a reserved format for the future. >=20 > -- Dick >=20 > On 2010-06-25, at 7:52 AM, Blaine Cook wrote: >=20 >> I agree with Dick that the scope should remain out of scope for OAuth. >> ;-) Having a shared parameter here gives the illusion of >> interoperability, but because there's no common understanding of >> permissible scopes, there's no way to guarantee that any given >> client-server pair could expect to produce predictable outcomes. >>=20 >> Furthermore, limiting the format of the scope prematurely means that >> we give up on a whole set of possibilities before we've even had a >> chance to see what those possibilities are. For example, YQL might >> want to allow a scope to be defined like "SELECT * FROM flickr" or >> something similar. Maybe scope is implicit in assertions, or even >> explicit. Scope might be tied to the degree to which the requesting >> and/or granting parties are trusted by the service provider. >>=20 >> If there were a compelling story about how scope is supposed to >> realistically achieve greater interoperability, it might be worthwhile >> for us to consider it. In the meantime, though, I think it just >> represents the same featuritis drive that got us an under-specified >> (and more harmful than helpful) version parameter in OAuth 1.0. >>=20 >> b. >>=20 >> On 25 June 2010 08:59, Tschofenig, Hannes (NSN - FI/Espoo) >> <hannes.tschofenig@nsn.com> wrote: >>> Dick pointed me to the Facebook API on how scope is used. >>> The main page is here: >>> http://developers.facebook.com/docs/authentication/ >>>=20 >>> It describes the basic functionality and also lists an example: >>>=20 >>> " >>> https://graph.facebook.com/oauth/authorize? >>> client_id=3D...& >>> redirect_uri=3Dhttp://www.example.com/callback& >>> scope=3Duser_photos,user_videos,publish_stream >>> " >>>=20 >>> The values of the scope parameter are then explained here: >>> http://developers.facebook.com/docs/authentication/permissions >>>=20 >>> Example: user_photos ... Provides access to the photos the user has upl= oaded >>>=20 >>> I think it provides a good example that the scope values are not opaque= . >>> Opaque (in this context) means that only the entity creating it needs t= o understand it and nobody else. Here the client needs to understand and se= t them. >>>=20 >>> However, one could argue that the scope values are already bound to the= specific entity the client requests to obtain the assertion from. In this = specific case it would be "https://graph.facebook.com". >>>=20 >>> To respond to the statement Dick made about having standardized values = later there would still be the need to decide about the structure of the va= lues now. One possibility is to just add a prefix for standardized values t= hat are not allowed to be used in other cases, such as "std:". >>>=20 >>> Ciao >>> Hannes >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: ext William Mills [mailto:wmills@yahoo-inc.com] >>>> Sent: Thursday, June 24, 2010 8:15 PM >>>> To: Tschofenig, Hannes (NSN - FI/Espoo); ext Lukas >>>> Rosenstock; Dick Hardt >>>> Cc: OAuth WG >>>> Subject: RE: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? >>>>=20 >>>> I'm in favor of having a spaces separated list of tokens. >>>> The only case I can think of where the client needs to handle >>>> the scope as anything other than opaque is when it is >>>> accessing multiple services. To reduce the numebr of login >>>> events the client will have to poll all the endpoints it >>>> wants to access and get all the scopes advertized by them and >>>> submit them all, and once it has them it needs to submit all >>>> of them in it's auth request, so we need something that's >>>> easy for the client to put together. >>>>=20 >>>>=20 >>>> -bill >>>>=20 >>>>> -----Original Message----- >>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] >>>>> On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) >>>>> Sent: Thursday, June 24, 2010 3:58 AM >>>>> To: ext Lukas Rosenstock; Dick Hardt >>>>> Cc: OAuth WG >>>>> Subject: Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? >>>>>=20 >>>>> The question is whether one would ever want to have a >>>>> standardized semantic for the scope parameter. >>>>> If the answer to that question is "no" then it does not >>>>> matter what the format is. It can well be a list of >>>>> space-delimited strings (as it is currently defined). >>>>>=20 >>>>> An evironment specific semantic works well in cases where >>>>> entity X sets the value and later it receives the value >>>>> again. Only entity X needs to understand what it means. >>>>>=20 >>>>> In some environments the use case is slightly different, >>>>> namely entity X and entity Y are from the same organization >>>>> and agree on the semantic. Usage of OAuth within an >>>>> enterprise might be such a case. >>>>>=20 >>>>> Now, the usage of the scope parameter is, however, a bit >>>>> different in the spec. Section 4, for example, describes how >>>>> a client obtains an access token. How does the client know >>>>> what scope parameters to set and what the semantic is? >>>>>=20 >>>>> Ciao >>>>> Hannes >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: ext Lukas Rosenstock [mailto:lr@lukasrosenstock.net] >>>>>> Sent: Thursday, June 24, 2010 10:49 AM >>>>>> To: Dick Hardt >>>>>> Cc: Tschofenig, Hannes (NSN - FI/Espoo); OAuth WG >>>>>> Subject: Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? >>>>>>=20 >>>>>> Wasn't there some concensus that URIs would be good for >>>> scope? They >>>>>> have "in-built namespacing" ... >>>>>>=20 >>>>>> Lukas >>>>>>=20 >>>>>> 2010/6/23 Dick Hardt <dick.hardt@gmail.com>: >>>>>>>=20 >>>>>>> On 2010-06-22, at 11:07 PM, Tschofenig, Hannes (NSN - >>>>>> FI/Espoo) wrote: >>>>>>>=20 >>>>>>>> " >>>>>>>> scope >>>>>>>> OPTIONAL. The scope of the access request >>>>>> expressed as a list >>>>>>>> of space-delimited strings. The value of the >>>>>> "scope" parameter >>>>>>>> is defined by the authorization server. If the >>>>>> value contains >>>>>>>> multiple space-delimited strings, their order does >>>>>> not matter, >>>>>>>> and each string adds an additional access range to the >>>>>>>> requested scope. >>>>>>>> " >>>>>>>>=20 >>>>>>>> Do folks think it would be useful to have standardized values? >>>>>>>=20 >>>>>>> Not at this time. The semantics of scope are all over the >>>>>> place. If standardized, people will feel they need to pick >>>>> one that is >>>>>> close to what they want, but is not exactly what they mean. >>>>> I think it >>>>>> is better for the AS to define what they mean by a scope >>>>> and give it a >>>>>> name that makes sense in that context. >>>>>>>=20 >>>>>>>>=20 >>>>>>>> If the answer is "yes", then it would be useful to >>>>>> differentiate the >>>>>>>> standardized values from those values that are purely >>>>>> defined locally by >>>>>>>> the authorization server. >>>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Fri Jun 25 11:00:18 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6A773A681E for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 11:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.213 X-Spam-Level: X-Spam-Status: No, score=-2.213 tagged_above=-999 required=5 tests=[AWL=0.386, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id byJhautpw92o for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 11:00:16 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id D4A2428C16B for <oauth@ietf.org>; Fri, 25 Jun 2010 11:00:14 -0700 (PDT) Received: (qmail 7208 invoked from network); 25 Jun 2010 18:00:23 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 25 Jun 2010 18:00:22 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Fri, 25 Jun 2010 11:00:08 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>, OAuth WG <oauth@ietf.org> Date: Fri, 25 Jun 2010 10:59:50 -0700 Thread-Topic: Extensibility for OAuth? Thread-Index: AcsSmmOz8+Jt3DWXRJyOV1i4UkJelAB9HoEA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EC84973@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <3D3C75174CB95F42AD6BCC56E5555B4502BE07CC@FIESEXC015.nsn-intra.net> In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B4502BE07CC@FIESEXC015.nsn-intra.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] Extensibility for OAuth? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 25 Jun 2010 18:00:18 -0000 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Tschofenig, Hannes (NSN - FI/Espoo) > Sent: Tuesday, June 22, 2010 11:08 PM > To: OAuth WG > Subject: [OAUTH-WG] Extensibility for OAuth? >=20 > Hi Eran, > Hi all, >=20 > I briefly browsed through the -08 version of the draft to figure out what > could be written about extensibility. Here are a few thoughts: >=20 > - Client Profiles >=20 > This is probably the most important item were people will want to write > extensions for. Currently, we have the following onces in the document: > 1) Web Server > 2) User Agent > 3) Native Application > 4) Autonomous > Note that the actual profile identifiers aren't clearly listed in the d= ocument > at the moment (or are inconsistent, such as "user_agent" and "user-agent" > for the user agent profile). Profiles are not normative language, they are just examples of the authoriz= ation and token endpoints can be used (profiled) for particular use cases (= the most common ones). This is why this has been moved to the introduction.= Instead, the spec now talks about grant types, providing three primary typ= es (user basic credentials, authorization code obtained from the authorizat= ion endpoint, and assertion). The assertion type is the generic extension p= oint using a URI-formatted assertion type (which does not require a registr= y). I would rather limit the ability to extend the two endpoints beyond their c= urrent architecture, and instead, allow others to specify new endpoints (e.= g. a device endpoint for getting an authorization code without using browse= r redirection) that work in addition to the token endpoint (using an existi= ng grant type or assertion). > We would want IANA to register them and then we need to list under what > conditions new profiles can be added, or existing onces updated/deleted. > RFC 5226 defines some typical policies, see > http://tools.ietf.org/html/rfc5226. > We probably want the policy "RFC Required". When people write new > profiles we want them to provide a description about the use case, maybe = an > example, we want them to discuss security, and we definitely want to > ensure that the overall write is consistent with the base specification (= such as > with the registry parameters it defines). The reviews would ensure that > existing profile do not in fact already provide the functionality of the = newly > defined profile. Note that "RFC Required" > does not require a Standards Track RFC; an Informational or an Experiment= al > RFC is already sufficient. Those are less difficult to get published but = they still > provide a stable reference. I think Specification Required is better for most registries. > - Error Codes >=20 > The document lists error codes in Section 3.1 and Section 4.3. I suspect = that > they are not from the same pool of error codes. >=20 > My question is whether some of the error codes are very specific to the > profiles themselves or rather generic in nature. I'm working to clean up errors in -09. > - Grant Type >=20 > The Grant Type (grant_type) is described in Section 4. Currently, there a= re 5 > values defines ("authorization_code", "user_basic_credentials", "assertio= n", > "refresh_token", "none") and I assume that the list should be extensible > (even though the text currently says something else at the moment). >=20 > Are there specific requirements that must be met in order to register new > grant types? I would rather not allow for new grant types. I think the assertion type of= fers as much extensibility as needed. However, I am going to propose we all= ow extension parameters to both endpoints. > - Assertion Type >=20 > Section 4.1.3 defines the assertion type ("assertion_type"). The text > indicates that the content is an absolute URI and as such it is a bit dif= ferent to > the other value encodings we have seen previously. > Nevertheless, the question is whether some folks want to write > standardized templates for assertions, such as a specific form of SAML > assertion. This could help interoperability a lot, I believe. The solutio= n is still > to have a URI but to define an IANA managed space for IETF standardized > assertion types. Such a style is btw common. I am not sure this is needed. URIs provide name collision protection. Beyon= d that, people should write specs as needed. EHL From breno.demedeiros@gmail.com Fri Jun 25 11:01:33 2010 Return-Path: <breno.demedeiros@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91E3628C184 for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 11:01:33 -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=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ugZtAz1wOwyV for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 11:01:32 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 9810A28C138 for <oauth@ietf.org>; Fri, 25 Jun 2010 11:01:32 -0700 (PDT) Received: by gxk8 with SMTP id 8so2233260gxk.31 for <oauth@ietf.org>; Fri, 25 Jun 2010 11:01:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=R1GoNckUyYIzG1Wq+i9Vd3d0rwFKdlQXCLfY70iPUhs=; b=E3O/pXSN9rTVeU31gvB7zM0XKSj/NXKMIpwqC0t6afw4UFj4L0PPGXyg0xiktrCcpO 5nAyv7XCcRI2Gh++HBIK4oViMdHpddOYDt2SLtvyRut+O35AeGgbjiiH9KpXg8EM4uf5 nvlPtEIA2tP1GI7ajNltFhIxKegMQLpdGqUcc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=JkDXpLpEtauwc7aEC5Sd85vbxX9B8Y5dIW+yF/CyH4r0jwYd6C5sqg0nM/ZVxZsK34 pWl7i80AXXFGBSVnrQTC3TmgpAS2b3kxZnn6/xjITUA5pVWG6lwFWN3LgQ/SDOh6B5wl ZJjIFCcf5X1cPiR13BFs9S2tJnswYzZ1TOpY4= MIME-Version: 1.0 Received: by 10.101.5.40 with SMTP id h40mr1296457ani.133.1277488896648; Fri, 25 Jun 2010 11:01:36 -0700 (PDT) Received: by 10.100.225.19 with HTTP; Fri, 25 Jun 2010 11:01:36 -0700 (PDT) In-Reply-To: <CFA39B76-586F-443B-81F2-AC65FC6361FC@facebook.com> References: <AANLkTingCgO-o3XRZbxYoD8U2rRTO-EgWcfg2hBlbQHm@mail.gmail.com> <AANLkTinZ1XIFO25mcgoiDV-V0Blvv8ZC6kV_F3fca3dC@mail.gmail.com> <4C5BCAC6-713F-4C42-8696-2931D1AB3199@gmail.com> <AANLkTinlATNBEQsmFJIxv_cgqfI_tsoGfTMy6OXN6F_B@mail.gmail.com> <A08279DC79B11C48AD587060CD9397712735068D@TK5EX14MBXC101.redmond.corp.microsoft.com> <AANLkTimLrZzwDW9rMtGjD9k6ZtXc_oDXIIIYWOMw-NCi@mail.gmail.com> <AANLkTilcn_qQLgriJEdPk95f2Zliyk0QXGvU6t77Aa7G@mail.gmail.com> <AANLkTinEjidY_HmcGHPTus7P1snjCl9DPL4dX-Sz_mTQ@mail.gmail.com> <AANLkTilRUQiD5oRyxUZXmPs2skCY8zAmc1Vl--8pEblS@mail.gmail.com> <AANLkTilAjh9Jl0__9jksh3eY7giVR6Wtr0NYNoFfYHZX@mail.gmail.com> <AANLkTil3NxM_TmrusslVpCTqwqA8AEtH_vPsHnxkrcE3@mail.gmail.com> <CFA39B76-586F-443B-81F2-AC65FC6361FC@facebook.com> Date: Fri, 25 Jun 2010 11:01:36 -0700 Message-ID: <AANLkTim0Z9wZrqX_zZxboZHCRjx9a28VcabWr-Hi1_-H@mail.gmail.com> From: Breno <breno.demedeiros@gmail.com> To: Luke Shepard <lshepard@facebook.com> Content-Type: text/plain; charset=ISO-8859-1 Cc: "Hannes.Tschofenig@gmx.net" <Hannes.Tschofenig@gmx.net>, OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] proposal for signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 25 Jun 2010 18:01:33 -0000 On Fri, Jun 25, 2010 at 10:51 AM, Luke Shepard <lshepard@facebook.com> wrote: >> What's the purpose of leaving out the key ID? > It's one more field that developers have to learn and configure and type in. > We should keep the simple case simple, while allowing for more complex > cases. I think the fact that many providers now offer only a single, shared > secret is an indication that the key ID is not required. Are you arguing here that the key_id should be an optional field, or that it should not be part of the specification at all? > On Jun 25, 2010, at 7:40 AM, Breno wrote: > > Key ids are an optimization in the case of rotating public keys, but pretty > much an operational requirement if you wish to support automatic rotation of > shared keys. > > On Jun 23, 2010 2:56 AM, "Ben Laurie" <benl@google.com> wrote: > > On 22 June 2010 21:45, David Recordon <recordond@gmail.com> wrote: >> Hey Dick, in answering my quest... > > I don't understand why they are unnecessary no matter how keys are > managed: if there's ever a possibility that you might have more than > one key for someone, then key IDs are a useful optimisation. > > Put it another way: what's the purpose of leaving out the key ID? > >> And yes, Applied Cryptography is worth reading. :) >> >> --David >> >> >> On Tue, Jun 22, 2010 at 12:5... > > <ATT00001..txt> > -- Breno de Medeiros From eran@hueniverse.com Fri Jun 25 11:11:33 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 414CA28C172 for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 11:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.217 X-Spam-Level: X-Spam-Status: No, score=-2.217 tagged_above=-999 required=5 tests=[AWL=0.382, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SLxWCk9CaYvu for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 11:11:30 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 5A1C028C16D for <oauth@ietf.org>; Fri, 25 Jun 2010 11:11:30 -0700 (PDT) Received: (qmail 18963 invoked from network); 25 Jun 2010 18:11:39 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 25 Jun 2010 18:11:38 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Fri, 25 Jun 2010 11:11:38 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: Blaine Cook <romeda@gmail.com>, "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com> Date: Fri, 25 Jun 2010 11:11:20 -0700 Thread-Topic: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? Thread-Index: AcsUdiUnQie0dyRCR9KmWvGW26saQgAGxpqg Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EC8498C@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <3D3C75174CB95F42AD6BCC56E5555B4502BE07CC@FIESEXC015.nsn-intra.net> <E7A7F197-3BBC-43F2-8242-D0164057A39A@gmail.com> <AANLkTild51WHVcXxYFCygL8sGSGiN3HILDFwIbym6Lfi@mail.gmail.com> <3D3C75174CB95F42AD6BCC56E5555B4502869858@FIESEXC015.nsn-intra.net> <012AB2B223CB3F4BB846962876F47217059B663D@SNV-EXVS08.ds.corp.yahoo.com> <3D3C75174CB95F42AD6BCC56E5555B450286986B@FIESEXC015.nsn-intra.net> <AANLkTinOJ-t3XLweZpcWbgtKKGlCfVD_-Md08hVsCXM9@mail.gmail.com> In-Reply-To: <AANLkTinOJ-t3XLweZpcWbgtKKGlCfVD_-Md08hVsCXM9@mail.gmail.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 Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 25 Jun 2010 18:11:33 -0000 VGhlIGludGVyb3AgdmFsdWUgb2YgdGhlIGN1cnJlbnQgcHJvcG9zYWwgaXMgc2ltcGxlOg0KDQot IGRlZmluZXMgaG93IG11bHRpcGxlIHNjb3BlcyBhcmUgdG8gYmUgZXhwcmVzc2VkIChvcmRlciBk b2Vzbid0IG1hdHRlciwgc3BhY2UgZGVsaW1pdGVkKQ0KLSBwcm92aWRlcyBhbiBlYXN5IHdheSB0 byBleHByZXNzIHRoZSByZXF1aXJlZCBzY29wZSB3aGVuIHJlamVjdGVkIGEgcHJvdGVjdGVkIHJl c291cmNlIHJlcXVlc3QNCi0gYWxsb3dzIGNsaWVudHMgdGhlIGFiaWxpdHkgdG8gY29tYmluZSBz Y29wZXMgKGtub3duIGFuZCBkaXNjb3ZlcmVkKSB3aXRob3V0IGFkZGl0aW9uYWwgc2VydmVyLXNw ZWNpZmljIGxvZ2ljDQoNCkkgdGhpbmsgdGhpcyBpcyBlbm91Z2ggdmFsdWUgdG8gZGVmaW5lIGFu IGludGVybmFsIHN0cnVjdHVyZSB0byB0aGUgc2NvcGUgc3RyaW5nIGJleW9uZCBqdXN0IGEgYmxv Yi4gVGhlIGN1cnJlbnQgcHJvcG9zYWwgZG9lc24ndCBwcmV2ZW50IHRoZSBZUUwgZXhhbXBsZSB5 b3UgcHJvdmlkZWQsIGp1c3QgdGhhdCBpdCBuZWVkcyB0byBiZSBlbmNvZGVkIHRvIHJlcGxhY2Ug dGhlIHNwYWNlcyB3aXRoIHNvbWV0aGluZyBlbHNlIChzaW5jZSBzcGFjZSBkZWxpbWl0ZWQgb3Jk ZXIgZG9lcyBub3QgbWF0dGVyKS4NCg0KV2Ugd2FudCB0byBrZWVwIHNjb3BlIHVuZGVyc3BlY2lm aWVkIGVub3VnaCB0byBhbGxvdyB0aGUgbGV2ZWwgb2YgY3VzdG9taXphdGlvbiBjdXJyZW50bHkg ZXhwcmVzc2VkIGJ5IHRoZSBkaWZmZXJlbnQgdmVuZG9ycyByZXByZXNlbnRlZCBoZXJlLiBCdXQg d2UgYWxzbyB3YW50IHRvIG1ha2Ugc3VyZSB0aGF0IGRlZmluaW5nIGludGVyb3Agc2NvcGVzIGlz IHdlbGwgdW5kZXJzdG9vZCBhbmQgc2ltcGxlIGFzIHdlIGFscmVhZHkgaGF2ZSBhIGZldyB1c2Ug Y2FzZXMgZm9yIGl0IChlLmcuIE9wZW5JRCBDb25uZWN0LCBQb3J0YWJsZSBDb250YWN0cykuDQoN CkVITA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IG9hdXRoLWJvdW5j ZXNAaWV0Zi5vcmcgW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4g T2YgQmxhaW5lIENvb2sNCj4gU2VudDogRnJpZGF5LCBKdW5lIDI1LCAyMDEwIDc6NTMgQU0NCj4g VG86IFRzY2hvZmVuaWcsIEhhbm5lcyAoTlNOIC0gRkkvRXNwb28pDQo+IENjOiBPQXV0aCBXRw0K PiBTdWJqZWN0OiBSZTogW09BVVRILVdHXSBTY29wZSA6OiBXYXM6IEV4dGVuc2liaWxpdHkgZm9y IE9BdXRoPw0KPiANCj4gSSBhZ3JlZSB3aXRoIERpY2sgdGhhdCB0aGUgc2NvcGUgc2hvdWxkIHJl bWFpbiBvdXQgb2Ygc2NvcGUgZm9yIE9BdXRoLg0KPiA7LSkgSGF2aW5nIGEgc2hhcmVkIHBhcmFt ZXRlciBoZXJlIGdpdmVzIHRoZSBpbGx1c2lvbiBvZiBpbnRlcm9wZXJhYmlsaXR5LCBidXQNCj4g YmVjYXVzZSB0aGVyZSdzIG5vIGNvbW1vbiB1bmRlcnN0YW5kaW5nIG9mIHBlcm1pc3NpYmxlIHNj b3BlcywgdGhlcmUncyBubw0KPiB3YXkgdG8gZ3VhcmFudGVlIHRoYXQgYW55IGdpdmVuIGNsaWVu dC1zZXJ2ZXIgcGFpciBjb3VsZCBleHBlY3QgdG8gcHJvZHVjZQ0KPiBwcmVkaWN0YWJsZSBvdXRj b21lcy4NCj4gDQo+IEZ1cnRoZXJtb3JlLCBsaW1pdGluZyB0aGUgZm9ybWF0IG9mIHRoZSBzY29w ZSBwcmVtYXR1cmVseSBtZWFucyB0aGF0IHdlDQo+IGdpdmUgdXAgb24gYSB3aG9sZSBzZXQgb2Yg cG9zc2liaWxpdGllcyBiZWZvcmUgd2UndmUgZXZlbiBoYWQgYSBjaGFuY2UgdG8gc2VlDQo+IHdo YXQgdGhvc2UgcG9zc2liaWxpdGllcyBhcmUuIEZvciBleGFtcGxlLCBZUUwgbWlnaHQgd2FudCB0 byBhbGxvdyBhIHNjb3BlIHRvDQo+IGJlIGRlZmluZWQgbGlrZSAiU0VMRUNUICogRlJPTSBmbGlj a3IiIG9yIHNvbWV0aGluZyBzaW1pbGFyLiBNYXliZSBzY29wZSBpcw0KPiBpbXBsaWNpdCBpbiBh c3NlcnRpb25zLCBvciBldmVuIGV4cGxpY2l0LiBTY29wZSBtaWdodCBiZSB0aWVkIHRvIHRoZSBk ZWdyZWUgdG8NCj4gd2hpY2ggdGhlIHJlcXVlc3RpbmcgYW5kL29yIGdyYW50aW5nIHBhcnRpZXMg YXJlIHRydXN0ZWQgYnkgdGhlIHNlcnZpY2UNCj4gcHJvdmlkZXIuDQo+IA0KPiBJZiB0aGVyZSB3 ZXJlIGEgY29tcGVsbGluZyBzdG9yeSBhYm91dCBob3cgc2NvcGUgaXMgc3VwcG9zZWQgdG8gcmVh bGlzdGljYWxseQ0KPiBhY2hpZXZlIGdyZWF0ZXIgaW50ZXJvcGVyYWJpbGl0eSwgaXQgbWlnaHQg YmUgd29ydGh3aGlsZSBmb3IgdXMgdG8gY29uc2lkZXIgaXQuDQo+IEluIHRoZSBtZWFudGltZSwg dGhvdWdoLCBJIHRoaW5rIGl0IGp1c3QgcmVwcmVzZW50cyB0aGUgc2FtZSBmZWF0dXJpdGlzIGRy aXZlDQo+IHRoYXQgZ290IHVzIGFuIHVuZGVyLXNwZWNpZmllZCAoYW5kIG1vcmUgaGFybWZ1bCB0 aGFuIGhlbHBmdWwpIHZlcnNpb24NCj4gcGFyYW1ldGVyIGluIE9BdXRoIDEuMC4NCj4gDQo+IGIu DQo+IA0KPiBPbiAyNSBKdW5lIDIwMTAgMDg6NTksIFRzY2hvZmVuaWcsIEhhbm5lcyAoTlNOIC0g RkkvRXNwb28pDQo+IDxoYW5uZXMudHNjaG9mZW5pZ0Buc24uY29tPiB3cm90ZToNCj4gPiBEaWNr IHBvaW50ZWQgbWUgdG8gdGhlIEZhY2Vib29rIEFQSSBvbiBob3cgc2NvcGUgaXMgdXNlZC4NCj4g PiBUaGUgbWFpbiBwYWdlIGlzIGhlcmU6DQo+ID4gaHR0cDovL2RldmVsb3BlcnMuZmFjZWJvb2su Y29tL2RvY3MvYXV0aGVudGljYXRpb24vDQo+ID4NCj4gPiBJdCBkZXNjcmliZXMgdGhlIGJhc2lj IGZ1bmN0aW9uYWxpdHkgYW5kIGFsc28gbGlzdHMgYW4gZXhhbXBsZToNCj4gPg0KPiA+ICINCj4g PiBodHRwczovL2dyYXBoLmZhY2Vib29rLmNvbS9vYXV0aC9hdXRob3JpemU/DQo+ID4gwqAgwqBj bGllbnRfaWQ9Li4uJg0KPiA+IMKgIMKgcmVkaXJlY3RfdXJpPWh0dHA6Ly93d3cuZXhhbXBsZS5j b20vY2FsbGJhY2smDQo+ID4gwqAgwqBzY29wZT11c2VyX3Bob3Rvcyx1c2VyX3ZpZGVvcyxwdWJs aXNoX3N0cmVhbQ0KPiA+ICINCj4gPg0KPiA+IFRoZSB2YWx1ZXMgb2YgdGhlIHNjb3BlIHBhcmFt ZXRlciBhcmUgdGhlbiBleHBsYWluZWQgaGVyZToNCj4gPiBodHRwOi8vZGV2ZWxvcGVycy5mYWNl Ym9vay5jb20vZG9jcy9hdXRoZW50aWNhdGlvbi9wZXJtaXNzaW9ucw0KPiA+DQo+ID4gRXhhbXBs ZTogdXNlcl9waG90b3MgLi4uIFByb3ZpZGVzIGFjY2VzcyB0byB0aGUgcGhvdG9zIHRoZSB1c2Vy IGhhcw0KPiA+IHVwbG9hZGVkDQo+ID4NCj4gPiBJIHRoaW5rIGl0IHByb3ZpZGVzIGEgZ29vZCBl eGFtcGxlIHRoYXQgdGhlIHNjb3BlIHZhbHVlcyBhcmUgbm90IG9wYXF1ZS4NCj4gPiBPcGFxdWUg KGluIHRoaXMgY29udGV4dCkgbWVhbnMgdGhhdCBvbmx5IHRoZSBlbnRpdHkgY3JlYXRpbmcgaXQg bmVlZHMgdG8NCj4gdW5kZXJzdGFuZCBpdCBhbmQgbm9ib2R5IGVsc2UuIEhlcmUgdGhlIGNsaWVu dCBuZWVkcyB0byB1bmRlcnN0YW5kIGFuZCBzZXQNCj4gdGhlbS4NCj4gPg0KPiA+IEhvd2V2ZXIs IG9uZSBjb3VsZCBhcmd1ZSB0aGF0IHRoZSBzY29wZSB2YWx1ZXMgYXJlIGFscmVhZHkgYm91bmQg dG8gdGhlDQo+IHNwZWNpZmljIGVudGl0eSB0aGUgY2xpZW50IHJlcXVlc3RzIHRvIG9idGFpbiB0 aGUgYXNzZXJ0aW9uIGZyb20uIEluIHRoaXMgc3BlY2lmaWMNCj4gY2FzZSBpdCB3b3VsZCBiZSAi aHR0cHM6Ly9ncmFwaC5mYWNlYm9vay5jb20iLg0KPiA+DQo+ID4gVG8gcmVzcG9uZCB0byB0aGUg c3RhdGVtZW50IERpY2sgbWFkZSBhYm91dCBoYXZpbmcgc3RhbmRhcmRpemVkIHZhbHVlcw0KPiBs YXRlciB0aGVyZSB3b3VsZCBzdGlsbCBiZSB0aGUgbmVlZCB0byBkZWNpZGUgYWJvdXQgdGhlIHN0 cnVjdHVyZSBvZiB0aGUNCj4gdmFsdWVzIG5vdy4gT25lIHBvc3NpYmlsaXR5IGlzIHRvIGp1c3Qg YWRkIGEgcHJlZml4IGZvciBzdGFuZGFyZGl6ZWQgdmFsdWVzIHRoYXQNCj4gYXJlIG5vdCBhbGxv d2VkIHRvIGJlIHVzZWQgaW4gb3RoZXIgY2FzZXMsIHN1Y2ggYXMgInN0ZDoiLg0KPiA+DQo+ID4g Q2lhbw0KPiA+IEhhbm5lcw0KPiA+DQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gPj4gRnJvbTogZXh0IFdpbGxpYW0gTWlsbHMgW21haWx0bzp3bWlsbHNAeWFob28taW5j LmNvbV0NCj4gPj4gU2VudDogVGh1cnNkYXksIEp1bmUgMjQsIDIwMTAgODoxNSBQTQ0KPiA+PiBU bzogVHNjaG9mZW5pZywgSGFubmVzIChOU04gLSBGSS9Fc3Bvbyk7IGV4dCBMdWthcyBSb3NlbnN0 b2NrOyBEaWNrDQo+ID4+IEhhcmR0DQo+ID4+IENjOiBPQXV0aCBXRw0KPiA+PiBTdWJqZWN0OiBS RTogW09BVVRILVdHXSBTY29wZSA6OiBXYXM6IEV4dGVuc2liaWxpdHkgZm9yIE9BdXRoPw0KPiA+ Pg0KPiA+PiBJJ20gaW4gZmF2b3Igb2YgaGF2aW5nIGEgc3BhY2VzIHNlcGFyYXRlZCBsaXN0IG9m IHRva2Vucy4NCj4gPj4gVGhlIG9ubHkgY2FzZSBJIGNhbiB0aGluayBvZiB3aGVyZSB0aGUgY2xp ZW50IG5lZWRzIHRvIGhhbmRsZSB0aGUNCj4gPj4gc2NvcGUgYXMgYW55dGhpbmcgb3RoZXIgdGhh biBvcGFxdWUgaXMgd2hlbiBpdCBpcyBhY2Nlc3NpbmcgbXVsdGlwbGUNCj4gPj4gc2VydmljZXMu IMKgVG8gcmVkdWNlIHRoZSBudW1lYnIgb2YgbG9naW4gZXZlbnRzIHRoZSBjbGllbnQgd2lsbCBo YXZlDQo+ID4+IHRvIHBvbGwgYWxsIHRoZSBlbmRwb2ludHMgaXQgd2FudHMgdG8gYWNjZXNzIGFu ZCBnZXQgYWxsIHRoZSBzY29wZXMNCj4gPj4gYWR2ZXJ0aXplZCBieSB0aGVtIGFuZCBzdWJtaXQg dGhlbSBhbGwsIGFuZCBvbmNlIGl0IGhhcyB0aGVtIGl0IG5lZWRzDQo+ID4+IHRvIHN1Ym1pdCBh bGwgb2YgdGhlbSBpbiBpdCdzIGF1dGggcmVxdWVzdCwgc28gd2UgbmVlZCBzb21ldGhpbmcNCj4g Pj4gdGhhdCdzIGVhc3kgZm9yIHRoZSBjbGllbnQgdG8gcHV0IHRvZ2V0aGVyLg0KPiA+Pg0KPiA+ Pg0KPiA+PiAtYmlsbA0KPiA+Pg0KPiA+PiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ ID4+ID4gRnJvbTogb2F1dGgtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm9hdXRoLWJvdW5jZXNA aWV0Zi5vcmddIE9uDQo+ID4+ID4gQmVoYWxmIE9mIFRzY2hvZmVuaWcsIEhhbm5lcyAoTlNOIC0g RkkvRXNwb28pDQo+ID4+ID4gU2VudDogVGh1cnNkYXksIEp1bmUgMjQsIDIwMTAgMzo1OCBBTQ0K PiA+PiA+IFRvOiBleHQgTHVrYXMgUm9zZW5zdG9jazsgRGljayBIYXJkdA0KPiA+PiA+IENjOiBP QXV0aCBXRw0KPiA+PiA+IFN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFNjb3BlIDo6IFdhczogRXh0 ZW5zaWJpbGl0eSBmb3IgT0F1dGg/DQo+ID4+ID4NCj4gPj4gPiBUaGUgcXVlc3Rpb24gaXMgd2hl dGhlciBvbmUgd291bGQgZXZlciB3YW50IHRvIGhhdmUgYSBzdGFuZGFyZGl6ZWQNCj4gPj4gPiBz ZW1hbnRpYyBmb3IgdGhlIHNjb3BlIHBhcmFtZXRlci4NCj4gPj4gPiBJZiB0aGUgYW5zd2VyIHRv IHRoYXQgcXVlc3Rpb24gaXMgIm5vIiB0aGVuIGl0IGRvZXMgbm90IG1hdHRlciB3aGF0DQo+ID4+ ID4gdGhlIGZvcm1hdCBpcy4gSXQgY2FuIHdlbGwgYmUgYSBsaXN0IG9mIHNwYWNlLWRlbGltaXRl ZCBzdHJpbmdzIChhcw0KPiA+PiA+IGl0IGlzIGN1cnJlbnRseSBkZWZpbmVkKS4NCj4gPj4gPg0K PiA+PiA+IEFuIGV2aXJvbm1lbnQgc3BlY2lmaWMgc2VtYW50aWMgd29ya3Mgd2VsbCBpbiBjYXNl cyB3aGVyZSBlbnRpdHkgWA0KPiA+PiA+IHNldHMgdGhlIHZhbHVlIGFuZCBsYXRlciBpdCByZWNl aXZlcyB0aGUgdmFsdWUgYWdhaW4uIE9ubHkgZW50aXR5IFgNCj4gPj4gPiBuZWVkcyB0byB1bmRl cnN0YW5kIHdoYXQgaXQgbWVhbnMuDQo+ID4+ID4NCj4gPj4gPiBJbiBzb21lIGVudmlyb25tZW50 cyB0aGUgdXNlIGNhc2UgaXMgc2xpZ2h0bHkgZGlmZmVyZW50LCBuYW1lbHkNCj4gPj4gPiBlbnRp dHkgWCBhbmQgZW50aXR5IFkgYXJlIGZyb20gdGhlIHNhbWUgb3JnYW5pemF0aW9uIGFuZCBhZ3Jl ZSBvbg0KPiA+PiA+IHRoZSBzZW1hbnRpYy4gVXNhZ2Ugb2YgT0F1dGggd2l0aGluIGFuIGVudGVy cHJpc2UgbWlnaHQgYmUgc3VjaCBhDQo+ID4+ID4gY2FzZS4NCj4gPj4gPg0KPiA+PiA+IE5vdywg dGhlIHVzYWdlIG9mIHRoZSBzY29wZSBwYXJhbWV0ZXIgaXMsIGhvd2V2ZXIsIGEgYml0IGRpZmZl cmVudA0KPiA+PiA+IGluIHRoZSBzcGVjLiBTZWN0aW9uIDQsIGZvciBleGFtcGxlLCBkZXNjcmli ZXMgaG93IGEgY2xpZW50IG9idGFpbnMNCj4gPj4gPiBhbiBhY2Nlc3MgdG9rZW4uIEhvdyBkb2Vz IHRoZSBjbGllbnQga25vdyB3aGF0IHNjb3BlIHBhcmFtZXRlcnMgdG8NCj4gPj4gPiBzZXQgYW5k IHdoYXQgdGhlIHNlbWFudGljIGlzPw0KPiA+PiA+DQo+ID4+ID4gQ2lhbw0KPiA+PiA+IEhhbm5l cw0KPiA+PiA+DQo+ID4+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiA+ID4g RnJvbTogZXh0IEx1a2FzIFJvc2Vuc3RvY2sgW21haWx0bzpsckBsdWthc3Jvc2Vuc3RvY2submV0 XQ0KPiA+PiA+ID4gU2VudDogVGh1cnNkYXksIEp1bmUgMjQsIDIwMTAgMTA6NDkgQU0NCj4gPj4g PiA+IFRvOiBEaWNrIEhhcmR0DQo+ID4+ID4gPiBDYzogVHNjaG9mZW5pZywgSGFubmVzIChOU04g LSBGSS9Fc3Bvbyk7IE9BdXRoIFdHDQo+ID4+ID4gPiBTdWJqZWN0OiBSZTogW09BVVRILVdHXSBT Y29wZSA6OiBXYXM6IEV4dGVuc2liaWxpdHkgZm9yIE9BdXRoPw0KPiA+PiA+ID4NCj4gPj4gPiA+ IFdhc24ndCB0aGVyZSBzb21lIGNvbmNlbnN1cyB0aGF0IFVSSXMgd291bGQgYmUgZ29vZCBmb3IN Cj4gPj4gc2NvcGU/IFRoZXkNCj4gPj4gPiA+IGhhdmUgImluLWJ1aWx0IG5hbWVzcGFjaW5nIiAu Li4NCj4gPj4gPiA+DQo+ID4+ID4gPiBMdWthcw0KPiA+PiA+ID4NCj4gPj4gPiA+IDIwMTAvNi8y MyBEaWNrIEhhcmR0IDxkaWNrLmhhcmR0QGdtYWlsLmNvbT46DQo+ID4+ID4gPiA+DQo+ID4+ID4g PiA+IE9uIDIwMTAtMDYtMjIsIGF0IDExOjA3IFBNLCBUc2Nob2ZlbmlnLCBIYW5uZXMgKE5TTiAt DQo+ID4+ID4gPiBGSS9Fc3Bvbykgd3JvdGU6DQo+ID4+ID4gPiA+DQo+ID4+ID4gPiA+PiAiDQo+ ID4+ID4gPiA+PiDCoCBzY29wZQ0KPiA+PiA+ID4gPj4gwqAgwqAgwqAgwqAgT1BUSU9OQUwuIMKg VGhlIHNjb3BlIG9mIHRoZSBhY2Nlc3MgcmVxdWVzdA0KPiA+PiA+ID4gZXhwcmVzc2VkIGFzIGEg bGlzdA0KPiA+PiA+ID4gPj4gwqAgwqAgwqAgwqAgb2Ygc3BhY2UtZGVsaW1pdGVkIHN0cmluZ3Mu IMKgVGhlIHZhbHVlIG9mIHRoZQ0KPiA+PiA+ID4gInNjb3BlIiBwYXJhbWV0ZXINCj4gPj4gPiA+ ID4+IMKgIMKgIMKgIMKgIGlzIGRlZmluZWQgYnkgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLiDC oElmIHRoZQ0KPiA+PiA+ID4gdmFsdWUgY29udGFpbnMNCj4gPj4gPiA+ID4+IMKgIMKgIMKgIMKg IG11bHRpcGxlIHNwYWNlLWRlbGltaXRlZCBzdHJpbmdzLCB0aGVpciBvcmRlciBkb2VzDQo+ID4+ ID4gPiBub3QgbWF0dGVyLA0KPiA+PiA+ID4gPj4gwqAgwqAgwqAgwqAgYW5kIGVhY2ggc3RyaW5n IGFkZHMgYW4gYWRkaXRpb25hbCBhY2Nlc3MgcmFuZ2UgdG8gdGhlDQo+ID4+ID4gPiA+PiDCoCDC oCDCoCDCoCByZXF1ZXN0ZWQgc2NvcGUuDQo+ID4+ID4gPiA+PiAiDQo+ID4+ID4gPiA+Pg0KPiA+ PiA+ID4gPj4gRG8gZm9sa3MgdGhpbmsgaXQgd291bGQgYmUgdXNlZnVsIHRvIGhhdmUgc3RhbmRh cmRpemVkIHZhbHVlcz8NCj4gPj4gPiA+ID4NCj4gPj4gPiA+ID4gTm90IGF0IHRoaXMgdGltZS4g VGhlIHNlbWFudGljcyBvZiBzY29wZSBhcmUgYWxsIG92ZXIgdGhlDQo+ID4+ID4gPiBwbGFjZS4g SWYgc3RhbmRhcmRpemVkLCBwZW9wbGUgd2lsbCBmZWVsIHRoZXkgbmVlZCB0byBwaWNrDQo+ID4+ ID4gb25lIHRoYXQgaXMNCj4gPj4gPiA+IGNsb3NlIHRvIHdoYXQgdGhleSB3YW50LCBidXQgaXMg bm90IGV4YWN0bHkgd2hhdCB0aGV5IG1lYW4uDQo+ID4+ID4gSSB0aGluayBpdA0KPiA+PiA+ID4g aXMgYmV0dGVyIGZvciB0aGUgQVMgdG8gZGVmaW5lIHdoYXQgdGhleSBtZWFuIGJ5IGEgc2NvcGUN Cj4gPj4gPiBhbmQgZ2l2ZSBpdCBhDQo+ID4+ID4gPiBuYW1lIHRoYXQgbWFrZXMgc2Vuc2UgaW4g dGhhdCBjb250ZXh0Lg0KPiA+PiA+ID4gPg0KPiA+PiA+ID4gPj4NCj4gPj4gPiA+ID4+IElmIHRo ZSBhbnN3ZXIgaXMgInllcyIsIHRoZW4gaXQgd291bGQgYmUgdXNlZnVsIHRvDQo+ID4+ID4gPiBk aWZmZXJlbnRpYXRlIHRoZQ0KPiA+PiA+ID4gPj4gc3RhbmRhcmRpemVkIHZhbHVlcyBmcm9tIHRo b3NlIHZhbHVlcyB0aGF0IGFyZSBwdXJlbHkNCj4gPj4gPiA+IGRlZmluZWQgbG9jYWxseSBieQ0K PiA+PiA+ID4gPj4gdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLg0KPiA+PiA+ID4NCj4gPj4gPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiA+IE9B dXRoIG1haWxpbmcgbGlzdA0KPiA+PiA+IE9BdXRoQGlldGYub3JnDQo+ID4+ID4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KPiA+PiA+DQo+ID4+DQo+ID4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBPQXV0aCBt YWlsaW5nIGxpc3QNCj4gPiBPQXV0aEBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vb2F1dGgNCj4gPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4gT0F1dGhAaWV0 Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0K From dick.hardt@gmail.com Fri Jun 25 11:13:00 2010 Return-Path: <dick.hardt@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8E7728C175 for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 11:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fCOs0zOGUnLw for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 11:12:58 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id ECED828C172 for <oauth@ietf.org>; Fri, 25 Jun 2010 11:12:57 -0700 (PDT) Received: by pvc21 with SMTP id 21so1396008pvc.31 for <oauth@ietf.org>; Fri, 25 Jun 2010 11:12:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=IJCJkGQeVkvWj8uIREJPLekHcXSU+MLbhv8fL1iM370=; b=nbYhegJL9heQA1H1yH1QCMj0xYw26+GAwp7eKUZKgt+uO7HWwEy9yLAFWsM4kV96Iu S6KD+CGsrRnbUvWNuNGyllMtMPIvKyQ7huNEkkITXMa/VIoApi1jdisxotm/BaBjVCbj GWtRU1vUW+bzP60WiO14BfOU9h6XQuf64G8JE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=SHsFN+q+UHkAVRNiLCaWfC0ZBy+njFckAml+0fvqnhJxAbQ4k/BhSAfPe4BoDz99/Q hxpx6V1GztYJfrU9vHcoLRAxFBVQts//bJ98cmSy5ZVMRBsdkFK0e6gJq/1oZEd/Vwbb 7gSaSMSLckuam03/1Ev0lBBoHlocCegYJWvXw= Received: by 10.114.188.3 with SMTP id l3mr1332483waf.150.1277489578039; Fri, 25 Jun 2010 11:12:58 -0700 (PDT) Received: from [192.168.1.2] (c-24-130-32-55.hsd1.ca.comcast.net [24.130.32.55]) by mx.google.com with ESMTPS id c22sm70123269wam.6.2010.06.25.11.12.57 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 25 Jun 2010 11:12:57 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Dick Hardt <dick.hardt@gmail.com> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EC84973@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Fri, 25 Jun 2010 11:12:55 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <B6B3E8C3-6B3B-4428-94E4-1D22A93424E6@gmail.com> References: <3D3C75174CB95F42AD6BCC56E5555B4502BE07CC@FIESEXC015.nsn-intra.net> <90C41DD21FB7C64BB94121FBBC2E72343B3EC84973@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav <eran@hueniverse.com> X-Mailer: Apple Mail (2.1078) Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <hannes.tschofenig@nsn.com>, OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] Extensibility for OAuth? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 25 Jun 2010 18:13:01 -0000 Would you elaborate on your reasons here? Do you think we have = enumerated all the possibilities?=20 On 2010-06-25, at 10:59 AM, Eran Hammer-Lahav wrote: > I would rather limit the ability to extend the two endpoints beyond = their current architecture, and instead, allow others to specify new = endpoints (e.g. a device endpoint for getting an authorization code = without using browser redirection) that work in addition to the token = endpoint (using an existing grant type or assertion). From eran@hueniverse.com Fri Jun 25 11:15:31 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEFB028C14E for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 11:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.222 X-Spam-Level: X-Spam-Status: No, score=-2.222 tagged_above=-999 required=5 tests=[AWL=0.377, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id joPlyJW3lLSe for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 11:15:09 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id BF5763A6A12 for <oauth@ietf.org>; Fri, 25 Jun 2010 11:15:06 -0700 (PDT) Received: (qmail 29031 invoked from network); 25 Jun 2010 18:15:15 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 25 Jun 2010 18:15:15 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 25 Jun 2010 11:15:10 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: Dick Hardt <dick.hardt@gmail.com>, "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com> Date: Fri, 25 Jun 2010 11:14:53 -0700 Thread-Topic: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? Thread-Index: AcsUfhXUk/ktt6NIQ7KrslszLvt3aQAE7yxQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EC84994@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <3D3C75174CB95F42AD6BCC56E5555B4502BE07CC@FIESEXC015.nsn-intra.net><E7A7F197-3BBC-43F2-8242-D0164057A39A@gmail.com><AANLkTild51WHVcXxYFCygL8sGSGiN3HILDFwIbym6Lfi@mail.gmail.com> <3D3C75174CB95F42AD6BCC56E5555B4502869858@FIESEXC015.nsn-intra.net> <012AB2B223CB3F4BB846962876F47217059B663D@SNV-EXVS08.ds.corp.yahoo.com> <3D3C75174CB95F42AD6BCC56E5555B450286986B@FIESEXC015.nsn-intra.net> <9BBAE9AB-A0CD-448F-B817-21389C1BBCAF@gmail.com> In-Reply-To: <9BBAE9AB-A0CD-448F-B817-21389C1BBCAF@gmail.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 <oauth@ietf.org> Subject: Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 25 Jun 2010 18:15:32 -0000 I like the idea of an extensibility mechanism for standard scopes, but I am= not sure I like the idea of a prefix or reserved characters. Using URIs as= scope values was a requirement (and something that is currently deployed b= y Google). We defined space-delimited to make simple strings and URIs possi= ble as values. My question is, why isn't URIs enough for standard scopes? Define simple st= rings as server-specific and allow URIs to be used in standards (which will= solve potential name collisions). It might make standard scopes a bit less= cool but that's not a technical argument. I also think scopes are likely t= o be extended a lot more than other extension types and would like to keep = the process as light as possible (i.e. no registration at all). EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Dick Hardt > Sent: Friday, June 25, 2010 8:50 AM > To: Tschofenig, Hannes (NSN - FI/Espoo) > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? >=20 > To clarify, the goal is to reserve a namespace for future use so that nea= r term > implementations won't collide? >=20 > I expect the standardization of scope values to not be in OAuth, but in > standardized APIs that use OAuth, so a namespace mechanism that > differentiates between a standardized scope and an implementation specifi= c > scope may be useful. >=20 > From what I have gathered, implementors are leaning towards simple string= s > rather than URIs to declare scope. Perhaps reserving the ":" character fr= om > being in a scope string unless the scope prefix has been registered with > IANA? >=20 > -- Dick > On 2010-06-25, at 12:59 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >=20 > > Dick pointed me to the Facebook API on how scope is used. > > The main page is here: > > http://developers.facebook.com/docs/authentication/ > > > > It describes the basic functionality and also lists an example: > > > > " > > https://graph.facebook.com/oauth/authorize? > > client_id=3D...& > > redirect_uri=3Dhttp://www.example.com/callback& > > scope=3Duser_photos,user_videos,publish_stream > > " > > > > The values of the scope parameter are then explained here: > > http://developers.facebook.com/docs/authentication/permissions > > > > Example: user_photos ... Provides access to the photos the user has > > uploaded > > > > I think it provides a good example that the scope values are not opaque= . > > Opaque (in this context) means that only the entity creating it needs t= o > understand it and nobody else. Here the client needs to understand and se= t > them. > > > > However, one could argue that the scope values are already bound to the > specific entity the client requests to obtain the assertion from. In this= specific > case it would be "https://graph.facebook.com". > > > > To respond to the statement Dick made about having standardized values > later there would still be the need to decide about the structure of the > values now. One possibility is to just add a prefix for standardized valu= es that > are not allowed to be used in other cases, such as "std:". > > > > Ciao > > Hannes > > > > > >> -----Original Message----- > >> From: ext William Mills [mailto:wmills@yahoo-inc.com] > >> Sent: Thursday, June 24, 2010 8:15 PM > >> To: Tschofenig, Hannes (NSN - FI/Espoo); ext Lukas Rosenstock; Dick > >> Hardt > >> Cc: OAuth WG > >> Subject: RE: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? > >> > >> I'm in favor of having a spaces separated list of tokens. > >> The only case I can think of where the client needs to handle the > >> scope as anything other than opaque is when it is accessing multiple > >> services. To reduce the numebr of login events the client will have > >> to poll all the endpoints it wants to access and get all the scopes > >> advertized by them and submit them all, and once it has them it needs > >> to submit all of them in it's auth request, so we need something > >> that's easy for the client to put together. > >> > >> > >> -bill > >> > >>> -----Original Message----- > >>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] > >>> On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) > >>> Sent: Thursday, June 24, 2010 3:58 AM > >>> To: ext Lukas Rosenstock; Dick Hardt > >>> Cc: OAuth WG > >>> Subject: Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? > >>> > >>> The question is whether one would ever want to have a > >>> standardized semantic for the scope parameter. > >>> If the answer to that question is "no" then it does not > >>> matter what the format is. It can well be a list of > >>> space-delimited strings (as it is currently defined). > >>> > >>> An evironment specific semantic works well in cases where > >>> entity X sets the value and later it receives the value > >>> again. Only entity X needs to understand what it means. > >>> > >>> In some environments the use case is slightly different, > >>> namely entity X and entity Y are from the same organization > >>> and agree on the semantic. Usage of OAuth within an > >>> enterprise might be such a case. > >>> > >>> Now, the usage of the scope parameter is, however, a bit > >>> different in the spec. Section 4, for example, describes how > >>> a client obtains an access token. How does the client know > >>> what scope parameters to set and what the semantic is? > >>> > >>> Ciao > >>> Hannes > >>> > >>>> -----Original Message----- > >>>> From: ext Lukas Rosenstock [mailto:lr@lukasrosenstock.net] > >>>> Sent: Thursday, June 24, 2010 10:49 AM > >>>> To: Dick Hardt > >>>> Cc: Tschofenig, Hannes (NSN - FI/Espoo); OAuth WG > >>>> Subject: Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? > >>>> > >>>> Wasn't there some concensus that URIs would be good for > >> scope? They > >>>> have "in-built namespacing" ... > >>>> > >>>> Lukas > >>>> > >>>> 2010/6/23 Dick Hardt <dick.hardt@gmail.com>: > >>>>> > >>>>> On 2010-06-22, at 11:07 PM, Tschofenig, Hannes (NSN - > >>>> FI/Espoo) wrote: > >>>>> > >>>>>> " > >>>>>> scope > >>>>>> OPTIONAL. The scope of the access request > >>>> expressed as a list > >>>>>> of space-delimited strings. The value of the > >>>> "scope" parameter > >>>>>> is defined by the authorization server. If the > >>>> value contains > >>>>>> multiple space-delimited strings, their order does > >>>> not matter, > >>>>>> and each string adds an additional access range to the > >>>>>> requested scope. > >>>>>> " > >>>>>> > >>>>>> Do folks think it would be useful to have standardized values? > >>>>> > >>>>> Not at this time. The semantics of scope are all over the > >>>> place. If standardized, people will feel they need to pick > >>> one that is > >>>> close to what they want, but is not exactly what they mean. > >>> I think it > >>>> is better for the AS to define what they mean by a scope > >>> and give it a > >>>> name that makes sense in that context. > >>>>> > >>>>>> > >>>>>> If the answer is "yes", then it would be useful to > >>>> differentiate the > >>>>>> standardized values from those values that are purely > >>>> defined locally by > >>>>>> the authorization server. > >>>> > >>> _______________________________________________ > >>> 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 yarong@microsoft.com Fri Jun 25 11:17:40 2010 Return-Path: <yarong@microsoft.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55B4328C12C for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 11:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.432 X-Spam-Level: X-Spam-Status: No, score=-8.432 tagged_above=-999 required=5 tests=[AWL=-0.434, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dWAyDjAEtPOo for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 11:17:38 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id EC92528C187 for <oauth@ietf.org>; Fri, 25 Jun 2010 11:17:20 -0700 (PDT) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 25 Jun 2010 11:17:29 -0700 Received: from TK5EX14MBXC117.redmond.corp.microsoft.com ([169.254.8.23]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.01.0160.007; Fri, 25 Jun 2010 11:17:28 -0700 From: Yaron Goland <yarong@microsoft.com> To: "oauth@ietf.org" <oauth@ietf.org> Thread-Topic: How do autonomous clients asks for access tokens? Thread-Index: AcsUhyWs09OFs5wQSWq4/S2IEg6MHw== Date: Fri, 25 Jun 2010 18:17:02 +0000 Message-ID: <7C01E631FF4B654FA1E783F1C0265F8C579CA967@TK5EX14MBXC117.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7C01E631FF4B654FA1E783F1C0265F8C579CA967TK5EX14MBXC117r_" MIME-Version: 1.0 Subject: [OAUTH-WG] How do autonomous clients asks for access tokens? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 25 Jun 2010 18:17:40 -0000 --_000_7C01E631FF4B654FA1E783F1C0265F8C579CA967TK5EX14MBXC117r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Section 1.4.4 says that autonomous clients can get access tokens. But how? = What grant_type should they use? Thanks, Yaron P.S. I looked for a grant_type of autonomous but I didn't see it in -08. So= rry if I missed it. --_000_7C01E631FF4B654FA1E783F1C0265F8C579CA967TK5EX14MBXC117r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"> <style><!-- /* Font Definitions */ @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} span.EmailStyle17 {mso-style-type:personal-compose; font-family:"Calibri","sans-serif"; color:windowtext;} .MsoChpDefault {mso-style-type:export-only; font-family:"Calibri","sans-serif";} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> <p class=3D"MsoNormal">Section 1.4.4 says that autonomous clients can get a= ccess tokens. But how? What grant_type should they use?<o:p></o:p></p> <p class=3D"MsoNormal">        &nbs= p;       Thanks,<o:p></o:p></p> <p class=3D"MsoNormal">        &nbs= p;            &= nbsp;          Yaron<o:p></o:p= ></p> <p class=3D"MsoNormal">P.S. I looked for a grant_type of autonomous but I d= idn’t see it in -08. Sorry if I missed it.<o:p></o:p></p> </div> </body> </html> --_000_7C01E631FF4B654FA1E783F1C0265F8C579CA967TK5EX14MBXC117r_-- From eran@hueniverse.com Fri Jun 25 11:18:26 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2B1B3A6928 for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 11:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.226 X-Spam-Level: X-Spam-Status: No, score=-2.226 tagged_above=-999 required=5 tests=[AWL=0.373, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CqGGZkXBs+WF for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 11:18:26 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id E79433A68BD for <oauth@ietf.org>; Fri, 25 Jun 2010 11:18:25 -0700 (PDT) Received: (qmail 1770 invoked from network); 25 Jun 2010 18:18:34 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 25 Jun 2010 18:18:34 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 25 Jun 2010 11:18:29 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: Dick Hardt <dick.hardt@gmail.com> Date: Fri, 25 Jun 2010 11:18:12 -0700 Thread-Topic: [OAUTH-WG] Extensibility for OAuth? Thread-Index: AcsUkgtMuUUiIQrkTlOdovjsi2b5cwAAFinw Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EC84999@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <3D3C75174CB95F42AD6BCC56E5555B4502BE07CC@FIESEXC015.nsn-intra.net> <90C41DD21FB7C64BB94121FBBC2E72343B3EC84973@P3PW5EX1MB01.EX1.SECURESERVER.NET> <B6B3E8C3-6B3B-4428-94E4-1D22A93424E6@gmail.com> In-Reply-To: <B6B3E8C3-6B3B-4428-94E4-1D22A93424E6@gmail.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, "Tschofenig, Hannes \(NSN - FI/Espoo\)" <hannes.tschofenig@nsn.com>, WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] Extensibility for OAuth? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 25 Jun 2010 18:18:26 -0000 I think the two endpoints are currently well defined. For example, the toke= n endpoint always takes an access grant and turns it into an access token w= ith optional refresh token. To "extend" it to say, register new clients dyn= amically, is a bad thing. But adding a new parameter (such as language) is = a good thing to support, and by requiring review, only parameters that don'= t change the overall design will be approved. EHL > -----Original Message----- > From: Dick Hardt [mailto:dick.hardt@gmail.com] > Sent: Friday, June 25, 2010 11:13 AM > To: Eran Hammer-Lahav > Cc: Tschofenig, Hannes (NSN - FI/Espoo); OAuth WG > Subject: Re: [OAUTH-WG] Extensibility for OAuth? >=20 > Would you elaborate on your reasons here? Do you think we have > enumerated all the possibilities? >=20 > On 2010-06-25, at 10:59 AM, Eran Hammer-Lahav wrote: >=20 > > I would rather limit the ability to extend the two endpoints beyond the= ir > current architecture, and instead, allow others to specify new endpoints = (e.g. > a device endpoint for getting an authorization code without using browser > redirection) that work in addition to the token endpoint (using an existi= ng > grant type or assertion). From dick.hardt@gmail.com Fri Jun 25 11:18:40 2010 Return-Path: <dick.hardt@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2227328C14D for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 11:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jr1CkGf1nGLG for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 11:18:38 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id 7298A3A69A5 for <oauth@ietf.org>; Fri, 25 Jun 2010 11:18:38 -0700 (PDT) Received: by pxi16 with SMTP id 16so214767pxi.31 for <oauth@ietf.org>; Fri, 25 Jun 2010 11:18:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=Kfp0R7Hel56d9H9T6Dsu93vjr/XrbZPXGX8HmhEMExM=; b=QQ7+gzYVhxlFt8HKKoNMZDubMKvlddDgyXUY70SeWiAyWsK7rPB31Ej0k94aGp4tES sAN+mJXQxv0k+0mQOJIIBwcdRy6puoJreKuCYqoVXimojJwvypc5rVCpylz/fsLzafiV lK58KDbUQexi0OqYUb1PRkmKHFGMbSQez6DuM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=NKilEQr2NzFfhmnwknWaLUnarpDmx5glpJZZIR4doTmlH/qLN4HUUZbLDkYk1mWHh6 7A8U5EQ9YqXy3R/NhuJfYhH/IjMxTkXqVvQnx3LS6wjEF559hT5ItpaMu/QZ7VyS+rTE eqru/+yDq3ZCd61B4qoTVQacnefMcSeBn9osk= Received: by 10.142.120.9 with SMTP id s9mr1475921wfc.157.1277489924567; Fri, 25 Jun 2010 11:18:44 -0700 (PDT) Received: from [192.168.1.2] (c-24-130-32-55.hsd1.ca.comcast.net [24.130.32.55]) by mx.google.com with ESMTPS id y15sm5117659wfd.10.2010.06.25.11.18.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 25 Jun 2010 11:18:44 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Dick Hardt <dick.hardt@gmail.com> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EC84994@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Fri, 25 Jun 2010 11:18:42 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8631D908-6D38-4CE8-BEA4-2C6BE6786251@gmail.com> References: <3D3C75174CB95F42AD6BCC56E5555B4502BE07CC@FIESEXC015.nsn-intra.net><E7A7F197-3BBC-43F2-8242-D0164057A39A@gmail.com><AANLkTild51WHVcXxYFCygL8sGSGiN3HILDFwIbym6Lfi@mail.gmail.com> <3D3C75174CB95F42AD6BCC56E5555B4502869858@FIESEXC015.nsn-intra.net> <012AB2B223CB3F4BB846962876F47217059B663D@SNV-EXVS08.ds.corp.yahoo.com> <3D3C75174CB95F42AD6BCC56E5555B450286986B@FIESEXC015.nsn-intra.net> <9BBAE9AB-A0CD-448F-B817-21389C1BBCAF@gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3EC84994@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav <eran@hueniverse.com> X-Mailer: Apple Mail (2.1078) Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <hannes.tschofenig@nsn.com>, OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 25 Jun 2010 18:18:40 -0000 I'm ok with that if we provide some guidance in the spec to implementors = that recommends the use of URIs for scopes they expect to be = standardized. On 2010-06-25, at 11:14 AM, Eran Hammer-Lahav wrote: > I like the idea of an extensibility mechanism for standard scopes, but = I am not sure I like the idea of a prefix or reserved characters. Using = URIs as scope values was a requirement (and something that is currently = deployed by Google). We defined space-delimited to make simple strings = and URIs possible as values. >=20 > My question is, why isn't URIs enough for standard scopes? Define = simple strings as server-specific and allow URIs to be used in standards = (which will solve potential name collisions). It might make standard = scopes a bit less cool but that's not a technical argument. I also think = scopes are likely to be extended a lot more than other extension types = and would like to keep the process as light as possible (i.e. no = registration at all). >=20 > EHL >=20 >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf >> Of Dick Hardt >> Sent: Friday, June 25, 2010 8:50 AM >> To: Tschofenig, Hannes (NSN - FI/Espoo) >> Cc: OAuth WG >> Subject: Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? >>=20 >> To clarify, the goal is to reserve a namespace for future use so that = near term >> implementations won't collide? >>=20 >> I expect the standardization of scope values to not be in OAuth, but = in >> standardized APIs that use OAuth, so a namespace mechanism that >> differentiates between a standardized scope and an implementation = specific >> scope may be useful. >>=20 >> =46rom what I have gathered, implementors are leaning towards simple = strings >> rather than URIs to declare scope. Perhaps reserving the ":" = character from >> being in a scope string unless the scope prefix has been registered = with >> IANA? >>=20 >> -- Dick >> On 2010-06-25, at 12:59 AM, Tschofenig, Hannes (NSN - FI/Espoo) = wrote: >>=20 >>> Dick pointed me to the Facebook API on how scope is used. >>> The main page is here: >>> http://developers.facebook.com/docs/authentication/ >>>=20 >>> It describes the basic functionality and also lists an example: >>>=20 >>> " >>> https://graph.facebook.com/oauth/authorize? >>> client_id=3D...& >>> redirect_uri=3Dhttp://www.example.com/callback& >>> scope=3Duser_photos,user_videos,publish_stream >>> " >>>=20 >>> The values of the scope parameter are then explained here: >>> http://developers.facebook.com/docs/authentication/permissions >>>=20 >>> Example: user_photos ... Provides access to the photos the user has >>> uploaded >>>=20 >>> I think it provides a good example that the scope values are not = opaque. >>> Opaque (in this context) means that only the entity creating it = needs to >> understand it and nobody else. Here the client needs to understand = and set >> them. >>>=20 >>> However, one could argue that the scope values are already bound to = the >> specific entity the client requests to obtain the assertion from. In = this specific >> case it would be "https://graph.facebook.com". >>>=20 >>> To respond to the statement Dick made about having standardized = values >> later there would still be the need to decide about the structure of = the >> values now. One possibility is to just add a prefix for standardized = values that >> are not allowed to be used in other cases, such as "std:". >>>=20 >>> Ciao >>> Hannes >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: ext William Mills [mailto:wmills@yahoo-inc.com] >>>> Sent: Thursday, June 24, 2010 8:15 PM >>>> To: Tschofenig, Hannes (NSN - FI/Espoo); ext Lukas Rosenstock; Dick >>>> Hardt >>>> Cc: OAuth WG >>>> Subject: RE: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? >>>>=20 >>>> I'm in favor of having a spaces separated list of tokens. >>>> The only case I can think of where the client needs to handle the >>>> scope as anything other than opaque is when it is accessing = multiple >>>> services. To reduce the numebr of login events the client will = have >>>> to poll all the endpoints it wants to access and get all the scopes >>>> advertized by them and submit them all, and once it has them it = needs >>>> to submit all of them in it's auth request, so we need something >>>> that's easy for the client to put together. >>>>=20 >>>>=20 >>>> -bill >>>>=20 >>>>> -----Original Message----- >>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] >>>>> On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) >>>>> Sent: Thursday, June 24, 2010 3:58 AM >>>>> To: ext Lukas Rosenstock; Dick Hardt >>>>> Cc: OAuth WG >>>>> Subject: Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? >>>>>=20 >>>>> The question is whether one would ever want to have a >>>>> standardized semantic for the scope parameter. >>>>> If the answer to that question is "no" then it does not >>>>> matter what the format is. It can well be a list of >>>>> space-delimited strings (as it is currently defined). >>>>>=20 >>>>> An evironment specific semantic works well in cases where >>>>> entity X sets the value and later it receives the value >>>>> again. Only entity X needs to understand what it means. >>>>>=20 >>>>> In some environments the use case is slightly different, >>>>> namely entity X and entity Y are from the same organization >>>>> and agree on the semantic. Usage of OAuth within an >>>>> enterprise might be such a case. >>>>>=20 >>>>> Now, the usage of the scope parameter is, however, a bit >>>>> different in the spec. Section 4, for example, describes how >>>>> a client obtains an access token. How does the client know >>>>> what scope parameters to set and what the semantic is? >>>>>=20 >>>>> Ciao >>>>> Hannes >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: ext Lukas Rosenstock [mailto:lr@lukasrosenstock.net] >>>>>> Sent: Thursday, June 24, 2010 10:49 AM >>>>>> To: Dick Hardt >>>>>> Cc: Tschofenig, Hannes (NSN - FI/Espoo); OAuth WG >>>>>> Subject: Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? >>>>>>=20 >>>>>> Wasn't there some concensus that URIs would be good for >>>> scope? They >>>>>> have "in-built namespacing" ... >>>>>>=20 >>>>>> Lukas >>>>>>=20 >>>>>> 2010/6/23 Dick Hardt <dick.hardt@gmail.com>: >>>>>>>=20 >>>>>>> On 2010-06-22, at 11:07 PM, Tschofenig, Hannes (NSN - >>>>>> FI/Espoo) wrote: >>>>>>>=20 >>>>>>>> " >>>>>>>> scope >>>>>>>> OPTIONAL. The scope of the access request >>>>>> expressed as a list >>>>>>>> of space-delimited strings. The value of the >>>>>> "scope" parameter >>>>>>>> is defined by the authorization server. If the >>>>>> value contains >>>>>>>> multiple space-delimited strings, their order does >>>>>> not matter, >>>>>>>> and each string adds an additional access range to the >>>>>>>> requested scope. >>>>>>>> " >>>>>>>>=20 >>>>>>>> Do folks think it would be useful to have standardized values? >>>>>>>=20 >>>>>>> Not at this time. The semantics of scope are all over the >>>>>> place. If standardized, people will feel they need to pick >>>>> one that is >>>>>> close to what they want, but is not exactly what they mean. >>>>> I think it >>>>>> is better for the AS to define what they mean by a scope >>>>> and give it a >>>>>> name that makes sense in that context. >>>>>>>=20 >>>>>>>>=20 >>>>>>>> If the answer is "yes", then it would be useful to >>>>>> differentiate the >>>>>>>> standardized values from those values that are purely >>>>>> defined locally by >>>>>>>> the authorization server. >>>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Fri Jun 25 11:20:32 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29B6F28C106 for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 11:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.229 X-Spam-Level: X-Spam-Status: No, score=-2.229 tagged_above=-999 required=5 tests=[AWL=0.369, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hv7J9CapdPru for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 11:20:28 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id DAF223A69A5 for <oauth@ietf.org>; Fri, 25 Jun 2010 11:20:28 -0700 (PDT) Received: (qmail 4849 invoked from network); 25 Jun 2010 18:20:37 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 25 Jun 2010 18:20:37 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Fri, 25 Jun 2010 11:20:35 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: Yaron Goland <yarong@microsoft.com> Date: Fri, 25 Jun 2010 11:20:17 -0700 Thread-Topic: How do autonomous clients asks for access tokens? Thread-Index: AcsUhyWs09OFs5wQSWq4/S2IEg6MHwAC8dzw Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EC8499B@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <7C01E631FF4B654FA1E783F1C0265F8C579CA967@TK5EX14MBXC117.redmond.corp.microsoft.com> In-Reply-To: <7C01E631FF4B654FA1E783F1C0265F8C579CA967@TK5EX14MBXC117.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_90C41DD21FB7C64BB94121FBBC2E72343B3EC8499BP3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] How do autonomous clients asks for access tokens? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 25 Jun 2010 18:20:32 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EC8499BP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The access grants do not correlate to the profiles anymore. For example, us= er-agent uses the authorization-code access grant. The section lists how an= autonomous client can use the client credentials or assertion to obtain an= access token. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Y= aron Goland Sent: Friday, June 25, 2010 11:17 AM To: oauth@ietf.org Subject: [OAUTH-WG] How do autonomous clients asks for access tokens? Section 1.4.4 says that autonomous clients can get access tokens. But how? = What grant_type should they use? Thanks, Yaron P.S. I looked for a grant_type of autonomous but I didn't see it in -08. So= rry if I missed it. --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EC8499BP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV=3D"Content-Type" CONTENT= =3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros= oft Word 14 (filtered medium)"><style><!-- /* Font Definitions */ @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} span.EmailStyle17 {mso-style-type:personal; font-family:"Calibri","sans-serif"; color:windowtext;} span.EmailStyle18 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue vli= nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><span style=3D'c= olor:#1F497D'>The access grants do not correlate to the profiles anymore. F= or example, user-agent uses the authorization-code access grant. The sectio= n lists how an autonomous client can use the client credentials or assertio= n to obtain an access token.<o:p></o:p></span></p><p class=3DMsoNormal><spa= n style=3D'color:#1F497D'><o:p> </o:p></span></p><p class=3DMsoNormal>= <span style=3D'color:#1F497D'>EHL<o:p></o:p></span></p><p class=3DMsoNormal= ><span style=3D'color:#1F497D'><o:p> </o:p></span></p><div style=3D'bo= rder:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><div><div= style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in = 0in'><p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;font-family:"T= ahoma","sans-serif"'>From:</span></b><span style=3D'font-size:10.0pt;font-f= amily:"Tahoma","sans-serif"'> oauth-bounces@ietf.org [mailto:oauth-bounces@= ietf.org] <b>On Behalf Of </b>Yaron Goland<br><b>Sent:</b> Friday, June 25,= 2010 11:17 AM<br><b>To:</b> oauth@ietf.org<br><b>Subject:</b> [OAUTH-WG] H= ow do autonomous clients asks for access tokens?<o:p></o:p></span></p></div= ></div><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>Secti= on 1.4.4 says that autonomous clients can get access tokens. But how? What = grant_type should they use?<o:p></o:p></p><p class=3DMsoNormal>  =             &nb= sp; Thanks,<o:p></o:p></p><p class=3DMsoNormal>    &nbs= p;            &= nbsp;           &nbs= p;  Yaron<o:p></o:p></p><p class=3DMsoNormal>P.S. I looked for a grant= _type of autonomous but I didn’t see it in -08. Sorry if I missed it.= <o:p></o:p></p></div></div></body></html>= --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EC8499BP3PW5EX1MB01E_-- From eran@hueniverse.com Fri Jun 25 11:21:41 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3E0E3A6A1E for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 11:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.234 X-Spam-Level: X-Spam-Status: No, score=-2.234 tagged_above=-999 required=5 tests=[AWL=0.365, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 73J4fTrHPjzt for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 11:21:36 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id A26D23A6A35 for <oauth@ietf.org>; Fri, 25 Jun 2010 11:21:36 -0700 (PDT) Received: (qmail 6350 invoked from network); 25 Jun 2010 18:21:45 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 25 Jun 2010 18:21:45 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Fri, 25 Jun 2010 11:21:45 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: Dick Hardt <dick.hardt@gmail.com> Date: Fri, 25 Jun 2010 11:21:27 -0700 Thread-Topic: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? Thread-Index: AcsUktnS2TbvdacLSfm2BVkAeKIJcAAAESgg Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EC8499F@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <3D3C75174CB95F42AD6BCC56E5555B4502BE07CC@FIESEXC015.nsn-intra.net><E7A7F197-3BBC-43F2-8242-D0164057A39A@gmail.com><AANLkTild51WHVcXxYFCygL8sGSGiN3HILDFwIbym6Lfi@mail.gmail.com> <3D3C75174CB95F42AD6BCC56E5555B4502869858@FIESEXC015.nsn-intra.net> <012AB2B223CB3F4BB846962876F47217059B663D@SNV-EXVS08.ds.corp.yahoo.com> <3D3C75174CB95F42AD6BCC56E5555B450286986B@FIESEXC015.nsn-intra.net> <9BBAE9AB-A0CD-448F-B817-21389C1BBCAF@gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3EC84994@P3PW5EX1MB01.EX1.SECURESERVER.NET> <8631D908-6D38-4CE8-BEA4-2C6BE6786251@gmail.com> In-Reply-To: <8631D908-6D38-4CE8-BEA4-2C6BE6786251@gmail.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, "Tschofenig, Hannes \(NSN - FI/Espoo\)" <hannes.tschofenig@nsn.com>, WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 25 Jun 2010 18:21:41 -0000 That's coming in -09. EHL > -----Original Message----- > From: Dick Hardt [mailto:dick.hardt@gmail.com] > Sent: Friday, June 25, 2010 11:19 AM > To: Eran Hammer-Lahav > Cc: Tschofenig, Hannes (NSN - FI/Espoo); OAuth WG > Subject: Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? >=20 > I'm ok with that if we provide some guidance in the spec to implementors > that recommends the use of URIs for scopes they expect to be standardized= . >=20 > On 2010-06-25, at 11:14 AM, Eran Hammer-Lahav wrote: >=20 > > I like the idea of an extensibility mechanism for standard scopes, but = I am > not sure I like the idea of a prefix or reserved characters. Using URIs a= s scope > values was a requirement (and something that is currently deployed by > Google). We defined space-delimited to make simple strings and URIs > possible as values. > > > > My question is, why isn't URIs enough for standard scopes? Define simpl= e > strings as server-specific and allow URIs to be used in standards (which = will > solve potential name collisions). It might make standard scopes a bit les= s cool > but that's not a technical argument. I also think scopes are likely to be > extended a lot more than other extension types and would like to keep the > process as light as possible (i.e. no registration at all). > > > > EHL > > > >> -----Original Message----- > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >> Behalf Of Dick Hardt > >> Sent: Friday, June 25, 2010 8:50 AM > >> To: Tschofenig, Hannes (NSN - FI/Espoo) > >> Cc: OAuth WG > >> Subject: Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? > >> > >> To clarify, the goal is to reserve a namespace for future use so that > >> near term implementations won't collide? > >> > >> I expect the standardization of scope values to not be in OAuth, but > >> in standardized APIs that use OAuth, so a namespace mechanism that > >> differentiates between a standardized scope and an implementation > >> specific scope may be useful. > >> > >> From what I have gathered, implementors are leaning towards simple > >> strings rather than URIs to declare scope. Perhaps reserving the ":" > >> character from being in a scope string unless the scope prefix has > >> been registered with IANA? > >> > >> -- Dick > >> On 2010-06-25, at 12:59 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > >> > >>> Dick pointed me to the Facebook API on how scope is used. > >>> The main page is here: > >>> http://developers.facebook.com/docs/authentication/ > >>> > >>> It describes the basic functionality and also lists an example: > >>> > >>> " > >>> https://graph.facebook.com/oauth/authorize? > >>> client_id=3D...& > >>> redirect_uri=3Dhttp://www.example.com/callback& > >>> scope=3Duser_photos,user_videos,publish_stream > >>> " > >>> > >>> The values of the scope parameter are then explained here: > >>> http://developers.facebook.com/docs/authentication/permissions > >>> > >>> Example: user_photos ... Provides access to the photos the user has > >>> uploaded > >>> > >>> I think it provides a good example that the scope values are not opaq= ue. > >>> Opaque (in this context) means that only the entity creating it > >>> needs to > >> understand it and nobody else. Here the client needs to understand > >> and set them. > >>> > >>> However, one could argue that the scope values are already bound to > >>> the > >> specific entity the client requests to obtain the assertion from. In > >> this specific case it would be "https://graph.facebook.com". > >>> > >>> To respond to the statement Dick made about having standardized > >>> values > >> later there would still be the need to decide about the structure of > >> the values now. One possibility is to just add a prefix for > >> standardized values that are not allowed to be used in other cases, su= ch > as "std:". > >>> > >>> Ciao > >>> Hannes > >>> > >>> > >>>> -----Original Message----- > >>>> From: ext William Mills [mailto:wmills@yahoo-inc.com] > >>>> Sent: Thursday, June 24, 2010 8:15 PM > >>>> To: Tschofenig, Hannes (NSN - FI/Espoo); ext Lukas Rosenstock; Dick > >>>> Hardt > >>>> Cc: OAuth WG > >>>> Subject: RE: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? > >>>> > >>>> I'm in favor of having a spaces separated list of tokens. > >>>> The only case I can think of where the client needs to handle the > >>>> scope as anything other than opaque is when it is accessing > >>>> multiple services. To reduce the numebr of login events the client > >>>> will have to poll all the endpoints it wants to access and get all > >>>> the scopes advertized by them and submit them all, and once it has > >>>> them it needs to submit all of them in it's auth request, so we > >>>> need something that's easy for the client to put together. > >>>> > >>>> > >>>> -bill > >>>> > >>>>> -----Original Message----- > >>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >>>>> Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) > >>>>> Sent: Thursday, June 24, 2010 3:58 AM > >>>>> To: ext Lukas Rosenstock; Dick Hardt > >>>>> Cc: OAuth WG > >>>>> Subject: Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? > >>>>> > >>>>> The question is whether one would ever want to have a standardized > >>>>> semantic for the scope parameter. > >>>>> If the answer to that question is "no" then it does not matter > >>>>> what the format is. It can well be a list of space-delimited > >>>>> strings (as it is currently defined). > >>>>> > >>>>> An evironment specific semantic works well in cases where entity X > >>>>> sets the value and later it receives the value again. Only entity > >>>>> X needs to understand what it means. > >>>>> > >>>>> In some environments the use case is slightly different, namely > >>>>> entity X and entity Y are from the same organization and agree on > >>>>> the semantic. Usage of OAuth within an enterprise might be such a > >>>>> case. > >>>>> > >>>>> Now, the usage of the scope parameter is, however, a bit different > >>>>> in the spec. Section 4, for example, describes how a client > >>>>> obtains an access token. How does the client know what scope > >>>>> parameters to set and what the semantic is? > >>>>> > >>>>> Ciao > >>>>> Hannes > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: ext Lukas Rosenstock [mailto:lr@lukasrosenstock.net] > >>>>>> Sent: Thursday, June 24, 2010 10:49 AM > >>>>>> To: Dick Hardt > >>>>>> Cc: Tschofenig, Hannes (NSN - FI/Espoo); OAuth WG > >>>>>> Subject: Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? > >>>>>> > >>>>>> Wasn't there some concensus that URIs would be good for > >>>> scope? They > >>>>>> have "in-built namespacing" ... > >>>>>> > >>>>>> Lukas > >>>>>> > >>>>>> 2010/6/23 Dick Hardt <dick.hardt@gmail.com>: > >>>>>>> > >>>>>>> On 2010-06-22, at 11:07 PM, Tschofenig, Hannes (NSN - > >>>>>> FI/Espoo) wrote: > >>>>>>> > >>>>>>>> " > >>>>>>>> scope > >>>>>>>> OPTIONAL. The scope of the access request > >>>>>> expressed as a list > >>>>>>>> of space-delimited strings. The value of the > >>>>>> "scope" parameter > >>>>>>>> is defined by the authorization server. If the > >>>>>> value contains > >>>>>>>> multiple space-delimited strings, their order does > >>>>>> not matter, > >>>>>>>> and each string adds an additional access range to the > >>>>>>>> requested scope. > >>>>>>>> " > >>>>>>>> > >>>>>>>> Do folks think it would be useful to have standardized values? > >>>>>>> > >>>>>>> Not at this time. The semantics of scope are all over the > >>>>>> place. If standardized, people will feel they need to pick > >>>>> one that is > >>>>>> close to what they want, but is not exactly what they mean. > >>>>> I think it > >>>>>> is better for the AS to define what they mean by a scope > >>>>> and give it a > >>>>>> name that makes sense in that context. > >>>>>>> > >>>>>>>> > >>>>>>>> If the answer is "yes", then it would be useful to > >>>>>> differentiate the > >>>>>>>> standardized values from those values that are purely > >>>>>> defined locally by > >>>>>>>> the authorization server. > >>>>>> > >>>>> _______________________________________________ > >>>>> OAuth mailing 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 dick.hardt@gmail.com Fri Jun 25 11:22:18 2010 Return-Path: <dick.hardt@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A9993A687D for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 11:22:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkD1RXVNyk91 for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 11:22:09 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 229E028C14D for <oauth@ietf.org>; Fri, 25 Jun 2010 11:22:09 -0700 (PDT) Received: by pwi6 with SMTP id 6so3543892pwi.31 for <oauth@ietf.org>; Fri, 25 Jun 2010 11:22:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=wlGm3V0r8sZHaBDwFUo3KvwKgIyAf2fPtXo6EUwFnKw=; b=NpMAkZ7nKHhku6qatRAhT3rwkHb06TvHCQxEt0JPDs+RwQK/D5z4KF9GInDc0J4uLV 5XJBZFrCj7ZV6kqSmWHlBYLbdKw1mTgATlG0waEK0IRJRd0M+xDGqi5aiLrHbhfJqRIb sqBbIBpqP2PatwYzP4m2eUjaHae2NkibsdSHg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=PDVj/s+SITq/G+VeynMxk6Cpn91QIZQnUwPlDW9SdCyJ2inrL2GoZJbYgslrQVMPt+ KQc3Sn0b48N4OAhlS1QgD1ZxWHOwKYKamuUv+zhxQOmOpYWdYC4WSv39eL9PeSjwFJBD 2zaOaamKLOEXsRIuX/AqMHLCfA/7h+DymGdqE= Received: by 10.115.84.8 with SMTP id m8mr1385332wal.9.1277490135435; Fri, 25 Jun 2010 11:22:15 -0700 (PDT) Received: from [192.168.1.2] (c-24-130-32-55.hsd1.ca.comcast.net [24.130.32.55]) by mx.google.com with ESMTPS id c22sm70210239wam.6.2010.06.25.11.22.14 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 25 Jun 2010 11:22:14 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Dick Hardt <dick.hardt@gmail.com> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EC84999@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Fri, 25 Jun 2010 11:22:13 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <345F0F5E-9401-4B76-98DF-FB7AF53ED0E2@gmail.com> References: <3D3C75174CB95F42AD6BCC56E5555B4502BE07CC@FIESEXC015.nsn-intra.net> <90C41DD21FB7C64BB94121FBBC2E72343B3EC84973@P3PW5EX1MB01.EX1.SECURESERVER.NET> <B6B3E8C3-6B3B-4428-94E4-1D22A93424E6@gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3EC84999@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav <eran@hueniverse.com> X-Mailer: Apple Mail (2.1078) Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <hannes.tschofenig@nsn.com>, OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] Extensibility for OAuth? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 25 Jun 2010 18:22:18 -0000 Agree that if it is a different kind of function, than a new end point = is a good thing. I'm not understanding the review process below in your example. Would = adding language parameters not be an extension? Would that need to be a = change to the spec or a new spec? . On 2010-06-25, at 11:18 AM, Eran Hammer-Lahav wrote: > I think the two endpoints are currently well defined. For example, the = token endpoint always takes an access grant and turns it into an access = token with optional refresh token. To "extend" it to say, register new = clients dynamically, is a bad thing. But adding a new parameter (such as = language) is a good thing to support, and by requiring review, only = parameters that don't change the overall design will be approved. >=20 > EHL >=20 >> -----Original Message----- >> From: Dick Hardt [mailto:dick.hardt@gmail.com] >> Sent: Friday, June 25, 2010 11:13 AM >> To: Eran Hammer-Lahav >> Cc: Tschofenig, Hannes (NSN - FI/Espoo); OAuth WG >> Subject: Re: [OAUTH-WG] Extensibility for OAuth? >>=20 >> Would you elaborate on your reasons here? Do you think we have >> enumerated all the possibilities? >>=20 >> On 2010-06-25, at 10:59 AM, Eran Hammer-Lahav wrote: >>=20 >>> I would rather limit the ability to extend the two endpoints beyond = their >> current architecture, and instead, allow others to specify new = endpoints (e.g. >> a device endpoint for getting an authorization code without using = browser >> redirection) that work in addition to the token endpoint (using an = existing >> grant type or assertion). >=20 From yarong@microsoft.com Fri Jun 25 11:26:13 2010 Return-Path: <yarong@microsoft.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0028D3A6928 for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 11:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.623 X-Spam-Level: X-Spam-Status: No, score=-9.623 tagged_above=-999 required=5 tests=[AWL=0.975, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7uvwkQOb0gW for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 11:26:10 -0700 (PDT) Received: from smtp.microsoft.com (maila.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id E3BFA3A6993 for <oauth@ietf.org>; Fri, 25 Jun 2010 11:26:09 -0700 (PDT) Received: from TK5EX14CASC131.redmond.corp.microsoft.com (157.54.52.38) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 25 Jun 2010 11:26:13 -0700 Received: from TK5EX14MBXC117.redmond.corp.microsoft.com ([169.254.8.23]) by TK5EX14CASC131.redmond.corp.microsoft.com ([157.54.52.38]) with mapi id 14.01.0160.007; Fri, 25 Jun 2010 11:26:14 -0700 From: Yaron Goland <yarong@microsoft.com> To: "oauth@ietf.org" <oauth@ietf.org> Thread-Topic: Clients authenticating with assertions Thread-Index: AcsUhz2iYfrAgGl/Q7+u4YeRqbxaDg== Date: Fri, 25 Jun 2010 18:26:10 +0000 Message-ID: <7C01E631FF4B654FA1E783F1C0265F8C579CA9D1@TK5EX14MBXC117.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7C01E631FF4B654FA1E783F1C0265F8C579CA9D1TK5EX14MBXC117r_" MIME-Version: 1.0 Subject: [OAUTH-WG] Clients authenticating with assertions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 25 Jun 2010 18:26:13 -0000 --_000_7C01E631FF4B654FA1E783F1C0265F8C579CA9D1TK5EX14MBXC117r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If a client wants to authenticate itself to a token endpoint to get an acce= ss token using an assertion how should it do it? Grant_Type =3D assertion doesn't seem right because that assertion should b= e from the resource owner who delegated the permission, not from the client= , right? In other words one can end up with an access token request with tw= o assertions, one from the client and one from the resource owner. How is t= his done? Thanks, Yaron P.S. I looked for something like client_assertion and client_assertion_type= in section 2 of -08 but didn't see it. Sorry if I missed it. --_000_7C01E631FF4B654FA1E783F1C0265F8C579CA9D1TK5EX14MBXC117r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"> <style><!-- /* Font Definitions */ @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} span.EmailStyle17 {mso-style-type:personal-compose; font-family:"Calibri","sans-serif"; color:windowtext;} .MsoChpDefault {mso-style-type:export-only; font-family:"Calibri","sans-serif";} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> <p class=3D"MsoNormal">If a client wants to authenticate itself to a token = endpoint to get an access token using an assertion how should it do it? <o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">Grant_Type =3D assertion doesn’t seem right be= cause that assertion should be from the resource owner who delegated the pe= rmission, not from the client, right? In other words one can end up with an= access token request with two assertions, one from the client and one from the resource owner. How is this done?<o:p= ></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">        &nbs= p;       Thanks,<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">        &nbs= p;            &= nbsp;          Yaron<o:p></o:p= ></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">P.S. I looked for something like client_assertion an= d client_assertion_type in section 2 of -08 but didn’t see it. Sorry = if I missed it.<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> </body> </html> --_000_7C01E631FF4B654FA1E783F1C0265F8C579CA9D1TK5EX14MBXC117r_-- From eran@hueniverse.com Fri Jun 25 11:31:52 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E963728C112 for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 11:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.237 X-Spam-Level: X-Spam-Status: No, score=-2.237 tagged_above=-999 required=5 tests=[AWL=0.361, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DmcfrirYxnHq for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 11:31:45 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 522163A6A2F for <oauth@ietf.org>; Fri, 25 Jun 2010 11:31:33 -0700 (PDT) Received: (qmail 21735 invoked from network); 25 Jun 2010 18:31:42 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 25 Jun 2010 18:31:42 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 25 Jun 2010 11:31:42 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: Yaron Goland <yarong@microsoft.com>, "oauth@ietf.org" <oauth@ietf.org> Date: Fri, 25 Jun 2010 11:31:24 -0700 Thread-Topic: Clients authenticating with assertions Thread-Index: AcsUhz2iYfrAgGl/Q7+u4YeRqbxaDgADS/YA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EC849A8@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <7C01E631FF4B654FA1E783F1C0265F8C579CA9D1@TK5EX14MBXC117.redmond.corp.microsoft.com> In-Reply-To: <7C01E631FF4B654FA1E783F1C0265F8C579CA9D1@TK5EX14MBXC117.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_90C41DD21FB7C64BB94121FBBC2E72343B3EC849A8P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Clients authenticating with assertions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 25 Jun 2010 18:31:52 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EC849A8P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We never had support for two assertions in one request. The client authenticates itself and can include an assertion (or use type '= none'). The client credentials are the "client assertion" and the assertion= is about the resource owner. Also, you can define an assertion type that's a composite assertion (of one= more more). EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Y= aron Goland Sent: Friday, June 25, 2010 11:26 AM To: oauth@ietf.org Subject: [OAUTH-WG] Clients authenticating with assertions If a client wants to authenticate itself to a token endpoint to get an acce= ss token using an assertion how should it do it? Grant_Type =3D assertion doesn't seem right because that assertion should b= e from the resource owner who delegated the permission, not from the client= , right? In other words one can end up with an access token request with tw= o assertions, one from the client and one from the resource owner. How is t= his done? Thanks, Yaron P.S. I looked for something like client_assertion and client_assertion_type= in section 2 of -08 but didn't see it. Sorry if I missed it. --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EC849A8P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV=3D"Content-Type" CONTENT= =3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros= oft Word 14 (filtered medium)"><style><!-- /* Font Definitions */ @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} span.EmailStyle17 {mso-style-type:personal; font-family:"Calibri","sans-serif"; color:windowtext;} span.EmailStyle18 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue vli= nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><span style=3D'c= olor:#1F497D'>We never had support for two assertions in one request.<o:p><= /o:p></span></p><p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nb= sp;</o:p></span></p><p class=3DMsoNormal><span style=3D'color:#1F497D'>The = client authenticates itself and can include an assertion (or use type ̵= 6;none’). The client credentials are the “client assertion̶= 1; and the assertion is about the resource owner.<o:p></o:p></span></p><p c= lass=3DMsoNormal><span style=3D'color:#1F497D'><o:p> </o:p></span></p>= <p class=3DMsoNormal><span style=3D'color:#1F497D'>Also, you can define an = assertion type that’s a composite assertion (of one more more).<o:p><= /o:p></span></p><p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nb= sp;</o:p></span></p><p class=3DMsoNormal><span style=3D'color:#1F497D'>EHL<= o:p></o:p></span></p><p class=3DMsoNormal><span style=3D'color:#1F497D'><o:= p> </o:p></span></p><div style=3D'border:none;border-left:solid blue 1= .5pt;padding:0in 0in 0in 4.0pt'><div><div style=3D'border:none;border-top:s= olid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=3DMsoNormal><b><span= style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span><= /b><span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> oaut= h-bounces@ietf.org [mailto:oauth-bounces@ietf.org] <b>On Behalf Of </b>Yaro= n Goland<br><b>Sent:</b> Friday, June 25, 2010 11:26 AM<br><b>To:</b> oauth= @ietf.org<br><b>Subject:</b> [OAUTH-WG] Clients authenticating with asserti= ons<o:p></o:p></span></p></div></div><p class=3DMsoNormal><o:p> </o:p>= </p><p class=3DMsoNormal>If a client wants to authenticate itself to a toke= n endpoint to get an access token using an assertion how should it do it? <= o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNorma= l>Grant_Type =3D assertion doesn’t seem right because that assertion = should be from the resource owner who delegated the permission, not from th= e client, right? In other words one can end up with an access token request= with two assertions, one from the client and one from the resource owner. = How is this done?<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><= p class=3DMsoNormal>         &= nbsp;      Thanks,<o:p></o:p></p><p class=3DMsoNor= mal><o:p> </o:p></p><p class=3DMsoNormal>     = ;            &n= bsp;            = ;  Yaron<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p cl= ass=3DMsoNormal>P.S. I looked for something like client_assertion and clien= t_assertion_type in section 2 of -08 but didn’t see it. Sorry if I mi= ssed it.<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p></div></di= v></body></html>= --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EC849A8P3PW5EX1MB01E_-- From yarong@microsoft.com Fri Jun 25 11:34:17 2010 Return-Path: <yarong@microsoft.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A3EF3A6A21 for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 11:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.519 X-Spam-Level: X-Spam-Status: No, score=-8.519 tagged_above=-999 required=5 tests=[AWL=-0.520, BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WebNsNqE7TDs for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 11:34:14 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 7D80228C15F for <oauth@ietf.org>; Fri, 25 Jun 2010 11:33:48 -0700 (PDT) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 25 Jun 2010 11:33:58 -0700 Received: from TK5EX14MBXC117.redmond.corp.microsoft.com ([169.254.8.23]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.01.0160.007; Fri, 25 Jun 2010 11:33:58 -0700 From: Yaron Goland <yarong@microsoft.com> To: Thomas Hardjono <hardjono@MIT.EDU>, "OAuth WG (oauth@ietf.org)" <oauth@ietf.org> Thread-Topic: OAuth discovery draft? Thread-Index: AQHLEbd88ANnc80E8EanM4mdFaHtZpKN3qcAgAH2zrCAAAvTUIADI6jQ Date: Fri, 25 Jun 2010 18:33:55 +0000 Message-ID: <7C01E631FF4B654FA1E783F1C0265F8C579CAA20@TK5EX14MBXC117.redmond.corp.microsoft.com> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB68D9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1126427308C@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343B3EC83F46@P3PW5EX1MB01.EX1.SECURESERVER.NET> <7C01E631FF4B654FA1E783F1C0265F8C579C6DC3@TK5EX14MBXC117.redmond.corp.microsoft.com> <DADD7EAD88AB484D8CCC328D40214CCD017A07BE35@EXPO10.exchange.mit.edu> In-Reply-To: <DADD7EAD88AB484D8CCC328D40214CCD017A07BE35@EXPO10.exchange.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [OAUTH-WG] OAuth discovery draft? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 25 Jun 2010 18:34:17 -0000 UmV2b2NhdGlvbiAtIE15IGFzc3VtcHRpb24gaXMgdGhhdCBZb2NoaSB3b3VsZCB0ZWxsIFlhaG9v IENhbGVuZGFyIHRvIHB1bGwgTGVvbidzIHBlcm1pc3Npb24uIFRoaXMgd291bGQgaGFwcGVuIG91 dCBvZiBiYW5kLiBXaGVuIExpdmUgQ2FsZW5kYXIgKExlb24ncyBzZXJ2aWNlIHByb3ZpZGVyKSB0 cmllcyB0byB1c2UgaXRzIHJlZnJlc2ggdG9rZW4gdG8gZ2V0IGFuIGFjY2VzcyB0b2tlbiBmcm9t IFlhaG9vJ3MgdG9rZW4gZW5kcG9pbnQgdGhlIHJlcXVlc3Qgd2lsbCBmYWlsIGJlY2F1c2UgdGhl IHBlcm1pc3Npb24gaXMgZ29uZS4gSSBoYXZlIHRob3VnaHQgYWJvdXQgaGF2aW5nIGEgJ25lZ2F0 aXZlJyBwZXJtaXNzaW9uIGZsb3cgKGUuZy4gYSBub3RpZmljYXRpb24gdGhhdCBhIHBlcm1pc3Np b24gaXMgbm8gbG9uZ2VyIHByb3ZpZGVkKSBidXQgdGhlcmUgYXJlIHNvY2lhbCBpc3N1ZXMgd2l0 aCB0aGlzIHRoYXQgbWFrZSBtZSB3b25kZXIgaWYgaXQncyB2aWFibGUuIFRoaW5rIG9mIHVuZnJp ZW5kaW5nIHBlb3BsZSBpbiBGYWNlYm9vay4gWW91IGRvbid0IGdldCBhIG5vdGlmaWNhdGlvbiB0 aGF0IHNvbWVvbmUgaGFzIHVuZnJpZW5kZWQgeW91IGZvciBqdXN0IHRoYXQgcmVhc29uLg0KDQpS ZS1EZWxlZ2F0aW9uIC0gVGhpcyBpcyBvbmUgb2YgdGhvc2UgZmVhdHVyZXMgdGhhdCBtYWtlcyBz ZW5zZSBpbiB0aGVvcnkgYnV0IEknbSBub3QgY29udmluY2VkIG5vcm1hbCBodW1hbnMgKGFuZCB0 aGF0IGluY2x1ZGVzIGRldmVsb3BlcnMpIGNhbiBncm9rLiBJIHRoaW5rIHdlIHNob3VsZCBzdGFy dCB3aXRoIDE6MSBwZXJtaXNzaW9ucyBmb3Igbm93LiBJbiBvdGhlciB3b3JkcyBmb3IgdGhlIHNj ZW5hcmlvIHlvdSBnYXZlIGJlbG93IFlvY2hpIHdvdWxkIGhhdmUgdG8gZGlyZWN0bHkgZ3JhbnQg cGVybWlzc2lvbiB0byB0aGUgM3JkIHBhcnR5IHNlcnZpY2UgdG8gYm90aCB0aGUgWWFob28gQ2Fs ZW5kYXIgYW5kIEZhY2Vib29rIGFjY291bnRzLg0KDQpCdXQgdGhhdCdzIHJlYWxseSBqdXN0IG15 IG9waW5pb24sDQoNCgkJVGhhbmtzLA0KDQoJCQlZYXJvbg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+IEZyb206IFRob21hcyBIYXJkam9ubyBbbWFpbHRvOmhhcmRqb25vQE1JVC5F RFVdDQo+IFNlbnQ6IFdlZG5lc2RheSwgSnVuZSAyMywgMjAxMCAxMTo0MCBBTQ0KPiBUbzogWWFy b24gR29sYW5kOyBPQXV0aCBXRyAob2F1dGhAaWV0Zi5vcmcpDQo+IFN1YmplY3Q6IFJFOiBPQXV0 aCBkaXNjb3ZlcnkgZHJhZnQ/DQo+IA0KPiANCj4gSGkgWWFyb24sDQo+IA0KPiBJIHRoaW5rIGRl bGVnYXRpb24gaXMgYSBncmVhdCBpZGVhL2ZlYXR1cmUgdGhhdCBzaG91bGQgYmUgYWRkZWQgb3Ig T0F1dGggKGFzIEkNCj4gc3VnZ2VzdGVkIGluIHRoZSBrZXJiZXJvcy1vYXV0aCBkcmFmdCkuIElu IHRoZSBLZXJiZXJvcyB3b3JsZCwgaXQgaGFzIGJlZW4gYQ0KPiB2ZXJ5IGltcG9ydGFudCBmZWF0 dXJlIChhIGxpZmUgc2F2ZXIpLg0KPiANCj4gSW4geW91ciBleGFtcGxlLCB3aGVuIFlvY2hpIHdh bnRzIHRvIHRlcm1pbmF0ZSB0aGUgZGVsZWdhdGlvbiBzaGUgZ2F2ZSB0bw0KPiBMZW9uLCBob3cg ZG9lcyBZb2NoaSBkbyB0aGlzPw0KPiANCj4gQWxzbywgd291bGQgaXQgYmUgcG9zc2libGUgZm9y IFlvY2hpIHRvIGRlbGVnYXRlIHRvIGFub3RoZXIgc3lzdGVtIChub3QgYQ0KPiBodW1hbiB1c2Vy KSB0byBkbyB0aGluZ3MgZm9yIGhlci4gRm9yIGV4YW1wbGUsIGdpdmUgZGVsZWdhdGlvbiB0byBh IDNyZCBwYXJ0eQ0KPiBzZXJ2aWNlL3N5c3RlbSB0byAoYSkgcmVndWxhcmx5IGZldGNoIFlvY2hp J3MgU2F0dXJkYXkvU3VuZGF5IHNjaGVkdWxlIGZyb20NCj4gWWFob28gQ2FsZW5kYXIsIGFuZCB0 aGVuIChiKSBwdWJsaXNoIGl0IHRvIEZhY2VCb29rIHNheS4NCj4gDQo+IC90aG9tYXMvDQo+IA0K PiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IG9hdXRoLWJvdW5j ZXNAaWV0Zi5vcmcgW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4g PiBPZiBZYXJvbiBHb2xhbmQNCj4gPiBTZW50OiBXZWRuZXNkYXksIEp1bmUgMjMsIDIwMTAgMjow MCBQTQ0KPiA+IFRvOiBFcmFuIEhhbW1lci1MYWhhdjsgTWFuZ2VyLCBKYW1lcyBIOyBPQXV0aCBX RyAob2F1dGhAaWV0Zi5vcmcpDQo+ID4gU3ViamVjdDogUmU6IFtPQVVUSC1XR10gT0F1dGggZGlz Y292ZXJ5IGRyYWZ0Pw0KPiA+DQo+ID4gSSd2ZSBiZWVuIG5vb2RsaW5nIFsxXSBhIGxvdCBhYm91 dCBmdWxsIGRlbGVnYXRpb24gaW4gT0F1dGggWzJdIGFuZCBvbmUNCj4gPiBvZiB0aGUgaXNzdWVz IHRoYXQgY2FtZSBvdXQgb2YgdGhhdCB3YXMgdGhlIG5lZWQgZm9yIGRpc2NvdmVyaW5nIGJvdGgN Cj4gPiB0aGUgbG9jYXRpb24gYW5kIHJlYWxtIG9mIGFuIGVuZHBvaW50J3MgdG9rZW4gc2VydmVy LiBCdXQgYXQgbGVhc3QgZm9yDQo+ID4gbXkgdXNlIGNhc2VzICh3aGljaCBjb25zaXN0IG9mIHdh bGtpbmcgdXAgdG8gYSBzZXJ2aWNlIGFuZCBtYWtpbmcgYW4NCj4gPiBvcHRpb25zIHJlcXVlc3Qg YW5kIGdldHRpbmcgYmFjayBhIHd3dy1hdXRoZW50aWNhdGUgaGVhZGVyKSBhbGwgSSBuZWVkDQo+ ID4gYmFjayBpcyBhIHJlYWxtIGFuZCBhIHRva2VuIHNlcnZlciBVUkwuIEluIG90aGVyIHdvcmRz IGp1c3QgaGF2aW5nIG9uZQ0KPiA+IGFyZ3VtZW50IGFkZGVkIHRvIG91ciB3d3ctYXV0aGVudGlj YXRlIGhlYWRlciB3b3VsZCBiZSBlbm91Z2ggdG8NCj4gc29sdmUNCj4gPiB0aGUgY2FzZSB3aGVy ZSBzb21lb25lIHdhbnRzIHRvIHdhbGsgdXAgdG8gYSBzZXJ2aWNlIGFuZCBmaW5kIG91dCB3aGVy ZQ0KPiA+IGl0cyB0b2tlbiBzZXJ2ZXIgaXMuIERvZXMgdGhhdCByZWFsbHkgbmVlZCBpdHMgb3du IHNwZWM/IE9yIGNhbiB3ZSBqdXN0DQo+ID4gYWRkIGFuIGFyZ3VtZW50IHRvIHd3dy1hdXRoZW50 aWNhdGUgaW4gdGhlIGN1cnJlbnQgc3BlYz8NCj4gPiAJVGhhbmtzLA0KPiA+IAkJWWFyb24NCj4g Pg0KPiA+IFsxXSBTZWUgaHR0cDovL3d3dy5nb2xhbmQub3JnL29hdXRoZ2VuZXJpY2RlbGVnYXRp b24vIGZvciBhbiBvdmVydmlldw0KPiA+IG9mIG15IHRoaW5raW5nIG9uIGZ1bGwgZGVsZWdhdGlv biBpbiBPQXV0aC4gQXQgdGhlIHZlcnkgZW5kIGFyZSBsaW5rcw0KPiA+IHRvIGEgYnVuY2ggb2Yg b3RoZXIgbXVjaCBtb3JlIGluLWRlcHRoIGFydGljbGVzIG9uIHBhcnRpY3VsYXIgc3ViamVjdHMN Cj4gPiB0b3VjaGVkIG9uIGluIHRoZSBtYWluIGFydGljbGUuDQo+ID4NCj4gPiBbMl0gSSBkZWZp bmUgJ2Z1bGwgZGVsZWdhdGlvbicgYXMgIlVzZXIgWCBvZiBTZXJ2aWNlIFkgZ3JhbnRzDQo+ID4g cGVybWlzc2lvbiBaIHRvIFVzZXIgQSBvZiBTZXJ2aWNlIEIiLiBDdXJyZW50bHkgT0F1dGggcmVx dWlyZXMgWCA9PSBBLg0KPiA+IEluIHRoZSBmdXR1cmUgSSBob3BlIHRvIHNlZSBleHRlbnNpb25z IHRvIE9BdXRoIHRoYXQgZW5hYmxlIHdoYXQgSSdtDQo+ID4gdGVybWluZyAnZnVsbCBkZWxlZ2F0 aW9uJy4gQnV0IHBlcnNvbmFsbHkgSSdtIHJlYWxseSBoYXBweSB0aGF0IE9BdXRoDQo+ID4gaGFz IHRoZSBYPT1BIHJlc3RyaWN0aW9uLiBJdCBzaW1wbGlmaWVzIGEgd2hvbGUgaG9zdCBvZiBpc3N1 ZXMgYW5kDQo+ID4gc2F0aXNmaWVzIGEgcmVhbGx5IGltcG9ydGFudCB1c2UgY2FzZS4NCj4gPg0K PiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+IEZyb206IG9hdXRoLWJvdW5j ZXNAaWV0Zi5vcmcgW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbg0KPiA+IEJlaGFs Zg0KPiA+ID4gT2YgRXJhbiBIYW1tZXItTGFoYXYNCj4gPiA+IFNlbnQ6IE1vbmRheSwgSnVuZSAy MSwgMjAxMCA5OjUwIFBNDQo+ID4gPiBUbzogTWFuZ2VyLCBKYW1lcyBIOyBPQXV0aCBXRyAob2F1 dGhAaWV0Zi5vcmcpDQo+ID4gPiBTdWJqZWN0OiBSZTogW09BVVRILVdHXSBPQXV0aCBkaXNjb3Zl cnkgZHJhZnQ/DQo+ID4gPg0KPiA+ID4gWWVzLCBpdCdzIG9uIG15IGRlc2sgYW5kIG5vdCB5ZXQg cmVhZHksIGJ1dCBJIGFtIHdvcmtpbmcgb24gb25lLiBJdA0KPiA+ID4gaW5jbHVkZXMgeW91ciBz aXRlcyBwcm9wb3NhbCBhbW9uZyBvdGhlciB0aGluZ3MuIEkgYW0gdHJ5aW5nIHRvIGdldA0KPiA+ ID4gdGhlIGNvcmUgc3BlYyBzdGFibGUgdGhpcyB3ZWVrIGFuZCBmb2N1cyBvbiB0aGF0IG5leHQu DQo+ID4gPg0KPiA+ID4gRUhMDQo+ID4gPg0KPiA+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiA+ID4gPiBGcm9tOiBNYW5nZXIsIEphbWVzIEggW21haWx0bzpKYW1lcy5ILk1hbmdl ckB0ZWFtLnRlbHN0cmEuY29tXQ0KPiA+ID4gPiBTZW50OiBNb25kYXksIEp1bmUgMjEsIDIwMTAg ODowMyBQTQ0KPiA+ID4gPiBUbzogRXJhbiBIYW1tZXItTGFoYXY7IE9BdXRoIFdHIChvYXV0aEBp ZXRmLm9yZykNCj4gPiA+ID4gU3ViamVjdDogT0F1dGggZGlzY292ZXJ5IGRyYWZ0Pw0KPiA+ID4g Pg0KPiA+ID4gPiBFcmFuLA0KPiA+ID4gPg0KPiA+ID4gPiBUaGVyZSBoYXZlIGJlZW4gYSBmZXcg bWVudGlvbnMgcmVjZW50bHkgb2YgYW4gT0F1dGggZGlzY292ZXJ5DQo+ID4gZHJhZnQuDQo+ID4g PiA+IElzIHRoZXJlIGFueSBzdWNoIGRyYWZ0IHlldCwgb3IgaXMgdGhpcyBqdXN0IGEgcGFydCB0 aGF0IHdlIGtub3cNCj4gPiA+ID4gbmVlZHMgdG8gYmUgZG9uZT8NCj4gPiA+ID4NCj4gPiA+ID4g VGhlIGVtYWlsIG9uICJPQXV0aCBtZWV0aW5nIG5vdGVzIG9uIC0wNSAod2l0aCB1cGRhdGVzKSIg c2FpZDoNCj4gPiA+ID4NCj4gPiA+ID4gPj4gNi4xLjEuIC0gZGVzY3JpYmluZyB0aGUgV1dXLUF1 dGhlbnRpY2F0ZSByZXNwb25zZSBoZWFkZXINCj4gPiA+ID4gPj4NCj4gPiA+ID4gPj4gLSBEaXNj b3ZlcnkgbmVlZGVkIGZvciB2YXJpb3VzIGVsZW1lbnRzDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBZ ZXMuIFRoYXQncyBmb3IgdGhlIGRpc2NvdmVyeSBkcmFmdC4NCj4gPiA+ID4NCj4gPiA+ID4NCj4g PiA+ID4gQSB3aWtpIHBhZ2Ugb24gIkZ1dHVyZSBPcGVuSUQgVGVjaG5pY2FsIFJlcXVpcmVtZW50 cyINCj4gPiA+ID4gPGh0dHA6Ly93aWtpLm9wZW5pZC5uZXQvRnV0dXJlLU9wZW5JRC1UZWNobmlj YWwtUmVxdWlyZW1lbnRzPg0KPiBzYXlzOg0KPiA+ID4gPg0KPiA+ID4gPiA+IDYpIElkUCBEaXNj b3ZlcnkNCj4gPiA+ID4gPg0KPiA+ID4gPiA+ICAgICogTXVjaCBvZiB0aGlzIHdpbGwgYmUgY292 ZXJlZCBieSBPQXV0aDIgRGlzY292ZXJ5LA0KPiA+ID4gPiA+ICAgICAgaG93ZXZlciBPSUMgbWF5 IG5lZWQgdG8gZGVmaW5lIE9wZW5JRCBzcGVjaWZpYyBmZWF0dXJlcy4NCj4gPiA+ID4gPuKApg0K PiA+ID4gPiA+IDE3KSBTaW1wbGVyIGRpc2NvdmVyeQ0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gICAg KiBTZWUgRXJhbidzIE9BdXRoIERpc2NvdmVyeSBwcm9wb3NhbA0KPiA+ID4gPg0KPiA+ID4gPg0K PiA+ID4gPiBUaGVyZSB3YXMgYW4gT0F1dGggMS4wIERpc2NvdmVyeSBkcmFmdCBvdmVyIDIgeWVh cnMgYWdvLCBidXQgdGhhdA0KPiA+IGlzIHRhZ2dlZDoNCj4gPiA+ID4gImV4cGlyZWQiLCAibWFy a2VkIGFzIG9ic29sZXRlIGJ5IGl0cyBhdXRob3IiLCAiZGlzY291cmFnZWQgZnJvbQ0KPiA+ID4g PiBpbXBsZW1lbnRpbmciLCAibm8gdXBkYXRlIGlzIGV4cGVjdGVkIiwgInJlcGxhY2VkIGJ5IHRo ZSBPQXV0aCAyLjANCj4gPiA+IGVmZm9ydCIuDQo+ID4gPiA+DQo+ID4gPiA+IEkga25vdyBJIHNo b3VsZCB3cml0ZSBhIGRpc2NvdmVyeSBkcmFmdCBteXNlbGYuDQo+ID4gPiA+DQo+ID4gPiA+IC0t DQo+ID4gPiA+IEphbWVzIE1hbmdlcg0KPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gPiA+IE9BdXRoIG1haWxpbmcgbGlzdA0KPiA+ID4gT0F1 dGhAaWV0Zi5vcmcNCj4gPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v b2F1dGgNCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiA+IE9BdXRoIG1haWxpbmcgbGlzdA0KPiA+IE9BdXRoQGlldGYub3JnDQo+ID4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0K From eran@hueniverse.com Fri Jun 25 11:35:49 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 611AB28C15B for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 11:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.242 X-Spam-Level: X-Spam-Status: No, score=-2.242 tagged_above=-999 required=5 tests=[AWL=0.357, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KCFp5kb28QrO for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 11:35:17 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 6EAD828C0EE for <oauth@ietf.org>; Fri, 25 Jun 2010 11:34:46 -0700 (PDT) Received: (qmail 3009 invoked from network); 25 Jun 2010 18:34:55 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 25 Jun 2010 18:34:55 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Fri, 25 Jun 2010 11:34:55 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: Dick Hardt <dick.hardt@gmail.com> Date: Fri, 25 Jun 2010 11:34:37 -0700 Thread-Topic: [OAUTH-WG] Extensibility for OAuth? Thread-Index: AcsUk1dNoQKeI1kORCCNowtk/cXMuQAAVH/g Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EC849AA@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <3D3C75174CB95F42AD6BCC56E5555B4502BE07CC@FIESEXC015.nsn-intra.net> <90C41DD21FB7C64BB94121FBBC2E72343B3EC84973@P3PW5EX1MB01.EX1.SECURESERVER.NET> <B6B3E8C3-6B3B-4428-94E4-1D22A93424E6@gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3EC84999@P3PW5EX1MB01.EX1.SECURESERVER.NET> <345F0F5E-9401-4B76-98DF-FB7AF53ED0E2@gmail.com> In-Reply-To: <345F0F5E-9401-4B76-98DF-FB7AF53ED0E2@gmail.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, "Tschofenig, Hannes \(NSN - FI/Espoo\)" <hannes.tschofenig@nsn.com>, WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] Extensibility for OAuth? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 25 Jun 2010 18:35:49 -0000 The language parameter will need a new spec (doesn't have to be an RFC, but= that's open to debate), and will register the parameter in the IANA regist= ry for that endpoint. In order to register, the request will be posted to a= public list and a designated expert(s) will review it in a timely manner. = If there is consensus, the request will be approved. By seeking consensus f= or the registration, the community will get to decide if the proposal does = not change the meaning of the endpoint. So: 1. write a new spec 2. request new parameter registration 3. discuss the use case and proposal on a public list (special for this) 4. get designated expert review 5. get IANA to register The whole thing can be as fast as 2-3 weeks. EHL > -----Original Message----- > From: Dick Hardt [mailto:dick.hardt@gmail.com] > Sent: Friday, June 25, 2010 11:22 AM > To: Eran Hammer-Lahav > Cc: Tschofenig, Hannes (NSN - FI/Espoo); OAuth WG > Subject: Re: [OAUTH-WG] Extensibility for OAuth? >=20 > Agree that if it is a different kind of function, than a new end point is= a good > thing. >=20 > I'm not understanding the review process below in your example. Would > adding language parameters not be an extension? Would that need to be a > change to the spec or a new spec? > . > On 2010-06-25, at 11:18 AM, Eran Hammer-Lahav wrote: >=20 > > I think the two endpoints are currently well defined. For example, the > token endpoint always takes an access grant and turns it into an access t= oken > with optional refresh token. To "extend" it to say, register new clients > dynamically, is a bad thing. But adding a new parameter (such as language= ) is > a good thing to support, and by requiring review, only parameters that do= n't > change the overall design will be approved. > > > > EHL > > > >> -----Original Message----- > >> From: Dick Hardt [mailto:dick.hardt@gmail.com] > >> Sent: Friday, June 25, 2010 11:13 AM > >> To: Eran Hammer-Lahav > >> Cc: Tschofenig, Hannes (NSN - FI/Espoo); OAuth WG > >> Subject: Re: [OAUTH-WG] Extensibility for OAuth? > >> > >> Would you elaborate on your reasons here? Do you think we have > >> enumerated all the possibilities? > >> > >> On 2010-06-25, at 10:59 AM, Eran Hammer-Lahav wrote: > >> > >>> I would rather limit the ability to extend the two endpoints beyond > >>> their > >> current architecture, and instead, allow others to specify new endpoin= ts > (e.g. > >> a device endpoint for getting an authorization code without using > >> browser > >> redirection) that work in addition to the token endpoint (using an > >> existing grant type or assertion). > > From yarong@microsoft.com Fri Jun 25 11:36:36 2010 Return-Path: <yarong@microsoft.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 997E13A68B2 for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 11:36:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.732 X-Spam-Level: X-Spam-Status: No, score=-9.732 tagged_above=-999 required=5 tests=[AWL=0.866, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XXTRUgRgYnv1 for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 11:36:19 -0700 (PDT) Received: from smtp.microsoft.com (mail1.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id F176B3A6800 for <oauth@ietf.org>; Fri, 25 Jun 2010 11:36:01 -0700 (PDT) Received: from TK5EX14CASC130.redmond.corp.microsoft.com (157.54.52.9) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 25 Jun 2010 11:36:11 -0700 Received: from TK5EX14MBXC117.redmond.corp.microsoft.com ([169.254.8.23]) by TK5EX14CASC130.redmond.corp.microsoft.com ([157.54.52.9]) with mapi id 14.01.0160.006; Fri, 25 Jun 2010 11:36:11 -0700 From: Yaron Goland <yarong@microsoft.com> To: Eran Hammer-Lahav <eran@hueniverse.com> Thread-Topic: How do autonomous clients asks for access tokens? Thread-Index: AcsUhyWs09OFs5wQSWq4/S2IEg6MHwAC8dzwAACPtlA= Date: Fri, 25 Jun 2010 18:36:09 +0000 Message-ID: <7C01E631FF4B654FA1E783F1C0265F8C579CAA4B@TK5EX14MBXC117.redmond.corp.microsoft.com> References: <7C01E631FF4B654FA1E783F1C0265F8C579CA967@TK5EX14MBXC117.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343B3EC8499B@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EC8499B@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7C01E631FF4B654FA1E783F1C0265F8C579CAA4BTK5EX14MBXC117r_" MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] How do autonomous clients asks for access tokens? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 25 Jun 2010 18:36:36 -0000 --_000_7C01E631FF4B654FA1E783F1C0265F8C579CAA4BTK5EX14MBXC117r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sorry. I screwed up. I somehow missed "none" as an option. From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Friday, June 25, 2010 11:20 AM To: Yaron Goland Cc: OAuth WG (oauth@ietf.org) Subject: RE: How do autonomous clients asks for access tokens? The access grants do not correlate to the profiles anymore. For example, us= er-agent uses the authorization-code access grant. The section lists how an= autonomous client can use the client credentials or assertion to obtain an= access token. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Y= aron Goland Sent: Friday, June 25, 2010 11:17 AM To: oauth@ietf.org Subject: [OAUTH-WG] How do autonomous clients asks for access tokens? Section 1.4.4 says that autonomous clients can get access tokens. But how? = What grant_type should they use? Thanks, Yaron P.S. I looked for a grant_type of autonomous but I didn't see it in -08. So= rry if I missed it. --_000_7C01E631FF4B654FA1E783F1C0265F8C579CAA4BTK5EX14MBXC117r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"> <style><!-- /* Font Definitions */ @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} p.MsoAcetate, li.MsoAcetate, div.MsoAcetate {mso-style-priority:99; mso-style-link:"Balloon Text Char"; margin:0in; margin-bottom:.0001pt; font-size:8.0pt; font-family:"Tahoma","sans-serif";} span.EmailStyle17 {mso-style-type:personal; font-family:"Calibri","sans-serif"; color:windowtext;} span.EmailStyle18 {mso-style-type:personal; font-family:"Calibri","sans-serif"; color:#1F497D;} span.EmailStyle19 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} span.BalloonTextChar {mso-style-name:"Balloon Text Char"; mso-style-priority:99; mso-style-link:"Balloon Text"; font-family:"Tahoma","sans-serif";} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">Sorry. I screwed up. I= somehow missed “none” as an option.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in = 4.0pt"> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:"= ;Tahoma","sans-serif"">From:</span></b><span style=3D"font-s= ize:10.0pt;font-family:"Tahoma","sans-serif""> Eran Ham= mer-Lahav [mailto:eran@hueniverse.com] <br> <b>Sent:</b> Friday, June 25, 2010 11:20 AM<br> <b>To:</b> Yaron Goland<br> <b>Cc:</b> OAuth WG (oauth@ietf.org)<br> <b>Subject:</b> RE: How do autonomous clients asks for access tokens?<o:p><= /o:p></span></p> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">The access grants do n= ot correlate to the profiles anymore. For example, user-agent uses the auth= orization-code access grant. The section lists how an autonomous client can= use the client credentials or assertion to obtain an access token.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">EHL<o:p></o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in = 4.0pt"> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:"= ;Tahoma","sans-serif"">From:</span></b><span style=3D"font-s= ize:10.0pt;font-family:"Tahoma","sans-serif""> oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] <b>On Behalf Of </b>Yaron Goland<br> <b>Sent:</b> Friday, June 25, 2010 11:17 AM<br> <b>To:</b> oauth@ietf.org<br> <b>Subject:</b> [OAUTH-WG] How do autonomous clients asks for access tokens= ?<o:p></o:p></span></p> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">Section 1.4.4 says that autonomous clients can get a= ccess tokens. But how? What grant_type should they use?<o:p></o:p></p> <p class=3D"MsoNormal">        &nbs= p;       Thanks,<o:p></o:p></p> <p class=3D"MsoNormal">        &nbs= p;            &= nbsp;          Yaron<o:p></o:p= ></p> <p class=3D"MsoNormal">P.S. I looked for a grant_type of autonomous but I d= idn’t see it in -08. Sorry if I missed it.<o:p></o:p></p> </div> </div> </div> </body> </html> --_000_7C01E631FF4B654FA1E783F1C0265F8C579CAA4BTK5EX14MBXC117r_-- From wmills@yahoo-inc.com Fri Jun 25 11:37:03 2010 Return-Path: <wmills@yahoo-inc.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EC293A67E7 for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 11:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.995 X-Spam-Level: X-Spam-Status: No, score=-16.995 tagged_above=-999 required=5 tests=[AWL=0.270, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id StIj1QVX6Fqq for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 11:36:59 -0700 (PDT) Received: from mrout2-b.corp.re1.yahoo.com (mrout2-b.corp.re1.yahoo.com [69.147.107.21]) by core3.amsl.com (Postfix) with ESMTP id 7A26B3A6928 for <oauth@ietf.org>; Fri, 25 Jun 2010 11:36:59 -0700 (PDT) Received: from SNV-EXPF01.ds.corp.yahoo.com (snv-expf01.ds.corp.yahoo.com [207.126.227.250]) by mrout2-b.corp.re1.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o5PIa3Og094650; Fri, 25 Jun 2010 11:36:04 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:x-mimeole:content-class:mime-version: content-type:content-transfer-encoding:subject:date:message-id: in-reply-to:x-ms-has-attach:x-ms-tnef-correlator:thread-topic: thread-index:references:from:to:cc:x-originalarrivaltime; b=CMon7j7SX2c/hv0vuSer8hiXrxoiPvDUTIF9W1SawRFEdMldCG+nO5PxtuYtWuGq Received: from SNV-EXVS08.ds.corp.yahoo.com ([207.126.227.8]) by SNV-EXPF01.ds.corp.yahoo.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 25 Jun 2010 11:36:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 25 Jun 2010 11:35:19 -0700 Message-ID: <012AB2B223CB3F4BB846962876F47217059B66E5@SNV-EXVS08.ds.corp.yahoo.com> In-Reply-To: <AANLkTim0Z9wZrqX_zZxboZHCRjx9a28VcabWr-Hi1_-H@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] proposal for signatures Thread-Index: AcsUkMLGgJ3sNIWWROmSTTL6q774xwABGQ0w References: <AANLkTingCgO-o3XRZbxYoD8U2rRTO-EgWcfg2hBlbQHm@mail.gmail.com><AANLkTinZ1XIFO25mcgoiDV-V0Blvv8ZC6kV_F3fca3dC@mail.gmail.com><4C5BCAC6-713F-4C42-8696-2931D1AB3199@gmail.com><AANLkTinlATNBEQsmFJIxv_cgqfI_tsoGfTMy6OXN6F_B@mail.gmail.com><A08279DC79B11C48AD587060CD9397712735068D@TK5EX14MBXC101.redmond.corp.microsoft.com><AANLkTimLrZzwDW9rMtGjD9k6ZtXc_oDXIIIYWOMw-NCi@mail.gmail.com><AANLkTilcn_qQLgriJEdPk95f2Zliyk0QXGvU6t77Aa7G@mail.gmail.com><AANLkTinEjidY_HmcGHPTus7P1snjCl9DPL4dX-Sz_mTQ@mail.gmail.com><AANLkTilRUQiD5oRyxUZXmPs2skCY8zAmc1Vl--8pEblS@mail.gmail.com><AANLkTilAjh9Jl0__9jksh3eY7giVR6Wtr0NYNoFfYHZX@mail.gmail.com><AANLkTil3NxM_TmrusslVpCTqwqA8AEtH_vPsHnxkrcE3@mail.gmail.com><CFA39B76-586F-443B-81F2-AC65FC6361FC@facebook.com> <AANLkTim0Z9wZrqX_zZxboZHCRjx9a28VcabWr-Hi1_-H@mail.gmail.com> From: "William Mills" <wmills@yahoo-inc.com> To: "Breno" <breno.demedeiros@gmail.com>, "Luke Shepard" <lshepard@facebook.com> X-OriginalArrivalTime: 25 Jun 2010 18:36:03.0180 (UTC) FILETIME=[43E2A2C0:01CB1495] Cc: Hannes.Tschofenig@gmx.net, OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] proposal for signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 25 Jun 2010 18:37:03 -0000 +1 for optional=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]=20 > On Behalf Of Breno > Sent: Friday, June 25, 2010 11:02 AM > To: Luke Shepard > Cc: Hannes.Tschofenig@gmx.net; OAuth WG > Subject: Re: [OAUTH-WG] proposal for signatures >=20 > On Fri, Jun 25, 2010 at 10:51 AM, Luke Shepard=20 > <lshepard@facebook.com> wrote: > >> What's the purpose of leaving out the key ID? > > It's one more field that developers have to learn and=20 > configure and type in. > > We should keep the simple case simple, while allowing for=20 > more complex=20 > > cases. I think the fact that many providers now offer only=20 > a single,=20 > > shared secret is an indication that the key ID is not required. >=20 > Are you arguing here that the key_id should be an optional=20 > field, or that it should not be part of the specification at all? >=20 > > On Jun 25, 2010, at 7:40 AM, Breno wrote: > > > > Key ids are an optimization in the case of rotating public=20 > keys, but=20 > > pretty much an operational requirement if you wish to support=20 > > automatic rotation of shared keys. > > > > On Jun 23, 2010 2:56 AM, "Ben Laurie" <benl@google.com> wrote: > > > > On 22 June 2010 21:45, David Recordon <recordond@gmail.com> wrote: > >> Hey Dick, in answering my quest... > > > > I don't understand why they are unnecessary no matter how keys are > > managed: if there's ever a possibility that you might have=20 > more than=20 > > one key for someone, then key IDs are a useful optimisation. > > > > Put it another way: what's the purpose of leaving out the key ID? > > > >> And yes, Applied Cryptography is worth reading. :) > >> > >> --David > >> > >> > >> On Tue, Jun 22, 2010 at 12:5... > > > > <ATT00001..txt> > > >=20 >=20 >=20 > -- > Breno de Medeiros > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 From breno.demedeiros@gmail.com Fri Jun 25 11:39:59 2010 Return-Path: <breno.demedeiros@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 331513A68F9 for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 11:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lzj83ZkUEboK for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 11:39:55 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id B4E3D3A6A1E for <oauth@ietf.org>; Fri, 25 Jun 2010 11:39:40 -0700 (PDT) Received: by gyh4 with SMTP id 4so5523621gyh.31 for <oauth@ietf.org>; Fri, 25 Jun 2010 11:39:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=g2L0ISEbvQ63/WO95qN7KfLDRoraaHq1qmAawXuK9LY=; b=JTZAHwVQv2z1gRWffxpy02q36Y8kgJV3ngbpeZyaIBi66zeH2Cx9qCwcH8dW9psQUC VDdiCysZLdlnFF7NlR/ClbNdDdgApo+pc6CkQ+qUmVnRB30PPH1znKyuuYQCiw3d2rYe ZnDJRNIVC6ZIig4hWkm7IsuLrDrMNjo6rX1z4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=fCZztCeIvSeiq8J2tSkF8geQwNGZMiBHvesQBp14FZW5IfkMqkT01lVBtUhVoIo0fQ D/vRZZ6qSgHbmuXmW5eRG3aIyPQPNXTgjQFK27ioW5TfIvW7ovzAx8srNWC5ZX7TB6Ow kbIXzMrNS1QLPcq2aT1iBAyBoGetzJmCpTbYU= MIME-Version: 1.0 Received: by 10.101.105.22 with SMTP id h22mr1420331anm.35.1277491189302; Fri, 25 Jun 2010 11:39:49 -0700 (PDT) Received: by 10.100.225.19 with HTTP; Fri, 25 Jun 2010 11:39:49 -0700 (PDT) In-Reply-To: <2625894F-2979-40BD-81E1-05A6EB8723CD@facebook.com> References: <AANLkTimMruKyblUWROkPMDapFKtTztOXqL64PpQxCmKO@mail.gmail.com> <2625894F-2979-40BD-81E1-05A6EB8723CD@facebook.com> Date: Fri, 25 Jun 2010 11:39:49 -0700 Message-ID: <AANLkTinvLOV0f3I-aWpeAbfIpfGyxZSB2RHu52iw5mDC@mail.gmail.com> From: Breno <breno.demedeiros@gmail.com> To: Luke Shepard <lshepard@facebook.com> Content-Type: text/plain; charset=ISO-8859-1 Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] Understanding the reasoning for Base64 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 25 Jun 2010 18:39:59 -0000 On Fri, Jun 25, 2010 at 10:49 AM, Luke Shepard <lshepard@facebook.com> wrote: > Brian, Dirk - just wondering if you had thoughts here? > > The only strong reason I can think of for base64 encoding is that it allows for a delimiter between the body and the signature. Is there any other reason? Without base64 encoding we have to define canonicalization procedures around spaces and we still have to URL encode separator characters such as {. There is also the risk that developers might be confused whether the URL encoding is to be performed before or after computation of the signature. If you say that the signature is computed on the base64 encoded blob, there's less scope for confusion and interoperability issues. > > On Jun 24, 2010, at 11:33 AM, Naitik Shah wrote: > >> I've been following some of the discussions wrt the new Signature proposal, and I think I get the reason for needing Base64, but wasn't quite sure if I understood it correctly (allows the use of a separator?). Would someone mind elaborating? >> >> The payload looks is urlencode(web_base64(json_encode(data))) -- and the urlencode in this case should be an identity function. >> >> I'm wondering if urlencode(json_encode(data)) would be acceptable. >> >> >> Thanks, >> -Naitik >> <ATT00001..txt> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Breno de Medeiros From briandunnington@gmail.com Fri Jun 25 11:53:19 2010 Return-Path: <briandunnington@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E7923A6800 for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 11:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.822 X-Spam-Level: X-Spam-Status: No, score=-0.822 tagged_above=-999 required=5 tests=[AWL=-0.823, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Idkfmuh6aciT for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 11:53:15 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id CD33E3A6407 for <oauth@ietf.org>; Fri, 25 Jun 2010 11:53:15 -0700 (PDT) Received: by iwn39 with SMTP id 39so606176iwn.31 for <oauth@ietf.org>; Fri, 25 Jun 2010 11:53:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=emv5WyOwDbJM3FrC8II9g8dbhl5EoQvgXT3IylLLlBI=; b=QNGhciAgEKXhm7yjyFkxHyaHazZL0KkpNNUJ1SAm0nPHGt/e/Z6ZOneNJAqetONeZ3 2OefSUQBJFSzwQSCC6Id46inuVlKQSIbiLdzjYycqlevEnM3oTiGbf7MKiuRI6LdjgpO VCw3tcmUTcGYjOH9poupBoxdTUcSEqup3tCnw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=ejpc8b1gCsts0qCdOWloFtHdG6S8PrZr7AEqRmPLeymnjdhhr6sfUqC74cru9YfFvg EG/UoZD2SxJimEWdDCc4lbm7YNI45tyMJ3nHZYtBH1H+G8G4dvyuq0h7YjvpdhmhIp+E 6kmgPUQ6JyVGAOSI77wu5vkQi6bxs484Fuazk= MIME-Version: 1.0 Received: by 10.231.36.9 with SMTP id r9mr1116916ibd.105.1277492004265; Fri, 25 Jun 2010 11:53:24 -0700 (PDT) Received: by 10.231.152.15 with HTTP; Fri, 25 Jun 2010 11:53:24 -0700 (PDT) In-Reply-To: <AANLkTimvvwzUhCBS3Nlq6Q5odfGTJkv-AYGoUGfS47SJ@mail.gmail.com> References: <AANLkTikbz5zmILsegGXoj6YjdC8h4TPfscqDMqFCB7l-@mail.gmail.com> <AANLkTimvvwzUhCBS3Nlq6Q5odfGTJkv-AYGoUGfS47SJ@mail.gmail.com> Date: Fri, 25 Jun 2010 11:53:24 -0700 Message-ID: <AANLkTim2WEUSbtqilolfrTdhKjNcRE6llRMffQLeb9VC@mail.gmail.com> From: Brian Dunnington <briandunnington@gmail.com> To: oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [OAUTH-WG] client secret used in Native App profile X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 25 Jun 2010 18:53:19 -0000 I think the line between 'native apps' and 'user-agent apps' is fuzzier than that. if the only difference being considered is that user-agent apps are not compiled (Javascript) vs. native apps that are, that is not the whole picture. some native apps may not be compiled (think Python, etc) and even those that are compiled are usually pretty easy to deconstruct. so in either case, secure storage of the key is not viable. beyond the storage of the key is the point of distribution. to use the too-oft cited example of Twitter, if i register my app (client), i get assigned a Client ID and Client Secret. if i want my native app to communicate with the Twitter API, i have to ship the Client ID *and* secret in every instance of my app. the secret is now distributed to n number of unsecured machines which can easily retrieve my secret and there is no centralized way to revoke/replace the secret. Eran Hammer-Lahav wrote on his blog: "However, when the Consumer is a desktop application, a mobile application, or any other client-side software such as browser applets (Flash, Java, Silverlight) and scripts (JavaScript), the Consumer credentials must be included in each copy of the application. This means the Consumer Secret (or Private Key) must be distributed with the application, which inheritably compromises them." - http://hueniverse.com/2008/10/beginners-guide-to-oauth-part-iii-security-ar= chitecture/ whether written in Javascript or not, any app that runs on the end-user's machine has the same problems with regard to client secrets. i am just trying to wrap my head around why there should be a distinction between the two in that regard. On Fri, Jun 25, 2010 at 12:22 AM, Marius Scurtescu <mscurtescu@google.com> wrote: > I think the main difference is that User-Agent clients (aka JavaScript > clients) cannot store a secret while Native Apps can safely store a > secret, but the secret cannot be distributed (or, even if it can be > distributed, it may not have much value). > > The difference is important. Each native app instance could require a > registration phase that would provide a unique secret and possibly Id. > This registration phase could be completely automatic or could involve > the end user. There have been proposals for both. How much value there > is in such a registration is not clear to me. > > Marius > > > > On Thu, Jun 24, 2010 at 6:50 PM, Brian Dunnington > <briandunnington@gmail.com> wrote: >> In the 'User-Agent' profile, it says: >> >> "This user-agent profile does not utilize the client secret since the >> =A0 client executables reside on the end-user's computer or device which >> =A0 makes the client secret accessible and exploitable" >> >> However, the 'Native Apps' profile does not include such verbiage and >> in fact specifically requires the use of the client secret. Native >> apps' executables also reside on the end-user's computer or device, >> making the client secret just as accessible and exploitable, so why >> the difference? >> >> Specifically, as a native app developer, there is no good (secure) way >> to distribute the client secret without it being compromised. Any >> open-source application would have even more problems keeping their >> secret secure, but even complied apps are easily exploitable. in this >> scenario, there is no single, secure repository to keep the client >> secret safe, so I would expect that the requirement of the client >> secret for native apps be removed and made conformant with the >> user-agent profile. >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > From eran@hueniverse.com Fri Jun 25 11:56:43 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C8443A6A2D for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 11:56:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.245 X-Spam-Level: X-Spam-Status: No, score=-2.245 tagged_above=-999 required=5 tests=[AWL=0.354, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LdA55x4D-e+z for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 11:56:42 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 1752D3A683D for <oauth@ietf.org>; Fri, 25 Jun 2010 11:56:42 -0700 (PDT) Received: (qmail 25208 invoked from network); 25 Jun 2010 18:56:50 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 25 Jun 2010 18:56:50 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Fri, 25 Jun 2010 11:56:45 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: Brian Dunnington <briandunnington@gmail.com>, "oauth@ietf.org" <oauth@ietf.org> Date: Fri, 25 Jun 2010 11:56:28 -0700 Thread-Topic: [OAUTH-WG] client secret used in Native App profile Thread-Index: AcsUl7Xcg0rEauCwS9SFbzvvBGWZdwAAC7cA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EC849C4@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <AANLkTikbz5zmILsegGXoj6YjdC8h4TPfscqDMqFCB7l-@mail.gmail.com> <AANLkTimvvwzUhCBS3Nlq6Q5odfGTJkv-AYGoUGfS47SJ@mail.gmail.com> <AANLkTim2WEUSbtqilolfrTdhKjNcRE6llRMffQLeb9VC@mail.gmail.com> In-Reply-To: <AANLkTim2WEUSbtqilolfrTdhKjNcRE6llRMffQLeb9VC@mail.gmail.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] client secret used in Native App profile X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 25 Jun 2010 18:56:43 -0000 The current prose makes the distinction as a matter of practicality, not no= rmative language. IOW, it uses these labels to provide an introduction on h= ow OAuth may be applied to these well establish client types. However, when= it comes to the actual endpoints (once the simplification proposal makes i= t into -09 shortly), there is no longer distinction between the client type= s, only the endpoint attributes. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Brian Dunnington > Sent: Friday, June 25, 2010 11:53 AM > To: oauth@ietf.org > Subject: Re: [OAUTH-WG] client secret used in Native App profile >=20 > I think the line between 'native apps' and 'user-agent apps' is fuzzier t= han > that. if the only difference being considered is that user-agent apps are= not > compiled (Javascript) vs. native apps that are, that is not the whole pic= ture. > some native apps may not be compiled (think Python, etc) and even those > that are compiled are usually pretty easy to deconstruct. so in either ca= se, > secure storage of the key is not viable. >=20 > beyond the storage of the key is the point of distribution. to use the to= o-oft > cited example of Twitter, if i register my app (client), i get assigned a= Client ID > and Client Secret. if i want my native app to communicate with the Twitte= r > API, i have to ship the Client ID *and* secret in every instance of my ap= p. the > secret is now distributed to n number of unsecured machines which can > easily retrieve my secret and there is no centralized way to revoke/repla= ce > the secret. >=20 > Eran Hammer-Lahav wrote on his blog: >=20 > "However, when the Consumer is a desktop application, a mobile applicatio= n, > or any other client-side software such as browser applets (Flash, Java, > Silverlight) and scripts (JavaScript), the Consumer credentials must be > included in each copy of the application. This means the Consumer Secret = (or > Private Key) must be distributed with the application, which inheritably > compromises them." - http://hueniverse.com/2008/10/beginners-guide-to- > oauth-part-iii-security-architecture/ >=20 > whether written in Javascript or not, any app that runs on the end-user's > machine has the same problems with regard to client secrets. i am just tr= ying > to wrap my head around why there should be a distinction between the two > in that regard. >=20 >=20 > On Fri, Jun 25, 2010 at 12:22 AM, Marius Scurtescu > <mscurtescu@google.com> wrote: > > I think the main difference is that User-Agent clients (aka JavaScript > > clients) cannot store a secret while Native Apps can safely store a > > secret, but the secret cannot be distributed (or, even if it can be > > distributed, it may not have much value). > > > > The difference is important. Each native app instance could require a > > registration phase that would provide a unique secret and possibly Id. > > This registration phase could be completely automatic or could involve > > the end user. There have been proposals for both. How much value there > > is in such a registration is not clear to me. > > > > Marius > > > > > > > > On Thu, Jun 24, 2010 at 6:50 PM, Brian Dunnington > > <briandunnington@gmail.com> wrote: > >> In the 'User-Agent' profile, it says: > >> > >> "This user-agent profile does not utilize the client secret since the > >> =A0 client executables reside on the end-user's computer or device > >> which > >> =A0 makes the client secret accessible and exploitable" > >> > >> However, the 'Native Apps' profile does not include such verbiage and > >> in fact specifically requires the use of the client secret. Native > >> apps' executables also reside on the end-user's computer or device, > >> making the client secret just as accessible and exploitable, so why > >> the difference? > >> > >> Specifically, as a native app developer, there is no good (secure) > >> way to distribute the client secret without it being compromised. Any > >> open-source application would have even more problems keeping their > >> secret secure, but even complied apps are easily exploitable. in this > >> scenario, there is no single, secure repository to keep the client > >> secret safe, so I would expect that the requirement of the client > >> secret for native apps be removed and made conformant with the > >> user-agent profile. > >> _______________________________________________ > >> OAuth mailing 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 Fri Jun 25 12:07:29 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A36553A6A12 for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 12:07:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.32 X-Spam-Level: X-Spam-Status: No, score=-1.32 tagged_above=-999 required=5 tests=[AWL=-0.580, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vjIDmy6j3dBG for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 12:07:28 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 8D48C3A68B2 for <oauth@ietf.org>; Fri, 25 Jun 2010 12:07:28 -0700 (PDT) Received: (qmail 6978 invoked from network); 25 Jun 2010 19:07:37 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 25 Jun 2010 19:07:37 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 25 Jun 2010 12:07:30 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: Marius Scurtescu <mscurtescu@google.com> Date: Fri, 25 Jun 2010 12:07:13 -0700 Thread-Topic: [OAUTH-WG] Proposal: simplification of the end-user authorization endpoint Thread-Index: AcsOZ+CKIj3UmbPBQQOiroaMF5VR3AGMO+8g Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EC849D2@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB6F56@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTilB1Z3Md87vUp5bu7M6PwkeXO0R7SKpTO1M4XrV@mail.gmail.com> <AANLkTikHiCFH2Zq0rnKJBF4WmCOMd6J636HMDvrTimn_@mail.gmail.com> <AANLkTikNF74QrjhbYHeVpeZaytt9KqNBLpqFIIkdEgQZ@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3EBB71D0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTin3knKmoMoy0-mbz1nXTNwp8sfaFkn1sDHnni9m@mail.gmail.com> In-Reply-To: <AANLkTin3knKmoMoy0-mbz1nXTNwp8sfaFkn1sDHnni9m@mail.gmail.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 \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Proposal: simplification of the end-user authorization endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 25 Jun 2010 19:07:29 -0000 > -----Original Message----- > From: Marius Scurtescu [mailto:mscurtescu@google.com] > Sent: Thursday, June 17, 2010 2:56 PM > >> Basically, why cannot be that problem solved by 2 different requests, > >> both done by the JavaScript layer? > >> > >> If latency is a problem, it would be good to know exactly where. I > >> assume that authorization codes are issued very infrequently. Does > >> this new token_and_code mode eliminate a transaction every two > weeks? > >> Does that make a difference? > > > > The advantage of the user-agent flow is that it address the lack of cli= ent > authentication with the presence of the end-user. The server might not > know who the client really is, but it does know that the right user is si= tting in > front of the client authorizing the request. It doesn't solve phishing bu= t it > provides some security. >=20 > Sure, but how is this affected by token_and_code? The authz server knows > who the user is when it issues the access token and the authorization cod= e. > The authorization code is passed down to the client server and now the cl= ient > server asks for access/refresh tokens. No user this time but potentially = there > is a client secret. But those are two different parts of the client. Returning a direct access = token uses the fact that the end-user it present which provides a measure o= f security because a good UI can help explain to the end-user what is going= on and put context into the transaction. If we force clients who need the = access token both in the client and on the server to use only the code mode= , then they need to find a way to share that access token. However, an acce= ss token issued using a code and client secret will potentially have more p= ower than an access token issued using the user-agent direct communication. The alternative of using both flows means annoying the end-user. > > In the case where a client (native application or user-agent) works in > > tandem with a server-based component, using just the web-server flow > > has two disadvantages I'm aware of: the client has to be more complex > > because it requires callbacks in order to obtain the access token from > > the server (multiple calls and more complex calls than just a simple > > server-hosted script), >=20 > The JavaScript client can either use the authorization code with a direct= call > (as you probably suggest), but then it cannot pass the authorization code > down to the client server anymore. The JavaScript client can do a separat= e > User-Agent call in immediate mode to get an access token directly. This i= s > what it would normally do. No point in swapping the authorization code si= nce > it can be exchanged only once. I think relying on immediate mode is a possible but more complex solution w= hich can break depending on the state of cookies and sessions. =20 EHL From naitiks@gmail.com Fri Jun 25 12:15:59 2010 Return-Path: <naitiks@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A34928C0F0 for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 12:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.046 X-Spam-Level: X-Spam-Status: No, score=-1.046 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f11fhoDV9QpP for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 12:15:48 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id B71B828C122 for <oauth@ietf.org>; Fri, 25 Jun 2010 12:15:43 -0700 (PDT) Received: by iwn39 with SMTP id 39so624732iwn.31 for <oauth@ietf.org>; Fri, 25 Jun 2010 12:15:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=N5mZ8GQfRQqI7MLfTW1836xLyT1Ks7Ll9r1cyJskhmA=; b=pyFZUhfZ4yggkEg8C29P7zrcsqKqR18F13xnoq1jGLf2851WbLvR2h+cCIE76lptwn fEawB4L4qvXF6EEUA9U0qtmFPLAURzyVxK2LOBqPPsmRcPYfCoa4XxoQTc7ospSbhBB+ Ge0OuFlsN5j1D62v3kPBtYibBC6Pc6VfsDzVc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=uuUtCAvXIca32yoXS+cG6wjvl8bpYopN1qa1m2n0rRpIs+54R5frUjeeZfW9DuZYkL v2W2yeymPQCQfFLaadU9SeqY0RrVhXrT4OLpAxv8tKOlmSSJ4LTc2+uQQCMOYkWG1NIE UzpcFcYuxGHhjEzvzWVOOlyA1KI8I7HfI9YKU= Received: by 10.231.194.223 with SMTP id dz31mr1190216ibb.87.1277493352559; Fri, 25 Jun 2010 12:15:52 -0700 (PDT) MIME-Version: 1.0 Sender: naitiks@gmail.com Received: by 10.231.170.9 with HTTP; Fri, 25 Jun 2010 12:15:31 -0700 (PDT) In-Reply-To: <AANLkTinvLOV0f3I-aWpeAbfIpfGyxZSB2RHu52iw5mDC@mail.gmail.com> References: <AANLkTimMruKyblUWROkPMDapFKtTztOXqL64PpQxCmKO@mail.gmail.com> <2625894F-2979-40BD-81E1-05A6EB8723CD@facebook.com> <AANLkTinvLOV0f3I-aWpeAbfIpfGyxZSB2RHu52iw5mDC@mail.gmail.com> From: Naitik Shah <n@daaku.org> Date: Fri, 25 Jun 2010 12:15:31 -0700 X-Google-Sender-Auth: xR-pByVeCMI722oYCC-9_q_nNFo Message-ID: <AANLkTilWNneonIRX21U1RZcE80FuVSJWXU7CNm5pV275@mail.gmail.com> To: Breno <breno.demedeiros@gmail.com> Content-Type: multipart/alternative; boundary=00504501748b7b759f0489df991f Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] Understanding the reasoning for Base64 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 25 Jun 2010 19:16:00 -0000 --00504501748b7b759f0489df991f Content-Type: text/plain; charset=UTF-8 On Fri, Jun 25, 2010 at 11:39 AM, Breno <breno.demedeiros@gmail.com> wrote: > On Fri, Jun 25, 2010 at 10:49 AM, Luke Shepard <lshepard@facebook.com> > wrote: > > Brian, Dirk - just wondering if you had thoughts here? > > > > The only strong reason I can think of for base64 encoding is that it > allows for a delimiter between the body and the signature. Is there any > other reason? > > Without base64 encoding we have to define canonicalization procedures > around spaces and we still have to URL encode separator characters > such as {. There is also the risk that developers might be confused > whether the URL encoding is to be performed before or after > computation of the signature. If you say that the signature is > computed on the base64 encoded blob, there's less scope for confusion > and interoperability issues. > > Yep, I get that the "web" version makes the url encoding a no op. But I fear we're trading one spec (urlencoding) to another one (web base64). I'm imagining the sample code (that does not rely on an SDK) we'ed give out to developers in our docs, and the thing that stands out is the "web" part in the web_base64. It means that our sample code will look like str_replace("+", "_", base64(json_encode(data)))) or for validating signatures: json_decode(decode64(str_replace("_", "+", data))) The str_replace() really stands out. From my quick read, it seemed like there were one or two other characters that needed to get replaced too. While some languages (like PHP) support arrays to specify multiple replacement patterns, in other languages you'll end up with a few str_replace calls. It would be nice if that wasn't necessary. I'm wondering if we can get away with "urlencode(json_encode(data) + '.' + sig)" as the value. then, instead of str_replace for getting normal base64 logic to work, we would instead need a rsplit or something, since the dot is not a reserved character in the json blob. Was that approach considered? -Naitik --00504501748b7b759f0489df991f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Jun 25, 2010 at 11:39 AM, Breno <span dir=3D"ltr"><<a href=3D"ma= ilto:breno.demedeiros@gmail.com">breno.demedeiros@gmail.com</a>></span> = wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" styl= e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div class=3D"im">On Fri, Jun 25, 2010 at 10:49 AM, Luke Shepard <<a hre= f=3D"mailto:lshepard@facebook.com">lshepard@facebook.com</a>> wrote:<br> > Brian, Dirk - just wondering if you had thoughts here?<br> ><br> > The only strong reason I can think of for base64 encoding is that it a= llows for a delimiter between the body and the signature. Is there any othe= r reason?<br> <br> </div>Without base64 encoding we have to define canonicalization procedures= <br> around spaces and we still have to URL encode separator characters<br> such as {. There is also the risk that developers might be confused<br> whether the URL encoding is to be performed before or after<br> computation of the signature. =C2=A0If you say that the signature is<br> computed on the base64 encoded blob, there's less scope for confusion<b= r> and interoperability issues.<br> <div class=3D"im"><br></div></blockquote><div><br></div><span class=3D"Appl= e-style-span" style=3D"font-family: arial, sans-serif; font-size: 13px; bor= der-collapse: collapse; "><div>Yep, I get that the "web" version = makes the url encoding a no op. But I fear we're trading one spec (urle= ncoding) to another one (web base64). I'm imagining the sample code (th= at does not rely on an SDK) we'ed give out to developers in our docs, a= nd the thing that stands out is the "web" part in the web_base64.= It means that our sample code will look like</div> <div><br></div><div>=C2=A0=C2=A0str_replace("+", "_", b= ase64(json_encode(data))))</div><div><br></div><div>or for validating signa= tures:</div><div><br></div><div>=C2=A0=C2=A0json_decode(decode64(str_replac= e("_", "+", data)))</div> <div><br></div><div>The str_replace() really stands out. From my quick read= , it seemed like there were one or two other characters that needed to get = replaced too. While some languages (like PHP) support arrays to specify mul= tiple replacement patterns, in other languages you'll end up with a few= str_replace calls. It would be nice if that wasn't necessary.</div> <div><br></div><div><span class=3D"Apple-style-span" style=3D"border-collap= se: separate; font-family: arial; font-size: small; "><span class=3D"Apple-= style-span" style=3D"font-family: arial, sans-serif; font-size: 13px; borde= r-collapse: collapse; ">I'm wondering if we can get away with "url= encode(json_encode(data) + '.' + sig)" as the value. then, ins= tead of str_replace for getting normal base64 logic to work, we would inste= ad need a rsplit or something, since the dot is not a reserved character in= the json blob. Was that approach considered?</span></span></div> <div><span class=3D"Apple-style-span" style=3D"border-collapse: separate; f= ont-family: arial; font-size: small; "><span class=3D"Apple-style-span" sty= le=3D"font-family: arial, sans-serif; font-size: 13px; border-collapse: col= lapse; "><br> </span></span></div><div><span class=3D"Apple-style-span" style=3D"border-c= ollapse: separate; font-family: arial; font-size: small; "><span class=3D"A= pple-style-span" style=3D"font-family: arial, sans-serif; font-size: 13px; = border-collapse: collapse; "><br> </span></span></div><div><span class=3D"Apple-style-span" style=3D"border-c= ollapse: separate; font-family: arial; font-size: small; "><span class=3D"A= pple-style-span" style=3D"font-family: arial, sans-serif; font-size: 13px; = border-collapse: collapse; ">-Naitik</span></span></div> </span></div> --00504501748b7b759f0489df991f-- From jhart@photobucket.com Fri Jun 25 12:18:34 2010 Return-Path: <jhart@photobucket.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6B5628C128 for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 12:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TRu29GLosFG6 for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 12:18:33 -0700 (PDT) Received: from EXHUB003-2.exch003intermedia.net (exhub003-2.exch003intermedia.net [207.5.74.29]) by core3.amsl.com (Postfix) with ESMTP id 11D3828C0F0 for <oauth@ietf.org>; Fri, 25 Jun 2010 12:18:33 -0700 (PDT) Received: from EXVMBX003-4.exch003intermedia.net ([207.5.74.44]) by EXHUB003-2.exch003intermedia.net ([207.5.74.29]) with mapi; Fri, 25 Jun 2010 12:18:42 -0700 From: Justin Hart <jhart@photobucket.com> To: Eran Hammer-Lahav <eran@hueniverse.com> Date: Fri, 25 Jun 2010 12:18:41 -0700 Thread-Topic: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? Thread-Index: AcsUmzlHYxo+kEaNT2Gl2fkqAkZbSQ== Message-ID: <672B689D-4DC2-46D0-BC38-678EAF7CC0B7@photobucket.com> References: <3D3C75174CB95F42AD6BCC56E5555B4502BE07CC@FIESEXC015.nsn-intra.net><E7A7F197-3BBC-43F2-8242-D0164057A39A@gmail.com><AANLkTild51WHVcXxYFCygL8sGSGiN3HILDFwIbym6Lfi@mail.gmail.com> <3D3C75174CB95F42AD6BCC56E5555B4502869858@FIESEXC015.nsn-intra.net> <012AB2B223CB3F4BB846962876F47217059B663D@SNV-EXVS08.ds.corp.yahoo.com> <3D3C75174CB95F42AD6BCC56E5555B450286986B@FIESEXC015.nsn-intra.net> <9BBAE9AB-A0CD-448F-B817-21389C1BBCAF@gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3EC84994@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EC84994@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 Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <hannes.tschofenig@nsn.com>, OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 25 Jun 2010 19:18:34 -0000 +1 towards space-seperated strings. It seems like every server is going to= have diverging requirements on scopes, so anything more will be awfully ha= rd for everyone to agree on. ---- -- Justin Hart -- jhart@photobucket.com On Jun 25, 2010, at 12:14 PM, Eran Hammer-Lahav wrote: > I like the idea of an extensibility mechanism for standard scopes, but I = am not sure I like the idea of a prefix or reserved characters. Using URIs = as scope values was a requirement (and something that is currently deployed= by Google). We defined space-delimited to make simple strings and URIs pos= sible as values. >=20 > My question is, why isn't URIs enough for standard scopes? Define simple = strings as server-specific and allow URIs to be used in standards (which wi= ll solve potential name collisions). It might make standard scopes a bit le= ss cool but that's not a technical argument. I also think scopes are likely= to be extended a lot more than other extension types and would like to kee= p the process as light as possible (i.e. no registration at all). >=20 > EHL >=20 >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Dick Hardt >> Sent: Friday, June 25, 2010 8:50 AM >> To: Tschofenig, Hannes (NSN - FI/Espoo) >> Cc: OAuth WG >> Subject: Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? >>=20 >> To clarify, the goal is to reserve a namespace for future use so that ne= ar term >> implementations won't collide? >>=20 >> I expect the standardization of scope values to not be in OAuth, but in >> standardized APIs that use OAuth, so a namespace mechanism that >> differentiates between a standardized scope and an implementation specif= ic >> scope may be useful. >>=20 >> From what I have gathered, implementors are leaning towards simple strin= gs >> rather than URIs to declare scope. Perhaps reserving the ":" character f= rom >> being in a scope string unless the scope prefix has been registered with >> IANA? >>=20 >> -- Dick >> On 2010-06-25, at 12:59 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >>=20 >>> Dick pointed me to the Facebook API on how scope is used. >>> The main page is here: >>> http://developers.facebook.com/docs/authentication/ >>>=20 >>> It describes the basic functionality and also lists an example: >>>=20 >>> " >>> https://graph.facebook.com/oauth/authorize? >>> client_id=3D...& >>> redirect_uri=3Dhttp://www.example.com/callback& >>> scope=3Duser_photos,user_videos,publish_stream >>> " >>>=20 >>> The values of the scope parameter are then explained here: >>> http://developers.facebook.com/docs/authentication/permissions >>>=20 >>> Example: user_photos ... Provides access to the photos the user has >>> uploaded >>>=20 >>> I think it provides a good example that the scope values are not opaque= . >>> Opaque (in this context) means that only the entity creating it needs t= o >> understand it and nobody else. Here the client needs to understand and s= et >> them. >>>=20 >>> However, one could argue that the scope values are already bound to the >> specific entity the client requests to obtain the assertion from. In thi= s specific >> case it would be "https://graph.facebook.com". >>>=20 >>> To respond to the statement Dick made about having standardized values >> later there would still be the need to decide about the structure of the >> values now. One possibility is to just add a prefix for standardized val= ues that >> are not allowed to be used in other cases, such as "std:". >>>=20 >>> Ciao >>> Hannes >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: ext William Mills [mailto:wmills@yahoo-inc.com] >>>> Sent: Thursday, June 24, 2010 8:15 PM >>>> To: Tschofenig, Hannes (NSN - FI/Espoo); ext Lukas Rosenstock; Dick >>>> Hardt >>>> Cc: OAuth WG >>>> Subject: RE: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? >>>>=20 >>>> I'm in favor of having a spaces separated list of tokens. >>>> The only case I can think of where the client needs to handle the >>>> scope as anything other than opaque is when it is accessing multiple >>>> services. To reduce the numebr of login events the client will have >>>> to poll all the endpoints it wants to access and get all the scopes >>>> advertized by them and submit them all, and once it has them it needs >>>> to submit all of them in it's auth request, so we need something >>>> that's easy for the client to put together. >>>>=20 >>>>=20 >>>> -bill >>>>=20 >>>>> -----Original Message----- >>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] >>>>> On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) >>>>> Sent: Thursday, June 24, 2010 3:58 AM >>>>> To: ext Lukas Rosenstock; Dick Hardt >>>>> Cc: OAuth WG >>>>> Subject: Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? >>>>>=20 >>>>> The question is whether one would ever want to have a >>>>> standardized semantic for the scope parameter. >>>>> If the answer to that question is "no" then it does not >>>>> matter what the format is. It can well be a list of >>>>> space-delimited strings (as it is currently defined). >>>>>=20 >>>>> An evironment specific semantic works well in cases where >>>>> entity X sets the value and later it receives the value >>>>> again. Only entity X needs to understand what it means. >>>>>=20 >>>>> In some environments the use case is slightly different, >>>>> namely entity X and entity Y are from the same organization >>>>> and agree on the semantic. Usage of OAuth within an >>>>> enterprise might be such a case. >>>>>=20 >>>>> Now, the usage of the scope parameter is, however, a bit >>>>> different in the spec. Section 4, for example, describes how >>>>> a client obtains an access token. How does the client know >>>>> what scope parameters to set and what the semantic is? >>>>>=20 >>>>> Ciao >>>>> Hannes >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: ext Lukas Rosenstock [mailto:lr@lukasrosenstock.net] >>>>>> Sent: Thursday, June 24, 2010 10:49 AM >>>>>> To: Dick Hardt >>>>>> Cc: Tschofenig, Hannes (NSN - FI/Espoo); OAuth WG >>>>>> Subject: Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth? >>>>>>=20 >>>>>> Wasn't there some concensus that URIs would be good for >>>> scope? They >>>>>> have "in-built namespacing" ... >>>>>>=20 >>>>>> Lukas >>>>>>=20 >>>>>> 2010/6/23 Dick Hardt <dick.hardt@gmail.com>: >>>>>>>=20 >>>>>>> On 2010-06-22, at 11:07 PM, Tschofenig, Hannes (NSN - >>>>>> FI/Espoo) wrote: >>>>>>>=20 >>>>>>>> " >>>>>>>> scope >>>>>>>> OPTIONAL. The scope of the access request >>>>>> expressed as a list >>>>>>>> of space-delimited strings. The value of the >>>>>> "scope" parameter >>>>>>>> is defined by the authorization server. If the >>>>>> value contains >>>>>>>> multiple space-delimited strings, their order does >>>>>> not matter, >>>>>>>> and each string adds an additional access range to the >>>>>>>> requested scope. >>>>>>>> " >>>>>>>>=20 >>>>>>>> Do folks think it would be useful to have standardized values? >>>>>>>=20 >>>>>>> Not at this time. The semantics of scope are all over the >>>>>> place. If standardized, people will feel they need to pick >>>>> one that is >>>>>> close to what they want, but is not exactly what they mean. >>>>> I think it >>>>>> is better for the AS to define what they mean by a scope >>>>> and give it a >>>>>> name that makes sense in that context. >>>>>>>=20 >>>>>>>>=20 >>>>>>>> If the answer is "yes", then it would be useful to >>>>>> differentiate the >>>>>>>> standardized values from those values that are purely >>>>>> defined locally by >>>>>>>> the authorization server. >>>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From jpanzer@google.com Fri Jun 25 13:36:28 2010 Return-Path: <jpanzer@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47C7928C10D for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 13:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.746 X-Spam-Level: X-Spam-Status: No, score=-99.746 tagged_above=-999 required=5 tests=[AWL=-0.370, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wW3dXLkKL+ex for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 13:36:26 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 2965128C10A for <oauth@ietf.org>; Fri, 25 Jun 2010 13:36:26 -0700 (PDT) Received: from hpaq6.eem.corp.google.com (hpaq6.eem.corp.google.com [172.25.149.6]) by smtp-out.google.com with ESMTP id o5PKaX0f027597 for <oauth@ietf.org>; Fri, 25 Jun 2010 13:36:33 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1277498193; bh=8RMMSdSKO/4kFRwrMt1LKvjyLWM=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=J4aYbbtMZ3irv01sEAngOnwA9VeZ1wmntiNAMkN3bcvJZAmNNV6FMKUl81r7Rs5qJ Po5ykLQR9Ez3aoDjkZDww== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=vMHaM55PpGLUHi3EPikxK9awQpZ0Tbbx2LIFVQrxxwqRudCYuFo1fG6UfqGG76G4N lMZASmWj9OBlGGbX7xwCQ== Received: from gxk19 (gxk19.prod.google.com [10.202.11.19]) by hpaq6.eem.corp.google.com with ESMTP id o5PKZscI000987 for <oauth@ietf.org>; Fri, 25 Jun 2010 13:36:32 -0700 Received: by gxk19 with SMTP id 19so4281893gxk.6 for <oauth@ietf.org>; Fri, 25 Jun 2010 13:36:32 -0700 (PDT) Received: by 10.101.145.21 with SMTP id x21mr1501539ann.232.1277498192245; Fri, 25 Jun 2010 13:36:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.100.10 with HTTP; Fri, 25 Jun 2010 13:36:12 -0700 (PDT) In-Reply-To: <AANLkTilWNneonIRX21U1RZcE80FuVSJWXU7CNm5pV275@mail.gmail.com> References: <AANLkTimMruKyblUWROkPMDapFKtTztOXqL64PpQxCmKO@mail.gmail.com> <2625894F-2979-40BD-81E1-05A6EB8723CD@facebook.com> <AANLkTinvLOV0f3I-aWpeAbfIpfGyxZSB2RHu52iw5mDC@mail.gmail.com> <AANLkTilWNneonIRX21U1RZcE80FuVSJWXU7CNm5pV275@mail.gmail.com> From: John Panzer <jpanzer@google.com> Date: Fri, 25 Jun 2010 13:36:12 -0700 Message-ID: <AANLkTin-7PNLv-Hc229JJcOrIBh4fJqY5CMaLCMbmoIk@mail.gmail.com> To: Naitik Shah <n@daaku.org> Content-Type: multipart/alternative; boundary=0016e6d3cf18f3343c0489e0b9c0 X-System-Of-Record: true Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] Understanding the reasoning for Base64 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 25 Jun 2010 20:36:28 -0000 --0016e6d3cf18f3343c0489e0b9c0 Content-Type: text/plain; charset=ISO-8859-1 There are 2 characters that are different between base64 and base64url. Many good libraries support both (as they're both useful, and both are in the base64 RFC spec); the ability to eliminate a class of encoding problems seems like a good trade-off for, in some languages without full base64 support, an additional substitution of 2 characters. -- John Panzer / Google jpanzer@google.com / abstractioneer.org <http://www.abstractioneer.org/> / @jpanzer On Fri, Jun 25, 2010 at 12:15 PM, Naitik Shah <n@daaku.org> wrote: > On Fri, Jun 25, 2010 at 11:39 AM, Breno <breno.demedeiros@gmail.com>wrote: > >> On Fri, Jun 25, 2010 at 10:49 AM, Luke Shepard <lshepard@facebook.com> >> wrote: >> > Brian, Dirk - just wondering if you had thoughts here? >> > >> > The only strong reason I can think of for base64 encoding is that it >> allows for a delimiter between the body and the signature. Is there any >> other reason? >> >> Without base64 encoding we have to define canonicalization procedures >> around spaces and we still have to URL encode separator characters >> such as {. There is also the risk that developers might be confused >> whether the URL encoding is to be performed before or after >> computation of the signature. If you say that the signature is >> computed on the base64 encoded blob, there's less scope for confusion >> and interoperability issues. >> >> > Yep, I get that the "web" version makes the url encoding a no op. But I > fear we're trading one spec (urlencoding) to another one (web base64). I'm > imagining the sample code (that does not rely on an SDK) we'ed give out to > developers in our docs, and the thing that stands out is the "web" part in > the web_base64. It means that our sample code will look like > > str_replace("+", "_", base64(json_encode(data)))) > > or for validating signatures: > > json_decode(decode64(str_replace("_", "+", data))) > > The str_replace() really stands out. From my quick read, it seemed like > there were one or two other characters that needed to get replaced too. > While some languages (like PHP) support arrays to specify multiple > replacement patterns, in other languages you'll end up with a few > str_replace calls. It would be nice if that wasn't necessary. > > I'm wondering if we can get away with "urlencode(json_encode(data) + '.' + > sig)" as the value. then, instead of str_replace for getting normal base64 > logic to work, we would instead need a rsplit or something, since the dot is > not a reserved character in the json blob. Was that approach considered? > > > -Naitik > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --0016e6d3cf18f3343c0489e0b9c0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable There are 2 characters that are different between base64 and base64url. =A0= Many good libraries support both (as they're both useful, and both are = in the base64 RFC spec); the ability to eliminate a class of encoding probl= ems seems like a good trade-off for, in some languages without full base64 = support, an additional substitution of 2 characters.<div> <br clear=3D"all"><div dir=3D"ltr">--<br>John Panzer / Google<br><a href=3D= "mailto:jpanzer@google.com" target=3D"_blank">jpanzer@google.com</a> / <a h= ref=3D"http://www.abstractioneer.org/" target=3D"_blank">abstractioneer.org= </a> / @jpanzer</div> <br> <br><br><div class=3D"gmail_quote">On Fri, Jun 25, 2010 at 12:15 PM, Naitik= Shah <span dir=3D"ltr"><<a href=3D"mailto:n@daaku.org">n@daaku.org</a>&= gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 = 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div class=3D"im">On Fri, Jun 25, 2010 at 11:39 AM, Breno <span dir=3D"ltr"= ><<a href=3D"mailto:breno.demedeiros@gmail.com" target=3D"_blank">breno.= demedeiros@gmail.com</a>></span> wrote:<br></div><div class=3D"gmail_quo= te"><div class=3D"im"> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> <div>On Fri, Jun 25, 2010 at 10:49 AM, Luke Shepard <<a href=3D"mailto:l= shepard@facebook.com" target=3D"_blank">lshepard@facebook.com</a>> wrote= :<br> > Brian, Dirk - just wondering if you had thoughts here?<br> ><br> > The only strong reason I can think of for base64 encoding is that it a= llows for a delimiter between the body and the signature. Is there any othe= r reason?<br> <br> </div>Without base64 encoding we have to define canonicalization procedures= <br> around spaces and we still have to URL encode separator characters<br> such as {. There is also the risk that developers might be confused<br> whether the URL encoding is to be performed before or after<br> computation of the signature. =A0If you say that the signature is<br> computed on the base64 encoded blob, there's less scope for confusion<b= r> and interoperability issues.<br> <div><br></div></blockquote><div><br></div></div><span style=3D"font-family= :arial, sans-serif;font-size:13px;border-collapse:collapse"><div>Yep, I get= that the "web" version makes the url encoding a no op. But I fea= r we're trading one spec (urlencoding) to another one (web base64). I&#= 39;m imagining the sample code (that does not rely on an SDK) we'ed giv= e out to developers in our docs, and the thing that stands out is the "= ;web" part in the web_base64. It means that our sample code will look = like</div> <div><br></div><div>=A0=A0str_replace("+", "_", base64(= json_encode(data))))</div><div><br></div><div>or for validating signatures:= </div><div><br></div><div>=A0=A0json_decode(decode64(str_replace("_&qu= ot;, "+", data)))</div> <div><br></div><div>The str_replace() really stands out. From my quick read= , it seemed like there were one or two other characters that needed to get = replaced too. While some languages (like PHP) support arrays to specify mul= tiple replacement patterns, in other languages you'll end up with a few= str_replace calls. It would be nice if that wasn't necessary.</div> <div><br></div><div><span style=3D"border-collapse:separate;font-family:ari= al;font-size:small"><span style=3D"font-family:arial, sans-serif;font-size:= 13px;border-collapse:collapse">I'm wondering if we can get away with &q= uot;urlencode(json_encode(data) + '.' + sig)" as the value. th= en, instead of str_replace for getting normal base64 logic to work, we woul= d instead need a rsplit or something, since the dot is not a reserved chara= cter in the json blob. Was that approach considered?</span></span></div> <div><span style=3D"border-collapse:separate;font-family:arial;font-size:sm= all"><span style=3D"font-family:arial, sans-serif;font-size:13px;border-col= lapse:collapse"><br> </span></span></div><div><span style=3D"border-collapse:separate;font-famil= y:arial;font-size:small"><span style=3D"font-family:arial, sans-serif;font-= size:13px;border-collapse:collapse"><br> </span></span></div><div><span style=3D"border-collapse:separate;font-famil= y:arial;font-size:small"><span style=3D"font-family:arial, sans-serif;font-= size:13px;border-collapse:collapse">-Naitik</span></span></div> </span></div> <br>_______________________________________________<br> OAuth mailing list<br> <a href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_blank">h= ttps://www.ietf.org/mailman/listinfo/oauth</a><br> <br></blockquote></div><br></div> --0016e6d3cf18f3343c0489e0b9c0-- From yarong@microsoft.com Fri Jun 25 15:33:25 2010 Return-Path: <yarong@microsoft.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68D883A69E3 for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 15:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.855 X-Spam-Level: X-Spam-Status: No, score=-9.855 tagged_above=-999 required=5 tests=[AWL=0.743, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lg-hR4nfDaeZ for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 15:33:08 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 040133A6861 for <oauth@ietf.org>; Fri, 25 Jun 2010 15:33:07 -0700 (PDT) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 25 Jun 2010 15:32:57 -0700 Received: from TK5EX14MBXC117.redmond.corp.microsoft.com ([169.254.8.23]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.01.0160.007; Fri, 25 Jun 2010 15:32:59 -0700 From: Yaron Goland <yarong@microsoft.com> To: Eran Hammer-Lahav <eran@hueniverse.com>, "oauth@ietf.org" <oauth@ietf.org> Thread-Topic: Proposal for text for section 2 Thread-Index: AcsUm7O3+LYTofkOQ6CsKuFeuynp2A== Date: Fri, 25 Jun 2010 22:32:54 +0000 Message-ID: <7C01E631FF4B654FA1E783F1C0265F8C579CC0C3@TK5EX14MBXC117.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7C01E631FF4B654FA1E783F1C0265F8C579CC0C3TK5EX14MBXC117r_" MIME-Version: 1.0 Subject: [OAUTH-WG] Proposal for text for section 2 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 25 Jun 2010 22:33:25 -0000 --_000_7C01E631FF4B654FA1E783F1C0265F8C579CC0C3TK5EX14MBXC117r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Motivating Scenario: A client makes a request to a token endpoint. It uses = an authorization token to authenticate itself and a refresh token to authen= ticate it's delegated right. This approach to authenticating clients is use= d in enterprises all the time because it's good security practice to send v= alues derived from a secret (e.g. an HMAC, digital signature, etc.) rather = than the secret itself across the wire, even if the wire is encrypted. Proposed Text: 2.2 Assertion Client Credentials The assertion client credentials include a client identifier, assertion and= assertion type. If the assertion client credentials are used then the clie= nt MUST include the credentials using the following request parameters: client_id REQUIRED. The client identifier. client_assertion_type REQUIRED. The format of the assertion as defined by the aut= horization server. The value MUST be an absolute URI. client_assertion REQUIRED. The client assertion. For example (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=3Drefresh_token&client_id=3Ds6BhdRkqt3& client_assertion=3DPHNhbWxwOl...[omitted for brevity]...ZT4= %3D& client_assertion_type=3Durn%3Aoasis%3Anames%sAtc%3ASAML%3A2= .0%3Aassertion& refresh_token=3Dn4E90119d The client MUST NOT include the client credentials using more than one mech= anism. If more than one mechanism is used regardless whether the credential= s are identical or valid, the server MUST reply with an HTTP 400 status cod= e (Bad Request) and include the "multiple_credentials" error code. From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Friday, June 25, 2010 11:31 AM To: Yaron Goland; oauth@ietf.org Subject: RE: Clients authenticating with assertions We never had support for two assertions in one request. The client authenticates itself and can include an assertion (or use type '= none'). The client credentials are the "client assertion" and the assertion= is about the resource owner. Also, you can define an assertion type that's a composite assertion (of one= more more). EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Y= aron Goland Sent: Friday, June 25, 2010 11:26 AM To: oauth@ietf.org Subject: [OAUTH-WG] Clients authenticating with assertions If a client wants to authenticate itself to a token endpoint to get an acce= ss token using an assertion how should it do it? Grant_Type =3D assertion doesn't seem right because that assertion should b= e from the resource owner who delegated the permission, not from the client= , right? In other words one can end up with an access token request with tw= o assertions, one from the client and one from the resource owner. How is t= his done? Thanks, Yaron P.S. I looked for something like client_assertion and client_assertion_type= in section 2 of -08 but didn't see it. Sorry if I missed it. --_000_7C01E631FF4B654FA1E783F1C0265F8C579CC0C3TK5EX14MBXC117r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"> <style><!-- /* Font Definitions */ @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} pre {mso-style-priority:99; mso-style-link:"HTML Preformatted Char"; margin:0in; margin-bottom:.0001pt; font-size:10.0pt; font-family:"Courier New";} p.MsoAcetate, li.MsoAcetate, div.MsoAcetate {mso-style-priority:99; mso-style-link:"Balloon Text Char"; margin:0in; margin-bottom:.0001pt; font-size:8.0pt; font-family:"Tahoma","sans-serif";} span.EmailStyle17 {mso-style-type:personal; font-family:"Calibri","sans-serif"; color:windowtext;} span.EmailStyle18 {mso-style-type:personal; font-family:"Calibri","sans-serif"; color:#1F497D;} span.EmailStyle19 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} span.BalloonTextChar {mso-style-name:"Balloon Text Char"; mso-style-priority:99; mso-style-link:"Balloon Text"; font-family:"Tahoma","sans-serif";} span.HTMLPreformattedChar {mso-style-name:"HTML Preformatted Char"; mso-style-priority:99; mso-style-link:"HTML Preformatted"; font-family:"Courier New";} span.grey {mso-style-name:grey;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">Motivating Scenario: A= client makes a request to a token endpoint. It uses an authorization token= to authenticate itself and a refresh token to authenticate it’s dele= gated right. This approach to authenticating clients is used in enterprises all the time because it’s good securi= ty practice to send values derived from a secret (e.g. an HMAC, digital sig= nature, etc.) rather than the secret itself across the wire, even if the wi= re is encrypted.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">Proposed Text:<o:p></o= :p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">2.2  Assertion Cl= ient Credentials<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">The assertion client c= redentials include a client identifier, assertion and assertion type. If th= e assertion client credentials are used then the client MUST include the cr= edentials using the following request parameters:<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">client_id<o:p></o:p></= span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">   &nbs= p;            REQUIR= ED. The client identifier.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">client_assertion_type<= o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">   &nbs= p;            REQUIR= ED. The format of the assertion as defined by the authorization server.&nbs= p; The value MUST be an absolute URI.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">client_assertion<o:p><= /o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">   &nbs= p;            REQUIR= ED. The client assertion.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">For example (line brea= ks are for display purposes only):<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">   &nbs= p;            POST /= token HTTP/1.1<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">   &nbs= p;            Host: = server.example.com<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">   &nbs= p;            Conten= t-Type: application/x-www-form-urlencoded<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">   &nbs= p;            grant_= type=3Drefresh_token&client_id=3Ds6BhdRkqt3&<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">   &nbs= p;            client= _assertion=3DPHNhbWxwOl...[omitted for brevity]...ZT4%3D&<o:p></o:p></s= pan></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">   &nbs= p;            client= _assertion_type=3Durn%3Aoasis%3Anames%sAtc%3ASAML%3A2.0%3Aassertion&<o:= p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">   &nbs= p;            refres= h_token=3Dn4E90119d<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">The client MUST NOT in= clude the client credentials using more than one mechanism. If more than on= e mechanism is used regardless whether the credentials are identical or val= id, the server MUST reply with an HTTP 400 status code (Bad Request) and include the “multiple_credentials&= #8221; error code.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in = 4.0pt"> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:"= ;Tahoma","sans-serif"">From:</span></b><span style=3D"font-s= ize:10.0pt;font-family:"Tahoma","sans-serif""> Eran Ham= mer-Lahav [mailto:eran@hueniverse.com] <br> <b>Sent:</b> Friday, June 25, 2010 11:31 AM<br> <b>To:</b> Yaron Goland; oauth@ietf.org<br> <b>Subject:</b> RE: Clients authenticating with assertions<o:p></o:p></span= ></p> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">We never had support f= or two assertions in one request.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">The client authenticat= es itself and can include an assertion (or use type ‘none’). Th= e client credentials are the “client assertion” and the asserti= on is about the resource owner.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">Also, you can define a= n assertion type that’s a composite assertion (of one more more).<o:p= ></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">EHL<o:p></o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in = 4.0pt"> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:"= ;Tahoma","sans-serif"">From:</span></b><span style=3D"font-s= ize:10.0pt;font-family:"Tahoma","sans-serif""> oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] <b>On Behalf Of </b>Yaron Goland<br> <b>Sent:</b> Friday, June 25, 2010 11:26 AM<br> <b>To:</b> oauth@ietf.org<br> <b>Subject:</b> [OAUTH-WG] Clients authenticating with assertions<o:p></o:p= ></span></p> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">If a client wants to authenticate itself to a token = endpoint to get an access token using an assertion how should it do it? <o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">Grant_Type =3D assertion doesn’t seem right be= cause that assertion should be from the resource owner who delegated the pe= rmission, not from the client, right? In other words one can end up with an= access token request with two assertions, one from the client and one from the resource owner. How is this done?<o:p= ></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">        &nbs= p;       Thanks,<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">        &nbs= p;            &= nbsp;          Yaron<o:p></o:p= ></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">P.S. I looked for something like client_assertion an= d client_assertion_type in section 2 of -08 but didn’t see it. Sorry = if I missed it.<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> </div> </div> </body> </html> --_000_7C01E631FF4B654FA1E783F1C0265F8C579CC0C3TK5EX14MBXC117r_-- From naitiks@gmail.com Fri Jun 25 16:42:29 2010 Return-Path: <naitiks@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4705C3A68F1 for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 16:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.624 X-Spam-Level: X-Spam-Status: No, score=0.624 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qIOxCH-K2KW for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 16:42:27 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id D147A3A68B0 for <oauth@ietf.org>; Fri, 25 Jun 2010 16:42:27 -0700 (PDT) Received: by pvc21 with SMTP id 21so1507292pvc.31 for <oauth@ietf.org>; Fri, 25 Jun 2010 16:42:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=tceGwuhUMsgMQlqVRlypcxwa/EOZbBSUKLOjcLYfy2g=; b=Wp9X9TfZFKSVNGkw5lm4+42Xc8+s45NV/nH5cYC4OBZqKqg27/ylfenMEgS0fQY0tB AHQH5xpZUQPP0BXm1Q7k1nW3ppWIyezCNa+JkPN/ejytT/OSEhFTBmQWmRob/0tFD+Zs 15K7nicDR35d9mUyNr3qrhuydPGMLS82DZCIY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=V1xdvi+txW/cFs+fzIOQ1r4UjTvkadDstq+qtu5wtyWctIZYQnc4y8+Ji9cEKZl+ZI sZoMkqLjk0NtuSQqRGKc+0pGF26V6ZeBk71/XcNmV0a6F9neY1pdZJRAfzmFfLqFO3ep Az4d4XKiqukV4Zp/9wdBbLZTaKkLTBpD2hHNU= Received: by 10.142.152.9 with SMTP id z9mr1851210wfd.314.1277509354143; Fri, 25 Jun 2010 16:42:34 -0700 (PDT) MIME-Version: 1.0 Sender: naitiks@gmail.com Received: by 10.142.223.10 with HTTP; Fri, 25 Jun 2010 16:42:13 -0700 (PDT) In-Reply-To: <AANLkTin-7PNLv-Hc229JJcOrIBh4fJqY5CMaLCMbmoIk@mail.gmail.com> References: <AANLkTimMruKyblUWROkPMDapFKtTztOXqL64PpQxCmKO@mail.gmail.com> <2625894F-2979-40BD-81E1-05A6EB8723CD@facebook.com> <AANLkTinvLOV0f3I-aWpeAbfIpfGyxZSB2RHu52iw5mDC@mail.gmail.com> <AANLkTilWNneonIRX21U1RZcE80FuVSJWXU7CNm5pV275@mail.gmail.com> <AANLkTin-7PNLv-Hc229JJcOrIBh4fJqY5CMaLCMbmoIk@mail.gmail.com> From: Naitik Shah <n@daaku.org> Date: Fri, 25 Jun 2010 16:42:13 -0700 X-Google-Sender-Auth: F4-__aWTjrWFLEVsDKws9sg_q40 Message-ID: <AANLkTikh_nQ8dXSp7QXJ79kCdbX1zeyPKAl_kgplb25x@mail.gmail.com> To: John Panzer <jpanzer@google.com> Content-Type: multipart/alternative; boundary=000e0cd2dfca40417d0489e3535a Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] Understanding the reasoning for Base64 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 25 Jun 2010 23:42:29 -0000 --000e0cd2dfca40417d0489e3535a Content-Type: text/plain; charset=UTF-8 So my litmus test was looking on the web for "web base 64" or "web base64". Both yield nothing useful. Looking at the docs for PHP, it doesn't seem to support it, Python does, Ruby doesn't seem to. Java doesn't seem to have a native base64, and the C# one doesn't seem to have the web version (a bit unsure about these two). The point I'm trying to make is to someone who comes and reads the docs for an API where we're talking about signature, web base64 will need to be explained in detail. I agree eliminating encoding problems is a good goal. But if we do have to teach the developer a new, or slightly modified encoding scheme, why not have it be URL encoding? It seems more valuable in the long term, since it's a spec that shows up more frequently on the web. And OAuth 1 has already taught this spec to at least some of the target audience. While encoding/decoding with any format will result in some learning, I think if we sign a JSON blob sans urlencoding or web-base64, it might work out to be easier. The fact that it's still mostly plain text is also a plus imho. -Naitik On Fri, Jun 25, 2010 at 1:36 PM, John Panzer <jpanzer@google.com> wrote: > There are 2 characters that are different between base64 and base64url. > Many good libraries support both (as they're both useful, and both are in > the base64 RFC spec); the ability to eliminate a class of encoding problems > seems like a good trade-off for, in some languages without full base64 > support, an additional substitution of 2 characters. > > -- > John Panzer / Google > jpanzer@google.com / abstractioneer.org <http://www.abstractioneer.org/> / > @jpanzer > > > > On Fri, Jun 25, 2010 at 12:15 PM, Naitik Shah <n@daaku.org> wrote: > >> On Fri, Jun 25, 2010 at 11:39 AM, Breno <breno.demedeiros@gmail.com>wrote: >> >>> On Fri, Jun 25, 2010 at 10:49 AM, Luke Shepard <lshepard@facebook.com> >>> wrote: >>> > Brian, Dirk - just wondering if you had thoughts here? >>> > >>> > The only strong reason I can think of for base64 encoding is that it >>> allows for a delimiter between the body and the signature. Is there any >>> other reason? >>> >>> Without base64 encoding we have to define canonicalization procedures >>> around spaces and we still have to URL encode separator characters >>> such as {. There is also the risk that developers might be confused >>> whether the URL encoding is to be performed before or after >>> computation of the signature. If you say that the signature is >>> computed on the base64 encoded blob, there's less scope for confusion >>> and interoperability issues. >>> >>> >> Yep, I get that the "web" version makes the url encoding a no op. But I >> fear we're trading one spec (urlencoding) to another one (web base64). I'm >> imagining the sample code (that does not rely on an SDK) we'ed give out to >> developers in our docs, and the thing that stands out is the "web" part in >> the web_base64. It means that our sample code will look like >> >> str_replace("+", "_", base64(json_encode(data)))) >> >> or for validating signatures: >> >> json_decode(decode64(str_replace("_", "+", data))) >> >> The str_replace() really stands out. From my quick read, it seemed like >> there were one or two other characters that needed to get replaced too. >> While some languages (like PHP) support arrays to specify multiple >> replacement patterns, in other languages you'll end up with a few >> str_replace calls. It would be nice if that wasn't necessary. >> >> I'm wondering if we can get away with "urlencode(json_encode(data) + '.' + >> sig)" as the value. then, instead of str_replace for getting normal base64 >> logic to work, we would instead need a rsplit or something, since the dot is >> not a reserved character in the json blob. Was that approach considered? >> >> >> -Naitik >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > --000e0cd2dfca40417d0489e3535a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div>So my litmus test was looking on the web for "web base 64" o= r "web base64". Both=C2=A0yield=C2=A0nothing useful. Looking at t= he docs for PHP, it doesn't seem to support it, Python does, Ruby doesn= 't seem to. Java doesn't seem to have a native base64, and the C# o= ne doesn't seem to have the web version (a bit unsure about these two).= The point I'm trying to make is to someone who comes and reads the doc= s for an API where we're talking about signature, web base64 will need = to be explained in detail.</div> <div><br></div><div>I agree eliminating encoding problems is a good goal. B= ut if we do have to teach the developer a new, or slightly modified encodin= g scheme, why not have it be URL encoding? It seems more valuable in the lo= ng term, since it's a spec that shows up more frequently on the web. An= d OAuth 1 has already taught this spec to at least some of the target audie= nce.</div> <div><br></div><div>While encoding/decoding with any format will result in = some learning, I think if we sign a JSON blob sans urlencoding or web-base6= 4, it might work out to be easier. The fact that it's still mostly plai= n text is also a plus imho.</div> <div><br></div><div><br></div><div>-Naitik</div><div><br></div><div><br></d= iv>On Fri, Jun 25, 2010 at 1:36 PM, John Panzer <span dir=3D"ltr"><<a hr= ef=3D"mailto:jpanzer@google.com">jpanzer@google.com</a>></span> wrote:<b= r> <div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi= n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">There are 2 char= acters that are different between base64 and base64url. =C2=A0Many good lib= raries support both (as they're both useful, and both are in the base64= RFC spec); the ability to eliminate a class of encoding problems seems lik= e a good trade-off for, in some languages without full base64 support, an a= dditional substitution of 2 characters.<div> <br clear=3D"all"><font color=3D"#888888"><div dir=3D"ltr">--<br>John Panze= r / Google<br><a href=3D"mailto:jpanzer@google.com" target=3D"_blank">jpanz= er@google.com</a> / <a href=3D"http://www.abstractioneer.org/" target=3D"_b= lank">abstractioneer.org</a> / @jpanzer</div> <br> <br><br></font><div class=3D"gmail_quote"><div><div></div><div class=3D"h5"= >On Fri, Jun 25, 2010 at 12:15 PM, Naitik Shah <span dir=3D"ltr"><<a hre= f=3D"mailto:n@daaku.org" target=3D"_blank">n@daaku.org</a>></span> wrote= :<br> </div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo= rder-left:1px #ccc solid;padding-left:1ex"><div><div></div><div class=3D"h5= "> <div>On Fri, Jun 25, 2010 at 11:39 AM, Breno <span dir=3D"ltr"><<a href= =3D"mailto:breno.demedeiros@gmail.com" target=3D"_blank">breno.demedeiros@g= mail.com</a>></span> wrote:<br></div><div class=3D"gmail_quote"><div> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> <div>On Fri, Jun 25, 2010 at 10:49 AM, Luke Shepard <<a href=3D"mailto:l= shepard@facebook.com" target=3D"_blank">lshepard@facebook.com</a>> wrote= :<br> > Brian, Dirk - just wondering if you had thoughts here?<br> ><br> > The only strong reason I can think of for base64 encoding is that it a= llows for a delimiter between the body and the signature. Is there any othe= r reason?<br> <br> </div>Without base64 encoding we have to define canonicalization procedures= <br> around spaces and we still have to URL encode separator characters<br> such as {. There is also the risk that developers might be confused<br> whether the URL encoding is to be performed before or after<br> computation of the signature. =C2=A0If you say that the signature is<br> computed on the base64 encoded blob, there's less scope for confusion<b= r> and interoperability issues.<br> <div><br></div></blockquote><div><br></div></div><span style=3D"font-family= :arial, sans-serif;font-size:13px;border-collapse:collapse"><div>Yep, I get= that the "web" version makes the url encoding a no op. But I fea= r we're trading one spec (urlencoding) to another one (web base64). I&#= 39;m imagining the sample code (that does not rely on an SDK) we'ed giv= e out to developers in our docs, and the thing that stands out is the "= ;web" part in the web_base64. It means that our sample code will look = like</div> <div><br></div><div>=C2=A0=C2=A0str_replace("+", "_", b= ase64(json_encode(data))))</div><div><br></div><div>or for validating signa= tures:</div><div><br></div><div>=C2=A0=C2=A0json_decode(decode64(str_replac= e("_", "+", data)))</div> <div><br></div><div>The str_replace() really stands out. From my quick read= , it seemed like there were one or two other characters that needed to get = replaced too. While some languages (like PHP) support arrays to specify mul= tiple replacement patterns, in other languages you'll end up with a few= str_replace calls. It would be nice if that wasn't necessary.</div> <div><br></div><div><span style=3D"border-collapse:separate;font-family:ari= al;font-size:small"><span style=3D"font-family:arial, sans-serif;font-size:= 13px;border-collapse:collapse">I'm wondering if we can get away with &q= uot;urlencode(json_encode(data) + '.' + sig)" as the value. th= en, instead of str_replace for getting normal base64 logic to work, we woul= d instead need a rsplit or something, since the dot is not a reserved chara= cter in the json blob. Was that approach considered?</span></span></div> <div><span style=3D"border-collapse:separate;font-family:arial;font-size:sm= all"><span style=3D"font-family:arial, sans-serif;font-size:13px;border-col= lapse:collapse"><br> </span></span></div><div><span style=3D"border-collapse:separate;font-famil= y:arial;font-size:small"><span style=3D"font-family:arial, sans-serif;font-= size:13px;border-collapse:collapse"><br> </span></span></div><div><span style=3D"border-collapse:separate;font-famil= y:arial;font-size:small"><span style=3D"font-family:arial, sans-serif;font-= size:13px;border-collapse:collapse">-Naitik</span></span></div> </span></div> <br></div></div><div class=3D"im">_________________________________________= ______<br> OAuth mailing list<br> <a href=3D"mailto:OAuth@ietf.org" target=3D"_blank">OAuth@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_blank">h= ttps://www.ietf.org/mailman/listinfo/oauth</a><br> <br></div></blockquote></div><br></div> </blockquote></div><br> --000e0cd2dfca40417d0489e3535a-- From dick.hardt@gmail.com Fri Jun 25 17:21:44 2010 Return-Path: <dick.hardt@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5F4C3A67A5 for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 17:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[AWL=-1.094, BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pU8RYqxGzKQG for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 17:21:37 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 2ECFB3A67CF for <oauth@ietf.org>; Fri, 25 Jun 2010 17:21:36 -0700 (PDT) Received: by pvc21 with SMTP id 21so1517377pvc.31 for <oauth@ietf.org>; Fri, 25 Jun 2010 17:21:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:message-id:references:to :x-mailer; bh=c43HQMK26e6mgEC3f4d4hT6lxO5+xC0uNfntJU3bzmE=; b=m1Ykw/vYKn5xTjas+57ldHoZHhTIMqhrXkCqzpj5JfFSS42TNd8ksZI+jA2fp4LLrt Bege1rHVmHAn1x6l2ej+OetkV4xkc4d6Qg6cNZF8va8niXRJTKt4g6F9pY3mitnA+wKr LaywTW9DhC+Lay+KJKrnYDp56NPrMLWSonjzE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; b=QcI9BrW1ZvFazz0NJshKpd5Lwqk9aqdV98WDSiW6/Ygk8W6kvBAbaXf772dNIyilzH QPpkQaSzv6tdcAqNZXo5K4jsiqmZefunoZDUCMEolhfgBUwii12NXsVs91O3eon/tBRy 5D+rgpG8pV1NUeklBeJIwTHrbrTqMbjBZ5+4E= Received: by 10.142.207.19 with SMTP id e19mr1940269wfg.186.1277511703236; Fri, 25 Jun 2010 17:21:43 -0700 (PDT) Received: from [192.168.1.5] (c-24-130-32-55.hsd1.ca.comcast.net [24.130.32.55]) by mx.google.com with ESMTPS id b2sm4056920rvn.19.2010.06.25.17.21.41 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 25 Jun 2010 17:21:42 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-1-704273892 From: Dick Hardt <dick.hardt@gmail.com> In-Reply-To: <AANLkTikh_nQ8dXSp7QXJ79kCdbX1zeyPKAl_kgplb25x@mail.gmail.com> Date: Fri, 25 Jun 2010 17:21:40 -0700 Message-Id: <3DC7AEF8-3283-4970-BB98-3D680A3E2429@gmail.com> References: <AANLkTimMruKyblUWROkPMDapFKtTztOXqL64PpQxCmKO@mail.gmail.com> <2625894F-2979-40BD-81E1-05A6EB8723CD@facebook.com> <AANLkTinvLOV0f3I-aWpeAbfIpfGyxZSB2RHu52iw5mDC@mail.gmail.com> <AANLkTilWNneonIRX21U1RZcE80FuVSJWXU7CNm5pV275@mail.gmail.com> <AANLkTin-7PNLv-Hc229JJcOrIBh4fJqY5CMaLCMbmoIk@mail.gmail.com> <AANLkTikh_nQ8dXSp7QXJ79kCdbX1zeyPKAl_kgplb25x@mail.gmail.com> To: Naitik Shah <n@daaku.org> X-Mailer: Apple Mail (2.1081) Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] Understanding the reasoning for Base64 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 26 Jun 2010 00:21:44 -0000 --Apple-Mail-1-704273892 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The RFC term is base64url which turns up much better results when = searching. "URL safe base64" is also a good search term. Note that the token may also be included in the HTTP header. base64url = encoding works well for HTTP headers. Note that the token is opaque to = the client, so being plain text is not as useful as it may seem. Unlike = URL encoding, it is pretty easy to see if a string is base64url or not. = With URL encoding, it may or may not be encoded which sometimes leads to = double encoding / mismatched encoding. -- Dick On 2010-06-25, at 4:42 PM, Naitik Shah wrote: > So my litmus test was looking on the web for "web base 64" or "web = base64". Both yield nothing useful. Looking at the docs for PHP, it = doesn't seem to support it, Python does, Ruby doesn't seem to. Java = doesn't seem to have a native base64, and the C# one doesn't seem to = have the web version (a bit unsure about these two). The point I'm = trying to make is to someone who comes and reads the docs for an API = where we're talking about signature, web base64 will need to be = explained in detail. >=20 > I agree eliminating encoding problems is a good goal. But if we do = have to teach the developer a new, or slightly modified encoding scheme, = why not have it be URL encoding? It seems more valuable in the long = term, since it's a spec that shows up more frequently on the web. And = OAuth 1 has already taught this spec to at least some of the target = audience. >=20 > While encoding/decoding with any format will result in some learning, = I think if we sign a JSON blob sans urlencoding or web-base64, it might = work out to be easier. The fact that it's still mostly plain text is = also a plus imho. >=20 >=20 > -Naitik >=20 >=20 > On Fri, Jun 25, 2010 at 1:36 PM, John Panzer <jpanzer@google.com> = wrote: > There are 2 characters that are different between base64 and = base64url. Many good libraries support both (as they're both useful, = and both are in the base64 RFC spec); the ability to eliminate a class = of encoding problems seems like a good trade-off for, in some languages = without full base64 support, an additional substitution of 2 characters. >=20 > -- > John Panzer / Google > jpanzer@google.com / abstractioneer.org / @jpanzer >=20 >=20 >=20 > On Fri, Jun 25, 2010 at 12:15 PM, Naitik Shah <n@daaku.org> wrote: > On Fri, Jun 25, 2010 at 11:39 AM, Breno <breno.demedeiros@gmail.com> = wrote: > On Fri, Jun 25, 2010 at 10:49 AM, Luke Shepard <lshepard@facebook.com> = wrote: > > Brian, Dirk - just wondering if you had thoughts here? > > > > The only strong reason I can think of for base64 encoding is that it = allows for a delimiter between the body and the signature. Is there any = other reason? >=20 > Without base64 encoding we have to define canonicalization procedures > around spaces and we still have to URL encode separator characters > such as {. There is also the risk that developers might be confused > whether the URL encoding is to be performed before or after > computation of the signature. If you say that the signature is > computed on the base64 encoded blob, there's less scope for confusion > and interoperability issues. >=20 >=20 > Yep, I get that the "web" version makes the url encoding a no op. But = I fear we're trading one spec (urlencoding) to another one (web base64). = I'm imagining the sample code (that does not rely on an SDK) we'ed give = out to developers in our docs, and the thing that stands out is the = "web" part in the web_base64. It means that our sample code will look = like >=20 > str_replace("+", "_", base64(json_encode(data)))) >=20 > or for validating signatures: >=20 > json_decode(decode64(str_replace("_", "+", data))) >=20 > The str_replace() really stands out. =46rom my quick read, it seemed = like there were one or two other characters that needed to get replaced = too. While some languages (like PHP) support arrays to specify multiple = replacement patterns, in other languages you'll end up with a few = str_replace calls. It would be nice if that wasn't necessary. >=20 > I'm wondering if we can get away with "urlencode(json_encode(data) + = '.' + sig)" as the value. then, instead of str_replace for getting = normal base64 logic to work, we would instead need a rsplit or = something, since the dot is not a reserved character in the json blob. = Was that approach considered? >=20 >=20 > -Naitik >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-1-704273892 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii <html><head></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">The = RFC term is base64url which turns up much better results when = searching. "URL safe base64" is also a good search = term.<br><div><div><br></div><div>Note that the token may also be = included in the HTTP header. base64url encoding works well for HTTP = headers. Note that the token is opaque to the client, so being plain = text is not as useful as it may seem. Unlike URL encoding, it is pretty = easy to see if a string is base64url or not. With URL encoding, it may = or may not be encoded which sometimes leads to double encoding / = mismatched encoding.</div><div><br></div><div>-- = Dick</div><div><br><div><div>On 2010-06-25, at 4:42 PM, Naitik Shah = wrote:</div><br class=3D"Apple-interchange-newline"><blockquote = type=3D"cite"><div>So my litmus test was looking on the web for "web = base 64" or "web base64". Both yield nothing useful. Looking = at the docs for PHP, it doesn't seem to support it, Python does, Ruby = doesn't seem to. Java doesn't seem to have a native base64, and the C# = one doesn't seem to have the web version (a bit unsure about these two). = The point I'm trying to make is to someone who comes and reads the docs = for an API where we're talking about signature, web base64 will need to = be explained in detail.</div> <div><br></div><div>I agree eliminating encoding problems is a good = goal. But if we do have to teach the developer a new, or slightly = modified encoding scheme, why not have it be URL encoding? It seems more = valuable in the long term, since it's a spec that shows up more = frequently on the web. And OAuth 1 has already taught this spec to at = least some of the target audience.</div> <div><br></div><div>While encoding/decoding with any format will result = in some learning, I think if we sign a JSON blob sans urlencoding or = web-base64, it might work out to be easier. The fact that it's still = mostly plain text is also a plus imho.</div> = <div><br></div><div><br></div><div>-Naitik</div><div><br></div><div><br></= div>On Fri, Jun 25, 2010 at 1:36 PM, John Panzer <span dir=3D"ltr"><<a = href=3D"mailto:jpanzer@google.com">jpanzer@google.com</a>></span> = wrote:<br> <div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" = style=3D"margin:0 0 0 .8ex;border-left:1px #ccc = solid;padding-left:1ex;">There are 2 characters that are different = between base64 and base64url.  Many good libraries support both (as = they're both useful, and both are in the base64 RFC spec); the ability = to eliminate a class of encoding problems seems like a good trade-off = for, in some languages without full base64 support, an additional = substitution of 2 characters.<div> <br clear=3D"all"><font color=3D"#888888"><div dir=3D"ltr">--<br>John = Panzer / Google<br><a href=3D"mailto:jpanzer@google.com" = target=3D"_blank">jpanzer@google.com</a> / <a = href=3D"http://www.abstractioneer.org/" = target=3D"_blank">abstractioneer.org</a> / @jpanzer</div> <br> <br><br></font><div class=3D"gmail_quote"><div><div></div><div = class=3D"h5">On Fri, Jun 25, 2010 at 12:15 PM, Naitik Shah <span = dir=3D"ltr"><<a href=3D"mailto:n@daaku.org" = target=3D"_blank">n@daaku.org</a>></span> wrote:<br> </div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 = .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div></div><div = class=3D"h5"> <div>On Fri, Jun 25, 2010 at 11:39 AM, Breno <span dir=3D"ltr"><<a = href=3D"mailto:breno.demedeiros@gmail.com" = target=3D"_blank">breno.demedeiros@gmail.com</a>></span> = wrote:<br></div><div class=3D"gmail_quote"><div> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 = .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div>On Fri, Jun 25, 2010 at 10:49 AM, Luke Shepard <<a = href=3D"mailto:lshepard@facebook.com" = target=3D"_blank">lshepard@facebook.com</a>> wrote:<br> > Brian, Dirk - just wondering if you had thoughts here?<br> ><br> > The only strong reason I can think of for base64 encoding is that = it allows for a delimiter between the body and the signature. Is there = any other reason?<br> <br> </div>Without base64 encoding we have to define canonicalization = procedures<br> around spaces and we still have to URL encode separator characters<br> such as {. There is also the risk that developers might be confused<br> whether the URL encoding is to be performed before or after<br> computation of the signature.  If you say that the signature is<br> computed on the base64 encoded blob, there's less scope for = confusion<br> and interoperability issues.<br> <div><br></div></blockquote><div><br></div></div><span = style=3D"font-family:arial, = sans-serif;font-size:13px;border-collapse:collapse"><div>Yep, I get that = the "web" version makes the url encoding a no op. But I fear we're = trading one spec (urlencoding) to another one (web base64). I'm = imagining the sample code (that does not rely on an SDK) we'ed give out = to developers in our docs, and the thing that stands out is the "web" = part in the web_base64. It means that our sample code will look = like</div> <div><br></div><div>  str_replace("+", "_", = base64(json_encode(data))))</div><div><br></div><div>or for validating = signatures:</div><div><br></div><div>  json_decode(decode64(str_= replace("_", "+", data)))</div> <div><br></div><div>The str_replace() really stands out. =46rom my quick = read, it seemed like there were one or two other characters that needed = to get replaced too. While some languages (like PHP) support arrays to = specify multiple replacement patterns, in other languages you'll end up = with a few str_replace calls. It would be nice if that wasn't = necessary.</div> <div><br></div><div><span = style=3D"border-collapse:separate;font-family:arial;font-size:small"><span= style=3D"font-family:arial, = sans-serif;font-size:13px;border-collapse:collapse">I'm wondering if we = can get away with "urlencode(json_encode(data) + '.' + sig)" as the = value. then, instead of str_replace for getting normal base64 logic to = work, we would instead need a rsplit or something, since the dot is not = a reserved character in the json blob. Was that approach = considered?</span></span></div> <div><span = style=3D"border-collapse:separate;font-family:arial;font-size:small"><span= style=3D"font-family:arial, = sans-serif;font-size:13px;border-collapse:collapse"><br> </span></span></div><div><span = style=3D"border-collapse:separate;font-family:arial;font-size:small"><span= style=3D"font-family:arial, = sans-serif;font-size:13px;border-collapse:collapse"><br> </span></span></div><div><span = style=3D"border-collapse:separate;font-family:arial;font-size:small"><span= style=3D"font-family:arial, = sans-serif;font-size:13px;border-collapse:collapse">-Naitik</span></span><= /div> </span></div> <br></div></div><div = class=3D"im">_______________________________________________<br> OAuth mailing list<br> <a href=3D"mailto:OAuth@ietf.org" target=3D"_blank">OAuth@ietf.org</a><br>= <a href=3D"https://www.ietf.org/mailman/listinfo/oauth" = target=3D"_blank">https://www.ietf.org/mailman/listinfo/oauth</a><br> <br></div></blockquote></div><br></div> </blockquote></div><br> _______________________________________________<br>OAuth mailing = list<br><a = href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a><br>https://www.ietf.org/= mailman/listinfo/oauth<br></blockquote></div><br></div></div></body></html= >= --Apple-Mail-1-704273892-- From torsten@lodderstedt.net Fri Jun 25 22:33:05 2010 Return-Path: <torsten@lodderstedt.net> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DF1A3A65A5 for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 22:33:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.314 X-Spam-Level: X-Spam-Status: No, score=-1.314 tagged_above=-999 required=5 tests=[AWL=0.935, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ta14HBcdJQ5J for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 22:33:03 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.42]) by core3.amsl.com (Postfix) with ESMTP id 664A43A63EC for <oauth@ietf.org>; Fri, 25 Jun 2010 22:33:02 -0700 (PDT) Received: from p4fff0ef0.dip.t-dialin.net ([79.255.14.240] helo=[127.0.0.1]) by smtprelay04.ispgateway.de with esmtpa (Exim 4.68) (envelope-from <torsten@lodderstedt.net>) id 1OSO0s-0000Vp-At; Sat, 26 Jun 2010 07:33:10 +0200 Message-ID: <4C259112.2040901@lodderstedt.net> Date: Sat, 26 Jun 2010 07:33:06 +0200 From: Torsten Lodderstedt <torsten@lodderstedt.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Marius Scurtescu <mscurtescu@google.com> References: <AANLkTil1BK4e6o6XSztS31Y-RhXgn01MByP7EBP9twwl@mail.gmail.com> <AANLkTinYLwvJy5T5ZRRpSWj48TvSBzcno93mkDyI63Fi@mail.gmail.com> <AANLkTimOWWZ_fc9KUzS6ZJxvDc_RfL-hoWOVxo-azELU@mail.gmail.com> In-Reply-To: <AANLkTimOWWZ_fc9KUzS6ZJxvDc_RfL-hoWOVxo-azELU@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] OAuth 2 for Native Apps X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 26 Jun 2010 05:33:05 -0000 comment/question regarding the Embedded Browser scenario: Is the URL bar and SSL verification symbols (lock + green bar) visible in that scenario? Otherwise, the user has no chance to verify the identity of the IDP/OAuth server. So there might be problems regarding password phishing . regards, Torsten. Am 22.06.2010 02:54, schrieb Marius Scurtescu: > Here is the wiki page: http://wiki.oauth.net/OAuth-2-for-Native-Apps > > Feel free to edit or comment. > > Marius > > > > On Wed, Jun 9, 2010 at 10:59 AM, David Recordon<recordond@gmail.com> wrote: > >> Want to put this on the wiki http://wiki.oauth.net/? >> >> >> On Mon, Jun 7, 2010 at 12:25 PM, Marius Scurtescu<mscurtescu@google.com> wrote: >> >>> Hi, >>> >>> I attached a document that summaries how native applications can use OAuth 2. >>> >>> Feedback more than welcome, especially if you have experience with >>> native apps and OAuth. >>> >>> The current Web Server and Device flows need small changes and >>> clarifications in order to properly support native apps, I will start >>> a separate thread on that. >>> >>> Marius >>> >>> _______________________________________________ >>> OAuth mailing 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 torsten@lodderstedt.net Fri Jun 25 23:09:35 2010 Return-Path: <torsten@lodderstedt.net> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57B6F3A635F for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 23:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.598 X-Spam-Level: X-Spam-Status: No, score=-1.598 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YpnoNgMQK4sm for <oauth@core3.amsl.com>; Fri, 25 Jun 2010 23:09:33 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.14]) by core3.amsl.com (Postfix) with ESMTP id EFA603A67D0 for <oauth@ietf.org>; Fri, 25 Jun 2010 23:09:32 -0700 (PDT) Received: from [80.187.100.84] (helo=[10.198.192.84]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from <torsten@lodderstedt.net>) id 1OSOa4-0008Oo-MG; Sat, 26 Jun 2010 08:09:34 +0200 References: <7C01E631FF4B654FA1E783F1C0265F8C579C6DC3@TK5EX14MBXC117.redmond.corp.microsoft.com> <C8479A94.363F3%eran@hueniverse.com> <7C01E631FF4B654FA1E783F1C0265F8C579C6E52@TK5EX14MBXC117.redmond.corp.microsoft.com> Message-Id: <CDD1DDBF-BD1B-4F4E-8620-AA2FEC402C90@lodderstedt.net> From: Torsten Lodderstedt <torsten@lodderstedt.net> To: Yaron Goland <yarong@microsoft.com> In-Reply-To: <7C01E631FF4B654FA1E783F1C0265F8C579C6E52@TK5EX14MBXC117.redmond.corp.microsoft.com> Content-Type: multipart/alternative; boundary=Apple-Mail-27-725117780 Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7E18) Mime-Version: 1.0 (iPhone Mail 7E18) Date: Sat, 26 Jun 2010 08:09:01 +0200 X-Df-Sender: 141509 Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] OAuth discovery draft? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 26 Jun 2010 06:09:35 -0000 --Apple-Mail-27-725117780 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable I think it should be possible to discover a resource's OAuth server =20 and its capabilities using a direct Discovery request. I don't think a =20= WWW-Authenticate Header is the right representation for this kind of =20 data. What about a JSON or XML document returned in response to an =20 OPTIONS request (as you suggested) or a GET request with a certain =20 content type in its ACCEPT Header? regards, Torsten. Am 23.06.2010 um 20:20 schrieb Yaron Goland <yarong@microsoft.com>: > No objections on my part. I would rather have a smaller core spec =20 > with features that everyone agrees on. > > > > BTW, a thought for the discovery draft =E2=80=93 RFC 2616/2617 only = defines =20 > www-authenticate=E2=80=99s semantics in the context of a 401. It=E2=80=99= s =20 > unclear from the draft what it would mean to return a www-authentica=20= > te header on a 200 response. The reason I care about this is that I =20= > think it makes sense that if someone wants to talk to an endpoint th=20= > ey know supports OAuth and need to know where their token issuer loc=20= > ation is they would want to fire off an OPTIONS request to the resou=20= > rce and find out from the response where the issuer is and what real=20= > m is being used. It seems to me that the simplest way to solve this =20= > problem is to just return www-authenticate on a 200 response to an O=20= > PTIONS request. > > > > Thoughts? > > > > Thanks, > > > > Yaron > > > > From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] > Sent: Wednesday, June 23, 2010 11:04 AM > To: Yaron Goland; James Manger; OAuth WG > Subject: Re: OAuth discovery draft? > > > > I think the core work is pretty stable now, unlike the discovery =20 > bits which (while simple) are not enjoying the same level of =20 > consensus. I think it is much more practical to propose them as a =20 > separate document and perhaps consider merging them later on when =20 > they reach an equal level of stability. But overall, I=E2=80=99m not = too wor=20 > ries about multiple documents. > > EHL > > > On 6/23/10 11:00 AM, "Yaron Goland" <yarong@microsoft.com> wrote: > > I've been noodling [1] a lot about full delegation in OAuth [2] and =20= > one of the issues that came out of that was the need for discovering =20= > both the location and realm of an endpoint's token server. But at =20 > least for my use cases (which consist of walking up to a service and =20= > making an options request and getting back a www-authenticate =20 > header) all I need back is a realm and a token server URL. In other =20= > words just having one argument added to our www-authenticate header =20= > would be enough to solve the case where someone wants to walk up to =20= > a service and find out where its token server is. Does that really =20 > need its own spec? Or can we just add an argument to www-=20 > authenticate in the current spec? > Thanks, > Yaron > > [1] See http://www.goland.org/oauthgenericdelegation/ for an =20 > overview of my thinking on full delegation in OAuth. At the very end =20= > are links to a bunch of other much more in-depth articles on =20 > particular subjects touched on in the main article. > > [2] I define 'full delegation' as "User X of Service Y grants =20 > permission Z to User A of Service B". Currently OAuth requires X =3D=3D = =20 > A. In the future I hope to see extensions to OAuth that enable what =20= > I'm terming 'full delegation'. But personally I'm really happy that =20= > OAuth has the X=3D=3DA restriction. It simplifies a whole host of = issues =20 > and satisfies a really important use case. > > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On =20 > Behalf > > Of Eran Hammer-Lahav > > Sent: Monday, June 21, 2010 9:50 PM > > To: Manger, James H; OAuth WG (oauth@ietf.org) > > Subject: Re: [OAUTH-WG] OAuth discovery draft? > > > > Yes, it's on my desk and not yet ready, but I am working on one. =20 > It includes > > your sites proposal among other things. I am trying to get the =20 > core spec > > stable this week and focus on that next. > > > > EHL > > > > > -----Original Message----- > > > From: Manger, James H [mailto:James.H.Manger@team.telstra.com] > > > Sent: Monday, June 21, 2010 8:03 PM > > > To: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org) > > > Subject: OAuth discovery draft? > > > > > > Eran, > > > > > > There have been a few mentions recently of an OAuth discovery =20 > draft. > > > Is there any such draft yet, or is this just a part that we know =20= > needs > > > to be done? > > > > > > The email on "OAuth meeting notes on -05 (with updates)" said: > > > > > > >> 6.1.1. - describing the WWW-Authenticate response header > > > >> > > > >> - Discovery needed for various elements > > > > > > > > Yes. That's for the discovery draft. > > > > > > > > > A wiki page on "Future OpenID Technical Requirements" > > > <http://wiki.openid.net/Future-OpenID-Technical-Requirements> =20 > says: > > > > > > > 6) IdP Discovery > > > > > > > > * Much of this will be covered by OAuth2 Discovery, > > > > however OIC may need to define OpenID specific features. > > > >=E2=80=A6 > > > > 17) Simpler discovery > > > > > > > > * See Eran's OAuth Discovery proposal > > > > > > > > > There was an OAuth 1.0 Discovery draft over 2 years ago, but =20 > that is tagged: > > > "expired", "marked as obsolete by its author", "discouraged from > > > implementing", "no update is expected", "replaced by the OAuth 2.0 > > effort". > > > > > > I know I should write a discovery draft myself. > > > > > > -- > > > James Manger > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-27-725117780 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><body bgcolor=3D"#FFFFFF"><div>I think it should be possible to = discover a resource's OAuth server and its capabilities using a direct = Discovery request. I don't think a WWW-Authenticate Header is the right = representation for this kind of data. What about a JSON or XML document = returned in response to an OPTIONS r<span class=3D"Apple-style-span" = style=3D"-webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); = -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); = -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); ">equest = (as you suggested) or a GET request with a certain content type in its = ACCEPT = Header?</span></div><div><br></div><div>regards,</div><div>Torsten. <= br><br><br></div><div><br>Am 23.06.2010 um 20:20 schrieb Yaron Goland = <<a = href=3D"mailto:yarong@microsoft.com">yarong@microsoft.com</a>>:<br><br>= </div><div></div><blockquote type=3D"cite"><div> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><span = style=3D"font-size:11.0pt;font-family:"Calibri","sans-serif= ";color:#1F497D">No objections on my part. I would rather have a = smaller core spec with features that everyone agrees = on.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span = style=3D"font-size:11.0pt;font-family:"Calibri","sans-serif= ";color:#1F497D"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span = style=3D"font-size:11.0pt;font-family:"Calibri","sans-serif= ";color:#1F497D">BTW, a thought for the discovery draft =E2=80=93 = RFC 2616/2617 only defines www-authenticate=E2=80=99s semantics in the = context of a 401. It=E2=80=99s unclear from the draft what it would mean to return a www-authenticate header on a 200 response. The = reason I care about this is that I think it makes sense that if someone = wants to talk to an endpoint they know supports OAuth and need to know = where their token issuer location is they would want to fire off an OPTIONS request to the resource and find out from = the response where the issuer is and what realm is being used. It seems = to me that the simplest way to solve this problem is to just return = www-authenticate on a 200 response to an OPTIONS request. <o:p></o:p></span></p> <p class=3D"MsoNormal"><span = style=3D"font-size:11.0pt;font-family:"Calibri","sans-serif= ";color:#1F497D"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span = style=3D"font-size:11.0pt;font-family:"Calibri","sans-serif= ";color:#1F497D">        &nbs= p;       Thoughts?<o:p></o:p></span></p> <p class=3D"MsoNormal"><span = style=3D"font-size:11.0pt;font-family:"Calibri","sans-serif= ";color:#1F497D"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span = style=3D"font-size:11.0pt;font-family:"Calibri","sans-serif= ";color:#1F497D">        &nbs= p;            =            = Thanks,<o:p></o:p></span></p> <p class=3D"MsoNormal"><span = style=3D"font-size:11.0pt;font-family:"Calibri","sans-serif= ";color:#1F497D"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span = style=3D"font-size:11.0pt;font-family:"Calibri","sans-serif= ";color:#1F497D">        &nbs= p;            =             &n= bsp;           &nbs= p;  Yaron<o:p></o:p></span></p> <p class=3D"MsoNormal"><span = style=3D"font-size:11.0pt;font-family:"Calibri","sans-serif= ";color:#1F497D"><o:p> </o:p></span></p> <div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in = 0in 4.0pt"> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt = 0in 0in 0in"> <p class=3D"MsoNormal"><b><span = style=3D"font-size:10.0pt;font-family:"Tahoma","sans-serif&= quot;">From:</span></b><span = style=3D"font-size:10.0pt;font-family:"Tahoma","sans-serif&= quot;"> Eran Hammer-Lahav [mailto:eran@hueniverse.com] <br> <b>Sent:</b> Wednesday, June 23, 2010 11:04 AM<br> <b>To:</b> Yaron Goland; James Manger; OAuth WG<br> <b>Subject:</b> Re: OAuth discovery draft?<o:p></o:p></span></p> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><span = style=3D"font-size:11.0pt;font-family:"Calibri","sans-serif= "">I think the core work is pretty stable now, unlike the discovery = bits which (while simple) are not enjoying the same level of consensus. = I think it is much more practical to propose them as a separate document and = perhaps consider merging them later on when they reach an equal level of = stability. But overall, I=E2=80=99m not too worries about multiple = documents.<br> <br> EHL<br> <br> <br> On 6/23/10 11:00 AM, "Yaron Goland" <<a = href=3D"yarong@microsoft.com"><a = href=3D"mailto:yarong@microsoft.com">yarong@microsoft.com</a></a>> = wrote:</span><o:p></o:p></p> <p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><span = style=3D"font-size:11.0pt;font-family:"Calibri","sans-serif= "">I've been noodling [1] a lot about full delegation in OAuth [2] = and one of the issues that came out of that was the need for discovering = both the location and realm of an endpoint's token server. But at least for = my use cases (which consist of walking up to a service and making an = options request and getting back a www-authenticate header) all I need = back is a realm and a token server URL. In other words just having one argument added to our www-authenticate header = would be enough to solve the case where someone wants to walk up to a = service and find out where its token server is. Does that really need = its own spec? Or can we just add an argument to www-authenticate in the current spec?<br>         Thanks,<br> =             &n= bsp;   Yaron<br> <br> [1] See <a href=3D"http://www.goland.org/oauthgenericdelegation/"><a = href=3D"http://www.goland.org/oauthgenericdelegation/">http://www.goland.o= rg/oauthgenericdelegation/</a></a> for an overview of my thinking on = full delegation in OAuth. At the very end are links to a bunch of other = much more in-depth articles on particular subjects touched on in the main article.<br> <br> [2] I define 'full delegation' as "User X of Service Y grants permission = Z to User A of Service B". Currently OAuth requires X =3D=3D A. In the = future I hope to see extensions to OAuth that enable what I'm terming = 'full delegation'. But personally I'm really happy that OAuth has the X=3D=3DA restriction. It simplifies a whole host of = issues and satisfies a really important use case.<br> <br> > -----Original Message-----<br> > From: <a href=3D"oauth-bounces@ietf.org"><a = href=3D"mailto:oauth-bounces@ietf.org">oauth-bounces@ietf.org</a></a> = [<a href=3D"mailto:oauth-bounces@ietf.org"><a = href=3D"mailto:oauth-bounces@ietf.org">mailto:oauth-bounces@ietf.org</a></= a>] On Behalf<br> > Of Eran Hammer-Lahav<br> > Sent: Monday, June 21, 2010 9:50 PM<br> > To: Manger, James H; OAuth WG (<a href=3D"oauth@ietf.org"><a = href=3D"mailto:oauth@ietf.org">oauth@ietf.org</a></a>)<br> > Subject: Re: [OAUTH-WG] OAuth discovery draft?<br> ><br> > Yes, it's on my desk and not yet ready, but I am working on one. It = includes<br> > your sites proposal among other things. I am trying to get the core = spec<br> > stable this week and focus on that next.<br> ><br> > EHL<br> ><br> > > -----Original Message-----<br> > > From: Manger, James H [<a = href=3D"mailto:James.H.Manger@team.telstra.com"><a = href=3D"mailto:James.H.Manger@team.telstra.com">mailto:James.H.Manger@team= .telstra.com</a></a>]<br> > > Sent: Monday, June 21, 2010 8:03 PM<br> > > To: Eran Hammer-Lahav; OAuth WG (<a href=3D"oauth@ietf.org"><a = href=3D"mailto:oauth@ietf.org">oauth@ietf.org</a></a>)<br> > > Subject: OAuth discovery draft?<br> > ><br> > > Eran,<br> > ><br> > > There have been a few mentions recently of an OAuth discovery = draft.<br> > > Is there any such draft yet, or is this just a part that we = know needs<br> > > to be done?<br> > ><br> > > The email on "OAuth meeting notes on -05 (with updates)" = said:<br> > ><br> > > >> 6.1.1. - describing the WWW-Authenticate response = header<br> > > >><br> > > >> - Discovery needed for various elements<br> > > ><br> > > > Yes. That's for the discovery draft.<br> > ><br> > ><br> > > A wiki page on "Future OpenID Technical Requirements"<br> > > <<a = href=3D"http://wiki.openid.net/Future-OpenID-Technical-Requirements"><a = href=3D"http://wiki.openid.net/Future-OpenID-Technical-Requirements">http:= //wiki.openid.net/Future-OpenID-Technical-Requirements</a></a>> = says:<br> > ><br> > > > 6) IdP Discovery<br> > > ><br> > > >    * Much of this will be covered by = OAuth2 Discovery,<br> > > >      however OIC may need to = define OpenID specific features.<br> > > >=E2=80=A6<br> > > > 17) Simpler discovery<br> > > ><br> > > >    * See Eran's OAuth Discovery = proposal<br> > ><br> > ><br> > > There was an OAuth 1.0 Discovery draft over 2 years ago, but = that is tagged:<br> > > "expired", "marked as obsolete by its author", "discouraged = from<br> > > implementing", "no update is expected", "replaced by the OAuth = 2.0<br> > effort".<br> > ><br> > > I know I should write a discovery draft myself.<br> > ><br> > > --<br> > > James Manger<br> > _______________________________________________<br> > OAuth mailing list<br> > <a href=3D"OAuth@ietf.org"><a = href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a></a><br> > <a href=3D"https://www.ietf.org/mailman/listinfo/oauth"><a = href=3D"https://www.ietf.org/mailman/listinfo/oauth">https://www.ietf.org/= mailman/listinfo/oauth</a></a></span><o:p></o:p></p> </div> </div> </div></blockquote><blockquote = type=3D"cite"><div><span>_______________________________________________</= span><br><span>OAuth mailing list</span><br><span><a = href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a></span><br><span><a = href=3D"https://www.ietf.org/mailman/listinfo/oauth">https://www.ietf.org/= mailman/listinfo/oauth</a></span><br></div></blockquote></body></html>= --Apple-Mail-27-725117780-- From andrewarnott@gmail.com Sat Jun 26 07:02:45 2010 Return-Path: <andrewarnott@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5196828C0CF for <oauth@core3.amsl.com>; Sat, 26 Jun 2010 07:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.79 X-Spam-Level: X-Spam-Status: No, score=-0.79 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kx+1qj7orALQ for <oauth@core3.amsl.com>; Sat, 26 Jun 2010 07:02:44 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id 72EC028C0CE for <oauth@ietf.org>; Sat, 26 Jun 2010 07:02:44 -0700 (PDT) Received: by pxi16 with SMTP id 16so535828pxi.31 for <oauth@ietf.org>; Sat, 26 Jun 2010 07:02:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=vWj55JCDJL3fEIlIuDt7zD+Yf3BzboTEBpVIMe9BkNg=; b=FYRTOKI/I1YBPOw6+R9Zi1Eiqj+1mFw6WJ6Wr3yVnPbTs8JMcig8KZSMydWvWaVnbq u8NAE1wcXCe0ZVxsaXy8GPUgIlKPsLuTrNKHA+dueKJpa7lMx0FUd6PxFeXayqB5TYWh wjb8/zMd3u3TANOVpFfWT8dK9YLGxCJ/d3ukI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=X7MnCX3gRUIG+lWfALtYYvY1/Pc6fbjIaG8lAw6SqyP7I+LqBZUJHm1tk9MlR2tSGH EU+KA/GtjdC00QeQ8tbBEKtFTz4bnbQK+nDqXFtvBQnWAu/uT8wWu9AVYPOaNdIJHo6i XqnKfwtlddPb7iTEOl5YnJKw4EVdUzFagkxEs= MIME-Version: 1.0 Received: by 10.115.133.39 with SMTP id k39mr2530393wan.198.1277560971347; Sat, 26 Jun 2010 07:02:51 -0700 (PDT) Received: by 10.114.67.10 with HTTP; Sat, 26 Jun 2010 07:02:51 -0700 (PDT) Date: Sat, 26 Jun 2010 07:02:51 -0700 Message-ID: <AANLkTilHhGQvsuvxfFF1e6zhOL7ldiqCHlrbuX47KBPV@mail.gmail.com> From: Andrew Arnott <andrewarnott@gmail.com> To: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org> Content-Type: multipart/alternative; boundary=0016e6477a94e046690489ef57af Subject: [OAUTH-WG] Basic questions about using the HTTP Authorization header X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 26 Jun 2010 14:02:45 -0000 --0016e6477a94e046690489ef57af Content-Type: text/plain; charset=ISO-8859-1 Can anyone point me to good reference material for understanding the Authorization header in Section 5.1 of the OAuth 2.0 draft 8 spec<http://tools.ietf.org/id/draft-ietf-oauth-v2-08.html#authz_header> and the WWW-Authenticate section 6? Specifically, some questions I have are: 1. How to properly escape the access token for inclusion in the header? (suppose a linefeed or null character were in the token... how to escape that?) 2. What do RWS and OWS stand for? 3. What is the "realm" value? Is the "service" string that is always set as its value a literal, or a placeholder? What are some actual values that might appear? I'm sure there's an RFC out there that describes all this stuff. RFC 2617 is mentioned as a source for some of this, but "RWS" doesn't show up anywhere in that RFC, for example, so I'm not sure where the best place is to look this up in. Thanks. -- 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 --0016e6477a94e046690489ef57af Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Can anyone point me to good reference material for understanding the Author= ization header in=A0<a href=3D"http://tools.ietf.org/id/draft-ietf-oauth-v2= -08.html#authz_header">Section 5.1 of the OAuth 2.0 draft 8 spec</a>=A0and = the WWW-Authenticate section 6?<div> <br></div><div>Specifically, some questions I have are:</div><div><ol><li>H= ow to properly escape the access token for inclusion in the header? (suppos= e a linefeed or null character were in the token... how to escape that?)</l= i> <li>What do RWS and OWS stand for?</li><li>What is the "realm" va= lue? Is the "service" string that is always set as its value a li= teral, or a placeholder? =A0What are some actual values that might appear?<= /li> </ol><div>I'm sure there's an RFC out there that describes all this= stuff. =A0RFC 2617 is mentioned as a source for some of this, but "RW= S" doesn't show up anywhere in that RFC, for example, so I'm n= ot sure where the best place is to look this up in.</div> <div><br></div><div>Thanks.</div>--<br>Andrew Arnott<br>"I [may] not a= gree with what you have to say, but I'll defend to the death your right= to say it." - S. G. Tallentyre<br> </div> --0016e6477a94e046690489ef57af-- From wmills@yahoo-inc.com Sat Jun 26 09:46:30 2010 Return-Path: <wmills@yahoo-inc.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75ADF3A6951 for <oauth@core3.amsl.com>; Sat, 26 Jun 2010 09:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.2 X-Spam-Level: X-Spam-Status: No, score=-17.2 tagged_above=-999 required=5 tests=[AWL=0.398, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FBFZQEpCD0yN for <oauth@core3.amsl.com>; Sat, 26 Jun 2010 09:46:29 -0700 (PDT) Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) by core3.amsl.com (Postfix) with ESMTP id 38A4A3A694E for <oauth@ietf.org>; Sat, 26 Jun 2010 09:46:29 -0700 (PDT) Received: from SNV-EXPF01.ds.corp.yahoo.com (snv-expf01.ds.corp.yahoo.com [207.126.227.250]) by mrout3.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o5QGg6cr083345; Sat, 26 Jun 2010 09:42:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:x-mimeole:content-class:mime-version: content-type:subject:date:message-id:in-reply-to:x-ms-has-attach: x-ms-tnef-correlator:thread-topic:thread-index:references:from:to:return-path:x-originalarrivaltime; b=gz9QNeWPe9yyodmtIN9lepQ+wHqLBXlCDqf4BRs9l8DtHAzmOCoKV6dRA4vg2m3w Received: from SNV-EXVS08.ds.corp.yahoo.com ([207.126.227.8]) by SNV-EXPF01.ds.corp.yahoo.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 26 Jun 2010 09:42:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB154E.82C07D78" Date: Sat, 26 Jun 2010 09:42:05 -0700 Message-ID: <012AB2B223CB3F4BB846962876F47217059B6711@SNV-EXVS08.ds.corp.yahoo.com> In-Reply-To: <AANLkTilHhGQvsuvxfFF1e6zhOL7ldiqCHlrbuX47KBPV@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] Basic questions about using the HTTP Authorization header Thread-Index: AcsVOLTCMyD2OhGXQqyYNaZ4vhN/0QAE+xpA References: <AANLkTilHhGQvsuvxfFF1e6zhOL7ldiqCHlrbuX47KBPV@mail.gmail.com> From: "William Mills" <wmills@yahoo-inc.com> To: "Andrew Arnott" <andrewarnott@gmail.com>, <oauth@ietf.org> X-OriginalArrivalTime: 26 Jun 2010 16:42:06.0003 (UTC) FILETIME=[8305F830:01CB154E] Subject: Re: [OAUTH-WG] Basic questions about using the HTTP Authorization header X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 26 Jun 2010 16:46:31 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB154E.82C07D78 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable I don't remember where I found it before, but OWS is Optional White Space, and RWS is Required White Space. There is also no BNF to define access_token or refresh_token. =20 =20 For this spec to be implementable "all this stuff" has to be explicitly defined.... =20 ________________________________ From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Andrew Arnott Sent: Saturday, June 26, 2010 7:03 AM To: OAuth WG (oauth@ietf.org) Subject: [OAUTH-WG] Basic questions about using the HTTP Authorization header =09 =09 Can anyone point me to good reference material for understanding the Authorization header in Section 5.1 of the OAuth 2.0 draft 8 spec <http://tools.ietf.org/id/draft-ietf-oauth-v2-08.html#authz_header> and the WWW-Authenticate section 6?=20 Specifically, some questions I have are: 1. How to properly escape the access token for inclusion in the header? (suppose a linefeed or null character were in the token... how to escape that?)=20 2. What do RWS and OWS stand for?=20 3. What is the "realm" value? Is the "service" string that is always set as its value a literal, or a placeholder? What are some actual values that might appear?=20 I'm sure there's an RFC out there that describes all this stuff. RFC 2617 is mentioned as a source for some of this, but "RWS" doesn't show up anywhere in that RFC, for example, so I'm not sure where the best place is to look this up in. Thanks. -- 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 =09 ------_=_NextPart_001_01CB154E.82C07D78 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META content=3D"text/html; charset=3Dus-ascii" = http-equiv=3DContent-Type> <META name=3DGENERATOR content=3D"MSHTML 8.00.6001.18904"></HEAD> <BODY> <DIV dir=3Dltr align=3Dleft><SPAN class=3D600372816-26062010><FONT = color=3D#0000ff=20 size=3D2 face=3DArial>I don't remember where I found it before, but OWS = is Optional=20 White Space, and RWS is Required White Space.  There is also no BNF = to=20 define access_token or refresh_token.  </FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D600372816-26062010><FONT = color=3D#0000ff=20 size=3D2 face=3DArial></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D600372816-26062010><FONT = color=3D#0000ff=20 size=3D2 face=3DArial>For this spec to be implementable "all this stuff" = has to be=20 explicitly defined....</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D600372816-26062010><FONT = color=3D#0000ff=20 size=3D2 face=3DArial></FONT></SPAN> </DIV><BR> <BLOCKQUOTE=20 style=3D"BORDER-LEFT: #0000ff 2px solid; PADDING-LEFT: 5px; MARGIN-LEFT: = 5px; MARGIN-RIGHT: 0px"=20 dir=3Dltr> <DIV dir=3Dltr lang=3Den-us class=3DOutlookMessageHeader align=3Dleft> <HR tabIndex=3D-1> <FONT size=3D2 face=3DTahoma><B>From:</B> oauth-bounces@ietf.org=20 [mailto:oauth-bounces@ietf.org] <B>On Behalf Of </B>Andrew=20 Arnott<BR><B>Sent:</B> Saturday, June 26, 2010 7:03 AM<BR><B>To:</B> = OAuth WG=20 (oauth@ietf.org)<BR><B>Subject:</B> [OAUTH-WG] Basic questions about = using the=20 HTTP Authorization header<BR></FONT><BR></DIV> <DIV></DIV>Can anyone point me to good reference material for = understanding=20 the Authorization header in <A=20 = href=3D"http://tools.ietf.org/id/draft-ietf-oauth-v2-08.html#authz_header= ">Section=20 5.1 of the OAuth 2.0 draft 8 spec</A> and the WWW-Authenticate = section 6? <DIV><BR></DIV> <DIV>Specifically, some questions I have are:</DIV> <DIV> <OL> <LI>How to properly escape the access token for inclusion in the = header?=20 (suppose a linefeed or null character were in the token... how to = escape=20 that?)=20 <LI>What do RWS and OWS stand for? <LI>What is the "realm" value? Is the "service" string that is = always set as=20 its value a literal, or a placeholder?  What are some actual = values=20 that might appear? </LI></OL> <DIV>I'm sure there's an RFC out there that describes all this stuff.=20  RFC 2617 is mentioned as a source for some of this, but "RWS" = doesn't=20 show up anywhere in that RFC, for example, so I'm not sure where the = best=20 place is to look this up in.</DIV> <DIV><BR></DIV> <DIV>Thanks.</DIV>--<BR>Andrew Arnott<BR>"I [may] not agree with what = you have=20 to say, but I'll defend to the death your right to say it." - S. G.=20 Tallentyre<BR></DIV></BLOCKQUOTE></BODY></HTML> ------_=_NextPart_001_01CB154E.82C07D78-- From torsten@lodderstedt.net Sat Jun 26 14:16:49 2010 Return-Path: <torsten@lodderstedt.net> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BC913A688C for <oauth@core3.amsl.com>; Sat, 26 Jun 2010 14:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.616 X-Spam-Level: X-Spam-Status: No, score=-0.616 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_05=-1.11, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZkA51vvc4p8 for <oauth@core3.amsl.com>; Sat, 26 Jun 2010 14:16:48 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.38]) by core3.amsl.com (Postfix) with ESMTP id DA0D33A6885 for <oauth@ietf.org>; Sat, 26 Jun 2010 14:16:47 -0700 (PDT) Received: from p4fff0ef0.dip.t-dialin.net ([79.255.14.240] helo=[127.0.0.1]) by smtprelay04.ispgateway.de with esmtpa (Exim 4.68) (envelope-from <torsten@lodderstedt.net>) id 1OSckB-0000t2-BK; Sat, 26 Jun 2010 23:16:55 +0200 Message-ID: <4C266E45.70603@lodderstedt.net> Date: Sat, 26 Jun 2010 23:16:53 +0200 From: Torsten Lodderstedt <torsten@lodderstedt.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Dirk Balfanz <balfanz@google.com> References: <AANLkTingCgO-o3XRZbxYoD8U2rRTO-EgWcfg2hBlbQHm@mail.gmail.com> In-Reply-To: <AANLkTingCgO-o3XRZbxYoD8U2rRTO-EgWcfg2hBlbQHm@mail.gmail.com> Content-Type: multipart/alternative; boundary="------------090503060000050204060900" X-Df-Sender: 141509 Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] proposal for signatures X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 26 Jun 2010 21:16:49 -0000 This is a multi-part message in MIME format. --------------090503060000050204060900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit would your proposal allow to issue and use HMAC Verification Keys in the same way as the "old" token secrets, i.e. an AS would issue such keys along with tokens to the OAuth client? A special key id could be used to indicate this scenario. regards, Torsten. Am 21.06.2010 09:04, schrieb Dirk Balfanz: > Hi guys, > > I think I owe the list a proposal for signatures. > > I wrote something down that liberally borrows ideas from Magic > Signatures > <http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-00.html>, > SWT <http://groups.google.com/group/WRAP-WG/files>, and (even the name > from) JSON Web Tokens > <https://groups.google.com/group/WRAP-WG/browse_thread/thread/a99369c4b74d4cd0#>. > > > Here is a short document (called "JSON Tokens") that just explains how > to sign something and verify the signature: > http://docs.google.com/document/pub?id=1kv6Oz_HRnWa0DaJx_SQ5Qlk_yqs_7zNAm75-FmKwNo4 > > Here is an extension of JSON Tokens that can be used for signed OAuth > tokens: > http://docs.google.com/document/pub?id=1JUn3Twd9nXwFDgi-fTKl-unDG_ndyowTZW8OWX9HOUU > > Here is a different extension of JSON Tokens that can be used for > 2-legged flows. The idea is that this could be used as a drop-in > replacement for SAML assertions in the OAuth2 assertion flow: > http://docs.google.com/document/pub?id=1s4kjRS9P0frG0ulhgP3He01ONlxeTwkFQV_pCoOowzc > > I also have started to write some code > <http://code.google.com/p/jsontoken/source/browse/#svn/trunk/src/main/java/net/oauth/signatures> > to implement this as a proof-of-concept. > > Thoughts? Comments? > > Dirk. > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --------------090503060000050204060900 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> would your proposal allow to issue and use HMAC Verification Keys in the same way as the "old" token secrets, i.e. an AS would issue such keys along with tokens to the OAuth client? A special key id could be used to indicate this scenario.<br> <br> regards,<br> Torsten.<br> <br> Am 21.06.2010 09:04, schrieb Dirk Balfanz: <blockquote cite="mid:AANLkTingCgO-o3XRZbxYoD8U2rRTO-EgWcfg2hBlbQHm@mail.gmail.com" type="cite"><span id="goog_1009121601"></span><span id="goog_1009121602"></span><span id="goog_1009121605"></span><span id="goog_1009121606"></span>Hi guys,  <div><br> </div> <div>I think I owe the list a proposal for signatures.</div> <div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><span class="Apple-style-span" style="border-collapse: separate;"><br> </span></span></font></div> <div><span class="Apple-style-span" style="font-family: arial,sans-serif; font-size: 13px; border-collapse: collapse;">I wrote something down that </span><span class="Apple-style-span" style="font-family: arial,sans-serif; font-size: 13px; border-collapse: collapse;">liberally </span><span class="Apple-style-span" style="font-family: arial,sans-serif; font-size: 13px; border-collapse: collapse;">borrows ideas from <a moz-do-not-send="true" href="http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-00.html">Magic Signatures</a>, <a moz-do-not-send="true" href="http://groups.google.com/group/WRAP-WG/files">SWT</a>, and (even the name from) <span class="Apple-style-span" style="border-collapse: separate; font-size: small;"><a moz-do-not-send="true" href="https://groups.google.com/group/WRAP-WG/browse_thread/thread/a99369c4b74d4cd0#">JSON Web Tokens</a></span>. </span></div> <meta charset="utf-8"> <div><span class="Apple-style-span" style="font-family: arial,sans-serif; font-size: 13px; border-collapse: collapse;"><br> </span><span class="Apple-style-span" style="font-family: arial,sans-serif; font-size: 13px; border-collapse: collapse;">Here is a short document (called "JSON Tokens") that just explains how to sign something and verify the signature:</span><span class="Apple-style-span" style="font-family: arial,sans-serif; font-size: 13px; border-collapse: collapse;"><br> </span><span class="Apple-style-span" style="font-family: arial,sans-serif; font-size: 13px; border-collapse: collapse;"><a moz-do-not-send="true" href="http://docs.google.com/document/pub?id=1kv6Oz_HRnWa0DaJx_SQ5Qlk_yqs_7zNAm75-FmKwNo4" target="_blank" style="color: rgb(119, 153, 187);">http://docs.google.com/document/pub?id=1kv6Oz_HRnWa0DaJx_SQ5Qlk_yqs_7zNAm75-FmKwNo4</a></span><span class="Apple-style-span" style="font-family: arial,sans-serif; font-size: 13px; border-collapse: collapse;"><br> </span><span class="Apple-style-span" style="font-family: arial,sans-serif; font-size: 13px; border-collapse: collapse;"><br> </span><span class="Apple-style-span" style="font-family: arial,sans-serif; font-size: 13px; border-collapse: collapse;">Here is an extension of JSON Tokens that can be used for signed OAuth tokens:</span></div> <div><span class="Apple-style-span" style="font-family: arial,sans-serif; font-size: 13px; border-collapse: collapse;"><a moz-do-not-send="true" href="http://docs.google.com/document/pub?id=1JUn3Twd9nXwFDgi-fTKl-unDG_ndyowTZW8OWX9HOUU" target="_blank" style="color: rgb(119, 153, 187);">http://docs.google.com/document/pub?id=1JUn3Twd9nXwFDgi-fTKl-unDG_ndyowTZW8OWX9HOUU</a></span></div> <div><br> </div> <div><span class="Apple-style-span" style="font-family: arial,sans-serif; font-size: 13px; border-collapse: collapse;">Here is a different extension of JSON Tokens that can be used for 2-legged flows. The idea is that this could be used as a drop-in replacement for SAML assertions in the OAuth2 assertion flow:</span><span class="Apple-style-span" style="font-family: arial,sans-serif; font-size: 13px; border-collapse: collapse;"><br> </span><span class="Apple-style-span" style="font-family: arial,sans-serif; font-size: 13px; border-collapse: collapse;"><a moz-do-not-send="true" href="http://docs.google.com/document/pub?id=1s4kjRS9P0frG0ulhgP3He01ONlxeTwkFQV_pCoOowzc" target="_blank" style="color: rgb(119, 153, 187);">http://docs.google.com/document/pub?id=1s4kjRS9P0frG0ulhgP3He01ONlxeTwkFQV_pCoOowzc</a></span></div> <div><br> </div> <div>I also have started to write <a moz-do-not-send="true" href="http://code.google.com/p/jsontoken/source/browse/#svn/trunk/src/main/java/net/oauth/signatures">some code</a> to implement this as a proof-of-concept. <br> <br> </div> <div>Thoughts? Comments?</div> <div><br> Dirk.</div> <div><br> </div> <pre wrap=""> <fieldset class="mimeAttachmentHeader"></fieldset> _______________________________________________ OAuth mailing list <a class="moz-txt-link-abbreviated" href="mailto:OAuth@ietf.org">OAuth@ietf.org</a> <a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/oauth">https://www.ietf.org/mailman/listinfo/oauth</a> </pre> </blockquote> </body> </html> --------------090503060000050204060900-- From sayrer@gmail.com Sun Jun 27 13:46:20 2010 Return-Path: <sayrer@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03D873A69E9 for <oauth@core3.amsl.com>; Sun, 27 Jun 2010 13:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lwXu+sxksAkV for <oauth@core3.amsl.com>; Sun, 27 Jun 2010 13:46:09 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id B2D643A67EF for <oauth@ietf.org>; Sun, 27 Jun 2010 13:46:08 -0700 (PDT) Received: by qwe5 with SMTP id 5so1307378qwe.31 for <oauth@ietf.org>; Sun, 27 Jun 2010 13:46:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=A/E7hP8nIJYscOilifsjSE9A0KByJNZN5wMHMetFbk0=; b=VHJZiFlhaDYURhfigJ60OoHyCaYnV4TLh/tuidBaw4cT3RMJjFigUht9iBQsHYUydJ hAZD7LDDHhz7jcjPRBZjdlU/ON8QApj+CMI7IgCW8QOhbgBvfVNsnqvSK24+wcN8J4WJ /RyzAH4JL3CjabvQ+6KGW4MQWDndswfYcqA/c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=gkrUVp2OYjTg5yFQZ6wBoHjftb04QtI7ZYkcWNqyu2q4RaZOQbSl8wVSptKDf+UVx3 LqghBvc9OyJGWCYBeSQsposIH01Vh5z8SiWwkw0xarB9SkDD+1yC4jUzD8EnVIgbRWm7 UqFXQuLSDclDyIbHzlLgi+gc2oBipcN9Gi9x4= MIME-Version: 1.0 Received: by 10.229.223.140 with SMTP id ik12mr2036214qcb.50.1277671575517; Sun, 27 Jun 2010 13:46:15 -0700 (PDT) Received: by 10.229.97.8 with HTTP; Sun, 27 Jun 2010 13:46:15 -0700 (PDT) Date: Sun, 27 Jun 2010 13:46:15 -0700 Message-ID: <AANLkTimgJSdxjfz7kY1a3zSaK9QQCtxVzVcICoseo3V6@mail.gmail.com> From: Robert Sayre <sayrer@gmail.com> To: Evan Gilbert <uidude@google.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: [OAUTH-WG] JSON parsing in the browser (was: Proposal for single JSON response format) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 27 Jun 2010 20:46:21 -0000 On Sun, Jun 13, 2010 at 11:20 AM, Evan Gilbert <uidude@google.com> wrote: > >> >> Can you explain the XSS hole from parsing a random JSON string? > > Naive processor calls: > var href =3D document.location.href; > var jsonBlob =3D href.substring(href.indexOf('#'), href.length) > var userData =A0=3D eval(jsonBlob); > This code would allow executing arbitrary code by sending a user a link, > which could, for example, steal your cookies on a site. > The fix is just a really complicated RegEx match I don't agree with this assessment. The fix is to use json2.js from json.org (which does indeed use a really complicated regex) if there is no global JSON object available in the browser. A global JSON object is available in IE8+, Firefox 3.5+, Safari 4.0.x+, and Chrome and Opera (don't have the versions handy). "Skate to where the puck is going, not to where it is." -- Wayne Gretzky --=20 Robert Sayre "I would have written a shorter letter, but I did not have the time." From tim.ridgely@gmail.com Sun Jun 27 18:47:12 2010 Return-Path: <tim.ridgely@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CEF03A67CF for <oauth@core3.amsl.com>; Sun, 27 Jun 2010 18:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RtV6GGY-oRvM for <oauth@core3.amsl.com>; Sun, 27 Jun 2010 18:47:11 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 1C75F3A6867 for <oauth@ietf.org>; Sun, 27 Jun 2010 18:47:10 -0700 (PDT) Received: by wye20 with SMTP id 20so3659299wye.31 for <oauth@ietf.org>; Sun, 27 Jun 2010 18:47:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=gsrexzBzkETKBSYAL9KTJSwegrxCndpUtwq4hhVM814=; b=ZyiaY8vOvyKnLBuxrkl9WCIZSsYblJHH3ngDyWbgjJViI/VGEsnNjMnckd0kF6QioJ f65Hs+HsMmkdml2OWbwAqXa9y5HOD27CUJx9GhWfrLyuMftNmvG09F8rzFdI4C3eoSKs xxZ+HjoYZ9bw/pyKIUggZenmon6nJqJp8++2A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=COfFboxiobwt7b3koYCIH/CSrdaAb+Vm6ZbxOKUxoMcpfVzkRC6pnX+UaeMMRcLrhV yQAvCftjthfUgne82sQuoS3/A3LNzDX6GNDcHR/5QuEDkRUlW4SPujKKp/Yra9EfwYsx YleQLDabMljQlrRG2b65mz+eJhL82nTqn8xLI= MIME-Version: 1.0 Received: by 10.216.157.201 with SMTP id o51mr7595326wek.6.1277689637111; Sun, 27 Jun 2010 18:47:17 -0700 (PDT) Received: by 10.216.70.199 with HTTP; Sun, 27 Jun 2010 18:47:17 -0700 (PDT) Date: Sun, 27 Jun 2010 21:47:17 -0400 Message-ID: <AANLkTikTes81Q5YkX3mKgKBLe3lXRy8EiBj5-cXm170F@mail.gmail.com> From: Tim Ridgely <tim.ridgely@gmail.com> To: oauth@ietf.org Content-Type: multipart/alternative; boundary=0016e649c7d2f407ca048a0d4c86 Subject: [OAUTH-WG] PHP-based OAuth 2.0 library, with sample Mongo DB implementation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 28 Jun 2010 01:47:53 -0000 --0016e649c7d2f407ca048a0d4c86 Content-Type: text/plain; charset=ISO-8859-1 Hi everybody, We're looking to adopt OAuth 2.0 here at Open Dining, and we couldn't find a suitable PHP server implementation. With the draft status of the spec in mind, we took a crack at an implementation anyway. Documentation is very sparse still, but we commented the heck out of the source. Blog: http://www.opendining.net/blog/oauth-2-0-php-library/ Google Code: http://code.google.com/p/oauth2-php/ Feedback welcome. Thanks! Tim --0016e649c7d2f407ca048a0d4c86 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi everybody,<div><br></div><div>We're looking to adopt OAuth 2.0 here = at Open Dining, and we couldn't find a suitable PHP server implementati= on. =A0With the draft status of the spec in mind, we took a crack at an imp= lementation anyway.</div> <div><br></div><div>Documentation is very sparse still, but we commented th= e heck out of the source.</div><div><br></div><div>Blog:=A0<a href=3D"http:= //www.opendining.net/blog/oauth-2-0-php-library/">http://www.opendining.net= /blog/oauth-2-0-php-library/</a></div> <div>Google Code:=A0<a href=3D"http://code.google.com/p/oauth2-php/">http:/= /code.google.com/p/oauth2-php/</a></div><div><br></div><div>Feedback welcom= e. =A0Thanks!</div><div><br></div><div>Tim</div> --0016e649c7d2f407ca048a0d4c86-- From eran@hueniverse.com Sun Jun 27 18:51:46 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A97D3A68B6 for <oauth@core3.amsl.com>; Sun, 27 Jun 2010 18:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.977 X-Spam-Level: X-Spam-Status: No, score=-0.977 tagged_above=-999 required=5 tests=[AWL=-0.979, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aor4VstjZnkX for <oauth@core3.amsl.com>; Sun, 27 Jun 2010 18:51:43 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 163E33A67CF for <oauth@ietf.org>; Sun, 27 Jun 2010 18:51:38 -0700 (PDT) Received: (qmail 20027 invoked from network); 28 Jun 2010 01:51:47 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 28 Jun 2010 01:51:47 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Sun, 27 Jun 2010 18:51:47 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org> Date: Sun, 27 Jun 2010 18:51:46 -0700 Thread-Topic: What to do about 'realm' Thread-Index: AcsWZA3VaAGfBKT6Rq+fJ1qCaXCqog== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EC84ADE@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_90C41DD21FB7C64BB94121FBBC2E72343B3EC84ADEP3PW5EX1MB01E_" MIME-Version: 1.0 Subject: [OAUTH-WG] What to do about 'realm' X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 28 Jun 2010 01:51:46 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EC84ADEP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Over the past year many people expressed concerns about the use of the 'rea= lm' WWW-Authenticate header parameter. The parameter is defined in RFC 2617= as required, and is allowed to have scheme-specific structure. We have a few options: 1. Leave it as required under the definition of RFC 2617 (i.e. provide no h= elp, developers will need to ready 2617 and figure out what to do with it). 2. Update 2617 to remove the requirement - this is not going to be easy or = possible to predict success. 3. Provide specific guidance as to what to do with the realm parameter. 4. Something else. Comments? EHL --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EC84ADEP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV=3D"Content-Type" CONTENT= =3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros= oft Word 14 (filtered medium)"><style><!-- /* Font Definitions */ @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {mso-style-priority:34; margin-top:0in; margin-right:0in; margin-bottom:0in; margin-left:.5in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} span.EmailStyle17 {mso-style-type:personal-compose; font-family:"Calibri","sans-serif"; color:windowtext;} .MsoChpDefault {mso-style-type:export-only; font-family:"Calibri","sans-serif";} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue vli= nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal>Over the past ye= ar many people expressed concerns about the use of the ‘realm’ = WWW-Authenticate header parameter. The parameter is defined in RFC 2617 as = required, and is allowed to have scheme-specific structure.<o:p></o:p></p><= p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>We have a few= options:<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p class= =3DMsoNormal>1. Leave it as required under the definition of RFC 2617 (i.e.= provide no help, developers will need to ready 2617 and figure out what to= do with it).<o:p></o:p></p><p class=3DMsoNormal>2. Update 2617 to remove t= he requirement – this is not going to be easy or possible to predict = success.<o:p></o:p></p><p class=3DMsoNormal>3. Provide specific guidance as= to what to do with the realm parameter.<o:p></o:p></p><p class=3DMsoNormal= >4. Something else.<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p= ><p class=3DMsoNormal>Comments?<o:p></o:p></p><p class=3DMsoNormal><o:p>&nb= sp;</o:p></p><p class=3DMsoNormal>EHL<o:p></o:p></p></div></body></html>= --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EC84ADEP3PW5EX1MB01E_-- From dick.hardt@gmail.com Sun Jun 27 22:37:34 2010 Return-Path: <dick.hardt@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 986113A6832 for <oauth@core3.amsl.com>; Sun, 27 Jun 2010 22:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id srZRqX5HGrz2 for <oauth@core3.amsl.com>; Sun, 27 Jun 2010 22:37:33 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 8911F3A67E5 for <oauth@ietf.org>; Sun, 27 Jun 2010 22:37:33 -0700 (PDT) Received: by pvd12 with SMTP id 12so647326pvd.31 for <oauth@ietf.org>; Sun, 27 Jun 2010 22:37:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:message-id:references:to :x-mailer; bh=xaRYHrsvgelaVR1NpUAQ1+Yhgp2GHouvpy8MDty8NeU=; b=tL62wB2CsRshJ0USEQ7Y1qfwk3CmA5iQnq6p3AJribpAU1/DfLw+755ktmHxB549g/ pacQMMa35H9bkGJl6v+lCVQXLjJs+KAEE1EhTrxRCi1+h0aQyC8CpQQhT4Ep3/ihZQuQ xRP1Lhza7pZNQtMHccNqFV1T25hbiv6sqfAmU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; b=JfsMA1hlNgrBLde/EgQs2ZqYMgFd7SdJU2TWbhM7P+dR2F4OuDvXPK0siG4fdI0XqQ iCkV4rzyBQbM8XV99E/DTuxbNQWU7VkqkAvkFjSaSswrMhXrndkN0ofnacOyDu5bIGtH LiyKzyq1oNSIwByPHyWuwq1/+E83K+TvSLXAA= Received: by 10.142.178.2 with SMTP id a2mr43569wff.308.1277703458925; Sun, 27 Jun 2010 22:37:38 -0700 (PDT) Received: from [192.168.1.5] (c-24-130-32-55.hsd1.ca.comcast.net [24.130.32.55]) by mx.google.com with ESMTPS id b12sm11000267rvn.22.2010.06.27.22.37.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 27 Jun 2010 22:37:37 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-12-896029306 From: Dick Hardt <dick.hardt@gmail.com> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EC84ADE@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Sun, 27 Jun 2010 22:37:36 -0700 Message-Id: <269A7D01-CB98-46F3-9D17-C0AAA31041E4@gmail.com> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EC84ADE@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav <eran@hueniverse.com> X-Mailer: Apple Mail (2.1081) Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] What to do about 'realm' X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 28 Jun 2010 05:37:34 -0000 --Apple-Mail-12-896029306 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I vote for (3) unless a good (4) is suggested. On 2010-06-27, at 6:51 PM, Eran Hammer-Lahav wrote: > Over the past year many people expressed concerns about the use of the = =91realm=92 WWW-Authenticate header parameter. The parameter is defined = in RFC 2617 as required, and is allowed to have scheme-specific = structure. > =20 > We have a few options: > =20 > 1. Leave it as required under the definition of RFC 2617 (i.e. provide = no help, developers will need to ready 2617 and figure out what to do = with it). > 2. Update 2617 to remove the requirement =96 this is not going to be = easy or possible to predict success. > 3. Provide specific guidance as to what to do with the realm = parameter. > 4. Something else. > =20 > Comments? > =20 > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-12-896029306 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 <html><head><base href=3D"x-msg://96/"></head><body style=3D"word-wrap: = break-word; -webkit-nbsp-mode: space; -webkit-line-break: = after-white-space; ">I vote for (3) unless a good (4) is = suggested.<div><br><div><div>On 2010-06-27, at 6:51 PM, Eran = Hammer-Lahav wrote:</div><br = class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><span = class=3D"Apple-style-span" style=3D"border-collapse: separate; = font-family: Helvetica; font-style: normal; font-variant: normal; = font-weight: normal; letter-spacing: normal; line-height: normal; = orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; = widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; = -webkit-border-vertical-spacing: 0px; = -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: = auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div = lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div class=3D"WordSection1" = style=3D"page: WordSection1; "><div style=3D"margin-top: 0in; = margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: = 11pt; font-family: Calibri, sans-serif; ">Over the past year many people = expressed concerns about the use of the =91realm=92 WWW-Authenticate = header parameter. The parameter is defined in RFC 2617 as required, and = is allowed to have scheme-specific structure.<o:p></o:p></div><div = style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; = margin-left: 0in; font-size: 11pt; font-family: Calibri, sans-serif; = "><o:p> </o:p></div><div style=3D"margin-top: 0in; margin-right: = 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 11pt; = font-family: Calibri, sans-serif; ">We have a few = options:<o:p></o:p></div><div style=3D"margin-top: 0in; margin-right: = 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 11pt; = font-family: Calibri, sans-serif; "><o:p> </o:p></div><div = style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; = margin-left: 0in; font-size: 11pt; font-family: Calibri, sans-serif; = ">1. Leave it as required under the definition of RFC 2617 (i.e. provide = no help, developers will need to ready 2617 and figure out what to do = with it).<o:p></o:p></div><div style=3D"margin-top: 0in; margin-right: = 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 11pt; = font-family: Calibri, sans-serif; ">2. Update 2617 to remove the = requirement =96 this is not going to be easy or possible to predict = success.<o:p></o:p></div><div style=3D"margin-top: 0in; margin-right: = 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 11pt; = font-family: Calibri, sans-serif; ">3. Provide specific guidance as to = what to do with the realm parameter.<o:p></o:p></div><div = style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; = margin-left: 0in; font-size: 11pt; font-family: Calibri, sans-serif; = ">4. Something else.<o:p></o:p></div><div style=3D"margin-top: 0in; = margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: = 11pt; font-family: Calibri, sans-serif; "><o:p> </o:p></div><div = style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; = margin-left: 0in; font-size: 11pt; font-family: Calibri, sans-serif; = ">Comments?<o:p></o:p></div><div style=3D"margin-top: 0in; margin-right: = 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 11pt; = font-family: Calibri, sans-serif; "><o:p> </o:p></div><div = style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; = margin-left: 0in; font-size: 11pt; font-family: Calibri, sans-serif; = ">EHL<o:p></o:p></div></div>______________________________________________= _<br>OAuth mailing list<br><a href=3D"mailto:OAuth@ietf.org" = style=3D"color: blue; text-decoration: underline; = ">OAuth@ietf.org</a><br><a = href=3D"https://www.ietf.org/mailman/listinfo/oauth" style=3D"color: = blue; text-decoration: underline; = ">https://www.ietf.org/mailman/listinfo/oauth</a><br></div></span></blockq= uote></div><br></div></body></html>= --Apple-Mail-12-896029306-- From dick.hardt@gmail.com Sun Jun 27 22:49:51 2010 Return-Path: <dick.hardt@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DC503A6967 for <oauth@core3.amsl.com>; Sun, 27 Jun 2010 22:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.445 X-Spam-Level: X-Spam-Status: No, score=-2.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9ZgSk5ldbbR for <oauth@core3.amsl.com>; Sun, 27 Jun 2010 22:48:34 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 71CBE3A6955 for <oauth@ietf.org>; Sun, 27 Jun 2010 22:48:34 -0700 (PDT) Received: by pwi6 with SMTP id 6so4463947pwi.31 for <oauth@ietf.org>; Sun, 27 Jun 2010 22:48:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:content-type :content-transfer-encoding:subject:date:message-id:to:mime-version :x-mailer; bh=s/1ldBh4DAC9UP1zLQayM0fLHvbw9EG9NyQBuOefyBY=; b=q3d6xGKG5Yjw9s9lOC3MVvB1iCN4ZCwhBq3/lxmZXcHle4D38IXNM98BmsoSx/g18q jhy1/MwhtaYN61KZWlkOGwvTgbBhj7VMJaS22nmNjgXJtUk//rMcgjcZ7/Oqjr8+Nid0 Bh17Js5ZDtAg889/zpFIeV8u9jQ2PKiz1KDmY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; b=B8RFux6q+hNreMW3IFNDYgyYrfHsENUWGiqMRVEJmcyJes1UNnOOaADFc/P/exNgB9 w0F758Y/NV5DV0HE6cuFugFeaDQQtLDbgRW3wBVBDukt9UTPYiZSt+4ohYtEks3RBx2p c9kMSsBNzmfw6XjNsGxY/qbfYNDILEY9Jr1IU= Received: by 10.142.158.12 with SMTP id g12mr1963408wfe.91.1277704120558; Sun, 27 Jun 2010 22:48:40 -0700 (PDT) Received: from [192.168.1.5] (c-24-130-32-55.hsd1.ca.comcast.net [24.130.32.55]) by mx.google.com with ESMTPS id b12sm11008259rvn.22.2010.06.27.22.48.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 27 Jun 2010 22:48:40 -0700 (PDT) From: Dick Hardt <dick.hardt@gmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 27 Jun 2010 22:48:38 -0700 Message-Id: <085C731D-5C07-422C-AC53-1C50CF6D9984@gmail.com> To: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org> Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [OAUTH-WG] semantics of scope parameter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 28 Jun 2010 05:50:08 -0000 X-List-Received-Date: Mon, 28 Jun 2010 05:50:08 -0000 The current spec defines scope (when the scope variable is introduced) = as: scope OPTIONAL. The scope of the access request expressed as a list of space-delimited strings. The value of the "scope" parameter is defined by the authorization server. If the value contains multiple space-delimited strings, their order does not matter, and each string adds an additional access range to the requested scope. I think the last phrase is adding semantics that may not be true, and = that the following is more accurate: scope OPTIONAL. The scope of the access request expressed as a list of space-delimited strings. The value of the "scope" parameter is defined by the authorization server. If the value contains multiple space-delimited strings, their order does not matter. A authorization server may define some scope parameters that add = restrictions to the access rather than are additive. For example, scope = could be defined by an AS as one or more resources (PHOTOS PROFILE = FRIENDS) and the type of access (READ WRITE READWRITE)=20 -- Dick From eran@hueniverse.com Sun Jun 27 23:10:22 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B6A43A698A for <oauth@core3.amsl.com>; Sun, 27 Jun 2010 23:10:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.923 X-Spam-Level: X-Spam-Status: No, score=-0.923 tagged_above=-999 required=5 tests=[AWL=-1.013, BAYES_05=-1.11, J_CHICKENPOX_74=0.6, J_CHICKENPOX_75=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TfaTOjFNMjJW for <oauth@core3.amsl.com>; Sun, 27 Jun 2010 23:10:20 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 49E913A698B for <oauth@ietf.org>; Sun, 27 Jun 2010 23:10:20 -0700 (PDT) Received: (qmail 29288 invoked from network); 28 Jun 2010 06:10:29 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 28 Jun 2010 06:10:29 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Sun, 27 Jun 2010 23:10:29 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: Dick Hardt <dick.hardt@gmail.com>, "OAuth WG (oauth@ietf.org)" <oauth@ietf.org> Date: Sun, 27 Jun 2010 23:10:29 -0700 Thread-Topic: [OAUTH-WG] semantics of scope parameter Thread-Index: AcsWhjkvOkkXfhgRRESj3hMAvQT4BgAAWF1Q Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EC84AE9@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <085C731D-5C07-422C-AC53-1C50CF6D9984@gmail.com> In-Reply-To: <085C731D-5C07-422C-AC53-1C50CF6D9984@gmail.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] semantics of scope parameter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 28 Jun 2010 06:10:22 -0000 First, there is nothing preventing the server from using: scope=3Dphotos:read profile:read friends:read or: scope=3Dphotos:read profile:readwrite friends:write --- I think the current language strikes the right balance between interop and = scopes definitions. While a generic client will not understand the meaning = of each scope, it will be able to tell that "x y" is the same as "y x", tha= t "x y" includes both "x" and "y", and that if it asked for "x y" and was t= old it needs "y z", it can ask for "x y z" and use it as a replacement of t= he "z y" token. Being able to manipulate scope values is essential to accomplish interop. W= ithout that, there is little value in defining any internal structure, and = if that is the case, I still maintain that there is no value in defining th= e entire parameter. The current language is a workable compromise that help= s libraries and developers, and does not restrict service providers from de= fining their own scope syntax (as long as they don't use spaces to mean som= ething else). For example: scope=3Dphotos,profile,friends,readwrite is perfectly valid, but treated by a generic client as one opaque scope. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Dick Hardt > Sent: Sunday, June 27, 2010 10:49 PM > To: OAuth WG (oauth@ietf.org) > Subject: [OAUTH-WG] semantics of scope parameter >=20 > The current spec defines scope (when the scope variable is introduced) as= : >=20 > scope > OPTIONAL. The scope of the access request expressed as a list > of space-delimited strings. The value of the "scope" parameter > is defined by the authorization server. If the value contains > multiple space-delimited strings, their order does not matter, > and each string adds an additional access range to the > requested scope. >=20 > I think the last phrase is adding semantics that may not be true, and tha= t the > following is more accurate: >=20 > scope > OPTIONAL. The scope of the access request expressed as a list > of space-delimited strings. The value of the "scope" parameter > is defined by the authorization server. If the value contains > multiple space-delimited strings, their order does not matter. >=20 > A authorization server may define some scope parameters that add > restrictions to the access rather than are additive. For example, scope c= ould > be defined by an AS as one or more resources (PHOTOS PROFILE FRIENDS) > and the type of access (READ WRITE READWRITE) >=20 > -- Dick >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Sun Jun 27 23:11:30 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C82DB3A698A for <oauth@core3.amsl.com>; Sun, 27 Jun 2010 23:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.613 X-Spam-Level: X-Spam-Status: No, score=-0.613 tagged_above=-999 required=5 tests=[AWL=-1.303, BAYES_05=-1.11, J_CHICKENPOX_56=0.6, J_CHICKENPOX_74=0.6, J_CHICKENPOX_75=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qEjcimoL0wpl for <oauth@core3.amsl.com>; Sun, 27 Jun 2010 23:11:29 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 3159F3A6988 for <oauth@ietf.org>; Sun, 27 Jun 2010 23:11:29 -0700 (PDT) Received: (qmail 29394 invoked from network); 28 Jun 2010 06:11:39 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 28 Jun 2010 06:11:39 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sun, 27 Jun 2010 23:11:39 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: Eran Hammer-Lahav <eran@hueniverse.com>, Dick Hardt <dick.hardt@gmail.com>, "OAuth WG (oauth@ietf.org)" <oauth@ietf.org> Date: Sun, 27 Jun 2010 23:11:39 -0700 Thread-Topic: [OAUTH-WG] semantics of scope parameter Thread-Index: AcsWhjkvOkkXfhgRRESj3hMAvQT4BgAAWF1QAABDalA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EC84AEA@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <085C731D-5C07-422C-AC53-1C50CF6D9984@gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3EC84AE9@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EC84AE9@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] semantics of scope parameter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 28 Jun 2010 06:11:31 -0000 Another way to think about it is that the current text reserves the space c= haracter to mean something specific but doesn't prevent service providers f= rom using any other delimiter as they see fit. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Eran Hammer-Lahav > Sent: Sunday, June 27, 2010 11:10 PM > To: Dick Hardt; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] semantics of scope parameter >=20 > First, there is nothing preventing the server from using: >=20 > scope=3Dphotos:read profile:read friends:read >=20 > or: >=20 > scope=3Dphotos:read profile:readwrite friends:write >=20 > --- >=20 > I think the current language strikes the right balance between interop an= d > scopes definitions. While a generic client will not understand the meanin= g of > each scope, it will be able to tell that "x y" is the same as "y x", that= "x y" > includes both "x" and "y", and that if it asked for "x y" and was told it= needs > "y z", it can ask for "x y z" and use it as a replacement of the "z y" to= ken. >=20 > Being able to manipulate scope values is essential to accomplish interop. > Without that, there is little value in defining any internal structure, a= nd if that > is the case, I still maintain that there is no value in defining the enti= re > parameter. The current language is a workable compromise that helps > libraries and developers, and does not restrict service providers from > defining their own scope syntax (as long as they don't use spaces to mean > something else). >=20 > For example: >=20 > scope=3Dphotos,profile,friends,readwrite >=20 > is perfectly valid, but treated by a generic client as one opaque scope. >=20 > EHL >=20 >=20 > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > Of Dick Hardt > > Sent: Sunday, June 27, 2010 10:49 PM > > To: OAuth WG (oauth@ietf.org) > > Subject: [OAUTH-WG] semantics of scope parameter > > > > The current spec defines scope (when the scope variable is introduced) = as: > > > > scope > > OPTIONAL. The scope of the access request expressed as a list > > of space-delimited strings. The value of the "scope" paramete= r > > is defined by the authorization server. If the value contains > > multiple space-delimited strings, their order does not matter, > > and each string adds an additional access range to the > > requested scope. > > > > I think the last phrase is adding semantics that may not be true, and > > that the following is more accurate: > > > > scope > > OPTIONAL. The scope of the access request expressed as a list > > of space-delimited strings. The value of the "scope" paramete= r > > is defined by the authorization server. If the value contains > > multiple space-delimited strings, their order does not matter. > > > > A authorization server may define some scope parameters that add > > restrictions to the access rather than are additive. For example, > > scope could be defined by an AS as one or more resources (PHOTOS > > PROFILE FRIENDS) and the type of access (READ WRITE READWRITE) > > > > -- Dick > > > > _______________________________________________ > > OAuth mailing 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 lr@lukasrosenstock.net Mon Jun 28 00:14:03 2010 Return-Path: <lr@lukasrosenstock.net> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F18E03A68F2 for <oauth@core3.amsl.com>; Mon, 28 Jun 2010 00:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CfUGHrNWOfop for <oauth@core3.amsl.com>; Mon, 28 Jun 2010 00:14:01 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 50C3E3A67F1 for <oauth@ietf.org>; Mon, 28 Jun 2010 00:14:01 -0700 (PDT) Received: by vws7 with SMTP id 7so1137996vws.31 for <oauth@ietf.org>; Mon, 28 Jun 2010 00:14:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.218.211 with SMTP id hr19mr2319782qcb.92.1277709248080; Mon, 28 Jun 2010 00:14:08 -0700 (PDT) Received: by 10.229.236.130 with HTTP; Mon, 28 Jun 2010 00:14:08 -0700 (PDT) In-Reply-To: <269A7D01-CB98-46F3-9D17-C0AAA31041E4@gmail.com> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EC84ADE@P3PW5EX1MB01.EX1.SECURESERVER.NET> <269A7D01-CB98-46F3-9D17-C0AAA31041E4@gmail.com> Date: Mon, 28 Jun 2010 09:14:08 +0200 Message-ID: <AANLkTikb7bGq-7Y7V4h-pErpkwFJAQ0wZV-lE2hBWNvJ@mail.gmail.com> From: Lukas Rosenstock <lr@lukasrosenstock.net> To: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [OAUTH-WG] What to do about 'realm' X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 28 Jun 2010 07:14:03 -0000 +1 2010/6/28 Dick Hardt <dick.hardt@gmail.com>: > I vote for (3) unless a good (4) is suggested. > On 2010-06-27, at 6:51 PM, Eran Hammer-Lahav wrote: > > Over the past year many people expressed concerns about the use of the > =91realm=92 WWW-Authenticate header parameter. The parameter is defined i= n RFC > 2617 as required, and is allowed to have scheme-specific structure. > > We have a few options: > > 1. Leave it as required under the definition of RFC 2617 (i.e. provide no > help, developers will need to ready 2617 and figure out what to do with i= t). > 2. Update 2617 to remove the requirement =96 this is not going to be easy= or > possible to predict success. > 3. Provide specific guidance as to what to do with the realm parameter. > 4. Something else. > > Comments? > > 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 > > --=20 http://lukasrosenstock.net/ From pid@pidster.com Mon Jun 28 00:43:25 2010 Return-Path: <pid@pidster.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EF223A67E3 for <oauth@core3.amsl.com>; Mon, 28 Jun 2010 00:43:25 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FScTzqhR8UVp for <oauth@core3.amsl.com>; Mon, 28 Jun 2010 00:43:24 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 074AE3A67D9 for <oauth@ietf.org>; Mon, 28 Jun 2010 00:43:22 -0700 (PDT) Received: by wye20 with SMTP id 20so3777454wye.31 for <oauth@ietf.org>; Mon, 28 Jun 2010 00:43:29 -0700 (PDT) Received: by 10.216.185.10 with SMTP id t10mr7794960wem.32.1277711008277; Mon, 28 Jun 2010 00:43:28 -0700 (PDT) Received: from Phoenix.local ([86.14.119.14]) by mx.google.com with ESMTPS id l2sm2240628wej.23.2010.06.28.00.43.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 28 Jun 2010 00:43:26 -0700 (PDT) Message-ID: <4C285291.2060501@pidster.com> Date: Mon, 28 Jun 2010 08:43:13 +0100 From: Pid <pid@pidster.com> Organization: Pidster Inc User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: OAuth WG <oauth@ietf.org> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EC84ADE@P3PW5EX1MB01.EX1.SECURESERVER.NET> <269A7D01-CB98-46F3-9D17-C0AAA31041E4@gmail.com> In-Reply-To: <269A7D01-CB98-46F3-9D17-C0AAA31041E4@gmail.com> X-Enigmail-Version: 1.1.1 OpenPGP: id=62590808 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigBCAA1212E7CFD94CE6F762C6" Subject: Re: [OAUTH-WG] What to do about 'realm' X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: pid@pidster.com List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 28 Jun 2010 07:43:25 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigBCAA1212E7CFD94CE6F762C6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 28/06/2010 06:37, Dick Hardt wrote: > I vote for (3) unless a good (4) is suggested. Ditto. p > On 2010-06-27, at 6:51 PM, Eran Hammer-Lahav wrote: >=20 >> Over the past year many people expressed concerns about the use of the= >> =91realm=92 WWW-Authenticate header parameter. The parameter is define= d in >> RFC 2617 as required, and is allowed to have scheme-specific structure= =2E >> =20 >> We have a few options: >> =20 >> 1. Leave it as required under the definition of RFC 2617 (i.e. provide= >> no help, developers will need to ready 2617 and figure out what to do >> with it). >> 2. Update 2617 to remove the requirement =96 this is not going to be >> easy or possible to predict success. >> 3. Provide specific guidance as to what to do with the realm parameter= =2E >> 4. Something else. >> =20 >> Comments? >> =20 >> EHL >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------enigBCAA1212E7CFD94CE6F762C6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) iQIcBAEBCgAGBQJMKFKXAAoJEGoM2OGpOvr9bOgQAK7Etv6/gbOI2Bt9e7tw8PGJ 2vbms2PwFqRzDFrE/1w6fKGXbVszeuOO3l43/h4L8uKlmB8QdehVYE4wd0fYdHkW y80xVmWy25qhCj2VgDs6qABF6Uo0il5XHJlqfmjRFts5rkChDFw5UaSG3w25pDX8 ctGRpogItDYoTrT8XJgV5u6idE6lzmpPy52hLV/4gu07k++7u4uAY2NbwgE605kQ 9vFTF60MU4ENfHU/Tp62L4cZYsrU2JLdcTUL/uRkAiBrBGJiOtifp6b9ThVRtV/p bpzrde6GTbku/hRAhXfhaggb2dXO2a9+I9ee56X4FsoBDmsQEOBhB2n3W2qxTBvi uv5pJok9eRwJm53zCfD5T76q27UqfzVBkQPesuHZs1hsyY7vyCBrGkwJEmeR7zyH odchzlGojEL0zNMsBbyNdZZB02m/W5bUYnz3wHi03b95Upsq14iB+m+LGlPRrp2B XHv8pjUVrm4j2KXXc1/j3Z7yV/Ho9ls/80ruFG4DAmgUNUetbFrr3FeMF7J4kFBL 2alE2YwnWRFlAxVoOX5CL2z3K3LXqcuWE+sSQx8wjEbuEnRYNeK56YSyJTYGoTVE O6Uv5Q3xaIEitUDtTD6IQY780owQz1bXBj5KEO7mhImlfniC/uQOGBeEqvaQHb9A YU33QeqhQ9FEuGeREfEK =i15Y -----END PGP SIGNATURE----- --------------enigBCAA1212E7CFD94CE6F762C6-- From elena.lozano@rediris.es Mon Jun 28 02:45:47 2010 Return-Path: <elena.lozano@rediris.es> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E88B3A69C3 for <oauth@core3.amsl.com>; Mon, 28 Jun 2010 02:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKr609PjZboz for <oauth@core3.amsl.com>; Mon, 28 Jun 2010 02:45:46 -0700 (PDT) Received: from irisout3.rediris.es (irisout3.rediris.es [130.206.24.5]) by core3.amsl.com (Postfix) with ESMTP id 78FFF3A687E for <oauth@ietf.org>; Mon, 28 Jun 2010 02:45:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,496,1272837600"; d="scan'208,217";a="24415775" Received: from snail.rediris.es.6.206.130.in-addr.arpa ([130.206.6.77]) by cain.rediris.es with ESMTP/TLS/AES128-SHA; 28 Jun 2010 11:42:44 +0200 From: Elena Lozano <elena.lozano@rediris.es> Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-1-910925121 Date: Mon, 28 Jun 2010 11:45:52 +0200 In-Reply-To: <AANLkTikTes81Q5YkX3mKgKBLe3lXRy8EiBj5-cXm170F@mail.gmail.com> To: oauth@ietf.org References: <AANLkTikTes81Q5YkX3mKgKBLe3lXRy8EiBj5-cXm170F@mail.gmail.com> Message-Id: <B4DCE065-F2FB-41DD-8C5E-27DF3836C51D@rediris.es> X-Mailer: Apple Mail (2.1081) Subject: Re: [OAUTH-WG] Assertion Profile PHP library X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 28 Jun 2010 09:45:47 -0000 --Apple-Mail-1-910925121 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi everyone, In RedIRIS[1], the Spanish academic and research network that provides = advanced communication services to the scientific community and national = universities, we are developing a PHP library to the Assertion Profile = of the OAuth2 specification. =20 This library [2] is in development and we're trying to adapt it to the = newest version of the protocol. So far, it has been adapted to the draft = v08. We have developed an Authorization Server, a Resource Server and a = Client. All the documentation and specification is in the url below. = We've been using it in some use cases and works fine in our environment. The documentation is still in its initial state, so if you think = something needs more explanation, let us know! We're open to any suggestions and reports, Thanks! Elena. [1] http://www.rediris.es/ [2] http://www.rediris.es/oauth2 --Apple-Mail-1-910925121 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii <html><head></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; = ">Hi <span class=3D"Apple-style-span" = style=3D"-webkit-border-horizontal-spacing: 1px; = -webkit-border-vertical-spacing: 1px; "><span class=3D"Apple-style-span" = style=3D"background-color: = transparent;">everyone</span></span>,<div><br><div><div>In = RedIRIS[1], <span class=3D"Apple-style-span" style=3D"line-height: = 13px; "><span class=3D"Apple-style-span" style=3D"background-color: = transparent;">the Spanish academic and research network that provides = advanced communication services to the scientific community and national = universities, we are developing a PHP library to the <b>Assertion = Profile</b> of the OAuth2 specification. =  </span></span></div><div><span class=3D"Apple-style-span" = style=3D"line-height: 13px; "><span class=3D"Apple-style-span" = style=3D"background-color: = transparent;"><br></span></span></div><div><span = class=3D"Apple-style-span" style=3D"line-height: 13px; "><span = class=3D"Apple-style-span" style=3D"background-color: transparent;">This = library [2] is in development and we're trying to adapt it to the newest = version of the protocol. So far, it has been adapted to the draft = v08.</span></span></div><div><span class=3D"Apple-style-span" = style=3D"line-height: 13px; "><span class=3D"Apple-style-span" = style=3D"background-color: transparent;">We have developed an = Authorization Server, a Resource Server and a Client. All the = documentation and specification is in the url below. We've been using it = in some use cases and works fine in our = environment.</span></span></div><div><span class=3D"Apple-style-span" = style=3D"line-height: 13px; "><span class=3D"Apple-style-span" = style=3D"background-color: = transparent;"><br></span></span></div><div><span = class=3D"Apple-style-span" style=3D"line-height: 13px;">The = documentation is still in its initial state, so if you think something = needs more explanation, let us know!</span></div><div><span = class=3D"Apple-style-span" style=3D"line-height: 13px; "><span = class=3D"Apple-style-span" style=3D"background-color: = transparent;"><br></span></span></div><div><span = class=3D"Apple-style-span" style=3D"-webkit-border-horizontal-spacing: = 1px; -webkit-border-vertical-spacing: 1px;"><span = class=3D"Apple-style-span" style=3D"background-color: = transparent;">We're open to any suggestions and reports, = Thanks!</span></span></div><div><span class=3D"Apple-style-span" = style=3D"-webkit-border-horizontal-spacing: 1px; = -webkit-border-vertical-spacing: 1px;"><span class=3D"Apple-style-span" = style=3D"background-color: = transparent;"><br></span></span></div><div><span = class=3D"Apple-style-span" style=3D"-webkit-border-horizontal-spacing: = 1px; -webkit-border-vertical-spacing: 1px;"><span = class=3D"Apple-style-span" style=3D"background-color: = transparent;">Elena.</span></span></div><br></div><div>[1] <a = href=3D"http://www.rediris.es/">http://www.rediris.es/</a><br>[2] <a = href=3D"http://www.rediris.es/oauth2">http://www.rediris.es/oauth2</a><br>= </div><br></div></body></html>= --Apple-Mail-1-910925121-- From wmills@yahoo-inc.com Mon Jun 28 09:30:23 2010 Return-Path: <wmills@yahoo-inc.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 238B33A6A68 for <oauth@core3.amsl.com>; Mon, 28 Jun 2010 09:30:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.251 X-Spam-Level: X-Spam-Status: No, score=-17.251 tagged_above=-999 required=5 tests=[AWL=0.348, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtvp88M1OlXk for <oauth@core3.amsl.com>; Mon, 28 Jun 2010 09:30:19 -0700 (PDT) Received: from mrout1.yahoo.com (mrout1.yahoo.com [216.145.54.171]) by core3.amsl.com (Postfix) with ESMTP id 643E23A6916 for <oauth@ietf.org>; Mon, 28 Jun 2010 09:30:19 -0700 (PDT) Received: from SNV-EXPF01.ds.corp.yahoo.com (snv-expf01.ds.corp.yahoo.com [207.126.227.250]) by mrout1.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o5SGTjb5095546; Mon, 28 Jun 2010 09:29:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:x-mimeole:content-class:mime-version: content-type:content-transfer-encoding:subject:date:message-id: in-reply-to:x-ms-has-attach:x-ms-tnef-correlator:thread-topic: thread-index:references:from:to:return-path:x-originalarrivaltime; b=XI9tTv5SZcxtJcsnbLQ7wyXGODvWDqT2p9+1ElsjDLMx4TxUiRxVrsJEy9otPFBa Received: from SNV-EXVS08.ds.corp.yahoo.com ([207.126.227.8]) by SNV-EXPF01.ds.corp.yahoo.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Jun 2010 09:29:45 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 28 Jun 2010 09:29:44 -0700 Message-ID: <012AB2B223CB3F4BB846962876F47217059B673F@SNV-EXVS08.ds.corp.yahoo.com> In-Reply-To: <AANLkTikb7bGq-7Y7V4h-pErpkwFJAQ0wZV-lE2hBWNvJ@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] What to do about 'realm' Thread-Index: AcsWkZFFhmGONOXORoCi1tQQbXIndAATYAOg References: <90C41DD21FB7C64BB94121FBBC2E72343B3EC84ADE@P3PW5EX1MB01.EX1.SECURESERVER.NET><269A7D01-CB98-46F3-9D17-C0AAA31041E4@gmail.com> <AANLkTikb7bGq-7Y7V4h-pErpkwFJAQ0wZV-lE2hBWNvJ@mail.gmail.com> From: "William Mills" <wmills@yahoo-inc.com> To: "Lukas Rosenstock" <lr@lukasrosenstock.net>, <oauth@ietf.org> X-OriginalArrivalTime: 28 Jun 2010 16:29:45.0693 (UTC) FILETIME=[1E9720D0:01CB16DF] Subject: Re: [OAUTH-WG] What to do about 'realm' X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 28 Jun 2010 16:30:23 -0000 #3 +1 > 2010/6/28 Dick Hardt <dick.hardt@gmail.com>: > > I vote for (3) unless a good (4) is suggested. > > On 2010-06-27, at 6:51 PM, Eran Hammer-Lahav wrote: > > > > Over the past year many people expressed concerns about the=20 > use of the=20 > > 'realm' WWW-Authenticate header parameter. The parameter is=20 > defined in=20 > > RFC > > 2617 as required, and is allowed to have scheme-specific structure. > > > > We have a few options: > > > > 1. Leave it as required under the definition of RFC 2617=20 > (i.e. provide=20 > > no help, developers will need to ready 2617 and figure out=20 > what to do with it). > > 2. Update 2617 to remove the requirement - this is not going to be=20 > > easy or possible to predict success. > > 3. Provide specific guidance as to what to do with the=20 > realm parameter. > > 4. Something else. > > > > Comments? > > > > 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 > > > > >=20 >=20 >=20 > -- > http://lukasrosenstock.net/ > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 From eran@hueniverse.com Mon Jun 28 10:39:45 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 855DF3A691A for <oauth@core3.amsl.com>; Mon, 28 Jun 2010 10:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.037 X-Spam-Level: X-Spam-Status: No, score=-1.037 tagged_above=-999 required=5 tests=[AWL=-0.853, BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FG6ybrGYOUhw for <oauth@core3.amsl.com>; Mon, 28 Jun 2010 10:39:37 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 7F16528C106 for <oauth@ietf.org>; Mon, 28 Jun 2010 10:39:34 -0700 (PDT) Received: (qmail 10192 invoked from network); 28 Jun 2010 17:39:35 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 28 Jun 2010 17:39:35 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 28 Jun 2010 10:39:33 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org> Date: Mon, 28 Jun 2010 10:39:34 -0700 Thread-Topic: Client credentials type Thread-Index: AcsW5Zz/FVZYBlj1T06cHdkG6yGF6w== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3EC84C9D@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_90C41DD21FB7C64BB94121FBBC2E72343B3EC84C9DP3PW5EX1MB01E_" MIME-Version: 1.0 Subject: [OAUTH-WG] Client credentials type X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 28 Jun 2010 17:39:45 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EC84C9DP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yaron Goland offered a proposal for an additional client credentials mechan= ism based on assertion. His proposal raises the issue of differentiating be= tween the different kind of credentials used. When it comes to access grant= types, this group argued for being explicit and providing a parameter decl= aring the grant type being used (even though it is not technically necessar= y). While I don't believe a grant or credential type parameter is needed - the = type can be deduced from the other parameters present - we now treat the sa= me requirement with a different solution. I think this creates a broken env= ironment for extensibility (which is my current focus). At the same time, introducing such a parameter can conflict with the standa= rd HTTP authentication mechanism. For example, a request containing both "c= lient_credentials_type=3Dbasic" and the HTTP Authorization header seems odd= . There are a few ways to address this: 1. Only use a type parameter when the credentials are passed using paramete= rs and not a header. 2. Only allow HTTP headers for authentication, while "grandfathering-in" th= e client_secret parameter to simplify the most common current practice. 3. Leave is underspecified, relying on the presence of extension parameters= or authentication headers for other credentials types. Thoughts? EHL --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EC84C9DP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"><head><meta http-equiv=3DContent-Type content= =3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros= oft Word 14 (filtered medium)"><style><!-- /* Font Definitions */ @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {mso-style-priority:34; margin-top:0in; margin-right:0in; margin-bottom:0in; margin-left:.5in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} span.EmailStyle17 {mso-style-type:personal-compose; font-family:"Calibri","sans-serif"; color:windowtext;} .MsoChpDefault {mso-style-type:export-only; font-family:"Calibri","sans-serif";} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue vli= nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal>Yaron Goland off= ered a proposal for an additional client credentials mechanism based on ass= ertion. His proposal raises the issue of differentiating between the differ= ent kind of credentials used. When it comes to access grant types, this gro= up argued for being explicit and providing a parameter declaring the grant = type being used (even though it is not technically necessary).<o:p></o:p></= p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>While I do= n’t believe a grant or credential type parameter is needed – th= e type can be deduced from the other parameters present – we now trea= t the same requirement with a different solution. I think this creates a br= oken environment for extensibility (which is my current focus).<o:p></o:p><= /p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>At the sa= me time, introducing such a parameter can conflict with the standard HTTP a= uthentication mechanism. For example, a request containing both “clie= nt_credentials_type=3Dbasic” and the HTTP Authorization header seems = odd.<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMso= Normal>There are a few ways to address this:<o:p></o:p></p><p class=3DMsoNo= rmal><o:p> </o:p></p><p class=3DMsoNormal>1. Only use a type parameter= when the credentials are passed using parameters and not a header.<o:p></o= :p></p><p class=3DMsoNormal>2. Only allow HTTP headers for authentication, = while “grandfathering-in” the client_secret parameter to simpli= fy the most common current practice.<o:p></o:p></p><p class=3DMsoNormal>3. = Leave is underspecified, relying on the presence of extension parameters or= authentication headers for other credentials types.<o:p></o:p></p><p class= =3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>Thoughts?<o:p></o:p>= </p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>EHL<o:p>= </o:p></p></div></body></html>= --_000_90C41DD21FB7C64BB94121FBBC2E72343B3EC84C9DP3PW5EX1MB01E_-- From uidude@google.com Mon Jun 28 10:54:04 2010 Return-Path: <uidude@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31A6F3A68FD for <oauth@core3.amsl.com>; Mon, 28 Jun 2010 10:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.655 X-Spam-Level: X-Spam-Status: No, score=-100.655 tagged_above=-999 required=5 tests=[AWL=0.721, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V5rk7nDLULoq for <oauth@core3.amsl.com>; Mon, 28 Jun 2010 10:54:03 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id D0F383A6925 for <oauth@ietf.org>; Mon, 28 Jun 2010 10:54:02 -0700 (PDT) Received: from wpaz37.hot.corp.google.com (wpaz37.hot.corp.google.com [172.24.198.101]) by smtp-out.google.com with ESMTP id o5SHsBus015944 for <oauth@ietf.org>; Mon, 28 Jun 2010 10:54:11 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1277747651; bh=KD5kBp/S9k68Jt3qFI+yRSBVUcI=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=VjuvMicJXnRp00GKTXYhZGuzbc2zcoa48wKUPZiBlZQmqIfM7Hmba0RM+YuWZabqG jUkV15vXpK/B6FJUockRQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=VnbNuwOIqL6DYdFmlD8SOpdVgZUgBsBfsfhejQGTCli3uf1ff1wdtRjQbDlGLzkRZ mFDgjIKHAS7jlK1K/CTdw== Received: from qwe5 (qwe5.prod.google.com [10.241.194.5]) by wpaz37.hot.corp.google.com with ESMTP id o5SHs4fH031679 for <oauth@ietf.org>; Mon, 28 Jun 2010 10:54:10 -0700 Received: by qwe5 with SMTP id 5so1709276qwe.31 for <oauth@ietf.org>; Mon, 28 Jun 2010 10:54:10 -0700 (PDT) Received: by 10.224.72.143 with SMTP id m15mr3618837qaj.231.1277747650179; Mon, 28 Jun 2010 10:54:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.11.229 with HTTP; Mon, 28 Jun 2010 10:53:47 -0700 (PDT) In-Reply-To: <AANLkTimgJSdxjfz7kY1a3zSaK9QQCtxVzVcICoseo3V6@mail.gmail.com> References: <AANLkTimgJSdxjfz7kY1a3zSaK9QQCtxVzVcICoseo3V6@mail.gmail.com> From: Evan Gilbert <uidude@google.com> Date: Mon, 28 Jun 2010 10:53:47 -0700 Message-ID: <AANLkTilYLA2AktwMv3ZIHTHFMwvDOOsOTxANhKzYhyrZ@mail.gmail.com> To: Robert Sayre <sayrer@gmail.com> Content-Type: multipart/alternative; boundary=00c09f88cfafcd3599048a1acea3 X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] JSON parsing in the browser (was: Proposal for single JSON response format) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 28 Jun 2010 17:54:04 -0000 --00c09f88cfafcd3599048a1acea3 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Jun 27, 2010 at 1:46 PM, Robert Sayre <sayrer@gmail.com> wrote: > On Sun, Jun 13, 2010 at 11:20 AM, Evan Gilbert <uidude@google.com> wrote: > > > >> > >> Can you explain the XSS hole from parsing a random JSON string? > > > > Naive processor calls: > > var href = document.location.href; > > var jsonBlob = href.substring(href.indexOf('#'), href.length) > > var userData = eval(jsonBlob); > > This code would allow executing arbitrary code by sending a user a link, > > which could, for example, steal your cookies on a site. > > The fix is just a really complicated RegEx match > > I don't agree with this assessment. What specifically don't you agree with? I agree that the RegEx match or a library will fix the security hole. The problem is that the insecure behavior - "eval(json)" - will just work, is obvious for developers to try, and non-obvious why this is a security hole. > The fix is to use json2.js from > json.org (which does indeed use a really complicated regex) if there > is no global JSON object available in the browser. A global JSON > object is available in IE8+, Firefox 3.5+, Safari 4.0.x+, and Chrome > and Opera (don't have the versions handy). > "Skate to where the puck is going, not to where it is." -- Wayne Gretzky > > -- > > Robert Sayre > > "I would have written a shorter letter, but I did not have the time." > --00c09f88cfafcd3599048a1acea3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <br><br><div class=3D"gmail_quote">On Sun, Jun 27, 2010 at 1:46 PM, Robert = Sayre <span dir=3D"ltr"><<a href=3D"mailto:sayrer@gmail.com">sayrer@gmai= l.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"m= argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> On Sun, Jun 13, 2010 at 11:20 AM, Evan Gilbert <<a href=3D"mailto:uidude= @google.com">uidude@google.com</a>> wrote:<br> ><br> >><br> >> Can you explain the XSS hole from parsing a random JSON string?<br= > ><br> > Naive processor calls:<br> > var href =3D document.location.href;<br> > var jsonBlob =3D href.substring(href.indexOf('#'), href.length= )<br> > var userData =A0=3D eval(jsonBlob);<br> > This code would allow executing arbitrary code by sending a user a lin= k,<br> > which could, for example, steal your cookies on a site.<br> > The fix is just a really complicated RegEx match<br> <br> I don't agree with this assessment. </blockquote><div><br></div><div>Wh= at specifically don't you agree with? I agree that the RegEx match or a= library will fix the security hole.</div><div><br></div><div>The problem i= s that the insecure behavior - "eval(json)" - will just work, is = obvious for developers to try, and non-obvious why this is a security hole.= </div> <div><br></div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"mar= gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">The fix is to = use json2.js from<br> <a href=3D"http://json.org" target=3D"_blank">json.org</a> (which does inde= ed use a really complicated regex) if there<br> is no global JSON object available in the browser. A global JSON<br> object is available in IE8+, Firefox 3.5+, Safari 4.0.x+, and Chrome<br> and Opera (don't have the versions handy).</blockquote><blockquote clas= s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad= ding-left:1ex;"> <br> "Skate to where the puck is going, not to where it is." -- Wayne = Gretzky<br> <font color=3D"#888888"><br> --<br> <br> Robert Sayre<br> <br> "I would have written a shorter letter, but I did not have the time.&q= uot;<br> </font></blockquote></div><br> --00c09f88cfafcd3599048a1acea3-- From torsten@lodderstedt.net Mon Jun 28 11:07:39 2010 Return-Path: <torsten@lodderstedt.net> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6CBC3A6924 for <oauth@core3.amsl.com>; Mon, 28 Jun 2010 11:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.367 X-Spam-Level: X-Spam-Status: No, score=-1.367 tagged_above=-999 required=5 tests=[AWL=0.881, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZH0h-WPGOcC for <oauth@core3.amsl.com>; Mon, 28 Jun 2010 11:07:39 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.14]) by core3.amsl.com (Postfix) with ESMTP id C92863A68E8 for <oauth@ietf.org>; Mon, 28 Jun 2010 11:07:38 -0700 (PDT) Received: from p4fff2973.dip.t-dialin.net ([79.255.41.115] helo=[127.0.0.1]) by smtprelay02.ispgateway.de with esmtpa (Exim 4.68) (envelope-from <torsten@lodderstedt.net>) id 1OTIkF-0000eF-A0; Mon, 28 Jun 2010 20:07:47 +0200 Message-ID: <4C28E4F2.6060605@lodderstedt.net> Date: Mon, 28 Jun 2010 20:07:46 +0200 From: Torsten Lodderstedt <torsten@lodderstedt.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Dick Hardt <dick.hardt@gmail.com> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EC84ADE@P3PW5EX1MB01.EX1.SECURESERVER.NET> <269A7D01-CB98-46F3-9D17-C0AAA31041E4@gmail.com> In-Reply-To: <269A7D01-CB98-46F3-9D17-C0AAA31041E4@gmail.com> Content-Type: multipart/alternative; boundary="------------080709060204070201090706" X-Df-Sender: 141509 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] What to do about 'realm' X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 28 Jun 2010 18:07:40 -0000 This is a multi-part message in MIME format. --------------080709060204070201090706 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit +1 Am 28.06.2010 07:37, schrieb Dick Hardt: > I vote for (3) unless a good (4) is suggested. > > On 2010-06-27, at 6:51 PM, Eran Hammer-Lahav wrote: > >> Over the past year many people expressed concerns about the use of >> the ‘realm’ WWW-Authenticate header parameter. The parameter is >> defined in RFC 2617 as required, and is allowed to have >> scheme-specific structure. >> We have a few options: >> 1. Leave it as required under the definition of RFC 2617 (i.e. >> provide no help, developers will need to ready 2617 and figure out >> what to do with it). >> 2. Update 2617 to remove the requirement – this is not going to be >> easy or possible to predict success. >> 3. Provide specific guidance as to what to do with the realm parameter. >> 4. Something else. >> Comments? >> EHL >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --------------080709060204070201090706 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=windows-1252" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> +1<br> <br> Am 28.06.2010 07:37, schrieb Dick Hardt: <blockquote cite="mid:269A7D01-CB98-46F3-9D17-C0AAA31041E4@gmail.com" type="cite"><base href="x-msg://96/">I vote for (3) unless a good (4) is suggested. <div><br> <div> <div>On 2010-06-27, at 6:51 PM, Eran Hammer-Lahav wrote:</div> <br class="Apple-interchange-newline"> <blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; font-size: medium;"> <div link="blue" vlink="purple" lang="EN-US"> <div class="WordSection1" style="page: WordSection1;"> <div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri,sans-serif;">Over the past year many people expressed concerns about the use of the ‘realm’ WWW-Authenticate header parameter. The parameter is defined in RFC 2617 as required, and is allowed to have scheme-specific structure.<o:p></o:p></div> <div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri,sans-serif;"><o:p> </o:p></div> <div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri,sans-serif;">We have a few options:<o:p></o:p></div> <div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri,sans-serif;"><o:p> </o:p></div> <div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri,sans-serif;">1. Leave it as required under the definition of RFC 2617 (i.e. provide no help, developers will need to ready 2617 and figure out what to do with it).<o:p></o:p></div> <div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri,sans-serif;">2. Update 2617 to remove the requirement – this is not going to be easy or possible to predict success.<o:p></o:p></div> <div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri,sans-serif;">3. Provide specific guidance as to what to do with the realm parameter.<o:p></o:p></div> <div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri,sans-serif;">4. Something else.<o:p></o:p></div> <div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri,sans-serif;"><o:p> </o:p></div> <div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri,sans-serif;">Comments?<o:p></o:p></div> <div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri,sans-serif;"><o:p> </o:p></div> <div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri,sans-serif;">EHL<o:p></o:p></div> </div> _______________________________________________<br> OAuth mailing list<br> <a moz-do-not-send="true" href="mailto:OAuth@ietf.org" style="color: blue; text-decoration: underline;">OAuth@ietf.org</a><br> <a moz-do-not-send="true" href="https://www.ietf.org/mailman/listinfo/oauth" style="color: blue; text-decoration: underline;">https://www.ietf.org/mailman/listinfo/oauth</a><br> </div> </span></blockquote> </div> <br> </div> <pre wrap=""> <fieldset class="mimeAttachmentHeader"></fieldset> _______________________________________________ OAuth mailing list <a class="moz-txt-link-abbreviated" href="mailto:OAuth@ietf.org">OAuth@ietf.org</a> <a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/oauth">https://www.ietf.org/mailman/listinfo/oauth</a> </pre> </blockquote> </body> </html> --------------080709060204070201090706-- From mscurtescu@google.com Mon Jun 28 11:11:39 2010 Return-Path: <mscurtescu@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EC5B3A6949 for <oauth@core3.amsl.com>; Mon, 28 Jun 2010 11:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.616 X-Spam-Level: X-Spam-Status: No, score=-100.616 tagged_above=-999 required=5 tests=[AWL=-0.498, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RwtG5ySIr+tN for <oauth@core3.amsl.com>; Mon, 28 Jun 2010 11:11:38 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id DDD103A6943 for <oauth@ietf.org>; Mon, 28 Jun 2010 11:11:37 -0700 (PDT) Received: from wpaz13.hot.corp.google.com (wpaz13.hot.corp.google.com [172.24.198.77]) by smtp-out.google.com with ESMTP id o5SIBkW5022666 for <oauth@ietf.org>; Mon, 28 Jun 2010 11:11:46 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1277748706; bh=tffYm7OoTwDE7lndE0B4woEBAKE=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=VD7eZLlEaA38m6ja6B5Z3n47Ac/dWQKOwhMV7ji3913w/MQNE/cxwdUWXp3DUwlfW aEXjsBOqgFsGO9JNyMbZw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding:x-system-of-record; b=Llvith2ZdpWL6vvv6dpfd8A5Cd+9X7AfqSY0xQsk+TihW9ayCQyltj+/bsNd424RJ YZqrvIaeiqwcWXg0IQIRg== Received: from gwaa12 (gwaa12.prod.google.com [10.200.27.12]) by wpaz13.hot.corp.google.com with ESMTP id o5SIAd9h005257 for <oauth@ietf.org>; Mon, 28 Jun 2010 11:11:45 -0700 Received: by gwaa12 with SMTP id a12so2045997gwa.34 for <oauth@ietf.org>; Mon, 28 Jun 2010 11:11:45 -0700 (PDT) Received: by 10.101.151.26 with SMTP id d26mr6967610ano.190.1277748704301; Mon, 28 Jun 2010 11:11:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.132.22 with HTTP; Mon, 28 Jun 2010 11:11:24 -0700 (PDT) In-Reply-To: <4C259112.2040901@lodderstedt.net> References: <AANLkTil1BK4e6o6XSztS31Y-RhXgn01MByP7EBP9twwl@mail.gmail.com> <AANLkTinYLwvJy5T5ZRRpSWj48TvSBzcno93mkDyI63Fi@mail.gmail.com> <AANLkTimOWWZ_fc9KUzS6ZJxvDc_RfL-hoWOVxo-azELU@mail.gmail.com> <4C259112.2040901@lodderstedt.net> From: Marius Scurtescu <mscurtescu@google.com> Date: Mon, 28 Jun 2010 11:11:24 -0700 Message-ID: <AANLkTikbPNugfdxVGthe7qVrxPTpDoya_b_v42M8wrdk@mail.gmail.com> To: Torsten Lodderstedt <torsten@lodderstedt.net> 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] OAuth 2 for Native Apps X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 28 Jun 2010 18:11:39 -0000 On Fri, Jun 25, 2010 at 10:33 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote: > comment/question regarding the Embedded Browser scenario: Is the URL bar = and > SSL verification symbols (lock + green bar) visible in that scenario? > Otherwise, the user has no chance to verify the identity of the IDP/OAuth > server. So there might be problems regarding password phishing . AFAIK the URL bar is not visible. Who would phish the end user? If it is the native app, then all bets are off regardless, the native app can show a fake address bar if it really wants. Marius > > regards, > Torsten. > > Am 22.06.2010 02:54, schrieb Marius Scurtescu: >> >> Here is the wiki page: http://wiki.oauth.net/OAuth-2-for-Native-Apps >> >> Feel free to edit or comment. >> >> Marius >> >> >> >> On Wed, Jun 9, 2010 at 10:59 AM, David Recordon<recordond@gmail.com> >> =A0wrote: >> >>> >>> Want to put this on the wiki http://wiki.oauth.net/? >>> >>> >>> On Mon, Jun 7, 2010 at 12:25 PM, Marius Scurtescu<mscurtescu@google.com= > >>> =A0wrote: >>> >>>> >>>> Hi, >>>> >>>> I attached a document that summaries how native applications can use >>>> OAuth 2. >>>> >>>> Feedback more than welcome, especially if you have experience with >>>> native apps and OAuth. >>>> >>>> The current Web Server and Device flows need small changes and >>>> clarifications in order to properly support native apps, I will start >>>> a separate thread on that. >>>> >>>> Marius >>>> >>>> _______________________________________________ >>>> OAuth mailing 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 torsten@lodderstedt.net Mon Jun 28 11:21:20 2010 Return-Path: <torsten@lodderstedt.net> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CD423A693F for <oauth@core3.amsl.com>; Mon, 28 Jun 2010 11:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.477 X-Spam-Level: X-Spam-Status: No, score=-0.477 tagged_above=-999 required=5 tests=[AWL=-0.088, BAYES_20=-0.74, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xNzHgnByG9u7 for <oauth@core3.amsl.com>; Mon, 28 Jun 2010 11:21:04 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.39]) by core3.amsl.com (Postfix) with ESMTP id 4B54F3A691F for <oauth@ietf.org>; Mon, 28 Jun 2010 11:21:00 -0700 (PDT) Received: from p4fff2973.dip.t-dialin.net ([79.255.41.115] helo=[127.0.0.1]) by smtprelay01.ispgateway.de with esmtpa (Exim 4.68) (envelope-from <torsten@lodderstedt.net>) id 1OTIxB-0006Bk-6v; Mon, 28 Jun 2010 20:21:09 +0200 Message-ID: <4C28E814.1060102@lodderstedt.net> Date: Mon, 28 Jun 2010 20:21:08 +0200 From: Torsten Lodderstedt <torsten@lodderstedt.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Eran Hammer-Lahav <eran@hueniverse.com> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EC84C9D@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EC84C9D@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: multipart/alternative; boundary="------------070007090501050404040906" X-Df-Sender: 141509 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Client credentials type X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 28 Jun 2010 18:21:21 -0000 This is a multi-part message in MIME format. --------------070007090501050404040906 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I would prefer (2) since authorization headers are the natural way to handle authentication in HTTP. Different client credential mechanisms can be represented by different authentication scheme (even custom-defined). HTTP libraries typically have special support for handling such headers and it keeps the authentication mechanism orthogonal of the API. Moreover, authorization headers very well work together with status code 401 and WWW-Authenticate headers. Using WWW-Authenticate headers, an authz server can easily signal what mechanisms (multiple WWW-Authenticate headers are allowed in a single HTTP response) it accepts for a particular request. regards, Torsten. Am 28.06.2010 19:39, schrieb Eran Hammer-Lahav: > > Yaron Goland offered a proposal for an additional client credentials > mechanism based on assertion. His proposal raises the issue of > differentiating between the different kind of credentials used. When > it comes to access grant types, this group argued for being explicit > and providing a parameter declaring the grant type being used (even > though it is not technically necessary). > > While I don't believe a grant or credential type parameter is needed > -- the type can be deduced from the other parameters present -- we now > treat the same requirement with a different solution. I think this > creates a broken environment for extensibility (which is my current > focus). > > At the same time, introducing such a parameter can conflict with the > standard HTTP authentication mechanism. For example, a request > containing both "client_credentials_type=basic" and the HTTP > Authorization header seems odd. > > There are a few ways to address this: > > 1. Only use a type parameter when the credentials are passed using > parameters and not a header. > > 2. Only allow HTTP headers for authentication, while > "grandfathering-in" the client_secret parameter to simplify the most > common current practice. > > 3. Leave is underspecified, relying on the presence of extension > parameters or authentication headers for other credentials types. > > Thoughts? > > EHL > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --------------070007090501050404040906 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> I would prefer (2) since authorization headers are the natural way to handle authentication in HTTP. Different client credential mechanisms can be represented by different authentication scheme (even custom-defined). HTTP libraries typically have special support for handling such headers and it keeps the authentication mechanism orthogonal of the API. Moreover, authorization headers very well work together with status code 401 and WWW-Authenticate headers. Using WWW-Authenticate headers, an authz server can easily signal what mechanisms (multiple WWW-Authenticate headers are allowed in a single HTTP response) it accepts for a particular request.<br> <br> regards,<br> Torsten. <br> <br> Am 28.06.2010 19:39, schrieb Eran Hammer-Lahav: <blockquote cite="mid:90C41DD21FB7C64BB94121FBBC2E72343B3EC84C9D@P3PW5EX1MB01.EX1.SECURESERVER.NET" type="cite"> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> <meta name="Generator" content="Microsoft Word 14 (filtered medium)"> <style><!-- /* Font Definitions */ @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {mso-style-priority:34; margin-top:0in; margin-right:0in; margin-bottom:0in; margin-left:.5in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} span.EmailStyle17 {mso-style-type:personal-compose; font-family:"Calibri","sans-serif"; color:windowtext;} .MsoChpDefault {mso-style-type:export-only; font-family:"Calibri","sans-serif";} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext="edit" spidmax="1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext="edit"> <o:idmap v:ext="edit" data="1" /> </o:shapelayout></xml><![endif]--> <div class="WordSection1"> <p class="MsoNormal">Yaron Goland offered a proposal for an additional client credentials mechanism based on assertion. His proposal raises the issue of differentiating between the different kind of credentials used. When it comes to access grant types, this group argued for being explicit and providing a parameter declaring the grant type being used (even though it is not technically necessary).<o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal">While I don’t believe a grant or credential type parameter is needed – the type can be deduced from the other parameters present – we now treat the same requirement with a different solution. I think this creates a broken environment for extensibility (which is my current focus).<o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal">At the same time, introducing such a parameter can conflict with the standard HTTP authentication mechanism. For example, a request containing both “client_credentials_type=basic” and the HTTP Authorization header seems odd.<o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal">There are a few ways to address this:<o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal">1. Only use a type parameter when the credentials are passed using parameters and not a header.<o:p></o:p></p> <p class="MsoNormal">2. Only allow HTTP headers for authentication, while “grandfathering-in” the client_secret parameter to simplify the most common current practice.<o:p></o:p></p> <p class="MsoNormal">3. Leave is underspecified, relying on the presence of extension parameters or authentication headers for other credentials types.<o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal">Thoughts?<o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal">EHL<o:p></o:p></p> </div> <pre wrap=""> <fieldset class="mimeAttachmentHeader"></fieldset> _______________________________________________ OAuth mailing list <a class="moz-txt-link-abbreviated" href="mailto:OAuth@ietf.org">OAuth@ietf.org</a> <a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/oauth">https://www.ietf.org/mailman/listinfo/oauth</a> </pre> </blockquote> </body> </html> --------------070007090501050404040906-- From sarahfaulkner3@gmail.com Mon Jun 28 11:29:02 2010 Return-Path: <sarahfaulkner3@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 682F23A6809 for <oauth@core3.amsl.com>; Mon, 28 Jun 2010 11:29:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.184 X-Spam-Level: X-Spam-Status: No, score=-0.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fYd0Od8CXBqc for <oauth@core3.amsl.com>; Mon, 28 Jun 2010 11:29:01 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id B83703A67B1 for <oauth@ietf.org>; Mon, 28 Jun 2010 11:29:00 -0700 (PDT) Received: by pwi2 with SMTP id 2so155084pwi.31 for <oauth@ietf.org>; Mon, 28 Jun 2010 11:29:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=+uARfydz8doPHl8yO1DJASfdNa0YPTR/llK43MU+vh4=; b=aUhe+9sWj3BFRZDfyMM5dklUv8MOKZgoQxt6w3RPCIRENF2pSa1SpVmQw/EUY931Zm 1LLLrcR8hD8s9cSjEbhd/7C7KQdEGlrMrMquI0fHPU8lrg0bonH4CqlPcy/AnVqw8+ln JK57xcmWZIhDqfqbNe283gS01452dhk4V06xM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=pBIpJDEA8YQWdY7XhmtC7hR+Fe1EcRDkkwflQX1bZRicmBBiq1imatTDpo6F6XRqr/ 6P5hdfsrkS/4+F42HyUNhZgv+2qDKZkaNZP3XIdjN8mqup/kTkx48X3w0n3x5MODZWvV 6B5VoAjGQmxSTztTrJbEU7mGyTQ20ryQzQY8w= MIME-Version: 1.0 Received: by 10.142.152.18 with SMTP id z18mr6346543wfd.230.1277749748155; Mon, 28 Jun 2010 11:29:08 -0700 (PDT) Received: by 10.142.97.9 with HTTP; Mon, 28 Jun 2010 11:29:08 -0700 (PDT) Date: Mon, 28 Jun 2010 11:29:08 -0700 Message-ID: <AANLkTinXrAKxkciklJPUEgDdN3bcEDWmZ18b3ADPGgjs@mail.gmail.com> From: Sarah Faulkner <sarahfaulkner3@gmail.com> To: OAuth WG <oauth@ietf.org> Content-Type: multipart/alternative; boundary=000e0cd2e05cd9c4d5048a1b4bfc Subject: [OAUTH-WG] Messenger Connect ships today X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 28 Jun 2010 18:29:02 -0000 --000e0cd2e05cd9c4d5048a1b4bfc Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Windows Live just shipped a beta of our Messenger Connect platform. The platform uses OAuth WRAP (among other standards<https://mail.exchange.microsoft.com/owa/redir.aspx?C=3Dd58070642e= a545469fe36f1c5485feff&URL=3Dhttp%3a%2f%2fwindowsteamblog.com%2fwindows_liv= e%2fb%2fdeveloper%2farchive%2f2010%2f06%2f27%2fdeveloping-with-messenger-co= nnect.aspx>) and a new consent dialogue<https://mail.exchange.microsoft.com/owa/redir.aspx?C=3Dd58070642ea= 545469fe36f1c5485feff&URL=3Dhttp%3a%2f%2fwindowsteamblog.com%2fcfs-filesyst= emfile.ashx%2f__key%2fCommunityServer-Blogs-Components-WeblogFiles%2f00-00-= 00-53-82-metablogapi%2f8585.image_5F00_60058FEB.png>to enable third party websites to access a user=92s Windows Live data. Some of the data that Messenger Connect beta will give third party websites access to is: contacts, activity streams, calendar, and photos. Messenger Connect will also support sign-up and sign-in with a Windows Live ID and chat through web messenger on the third party site. For more information, read our blog post<https://mail.exchange.microsoft.com/owa/redir.aspx?C=3Dd58070642ea5454= 69fe36f1c5485feff&URL=3Dhttp%3a%2f%2fwindowsteamblog.com%2fwindows_live%2fb= %2fwindowslive%2farchive%2f2010%2f06%2f28%2fmessenger-connect-is-now-availa= ble.aspx>announcing the release, and check out the documentation<https://mail.exchange.microsoft.com/owa/redir.aspx?C=3Dd58070= 642ea545469fe36f1c5485feff&URL=3Dhttp%3a%2f%2fmsdn.microsoft.com%2fen-us%2f= library%2fff749458.aspx>. If you want to try it out, here are the instructions<https://mail.exchange.microsoft.com/owa/redir.aspx?C=3Dd580706= 42ea545469fe36f1c5485feff&URL=3Dhttp%3a%2f%2fsocial.msdn.microsoft.com%2fFo= rums%2fen-US%2fmessengerconnect%2fthread%2f6a63b5b9-3603-4662-8996-929b83ea= a1f9>for how to sign up for the Messenger Connect beta and get access to the libraries. We=92d love to hear your feedback through the forums, e-mail, et= c. --000e0cd2e05cd9c4d5048a1b4bfc Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable <div class=3D"MsoNormal"><span style=3D"FONT-FAMILY: 'Franklin Gothic M= edium','sans-serif'; COLOR: #002060">Windows Live just shipped = a beta of our Messenger Connect platform. The platform uses OAuth WRAP (amo= ng <a href=3D"https://mail.exchange.microsoft.com/owa/redir.aspx?C=3Dd58070= 642ea545469fe36f1c5485feff&URL=3Dhttp%3a%2f%2fwindowsteamblog.com%2fwin= dows_live%2fb%2fdeveloper%2farchive%2f2010%2f06%2f27%2fdeveloping-with-mess= enger-connect.aspx" target=3D"_blank"><font color=3D"#0000ff">other standar= ds</font></a>) and a new <a href=3D"https://mail.exchange.microsoft.com/owa= /redir.aspx?C=3Dd58070642ea545469fe36f1c5485feff&URL=3Dhttp%3a%2f%2fwin= dowsteamblog.com%2fcfs-filesystemfile.ashx%2f__key%2fCommunityServer-Blogs-= Components-WeblogFiles%2f00-00-00-53-82-metablogapi%2f8585.image_5F00_60058= FEB.png" target=3D"_blank"><font color=3D"#0000ff">consent dialogue</font><= /a> to enable third party websites to access a user=92s Windows Live data. = Some of the data that Messenger Connect beta will give third party websites= access to is: contacts, activity streams, calendar, and photos. Messenger = Connect will also support sign-up and sign-in with a Windows Live ID and ch= at through web messenger on the third party site.</span></div> <div class=3D"MsoNormal"><span style=3D"FONT-FAMILY: 'Franklin Gothic M= edium','sans-serif'; COLOR: #002060"></span>=A0</div> <div class=3D"MsoNormal"><span style=3D"FONT-FAMILY: 'Franklin Gothic M= edium','sans-serif'; COLOR: #002060"></span><span style=3D"FONT= -FAMILY: 'Franklin Gothic Medium','sans-serif'; COLOR: #002= 060">For more information, read our <a href=3D"https://mail.exchange.micros= oft.com/owa/redir.aspx?C=3Dd58070642ea545469fe36f1c5485feff&URL=3Dhttp%= 3a%2f%2fwindowsteamblog.com%2fwindows_live%2fb%2fwindowslive%2farchive%2f20= 10%2f06%2f28%2fmessenger-connect-is-now-available.aspx" target=3D"_blank"><= font color=3D"#0000ff">blog post</font></a> announcing the release, and che= ck out the <a href=3D"https://mail.exchange.microsoft.com/owa/redir.aspx?C= =3Dd58070642ea545469fe36f1c5485feff&URL=3Dhttp%3a%2f%2fmsdn.microsoft.c= om%2fen-us%2flibrary%2fff749458.aspx" target=3D"_blank"><font color=3D"#000= 0ff">documentation</font></a>. If you want to try it out, here are the <a h= ref=3D"https://mail.exchange.microsoft.com/owa/redir.aspx?C=3Dd58070642ea54= 5469fe36f1c5485feff&URL=3Dhttp%3a%2f%2fsocial.msdn.microsoft.com%2fForu= ms%2fen-US%2fmessengerconnect%2fthread%2f6a63b5b9-3603-4662-8996-929b83eaa1= f9" target=3D"_blank"><font color=3D"#0000ff">instructions</font></a> for h= ow to sign up for the Messenger Connect beta and get access to the librarie= s. We=92d love to hear your feedback through the forums, e-mail, etc.</span= ></div> --000e0cd2e05cd9c4d5048a1b4bfc-- From mscurtescu@google.com Mon Jun 28 12:19:54 2010 Return-Path: <mscurtescu@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89FF43A6952 for <oauth@core3.amsl.com>; Mon, 28 Jun 2010 12:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.781 X-Spam-Level: X-Spam-Status: No, score=-100.781 tagged_above=-999 required=5 tests=[AWL=-0.293, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Ze272TlrCJ9 for <oauth@core3.amsl.com>; Mon, 28 Jun 2010 12:19:53 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 4B9553A6923 for <oauth@ietf.org>; Mon, 28 Jun 2010 12:19:53 -0700 (PDT) Received: from hpaq3.eem.corp.google.com (hpaq3.eem.corp.google.com [172.25.149.3]) by smtp-out.google.com with ESMTP id o5SJK23E020301 for <oauth@ietf.org>; Mon, 28 Jun 2010 12:20:02 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1277752802; bh=zMr6bkhC1zACT6xUojw7TTwZYX8=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=TnJoEdN3IlMj37t4EUsSkTWxcja5Q8y4C5RnwY2kS7aUa3PfhIfobqRaOfYA1xT0n 8TSk+qkJiyhEFQdvf93SA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding:x-system-of-record; b=xtJoXfg2yu2ok348HYzP80sLeg5dl18j8tSiT5Nb2F6VQzkCnB7Tz2a6/4td9pt/P zbCTDf1UgLWzFI/Tx1fbQ== Received: from gyf1 (gyf1.prod.google.com [10.243.50.65]) by hpaq3.eem.corp.google.com with ESMTP id o5SJK0dW027357 for <oauth@ietf.org>; Mon, 28 Jun 2010 12:20:01 -0700 Received: by gyf1 with SMTP id 1so9466gyf.28 for <oauth@ietf.org>; Mon, 28 Jun 2010 12:20:00 -0700 (PDT) Received: by 10.100.171.18 with SMTP id t18mr693587ane.160.1277752800190; Mon, 28 Jun 2010 12:20:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.132.22 with HTTP; Mon, 28 Jun 2010 12:19:40 -0700 (PDT) In-Reply-To: <4C28E814.1060102@lodderstedt.net> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EC84C9D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C28E814.1060102@lodderstedt.net> From: Marius Scurtescu <mscurtescu@google.com> Date: Mon, 28 Jun 2010 12:19:40 -0700 Message-ID: <AANLkTilw0noo6qyKKXDI06Y4bIiippjvjGRFia0MwXmY@mail.gmail.com> To: Torsten Lodderstedt <torsten@lodderstedt.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Client credentials type X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 28 Jun 2010 19:19:54 -0000 Only HTTP headers may not be enough. In Yaron's proposal, the assertion could be a SAML assertion, and these could be too large for headers. I think #1 makes sense. Marius On Mon, Jun 28, 2010 at 11:21 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote: > I would prefer (2) since authorization headers are the natural way to han= dle > authentication in HTTP. Different client credential mechanisms can be > represented by different authentication scheme (even custom-defined). HTT= P > libraries typically have special support for handling such headers and it > keeps the authentication mechanism orthogonal of the API. Moreover, > authorization headers very well work together with status code 401 and > WWW-Authenticate headers. Using WWW-Authenticate headers, an authz server > can easily signal what mechanisms (multiple WWW-Authenticate headers are > allowed in a single HTTP response) it accepts for a particular request. > > regards, > Torsten. > > Am 28.06.2010 19:39, schrieb Eran Hammer-Lahav: > > Yaron Goland offered a proposal for an additional client credentials > mechanism based on assertion. His proposal raises the issue of > differentiating between the different kind of credentials used. When it > comes to access grant types, this group argued for being explicit and > providing a parameter declaring the grant type being used (even though it= is > not technically necessary). > > > > While I don=92t believe a grant or credential type parameter is needed = =96 the > type can be deduced from the other parameters present =96 we now treat th= e > same requirement with a different solution. I think this creates a broken > environment for extensibility (which is my current focus). > > > > At the same time, introducing such a parameter can conflict with the > standard HTTP authentication mechanism. For example, a request containing > both =93client_credentials_type=3Dbasic=94 and the HTTP Authorization hea= der seems > odd. > > > > There are a few ways to address this: > > > > 1. Only use a type parameter when the credentials are passed using > parameters and not a header. > > 2. Only allow HTTP headers for authentication, while =93grandfathering-in= =94 the > client_secret parameter to simplify the most common current practice. > > 3. Leave is underspecified, relying on the presence of extension paramete= rs > or authentication headers for other credentials types. > > > > Thoughts? > > > > 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 dick.hardt@gmail.com Mon Jun 28 12:24:49 2010 Return-Path: <dick.hardt@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F35883A693E for <oauth@core3.amsl.com>; Mon, 28 Jun 2010 12:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.451 X-Spam-Level: X-Spam-Status: No, score=-2.451 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8UKdXXgGnIMh for <oauth@core3.amsl.com>; Mon, 28 Jun 2010 12:24:48 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id 025A13A691D for <oauth@ietf.org>; Mon, 28 Jun 2010 12:24:47 -0700 (PDT) Received: by pxi16 with SMTP id 16so1580191pxi.31 for <oauth@ietf.org>; Mon, 28 Jun 2010 12:24:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:message-id:references:to :x-mailer; bh=/wtCDVxHiqQMKN5/DQlVHIm2DboOBKmmaIHFhiQZ9oc=; b=B1Nx8jn1sH92HjDqWee2Mq7MbcA1leh/q17BhzvHQu02W7dMTMLuJD7wZO5AB630Vj E33RRis+AyHXe9EXKvGCNyyPc7B0cjk8TozifbJ/yuq/fjgsc8hMCZLPGf3DE1eTjl6q w73oc32x/Kz59LRE6qsgJ67iUBUapcjlEQd6g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; b=vuVFomK0D8nWqQm4es6V5eyg7hh0/Tfpi20v7G1HWSq8LZCeYxJe4xLRfCyz06iAcd /8ZuwJSaeRvC5eXZgD+xmEfiNOvLmnsyxLvVLHOPtt8PRlTksi+nI+3wTzW5LlazuyK4 ckdVO3gQbDm+M9avPHWoxEqKKo1WiFbIP12I4= Received: by 10.114.164.37 with SMTP id m37mr6014168wae.39.1277753095422; Mon, 28 Jun 2010 12:24:55 -0700 (PDT) Received: from [192.168.1.5] ([24.130.32.55]) by mx.google.com with ESMTPS id h4sm50485261wae.11.2010.06.28.12.24.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 28 Jun 2010 12:24:53 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-21-945665006 From: Dick Hardt <dick.hardt@gmail.com> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EC84C9D@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 28 Jun 2010 12:24:51 -0700 Message-Id: <227B14C5-25DB-43F9-8754-ECB09EB33205@gmail.com> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EC84C9D@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav <eran@hueniverse.com> X-Mailer: Apple Mail (2.1081) Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Client credentials type X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 28 Jun 2010 19:24:49 -0000 --Apple-Mail-21-945665006 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 While the AS implementor can infer the request by the parameters, I = prefer the programmer explicitly state what she is doing. Thinking of it = as a method parameter rather than a type parameter makes more sense to = me. Similiarly, HTTP has GET, POST, PUT etc. even though you could = differentiate between them by looking at what was passed or not passed. -- Dick On 2010-06-28, at 10:39 AM, Eran Hammer-Lahav wrote: > Yaron Goland offered a proposal for an additional client credentials = mechanism based on assertion. His proposal raises the issue of = differentiating between the different kind of credentials used. When it = comes to access grant types, this group argued for being explicit and = providing a parameter declaring the grant type being used (even though = it is not technically necessary). > =20 > While I don=92t believe a grant or credential type parameter is needed = =96 the type can be deduced from the other parameters present =96 we now = treat the same requirement with a different solution. I think this = creates a broken environment for extensibility (which is my current = focus). > =20 > At the same time, introducing such a parameter can conflict with the = standard HTTP authentication mechanism. For example, a request = containing both =93client_credentials_type=3Dbasic=94 and the HTTP = Authorization header seems odd. > =20 > There are a few ways to address this: > =20 > 1. Only use a type parameter when the credentials are passed using = parameters and not a header. > 2. Only allow HTTP headers for authentication, while = =93grandfathering-in=94 the client_secret parameter to simplify the most = common current practice. > 3. Leave is underspecified, relying on the presence of extension = parameters or authentication headers for other credentials types. > =20 > Thoughts? > =20 > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-21-945665006 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 <html><head><base href=3D"x-msg://176/"></head><body style=3D"word-wrap: = break-word; -webkit-nbsp-mode: space; -webkit-line-break: = after-white-space; ">While the AS implementor can infer the request by = the parameters, I prefer the programmer explicitly state what she is = doing. Thinking of it as a method parameter rather than a type parameter = makes more sense to me. Similiarly, HTTP has GET, POST, PUT etc. even = though you could differentiate between them by looking at what was = passed or not passed.<div><br></div><div>-- = Dick</div><div><br><div><div>On 2010-06-28, at 10:39 AM, Eran = Hammer-Lahav wrote:</div><br = class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><span = class=3D"Apple-style-span" style=3D"border-collapse: separate; = font-family: Helvetica; font-style: normal; font-variant: normal; = font-weight: normal; letter-spacing: normal; line-height: normal; = orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; = widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; = -webkit-border-vertical-spacing: 0px; = -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: = auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div = lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div class=3D"WordSection1" = style=3D"page: WordSection1; "><div style=3D"margin-top: 0in; = margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: = 11pt; font-family: Calibri, sans-serif; ">Yaron Goland offered a = proposal for an additional client credentials mechanism based on = assertion. His proposal raises the issue of differentiating between the = different kind of credentials used. When it comes to access grant types, = this group argued for being explicit and providing a parameter declaring = the grant type being used (even though it is not technically = necessary).<o:p></o:p></div><div style=3D"margin-top: 0in; margin-right: = 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 11pt; = font-family: Calibri, sans-serif; "><o:p> </o:p></div><div = style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; = margin-left: 0in; font-size: 11pt; font-family: Calibri, sans-serif; = ">While I don=92t believe a grant or credential type parameter is needed = =96 the type can be deduced from the other parameters present =96 we now = treat the same requirement with a different solution. I think this = creates a broken environment for extensibility (which is my current = focus).<o:p></o:p></div><div style=3D"margin-top: 0in; margin-right: = 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 11pt; = font-family: Calibri, sans-serif; "><o:p> </o:p></div><div = style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; = margin-left: 0in; font-size: 11pt; font-family: Calibri, sans-serif; = ">At the same time, introducing such a parameter can conflict with the = standard HTTP authentication mechanism. For example, a request = containing both =93client_credentials_type=3Dbasic=94 and the HTTP = Authorization header seems odd.<o:p></o:p></div><div style=3D"margin-top: = 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; = font-size: 11pt; font-family: Calibri, sans-serif; = "><o:p> </o:p></div><div style=3D"margin-top: 0in; margin-right: = 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 11pt; = font-family: Calibri, sans-serif; ">There are a few ways to address = this:<o:p></o:p></div><div style=3D"margin-top: 0in; margin-right: 0in; = margin-bottom: 0.0001pt; margin-left: 0in; font-size: 11pt; font-family: = Calibri, sans-serif; "><o:p> </o:p></div><div style=3D"margin-top: = 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; = font-size: 11pt; font-family: Calibri, sans-serif; ">1. Only use a type = parameter when the credentials are passed using parameters and not a = header.<o:p></o:p></div><div style=3D"margin-top: 0in; margin-right: = 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 11pt; = font-family: Calibri, sans-serif; ">2. Only allow HTTP headers for = authentication, while =93grandfathering-in=94 the client_secret = parameter to simplify the most common current = practice.<o:p></o:p></div><div style=3D"margin-top: 0in; margin-right: = 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 11pt; = font-family: Calibri, sans-serif; ">3. Leave is underspecified, relying = on the presence of extension parameters or authentication headers for = other credentials types.<o:p></o:p></div><div style=3D"margin-top: 0in; = margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: = 11pt; font-family: Calibri, sans-serif; "><o:p> </o:p></div><div = style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; = margin-left: 0in; font-size: 11pt; font-family: Calibri, sans-serif; = ">Thoughts?<o:p></o:p></div><div style=3D"margin-top: 0in; margin-right: = 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 11pt; = font-family: Calibri, sans-serif; "><o:p> </o:p></div><div = style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; = margin-left: 0in; font-size: 11pt; font-family: Calibri, sans-serif; = ">EHL<o:p></o:p></div></div>______________________________________________= _<br>OAuth mailing list<br><a href=3D"mailto:OAuth@ietf.org" = style=3D"color: blue; text-decoration: underline; = ">OAuth@ietf.org</a><br><a = href=3D"https://www.ietf.org/mailman/listinfo/oauth" style=3D"color: = blue; text-decoration: underline; = ">https://www.ietf.org/mailman/listinfo/oauth</a><br></div></span></blockq= uote></div><br></div></body></html>= --Apple-Mail-21-945665006-- From torsten@lodderstedt.net Mon Jun 28 12:25:40 2010 Return-Path: <torsten@lodderstedt.net> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E59233A6960 for <oauth@core3.amsl.com>; Mon, 28 Jun 2010 12:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.474 X-Spam-Level: X-Spam-Status: No, score=-0.474 tagged_above=-999 required=5 tests=[AWL=-0.084, BAYES_20=-0.74, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bVWDBvbPNmxR for <oauth@core3.amsl.com>; Mon, 28 Jun 2010 12:25:38 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.38]) by core3.amsl.com (Postfix) with ESMTP id 9262C3A691D for <oauth@ietf.org>; Mon, 28 Jun 2010 12:25:38 -0700 (PDT) Received: from p4fff2973.dip.t-dialin.net ([79.255.41.115] helo=[127.0.0.1]) by smtprelay04.ispgateway.de with esmtpa (Exim 4.68) (envelope-from <torsten@lodderstedt.net>) id 1OTJxj-00066B-F0; Mon, 28 Jun 2010 21:25:47 +0200 Message-ID: <4C28F73A.4090800@lodderstedt.net> Date: Mon, 28 Jun 2010 21:25:46 +0200 From: Torsten Lodderstedt <torsten@lodderstedt.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Marius Scurtescu <mscurtescu@google.com> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EC84C9D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C28E814.1060102@lodderstedt.net> <AANLkTilw0noo6qyKKXDI06Y4bIiippjvjGRFia0MwXmY@mail.gmail.com> In-Reply-To: <AANLkTilw0noo6qyKKXDI06Y4bIiippjvjGRFia0MwXmY@mail.gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Df-Sender: 141509 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Client credentials type X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 28 Jun 2010 19:25:40 -0000 what size do you expect? SPNEGO authentication headers can be up to 12392 bytes and this does not seem to be a problem. regards, Torsten. Am 28.06.2010 21:19, schrieb Marius Scurtescu: > Only HTTP headers may not be enough. In Yaron's proposal, the > assertion could be a SAML assertion, and these could be too large for > headers. > > I think #1 makes sense. > > Marius > > > > On Mon, Jun 28, 2010 at 11:21 AM, Torsten Lodderstedt > <torsten@lodderstedt.net> wrote: > >> I would prefer (2) since authorization headers are the natural way to handle >> authentication in HTTP. Different client credential mechanisms can be >> represented by different authentication scheme (even custom-defined). HTTP >> libraries typically have special support for handling such headers and it >> keeps the authentication mechanism orthogonal of the API. Moreover, >> authorization headers very well work together with status code 401 and >> WWW-Authenticate headers. Using WWW-Authenticate headers, an authz server >> can easily signal what mechanisms (multiple WWW-Authenticate headers are >> allowed in a single HTTP response) it accepts for a particular request. >> >> regards, >> Torsten. >> >> Am 28.06.2010 19:39, schrieb Eran Hammer-Lahav: >> >> Yaron Goland offered a proposal for an additional client credentials >> mechanism based on assertion. His proposal raises the issue of >> differentiating between the different kind of credentials used. When it >> comes to access grant types, this group argued for being explicit and >> providing a parameter declaring the grant type being used (even though it is >> not technically necessary). >> >> >> >> While I don’t believe a grant or credential type parameter is needed – the >> type can be deduced from the other parameters present – we now treat the >> same requirement with a different solution. I think this creates a broken >> environment for extensibility (which is my current focus). >> >> >> >> At the same time, introducing such a parameter can conflict with the >> standard HTTP authentication mechanism. For example, a request containing >> both “client_credentials_type=basic” and the HTTP Authorization header seems >> odd. >> >> >> >> There are a few ways to address this: >> >> >> >> 1. Only use a type parameter when the credentials are passed using >> parameters and not a header. >> >> 2. Only allow HTTP headers for authentication, while “grandfathering-in” the >> client_secret parameter to simplify the most common current practice. >> >> 3. Leave is underspecified, relying on the presence of extension parameters >> or authentication headers for other credentials types. >> >> >> >> Thoughts? >> >> >> >> 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 sarahfaulkner3@gmail.com Mon Jun 28 13:11:26 2010 Return-Path: <sarahfaulkner3@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF6E93A697A for <oauth@core3.amsl.com>; Mon, 28 Jun 2010 13:11:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.647 X-Spam-Level: X-Spam-Status: No, score=-0.647 tagged_above=-999 required=5 tests=[AWL=0.463, BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VCOy-R-cpPl3 for <oauth@core3.amsl.com>; Mon, 28 Jun 2010 13:11:25 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id 6A79D3A692C for <oauth@ietf.org>; Mon, 28 Jun 2010 13:11:25 -0700 (PDT) Received: by pxi16 with SMTP id 16so1605391pxi.31 for <oauth@ietf.org>; Mon, 28 Jun 2010 13:11:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=ngokUkU/NuhDQ+Q9HEe6eMmZV+2u9e+Sm2+zR+N3cWY=; b=wZ2EuCBYjXRFvryExCR2EBi9/M0x+cT9kiYmq/+cjkQYBwwH2PqDAi8ypptCxWJ4sU q+9ffM8mRsCpbByfLAOx2yiJ1dFKZKc0551Zo/krnF7R207H8PvboY0WbcvCYmFUWNav Oe3CeI9+K5HjSxlGeLp1CcBLjDbN9C04SD+5M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=NZDjzNDFxVGB2XI4LIRItjWTzVsSOdCfdhCxfvBLJw9kZXyM5BoGGCiPshQvqaLvTS 4QBDgz6PXCtwcVRDYnWpr5fP674R5BXoWe+NdvzZmYtRtD6yaXDVEZMXlzFX4Qn/z5J1 agWRJYw7F1MPqzcd8cq5vdPTE1e/u2e+MOINM= MIME-Version: 1.0 Received: by 10.142.208.20 with SMTP id f20mr6476842wfg.295.1277755890934; Mon, 28 Jun 2010 13:11:30 -0700 (PDT) Received: by 10.142.97.9 with HTTP; Mon, 28 Jun 2010 13:11:30 -0700 (PDT) In-Reply-To: <AANLkTinXrAKxkciklJPUEgDdN3bcEDWmZ18b3ADPGgjs@mail.gmail.com> References: <AANLkTinXrAKxkciklJPUEgDdN3bcEDWmZ18b3ADPGgjs@mail.gmail.com> Date: Mon, 28 Jun 2010 13:11:30 -0700 Message-ID: <AANLkTiknaHHvqrhKBPXEE8MQYAQep33fVd9AZPZjY4kv@mail.gmail.com> From: Sarah Faulkner <sarahfaulkner3@gmail.com> To: OAuth WG <oauth@ietf.org> Content-Type: multipart/alternative; boundary=000e0cd29c9afd2339048a1cb9aa Subject: Re: [OAUTH-WG] Messenger Connect ships today X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 28 Jun 2010 20:11:27 -0000 --000e0cd29c9afd2339048a1cb9aa Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Here's a draft with the links fixed:) Windows Live just shipped a beta of our Messenger Connect platform. The platform uses OAuth WRAP (among other standards<http://windowsteamblog.com/windows_live/b/developer/archive/2010/= 06/27/developing-with-messenger-connect.aspx>) and a new consent dialogue<http://windowsteamblog.com/cfs-filesystemfile.ashx/__key/Community= Server-Blogs-Components-WeblogFiles/00-00-00-53-82-metablogapi/8585.image_5= F00_60058FEB.png>to enable third party websites to access a user=92s Windows Live data. Some of the data that Messenger Connect beta will give third party websites access to is: contacts, activity streams, calendar, and photos. Messenger Connect will also support sign-up and sign-in with a Windows Live ID and chat through web messenger on the third party site. For more information, read our blog post<http://windowsteamblog.com/windows_live/b/windowslive/archive/2010/06/= 28/messenger-connect-is-now-available.aspx>announcing the release, and check out the documentation <http://msdn.microsoft.com/en-us/library/ff749458.aspx>. If you want to try it out, here are the instructions<http://social.msdn.microsoft.com/Forums/en-US/messengerconnect= /thread/6a63b5b9-3603-4662-8996-929b83eaa1f9>for how to sign up for the Messenger Connect beta and get access to the libraries. We=92d love to hear your feedback through the forums, e-mail, et= c. --000e0cd29c9afd2339048a1cb9aa Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable <div style=3D"MARGIN: 0in 0in 0pt" class=3D"MsoNormal"><span style=3D"FONT-= FAMILY: 'Franklin Gothic Medium','sans-serif'; COLOR: #0020= 60"><font size=3D"3">Here's a draft with the links fixed:)</font></span= ></div> <div style=3D"MARGIN: 0in 0in 0pt" class=3D"MsoNormal"><span style=3D"FONT-= FAMILY: 'Franklin Gothic Medium','sans-serif'; COLOR: #0020= 60">=A0</span></div> <div style=3D"MARGIN: 0in 0in 0pt" class=3D"MsoNormal"><span style=3D"FONT-= FAMILY: 'Franklin Gothic Medium','sans-serif'; COLOR: #0020= 60"><font size=3D"3">Windows Live just shipped a beta of our Messenger Conn= ect platform. The platform uses OAuth WRAP (among </font><a href=3D"http://= windowsteamblog.com/windows_live/b/developer/archive/2010/06/27/developing-= with-messenger-connect.aspx"><font size=3D"3">other standards</font></a><fo= nt size=3D"3">) and a new </font><a href=3D"http://windowsteamblog.com/cfs-= filesystemfile.ashx/__key/CommunityServer-Blogs-Components-WeblogFiles/00-0= 0-00-53-82-metablogapi/8585.image_5F00_60058FEB.png"><font size=3D"3">conse= nt dialogue</font></a><font size=3D"3"> to enable third party websites to a= ccess a user=92s Windows Live data. Some of the data that Messenger Connect= beta will give third party websites access to is: contacts, activity strea= ms, calendar, and photos. Messenger Connect will also support sign-up and s= ign-in with a Windows Live ID and chat through web messenger on the third p= arty site.</font></span></div> <p style=3D"MARGIN: 0in 0in 0pt" class=3D"MsoNormal"><span style=3D"FONT-FA= MILY: 'Franklin Gothic Medium','sans-serif'; COLOR: #002060= "><font size=3D"3">=A0</font></span></p> <p style=3D"MARGIN: 0in 0in 0pt" class=3D"MsoNormal"><span style=3D"FONT-FA= MILY: 'Franklin Gothic Medium','sans-serif'; COLOR: #002060= "><font size=3D"3">For more information, read our </font><a href=3D"http://= windowsteamblog.com/windows_live/b/windowslive/archive/2010/06/28/messenger= -connect-is-now-available.aspx"><font size=3D"3">blog post</font></a><font = size=3D"3"> announcing the release, and check out the </font><a href=3D"htt= p://msdn.microsoft.com/en-us/library/ff749458.aspx"><font color=3D"#0000ff"= size=3D"3">documentation</font></a><font size=3D"3">. If you want to try i= t out, here are the </font><a href=3D"http://social.msdn.microsoft.com/Foru= ms/en-US/messengerconnect/thread/6a63b5b9-3603-4662-8996-929b83eaa1f9"><fon= t color=3D"#0000ff" size=3D"3">instructions</font></a><font size=3D"3"> for= how to sign up for the Messenger Connect beta and get access to the librar= ies. We=92d love to hear your feedback through the forums, e-mail, etc.</fo= nt></span></p> --000e0cd29c9afd2339048a1cb9aa-- From mscurtescu@google.com Mon Jun 28 13:27:39 2010 Return-Path: <mscurtescu@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D49F3A6978 for <oauth@core3.amsl.com>; Mon, 28 Jun 2010 13:27:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.308 X-Spam-Level: X-Spam-Status: No, score=-100.308 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R6UgBLcV6xpZ for <oauth@core3.amsl.com>; Mon, 28 Jun 2010 13:27:38 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 2B9D43A6958 for <oauth@ietf.org>; Mon, 28 Jun 2010 13:27:34 -0700 (PDT) Received: from wpaz9.hot.corp.google.com (wpaz9.hot.corp.google.com [172.24.198.73]) by smtp-out.google.com with ESMTP id o5SKRg3N017824 for <oauth@ietf.org>; Mon, 28 Jun 2010 13:27:43 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1277756863; bh=wSfffXZl7hDO/GD0Qv7OOhYRmXc=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=Nfpkf6bVyRG23etYqXJXIfLRaHxvr5lfQwq5VR9LzD7zusYyexPttLGKFPH/nrThR Cas5Tsgyc5vmscgGFNN/Q== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding:x-system-of-record; b=dtntQ05IB9zxZ+JjJwOhgQOLCPsO3yXVgyIBpxr82wdcAdZ/ps1cEf29HVc3TXYqo RVYqQS87RaLCaQ4Xw96cw== Received: from gyg13 (gyg13.prod.google.com [10.243.50.141]) by wpaz9.hot.corp.google.com with ESMTP id o5SKRfEB027769 for <oauth@ietf.org>; Mon, 28 Jun 2010 13:27:41 -0700 Received: by gyg13 with SMTP id 13so5897846gyg.25 for <oauth@ietf.org>; Mon, 28 Jun 2010 13:27:41 -0700 (PDT) Received: by 10.100.171.18 with SMTP id t18mr792264ane.160.1277756861343; Mon, 28 Jun 2010 13:27:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.132.22 with HTTP; Mon, 28 Jun 2010 13:27:20 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EC849D2@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EBB6F56@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTilB1Z3Md87vUp5bu7M6PwkeXO0R7SKpTO1M4XrV@mail.gmail.com> <AANLkTikHiCFH2Zq0rnKJBF4WmCOMd6J636HMDvrTimn_@mail.gmail.com> <AANLkTikNF74QrjhbYHeVpeZaytt9KqNBLpqFIIkdEgQZ@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3EBB71D0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTin3knKmoMoy0-mbz1nXTNwp8sfaFkn1sDHnni9m@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3EC849D2@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu <mscurtescu@google.com> Date: Mon, 28 Jun 2010 13:27:20 -0700 Message-ID: <AANLkTilttAFbBwVDgFuNTLyg4vtjoj9n9CqdUpLBHETC@mail.gmail.com> To: Eran Hammer-Lahav <eran@hueniverse.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Proposal: simplification of the end-user authorization endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 28 Jun 2010 20:27:39 -0000 On Fri, Jun 25, 2010 at 12:07 PM, Eran Hammer-Lahav <eran@hueniverse.com> w= rote: > >> -----Original Message----- >> From: Marius Scurtescu [mailto:mscurtescu@google.com] >> Sent: Thursday, June 17, 2010 2:56 PM > >> >> Basically, why cannot be that problem solved by 2 different requests, >> >> both done by the JavaScript layer? >> >> >> >> If latency is a problem, it would be good to know exactly where. I >> >> assume that authorization codes are issued very infrequently. Does >> >> this new token_and_code mode eliminate a transaction every two >> weeks? >> >> Does that make a difference? >> > >> > The advantage of the user-agent flow is that it address the lack of cl= ient >> authentication with the presence of the end-user. The server might not >> know who the client really is, but it does know that the right user is s= itting in >> front of the client authorizing the request. It doesn't solve phishing b= ut it >> provides some security. >> >> Sure, but how is this affected by token_and_code? The authz server knows >> who the user is when it issues the access token and the authorization co= de. >> The authorization code is passed down to the client server and now the c= lient >> server asks for access/refresh tokens. No user this time but potentially= there >> is a client secret. > > But those are two different parts of the client. Returning a direct acces= s token uses the fact that the end-user it present which provides a measure= of security because a good UI can help explain to the end-user what is goi= ng on and put context into the transaction. If we force clients who need th= e access token both in the client and on the server to use only the code mo= de, then they need to find a way to share that access token. However, an ac= cess token issued using a code and client secret will potentially have more= power than an access token issued using the user-agent direct communicatio= n. > > The alternative of using both flows means annoying the end-user. Not if the second flow is done in immediate mode. >> > In the case where a client (native application or user-agent) works in >> > tandem with a server-based component, using just the web-server flow >> > has two disadvantages I'm aware of: the client has to be more complex >> > because it requires callbacks in order to obtain the access token from >> > the server (multiple calls and more complex calls than just a simple >> > server-hosted script), >> >> The JavaScript client can either use the authorization code with a direc= t call >> (as you probably suggest), but then it cannot pass the authorization cod= e >> down to the client server anymore. The JavaScript client can do a separa= te >> User-Agent call in immediate mode to get an access token directly. This = is >> what it would normally do. No point in swapping the authorization code s= ince >> it can be exchanged only once. > > I think relying on immediate mode is a possible but more complex solution= which can break depending on the state of cookies and sessions. Not sure if a JavaScript client can reliably work without an immediate mode. Access tokens are short lived, the user would have to approve every single renewal (which could be every hour). Again, all I am saying is that it would help to have a very detailed use case for this token_and_code mode, to see if it is really needed. Or, an actual implementation. Marius From eran@hueniverse.com Mon Jun 28 13:37:52 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 947143A67AA for <oauth@core3.amsl.com>; Mon, 28 Jun 2010 13:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.236 X-Spam-Level: X-Spam-Status: No, score=-2.236 tagged_above=-999 required=5 tests=[AWL=0.363, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mEJlXrr27UAO for <oauth@core3.amsl.com>; Mon, 28 Jun 2010 13:37:51 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id B44A43A68AB for <oauth@ietf.org>; Mon, 28 Jun 2010 13:37:51 -0700 (PDT) Received: (qmail 2485 invoked from network); 28 Jun 2010 20:38:01 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 28 Jun 2010 20:38:01 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 28 Jun 2010 13:37:54 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: Marius Scurtescu <mscurtescu@google.com> Date: Mon, 28 Jun 2010 13:37:51 -0700 Thread-Topic: [OAUTH-WG] Proposal: simplification of the end-user authorization endpoint Thread-Index: AcsXAGYuVMHHbiwvRneptliYUfM+kwAAWC8N Message-ID: <C84E562F.366D8%eran@hueniverse.com> In-Reply-To: <AANLkTilttAFbBwVDgFuNTLyg4vtjoj9n9CqdUpLBHETC@mail.gmail.com> Accept-Language: en-US Content-Language: en 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 <oauth@ietf.org> Subject: Re: [OAUTH-WG] Proposal: simplification of the end-user authorization endpoint X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 28 Jun 2010 20:37:52 -0000 On 6/28/10 1:27 PM, "Marius Scurtescu" <mscurtescu@google.com> wrote: >=20 > Again, all I am saying is that it would help to have a very detailed > use case for this token_and_code mode, to see if it is really needed. > Or, an actual implementation. I have no objections. I will include it in -09 but will mark it as conditional pending more discussions. I hope -09 will become stable and allow most vendors to start implementing it and gather experience. We will decide what to do with this option once we get more insight. It would be useful if someone from Twitter who initially proposed this woul= d come to defend their use case. EHL From yarong@microsoft.com Mon Jun 28 14:56:34 2010 Return-Path: <yarong@microsoft.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E27CE3A681D for <oauth@core3.amsl.com>; Mon, 28 Jun 2010 14:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.648 X-Spam-Level: X-Spam-Status: No, score=-8.648 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Enwsc2MZ3mxO for <oauth@core3.amsl.com>; Mon, 28 Jun 2010 14:56:25 -0700 (PDT) Received: from smtp.microsoft.com (mail1.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id A750628C134 for <oauth@ietf.org>; Mon, 28 Jun 2010 14:56:24 -0700 (PDT) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 28 Jun 2010 14:56:29 -0700 Received: from TK5EX14MBXC117.redmond.corp.microsoft.com ([169.254.8.23]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.01.0160.007; Mon, 28 Jun 2010 14:56:27 -0700 From: Yaron Goland <yarong@microsoft.com> To: Eran Hammer-Lahav <eran@hueniverse.com>, "oauth@ietf.org" <oauth@ietf.org> Thread-Topic: Proposal for text for section 2 Thread-Index: AcsUm7O3+LYTofkOQ6CsKuFeuynp2ACcJnPg Date: Mon, 28 Jun 2010 21:56:21 +0000 Message-ID: <7C01E631FF4B654FA1E783F1C0265F8C579D0F31@TK5EX14MBXC117.redmond.corp.microsoft.com> References: <7C01E631FF4B654FA1E783F1C0265F8C579CC0C3@TK5EX14MBXC117.redmond.corp.microsoft.com> In-Reply-To: <7C01E631FF4B654FA1E783F1C0265F8C579CC0C3@TK5EX14MBXC117.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7C01E631FF4B654FA1E783F1C0265F8C579D0F31TK5EX14MBXC117r_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Proposal for text for section 2 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 28 Jun 2010 21:56:35 -0000 --_000_7C01E631FF4B654FA1E783F1C0265F8C579D0F31TK5EX14MBXC117r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The following is proposed language for a new section, 2.2, in the spec. Thi= s is part of the spec that deals with client authentication. This proposal = is completely orthogonal to anything in section 4 such as grant types. At E= ran's suggestion I added in an example into the text to help readers unders= tand both what the feature is for and how it is used. Eran also suggested that we should probably introduce a client_cred_type pa= rameter (since we are explicitly support multiple types of client parameter= s) just to be consistent with grant_type. I don't have strong feelings on t= he subject and am happy to go with whatever the group wants. Thoughts? Thanks, Yaron 2.2 Assertion Client Credentials In scenarios where security is at a premium one wants to avoid sending secr= ets across the Internet, even on encrypted connections. Instead one wants t= o send values derived from the secret that prove to the receiver that the s= ender is in possession of the secret without actually sending the secret. T= ypically the way derived values are created is by generating an assertion t= hat is then either HMAC'd or digitally signed using an agreed upon secret. = By validating the HMAC or digital signature on the assertion the receiver o= f the assertion can prove to themselves that the entity that generated the = assertion was in possession of the secret without actually communicating th= e secret directly. So, for example, a client can establish a secret using an out of band mecha= nism with a resource server. As part of this out of band communication the = client and resource server agree that the client will authenticate itself u= sing a SAML assertion with agreed upon parameters that will be signed by th= e provisioned secret. Later on the client interacts with an end-user and uses the end-user author= ization process with the resource server to get an authorization code. The = client then sends an access token request to the token endpoint for the res= ource server and includes, along with the authorization code, a SAML assert= ion it signed with the previously agreed key and parameters. The SAML asser= tion proves to the token endpoint the identity of the client and the author= ization code provides the link to the end-user authorization. If the access= token request comes back with a refresh token then in the future the clien= t can get new access tokens by submitting an access token request containin= g both a properly signed and formatted SAML assertion as well as the refres= h token. The following defines how to send an assertion as client credentials. If th= e assertion client credentials are used then the client MUST include the cr= edentials using the following request parameters: client_id REQUIRED. The client identifier. client_assertion_type REQUIRED. The format of the assertion as defined by the aut= horization server. The value MUST be an absolute URI. client_assertion REQUIRED. The client assertion. For example (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=3Drefresh_token&client_id=3Ds6BhdRkqt3& client_assertion=3DPHNhbWxwOl...[omitted for brevity]...ZT4= %3D& client_assertion_type=3Durn%3Aoasis%3Anames%sAtc%3ASAML%3A2= .0%3Aassertion& refresh_token=3Dn4E90119d The client MUST NOT include the client credentials using more than one mech= anism. If more than one mechanism is used regardless whether the credential= s are identical or valid, the server MUST reply with an HTTP 400 status cod= e (Bad Request) and include the "multiple_credentials" error code. Token endpoints can differentiate between client assertion credentials and = other client credential types by looking for the presence of the client_ass= ertion and client_assertion_type attributes which will only be present with= client assertion credentials. From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Y= aron Goland Sent: Friday, June 25, 2010 3:33 PM To: Eran Hammer-Lahav; oauth@ietf.org Subject: [OAUTH-WG] Proposal for text for section 2 Motivating Scenario: A client makes a request to a token endpoint. It uses = an authorization token to authenticate itself and a refresh token to authen= ticate it's delegated right. This approach to authenticating clients is use= d in enterprises all the time because it's good security practice to send v= alues derived from a secret (e.g. an HMAC, digital signature, etc.) rather = than the secret itself across the wire, even if the wire is encrypted. Proposed Text: 2.2 Assertion Client Credentials The assertion client credentials include a client identifier, assertion and= assertion type. If the assertion client credentials are used then the clie= nt MUST include the credentials using the following request parameters: client_id REQUIRED. The client identifier. client_assertion_type REQUIRED. The format of the assertion as defined by the aut= horization server. The value MUST be an absolute URI. client_assertion REQUIRED. The client assertion. For example (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=3Drefresh_token&client_id=3Ds6BhdRkqt3& client_assertion=3DPHNhbWxwOl...[omitted for brevity]...ZT4= %3D& client_assertion_type=3Durn%3Aoasis%3Anames%sAtc%3ASAML%3A2= .0%3Aassertion& refresh_token=3Dn4E90119d The client MUST NOT include the client credentials using more than one mech= anism. If more than one mechanism is used regardless whether the credential= s are identical or valid, the server MUST reply with an HTTP 400 status cod= e (Bad Request) and include the "multiple_credentials" error code. From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Friday, June 25, 2010 11:31 AM To: Yaron Goland; oauth@ietf.org Subject: RE: Clients authenticating with assertions We never had support for two assertions in one request. The client authenticates itself and can include an assertion (or use type '= none'). The client credentials are the "client assertion" and the assertion= is about the resource owner. Also, you can define an assertion type that's a composite assertion (of one= more more). EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Y= aron Goland Sent: Friday, June 25, 2010 11:26 AM To: oauth@ietf.org Subject: [OAUTH-WG] Clients authenticating with assertions If a client wants to authenticate itself to a token endpoint to get an acce= ss token using an assertion how should it do it? Grant_Type =3D assertion doesn't seem right because that assertion should b= e from the resource owner who delegated the permission, not from the client= , right? In other words one can end up with an access token request with tw= o assertions, one from the client and one from the resource owner. How is t= his done? Thanks, Yaron P.S. I looked for something like client_assertion and client_assertion_type= in section 2 of -08 but didn't see it. Sorry if I missed it. --_000_7C01E631FF4B654FA1E783F1C0265F8C579D0F31TK5EX14MBXC117r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"> <style><!-- /* Font Definitions */ @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} pre {mso-style-priority:99; mso-style-link:"HTML Preformatted Char"; margin:0in; margin-bottom:.0001pt; font-size:10.0pt; font-family:"Courier New";} p.MsoAcetate, li.MsoAcetate, div.MsoAcetate {mso-style-priority:99; mso-style-link:"Balloon Text Char"; margin:0in; margin-bottom:.0001pt; font-size:8.0pt; font-family:"Tahoma","sans-serif";} span.HTMLPreformattedChar {mso-style-name:"HTML Preformatted Char"; mso-style-priority:99; mso-style-link:"HTML Preformatted"; font-family:"Courier New";} span.BalloonTextChar {mso-style-name:"Balloon Text Char"; mso-style-priority:99; mso-style-link:"Balloon Text"; font-family:"Tahoma","sans-serif";} span.EmailStyle21 {mso-style-type:personal; font-family:"Calibri","sans-serif"; color:windowtext;} span.EmailStyle22 {mso-style-type:personal; font-family:"Calibri","sans-serif"; color:#1F497D;} span.EmailStyle23 {mso-style-type:personal; font-family:"Calibri","sans-serif"; color:#1F497D;} span.grey {mso-style-name:grey;} span.EmailStyle25 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">The following is propo= sed language for a new section, 2.2, in the spec. This is part of the spec = that deals with client authentication. This proposal is completely orthogon= al to anything in section 4 such as grant types. At Eran’s suggestion I added in an example into the tex= t to help readers understand both what the feature is for and how it is use= d. <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">Eran also suggested th= at we should probably introduce a client_cred_type parameter (since we are = explicitly support multiple types of client parameters) just to be consiste= nt with grant_type. I don’t have strong feelings on the subject and am happy to go with whatever the group wants.<= o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">   &nbs= p;            Though= ts?<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">   &nbs= p;            &= nbsp;           &nbs= p;   Thanks,<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;      Yaron<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">2.2 Assertion Client C= redentials<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">In scenarios where sec= urity is at a premium one wants to avoid sending secrets across the Interne= t, even on encrypted connections. Instead one wants to send values derived = from the secret that prove to the receiver that the sender is in possession of the secret without actually sending th= e secret. Typically the way derived values are created is by generating an = assertion that is then either HMAC’d or digitally signed using an agr= eed upon secret. By validating the HMAC or digital signature on the assertion the receiver of the assertion can pr= ove to themselves that the entity that generated the assertion was in posse= ssion of the secret without actually communicating the secret directly.<o:p= ></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">So, for example, a cli= ent can establish a secret using an out of band mechanism with a resource s= erver. As part of this out of band communication the client and resource se= rver agree that the client will authenticate itself using a SAML assertion with agreed upon parameters that will be sig= ned by the provisioned secret. <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">Later on the client in= teracts with an end-user and uses the end-user authorization process with t= he resource server to get an authorization code. The client then sends an a= ccess token request to the token endpoint for the resource server and includes, along with the authorization code, a= SAML assertion it signed with the previously agreed key and parameters. Th= e SAML assertion proves to the token endpoint the identity of the client an= d the authorization code provides the link to the end-user authorization. If the access token request comes = back with a refresh token then in the future the client can get new access = tokens by submitting an access token request containing both a properly sig= ned and formatted SAML assertion as well as the refresh token. <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">The following defines = how to send an assertion as client credentials. If the assertion client cre= dentials are used then the client MUST include the credentials using the fo= llowing request parameters:<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">client_id<o:p></o:p></= span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">   &nbs= p;            REQUIR= ED. The client identifier.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">client_assertion_type<= o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">   &nbs= p;            REQUIR= ED. The format of the assertion as defined by the authorization server.&nbs= p; The value MUST be an absolute URI.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">client_assertion<o:p><= /o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">   &nbs= p;            REQUIR= ED. The client assertion.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">For example (line brea= ks are for display purposes only):<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">   &nbs= p;            POST /= token HTTP/1.1<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">   &nbs= p;            Host: = server.example.com<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">   &nbs= p;            Conten= t-Type: application/x-www-form-urlencoded<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">   &nbs= p;            grant_= type=3Drefresh_token&client_id=3Ds6BhdRkqt3&<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">   &nbs= p;            client= _assertion=3DPHNhbWxwOl...[omitted for brevity]...ZT4%3D&<o:p></o:p></s= pan></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">   &nbs= p;            client= _assertion_type=3Durn%3Aoasis%3Anames%sAtc%3ASAML%3A2.0%3Aassertion&<o:= p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">   &nbs= p;            refres= h_token=3Dn4E90119d<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">The client MUST NOT in= clude the client credentials using more than one mechanism. If more than on= e mechanism is used regardless whether the credentials are identical or val= id, the server MUST reply with an HTTP 400 status code (Bad Request) and include the “multiple_credentials&= #8221; error code.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">Token endpoints can di= fferentiate between client assertion credentials and other client credentia= l types by looking for the presence of the client_assertion and client_asse= rtion_type attributes which will only be present with client assertion credentials.</span><span style=3D"color:#= 1F497D"><o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in = 4.0pt"> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:"= ;Tahoma","sans-serif"">From:</span></b><span style=3D"font-s= ize:10.0pt;font-family:"Tahoma","sans-serif""> oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] <b>On Behalf Of </b>Yaron Goland<br> <b>Sent:</b> Friday, June 25, 2010 3:33 PM<br> <b>To:</b> Eran Hammer-Lahav; oauth@ietf.org<br> <b>Subject:</b> [OAUTH-WG] Proposal for text for section 2<o:p></o:p></span= ></p> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">Motivating Scenario: A= client makes a request to a token endpoint. It uses an authorization token= to authenticate itself and a refresh token to authenticate it’s dele= gated right. This approach to authenticating clients is used in enterprises all the time because it’s good securi= ty practice to send values derived from a secret (e.g. an HMAC, digital sig= nature, etc.) rather than the secret itself across the wire, even if the wi= re is encrypted.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">Proposed Text:<o:p></o= :p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">2.2  Assertion Cl= ient Credentials<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">The assertion client c= redentials include a client identifier, assertion and assertion type. If th= e assertion client credentials are used then the client MUST include the cr= edentials using the following request parameters:<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">client_id<o:p></o:p></= span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">   &nbs= p;            REQUIR= ED. The client identifier.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">client_assertion_type<= o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">   &nbs= p;            REQUIR= ED. The format of the assertion as defined by the authorization server.&nbs= p; The value MUST be an absolute URI.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">client_assertion<o:p><= /o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">   &nbs= p;            REQUIR= ED. The client assertion.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">For example (line brea= ks are for display purposes only):<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">   &nbs= p;            POST /= token HTTP/1.1<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">   &nbs= p;            Host: = server.example.com<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">   &nbs= p;            Conten= t-Type: application/x-www-form-urlencoded<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">   &nbs= p;            grant_= type=3Drefresh_token&client_id=3Ds6BhdRkqt3&<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">   &nbs= p;            client= _assertion=3DPHNhbWxwOl...[omitted for brevity]...ZT4%3D&<o:p></o:p></s= pan></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">   &nbs= p;            client= _assertion_type=3Durn%3Aoasis%3Anames%sAtc%3ASAML%3A2.0%3Aassertion&<o:= p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">   &nbs= p;            refres= h_token=3Dn4E90119d<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">The client MUST NOT in= clude the client credentials using more than one mechanism. If more than on= e mechanism is used regardless whether the credentials are identical or val= id, the server MUST reply with an HTTP 400 status code (Bad Request) and include the “multiple_credentials&= #8221; error code.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in = 4.0pt"> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:"= ;Tahoma","sans-serif"">From:</span></b><span style=3D"font-s= ize:10.0pt;font-family:"Tahoma","sans-serif""> Eran Ham= mer-Lahav [mailto:eran@hueniverse.com] <br> <b>Sent:</b> Friday, June 25, 2010 11:31 AM<br> <b>To:</b> Yaron Goland; oauth@ietf.org<br> <b>Subject:</b> RE: Clients authenticating with assertions<o:p></o:p></span= ></p> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">We never had support f= or two assertions in one request.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">The client authenticat= es itself and can include an assertion (or use type ‘none’). Th= e client credentials are the “client assertion” and the asserti= on is about the resource owner.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">Also, you can define a= n assertion type that’s a composite assertion (of one more more).<o:p= ></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">EHL<o:p></o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in = 4.0pt"> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:"= ;Tahoma","sans-serif"">From:</span></b><span style=3D"font-s= ize:10.0pt;font-family:"Tahoma","sans-serif""> oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] <b>On Behalf Of </b>Yaron Goland<br> <b>Sent:</b> Friday, June 25, 2010 11:26 AM<br> <b>To:</b> oauth@ietf.org<br> <b>Subject:</b> [OAUTH-WG] Clients authenticating with assertions<o:p></o:p= ></span></p> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">If a client wants to authenticate itself to a token = endpoint to get an access token using an assertion how should it do it? <o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">Grant_Type =3D assertion doesn’t seem right be= cause that assertion should be from the resource owner who delegated the pe= rmission, not from the client, right? In other words one can end up with an= access token request with two assertions, one from the client and one from the resource owner. How is this done?<o:p= ></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">        &nbs= p;       Thanks,<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">        &nbs= p;            &= nbsp;          Yaron<o:p></o:p= ></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">P.S. I looked for something like client_assertion an= d client_assertion_type in section 2 of -08 but didn’t see it. Sorry = if I missed it.<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> </div> </div> </div> </body> </html> --_000_7C01E631FF4B654FA1E783F1C0265F8C579D0F31TK5EX14MBXC117r_-- From yarong@microsoft.com Mon Jun 28 15:01:47 2010 Return-Path: <yarong@microsoft.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A39433A68F9 for <oauth@core3.amsl.com>; Mon, 28 Jun 2010 15:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.946 X-Spam-Level: X-Spam-Status: No, score=-8.946 tagged_above=-999 required=5 tests=[AWL=-0.207, BAYES_20=-0.74, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jCLGb7UhwctI for <oauth@core3.amsl.com>; Mon, 28 Jun 2010 15:01:41 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id C9FC13A681D for <oauth@ietf.org>; Mon, 28 Jun 2010 15:01:41 -0700 (PDT) Received: from TK5EX14CASC131.redmond.corp.microsoft.com (157.54.52.38) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 28 Jun 2010 15:01:51 -0700 Received: from TK5EX14MBXC117.redmond.corp.microsoft.com ([169.254.8.23]) by TK5EX14CASC131.redmond.corp.microsoft.com ([157.54.52.38]) with mapi id 14.01.0160.007; Mon, 28 Jun 2010 15:01:51 -0700 From: Yaron Goland <yarong@microsoft.com> To: "oauth@ietf.org" <oauth@ietf.org> Thread-Topic: How do we deal with unrecognized elements in requests and responses? Thread-Index: AcsXDNz7BtsGZbPiSvu5gteEiVcThw== Date: Mon, 28 Jun 2010 22:01:48 +0000 Message-ID: <7C01E631FF4B654FA1E783F1C0265F8C579D0F52@TK5EX14MBXC117.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7C01E631FF4B654FA1E783F1C0265F8C579D0F52TK5EX14MBXC117r_" MIME-Version: 1.0 Subject: [OAUTH-WG] How do we deal with unrecognized elements in requests and responses? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 28 Jun 2010 22:01:47 -0000 --_000_7C01E631FF4B654FA1E783F1C0265F8C579D0F52TK5EX14MBXC117r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In a private thread with Eran an issue came up regarding how to handle unre= cognized arguments in OAuth requests and responses. For example, if a token endpoint receives an access token request that cont= ains both a client_id and a client_foo_bar argument, what should it do? Sho= uld it reject the request since it doesn't recognize client_foo_bar? Should= it ignore client_foo_bar and just process the request based on client_id? Similarly imagine that a response to an access token request contains a JSO= N member with some unrecognized name. What's the right behavior? Ignore the= unrecognized value? Or treat the response as badly formatted and fail out? We need to define in the spec how to deal with unrecognized extensions. Typ= ically the rule is 'ignore what you don't recognize' but there is a counter= vailing rule which applies here which is "security is different". Typically= ignoring unrecognized elements in a security context can lead to security = holes. Just looking at the history of OAuth I suspect we need to go with the ignor= e rule and then explore ad nauseam in the security considerations section a= ll the ways that the ignore rule can go wrong if extensions aren't handled = carefully. Thoughts? Thanks, Yaron --_000_7C01E631FF4B654FA1E783F1C0265F8C579D0F52TK5EX14MBXC117r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"> <style><!-- /* Font Definitions */ @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} span.EmailStyle17 {mso-style-type:personal-compose; font-family:"Calibri","sans-serif"; color:windowtext;} .MsoChpDefault {mso-style-type:export-only; font-family:"Calibri","sans-serif";} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> <p class=3D"MsoNormal">In a private thread with Eran an issue came up regar= ding how to handle unrecognized arguments in OAuth requests and responses.<= o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">For example, if a token endpoint receives an access = token request that contains both a client_id and a client_foo_bar argument,= what should it do? Should it reject the request since it doesn’t rec= ognize client_foo_bar? Should it ignore client_foo_bar and just process the request based on client_id?<o:p></o:p>= </p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">Similarly imagine that a response to an access token= request contains a JSON member with some unrecognized name. What’s t= he right behavior? Ignore the unrecognized value? Or treat the response as = badly formatted and fail out?<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">We need to define in the spec how to deal with unrec= ognized extensions. Typically the rule is ‘ignore what you don’= t recognize’ but there is a countervailing rule which applies here wh= ich is “security is different”. Typically ignoring unrecognized elements in a security context can lead to security holes.<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">Just looking at the history of OAuth I suspect we ne= ed to go with the ignore rule and then explore ad nauseam in the security c= onsiderations section all the ways that the ignore rule can go wrong if ext= ensions aren’t handled carefully.<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">        &nbs= p;       Thoughts?<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">        &nbs= p;            &= nbsp;          Thanks,<o:p></o= :p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp; Yaron<o:p></o:p></p> </div> </body> </html> --_000_7C01E631FF4B654FA1E783F1C0265F8C579D0F52TK5EX14MBXC117r_-- From mscurtescu@google.com Mon Jun 28 15:08:53 2010 Return-Path: <mscurtescu@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AA1B3A6A90 for <oauth@core3.amsl.com>; Mon, 28 Jun 2010 15:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.32 X-Spam-Level: X-Spam-Status: No, score=-105.32 tagged_above=-999 required=5 tests=[AWL=0.657, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Engg85U0E3bD for <oauth@core3.amsl.com>; Mon, 28 Jun 2010 15:08:52 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 8E8E83A6A8D for <oauth@ietf.org>; Mon, 28 Jun 2010 15:08:52 -0700 (PDT) Received: from kpbe14.cbf.corp.google.com (kpbe14.cbf.corp.google.com [172.25.105.78]) by smtp-out.google.com with ESMTP id o5SM91cf018943 for <oauth@ietf.org>; Mon, 28 Jun 2010 15:09:01 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1277762942; bh=t8aYjbVgBdOvZi7ycbkThGpTlWw=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=QyVFEKUU4bXQPNJy5g2XiRk3CCjVYafl9aZpzdKRL0sBwooeoRSWNPh5GCvp2iprW U6acOSKwZ0q/QwveSmv7A== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding:x-system-of-record; b=GJBSqhvZZEmNPqdZn9CbtdclEewfUSOeEFTs+6t6ILFbUoOt4Cdg05LZDE4sJGmvh yF/reeY3NyrFBv7TFPKWg== Received: from gxk3 (gxk3.prod.google.com [10.202.11.3]) by kpbe14.cbf.corp.google.com with ESMTP id o5SM901L028317 for <oauth@ietf.org>; Mon, 28 Jun 2010 15:09:00 -0700 Received: by gxk3 with SMTP id 3so483489gxk.1 for <oauth@ietf.org>; Mon, 28 Jun 2010 15:09:00 -0700 (PDT) Received: by 10.101.128.32 with SMTP id f32mr7031307ann.93.1277762940260; Mon, 28 Jun 2010 15:09:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.132.22 with HTTP; Mon, 28 Jun 2010 15:08:40 -0700 (PDT) In-Reply-To: <7C01E631FF4B654FA1E783F1C0265F8C579D0F52@TK5EX14MBXC117.redmond.corp.microsoft.com> References: <7C01E631FF4B654FA1E783F1C0265F8C579D0F52@TK5EX14MBXC117.redmond.corp.microsoft.com> From: Marius Scurtescu <mscurtescu@google.com> Date: Mon, 28 Jun 2010 15:08:40 -0700 Message-ID: <AANLkTilFyQBDYtZN3vuN9G9lghaOs9JviPlIKQGHFrbw@mail.gmail.com> To: Yaron Goland <yarong@microsoft.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "oauth@ietf.org" <oauth@ietf.org> Subject: Re: [OAUTH-WG] How do we deal with unrecognized elements in requests and responses? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 28 Jun 2010 22:08:53 -0000 It also depends on how extensions will work, looking forward to read -09. If extensions are namespaced somehow then you could ignore unknown extension but be strict with core parameters (those would be parameters with no namespace) and with known extensions. Marius On Mon, Jun 28, 2010 at 3:01 PM, Yaron Goland <yarong@microsoft.com> wrote: > In a private thread with Eran an issue came up regarding how to handle > unrecognized arguments in OAuth requests and responses. > > > > For example, if a token endpoint receives an access token request that > contains both a client_id and a client_foo_bar argument, what should it d= o? > Should it reject the request since it doesn=92t recognize client_foo_bar? > Should it ignore client_foo_bar and just process the request based on > client_id? > > > > Similarly imagine that a response to an access token request contains a J= SON > member with some unrecognized name. What=92s the right behavior? Ignore t= he > unrecognized value? Or treat the response as badly formatted and fail out= ? > > > > We need to define in the spec how to deal with unrecognized extensions. > Typically the rule is =91ignore what you don=92t recognize=92 but there i= s a > countervailing rule which applies here which is =93security is different= =94. > Typically ignoring unrecognized elements in a security context can lead t= o > security holes. > > > > Just looking at the history of OAuth I suspect we need to go with the ign= ore > rule and then explore ad nauseam in the security considerations section a= ll > the ways that the ignore rule can go wrong if extensions aren=92t handled > carefully. > > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Thoughts? > > > > =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 Yaron > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From yarong@microsoft.com Mon Jun 28 15:10:25 2010 Return-Path: <yarong@microsoft.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4F313A6A8D for <oauth@core3.amsl.com>; Mon, 28 Jun 2010 15:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.111 X-Spam-Level: X-Spam-Status: No, score=-9.111 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9lPVMCe6l3i2 for <oauth@core3.amsl.com>; Mon, 28 Jun 2010 15:10:21 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 17CBA3A6892 for <oauth@ietf.org>; Mon, 28 Jun 2010 15:10:21 -0700 (PDT) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 28 Jun 2010 15:10:24 -0700 Received: from TK5EX14MBXC117.redmond.corp.microsoft.com ([169.254.8.23]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.01.0160.007; Mon, 28 Jun 2010 15:10:24 -0700 From: Yaron Goland <yarong@microsoft.com> To: Torsten Lodderstedt <torsten@lodderstedt.net> Thread-Topic: [OAUTH-WG] OAuth discovery draft? Thread-Index: AQHLEbd88ANnc80E8EanM4mdFaHtZpKN3qcAgAH2zrCAAAP3tYAAAdRggARizoCAA7n10A== Date: Mon, 28 Jun 2010 22:10:21 +0000 Message-ID: <7C01E631FF4B654FA1E783F1C0265F8C579D0FED@TK5EX14MBXC117.redmond.corp.microsoft.com> References: <7C01E631FF4B654FA1E783F1C0265F8C579C6DC3@TK5EX14MBXC117.redmond.corp.microsoft.com> <C8479A94.363F3%eran@hueniverse.com> <7C01E631FF4B654FA1E783F1C0265F8C579C6E52@TK5EX14MBXC117.redmond.corp.microsoft.com> <CDD1DDBF-BD1B-4F4E-8620-AA2FEC402C90@lodderstedt.net> In-Reply-To: <CDD1DDBF-BD1B-4F4E-8620-AA2FEC402C90@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7C01E631FF4B654FA1E783F1C0265F8C579D0FEDTK5EX14MBXC117r_" MIME-Version: 1.0 Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] OAuth discovery draft? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 28 Jun 2010 22:10:25 -0000 --_000_7C01E631FF4B654FA1E783F1C0265F8C579D0FEDTK5EX14MBXC117r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBiZWxpZXZlIHRoYXQgR0VUIHNob3VsZCBiZSB1c2VkIHRvIHJldHVybiB0aGUgcmVzb3VyY2Xi gJlzIHN0YXRlIGFuZCBpdHMgT0F1dGggdG9rZW4gZW5kcG9pbnQgaXMganVzdCBhIHRpbnkgcGFy dCBvZiB0aGF0IHN0YXRlLiBXaGVuIHdlIHdhbnQgdG8gcmV0dXJuIHBhcnQgb2YgdGhlIHN0YXRl IHdlIHR5cGljYWxseSB1c2UgZWl0aGVyIGV4cGxpY2l0IGhlYWRlcnMgKGEgbGEgYnl0ZSByYW5n ZXMpIG9yIGEgcXVlcnkgcGFyYW1ldGVyLiBDb250ZW50LXR5cGVzIHNob3VsZCwgSSB0aGluaywg anVzdCBjb250cm9sIHRoZSBzeW50YXggb2Ygd2hhdCBpcyByZXR1cm5lZCwgbm90IHRoZSBzdWJz ZXQgb2YgZGF0YSBpdCBjb250YWlucy4gU28gSSBoYXZlIHRvIGFkbWl0IHRoYXQgSSByZWFsbHkg ZG9u4oCZdCBsaWtlIHVzaW5nIEdFVCBmb3IgdGhpcyBzb3J0IG9mIHNjZW5hcmlvLg0KDQpPUFRJ T05TIGlzIGFjdHVhbGx5IHRoZSBvZmZpY2lhbGx5IGJsZXNzZWQgd2F5IHRvIHdhbGsgdXAgdG8g YSByZXNvdXJjZSwga25vY2sgb24gdGhlIGZyb250IGRvb3IgYW5kIGFzayDigJh3aGF0IGFyZSB5 b3UgYW5kIHdoYXQgY2FuIHlvdSBkbz/igJkgU28gaXQgc2VlbXMgdG8gbWUgd2Ugc2hvdWxkIHN0 YXJ0IHdpdGggT1BUSU9OUy4gQnV0IHRoaXMgZG9lcyBicmluZyB1cCBhIHByb2JsZW0g4oCTIG5v Ym9keSBldmVyIHJlYWxseSBkZWZpbmVkIGEgcmVzcG9uc2UgYm9keSBmb3IgT1BUSU9OUy4gUkZD IDI2MTYgZXhwbGljaXRseSBkZWZpbmVkIHRoZSBsZWdhbGl0eSBvZiBzdWNoIGEgYm9keSBidXQg bm8gc3RhbmRhcmQgd2FzIGRlZmluZWQgZm9yIHdoYXQgdGhlIGJvZHkgc2hvdWxkIGxvb2sgbGlr ZS4gVGhpcyBpcyBhbiBpc3N1ZSBiZWNhdXNlIGlmIHNvbWVvbmUgZG9lcyBkZWZpbmUgYSBib2R5 IGZvciBPUFRJT05TIHRoZW4gdGhleSByZWFsbHkgbmVlZCB0byBkbyBzbyBpbiBhIHdheSB0aGF0 IG90aGVyIHN0YW5kYXJkcyBjYW4gYnVpbGQgb24gdG9wIG9mLg0KDQpTbyB3ZSBoYXZlIGEgY2hv aWNlIHdoZW4gaXQgY29tZXMgdG8gdXNpbmcgT1BUSU9OUy4gV2UgY2FuIHJldHVybiBkYXRhIGlu IHRoZSBoZWFkZXIgaW4gd2hpY2ggY2FzZSBhbGwgd2UgaGF2ZSB0byBkbyBpcyBqdXN0IGRlZmlu ZSB0aGUgaGVhZGVyLCBzdWJtaXQgdGhlIFJGQyBhbmQgY2FsbCBpdCBkYXkuIE9yIHdlIGNhbiB1 c2UgdGhlIGJvZHkgYnV0IGluIHRoYXQgY2FzZSB3ZSBwcm9iYWJseSBuZWVkIHRvIHdyaXRlIG9u ZSBzcGVjIHRvIGRlZmluZSBhIGdlbmVyaWMgd2F5IHRvIHJldHVybiBkYXRhIGluIE9QVElPTlMg cmVzcG9uc2UgYm9kaWVzIChlLmcuIGhvdyBkbyBkaWZmZXJlbnQgT1BUSU9OUyByZXNwb25zZXMg bGl2ZSB0b2dldGhlcj8pIGFuZCBnZXQgdGhhdCBzdGFuZGFyZGl6ZWQuIFRoZW4gd2UgY2FuIHdy aXRlIGEgc2Vjb25kIFJGQyB0byBkZWZpbmUgaG93IG91ciBzcGVjaWZpYyBkYXRhIHdvdWxkIGJl IGNhcnJpZWQgaW4gT1BUSU9OUy4NCg0KICAgICAgICAgICAgICAgIFRob3VnaHRzPw0KDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFlhcm9uDQoNCkZyb206IFRvcnN0ZW4gTG9kZGVy c3RlZHQgW21haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldF0NClNlbnQ6IEZyaWRheSwgSnVu ZSAyNSwgMjAxMCAxMTowOSBQTQ0KVG86IFlhcm9uIEdvbGFuZA0KQ2M6IEVyYW4gSGFtbWVyLUxh aGF2OyBKYW1lcyBNYW5nZXI7IE9BdXRoIFdHDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBPQXV0 aCBkaXNjb3ZlcnkgZHJhZnQ/DQoNCkkgdGhpbmsgaXQgc2hvdWxkIGJlIHBvc3NpYmxlIHRvIGRp c2NvdmVyIGEgcmVzb3VyY2UncyBPQXV0aCBzZXJ2ZXIgYW5kIGl0cyBjYXBhYmlsaXRpZXMgdXNp bmcgYSBkaXJlY3QgRGlzY292ZXJ5IHJlcXVlc3QuIEkgZG9uJ3QgdGhpbmsgYSBXV1ctQXV0aGVu dGljYXRlIEhlYWRlciBpcyB0aGUgcmlnaHQgcmVwcmVzZW50YXRpb24gZm9yIHRoaXMga2luZCBv ZiBkYXRhLiBXaGF0IGFib3V0IGEgSlNPTiBvciBYTUwgZG9jdW1lbnQgcmV0dXJuZWQgaW4gcmVz cG9uc2UgdG8gYW4gT1BUSU9OUyByZXF1ZXN0IChhcyB5b3Ugc3VnZ2VzdGVkKSBvciBhIEdFVCBy ZXF1ZXN0IHdpdGggYSBjZXJ0YWluIGNvbnRlbnQgdHlwZSBpbiBpdHMgQUNDRVBUIEhlYWRlcj8N Cg0KcmVnYXJkcywNClRvcnN0ZW4uDQoNCg0KQW0gMjMuMDYuMjAxMCB1bSAyMDoyMCBzY2hyaWVi IFlhcm9uIEdvbGFuZCA8eWFyb25nQG1pY3Jvc29mdC5jb208bWFpbHRvOnlhcm9uZ0BtaWNyb3Nv ZnQuY29tPj46DQpObyBvYmplY3Rpb25zIG9uIG15IHBhcnQuIEkgd291bGQgcmF0aGVyIGhhdmUg YSBzbWFsbGVyIGNvcmUgc3BlYyB3aXRoIGZlYXR1cmVzIHRoYXQgZXZlcnlvbmUgYWdyZWVzIG9u Lg0KDQpCVFcsIGEgdGhvdWdodCBmb3IgdGhlIGRpc2NvdmVyeSBkcmFmdCDigJMgUkZDIDI2MTYv MjYxNyBvbmx5IGRlZmluZXMgd3d3LWF1dGhlbnRpY2F0ZeKAmXMgc2VtYW50aWNzIGluIHRoZSBj b250ZXh0IG9mIGEgNDAxLiBJdOKAmXMgdW5jbGVhciBmcm9tIHRoZSBkcmFmdCB3aGF0IGl0IHdv dWxkIG1lYW4gdG8gcmV0dXJuIGEgd3d3LWF1dGhlbnRpY2F0ZSBoZWFkZXIgb24gYSAyMDAgcmVz cG9uc2UuIFRoZSByZWFzb24gSSBjYXJlIGFib3V0IHRoaXMgaXMgdGhhdCBJIHRoaW5rIGl0IG1h a2VzIHNlbnNlIHRoYXQgaWYgc29tZW9uZSB3YW50cyB0byB0YWxrIHRvIGFuIGVuZHBvaW50IHRo ZXkga25vdyBzdXBwb3J0cyBPQXV0aCBhbmQgbmVlZCB0byBrbm93IHdoZXJlIHRoZWlyIHRva2Vu IGlzc3VlciBsb2NhdGlvbiBpcyB0aGV5IHdvdWxkIHdhbnQgdG8gZmlyZSBvZmYgYW4gT1BUSU9O UyByZXF1ZXN0IHRvIHRoZSByZXNvdXJjZSBhbmQgZmluZCBvdXQgZnJvbSB0aGUgcmVzcG9uc2Ug d2hlcmUgdGhlIGlzc3VlciBpcyBhbmQgd2hhdCByZWFsbSBpcyBiZWluZyB1c2VkLiBJdCBzZWVt cyB0byBtZSB0aGF0IHRoZSBzaW1wbGVzdCB3YXkgdG8gc29sdmUgdGhpcyBwcm9ibGVtIGlzIHRv IGp1c3QgcmV0dXJuIHd3dy1hdXRoZW50aWNhdGUgb24gYSAyMDAgcmVzcG9uc2UgdG8gYW4gT1BU SU9OUyByZXF1ZXN0Lg0KDQogICAgICAgICAgICAgICAgVGhvdWdodHM/DQoNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgVGhhbmtzLA0KDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBZYXJvbg0KDQpGcm9tOiBFcmFuIEhhbW1lci1MYWhhdiBb bWFpbHRvOmVyYW5AaHVlbml2ZXJzZS5jb21dDQpTZW50OiBXZWRuZXNkYXksIEp1bmUgMjMsIDIw MTAgMTE6MDQgQU0NClRvOiBZYXJvbiBHb2xhbmQ7IEphbWVzIE1hbmdlcjsgT0F1dGggV0cNClN1 YmplY3Q6IFJlOiBPQXV0aCBkaXNjb3ZlcnkgZHJhZnQ/DQoNCkkgdGhpbmsgdGhlIGNvcmUgd29y ayBpcyBwcmV0dHkgc3RhYmxlIG5vdywgdW5saWtlIHRoZSBkaXNjb3ZlcnkgYml0cyB3aGljaCAo d2hpbGUgc2ltcGxlKSBhcmUgbm90IGVuam95aW5nIHRoZSBzYW1lIGxldmVsIG9mIGNvbnNlbnN1 cy4gSSB0aGluayBpdCBpcyBtdWNoIG1vcmUgcHJhY3RpY2FsIHRvIHByb3Bvc2UgdGhlbSBhcyBh IHNlcGFyYXRlIGRvY3VtZW50IGFuZCBwZXJoYXBzIGNvbnNpZGVyIG1lcmdpbmcgdGhlbSBsYXRl ciBvbiB3aGVuIHRoZXkgcmVhY2ggYW4gZXF1YWwgbGV2ZWwgb2Ygc3RhYmlsaXR5LiBCdXQgb3Zl cmFsbCwgSeKAmW0gbm90IHRvbyB3b3JyaWVzIGFib3V0IG11bHRpcGxlIGRvY3VtZW50cy4NCg0K RUhMDQoNCg0KT24gNi8yMy8xMCAxMTowMCBBTSwgIllhcm9uIEdvbGFuZCIgPHlhcm9uZ0BtaWNy b3NvZnQuY29tPG1haWx0bzp5YXJvbmdAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KSSd2ZSBiZWVu IG5vb2RsaW5nIFsxXSBhIGxvdCBhYm91dCBmdWxsIGRlbGVnYXRpb24gaW4gT0F1dGggWzJdIGFu ZCBvbmUgb2YgdGhlIGlzc3VlcyB0aGF0IGNhbWUgb3V0IG9mIHRoYXQgd2FzIHRoZSBuZWVkIGZv ciBkaXNjb3ZlcmluZyBib3RoIHRoZSBsb2NhdGlvbiBhbmQgcmVhbG0gb2YgYW4gZW5kcG9pbnQn cyB0b2tlbiBzZXJ2ZXIuIEJ1dCBhdCBsZWFzdCBmb3IgbXkgdXNlIGNhc2VzICh3aGljaCBjb25z aXN0IG9mIHdhbGtpbmcgdXAgdG8gYSBzZXJ2aWNlIGFuZCBtYWtpbmcgYW4gb3B0aW9ucyByZXF1 ZXN0IGFuZCBnZXR0aW5nIGJhY2sgYSB3d3ctYXV0aGVudGljYXRlIGhlYWRlcikgYWxsIEkgbmVl ZCBiYWNrIGlzIGEgcmVhbG0gYW5kIGEgdG9rZW4gc2VydmVyIFVSTC4gSW4gb3RoZXIgd29yZHMg anVzdCBoYXZpbmcgb25lIGFyZ3VtZW50IGFkZGVkIHRvIG91ciB3d3ctYXV0aGVudGljYXRlIGhl YWRlciB3b3VsZCBiZSBlbm91Z2ggdG8gc29sdmUgdGhlIGNhc2Ugd2hlcmUgc29tZW9uZSB3YW50 cyB0byB3YWxrIHVwIHRvIGEgc2VydmljZSBhbmQgZmluZCBvdXQgd2hlcmUgaXRzIHRva2VuIHNl cnZlciBpcy4gRG9lcyB0aGF0IHJlYWxseSBuZWVkIGl0cyBvd24gc3BlYz8gT3IgY2FuIHdlIGp1 c3QgYWRkIGFuIGFyZ3VtZW50IHRvIHd3dy1hdXRoZW50aWNhdGUgaW4gdGhlIGN1cnJlbnQgc3Bl Yz8NCiAgICAgICAgVGhhbmtzLA0KICAgICAgICAgICAgICAgIFlhcm9uDQoNClsxXSBTZWUgaHR0 cDovL3d3dy5nb2xhbmQub3JnL29hdXRoZ2VuZXJpY2RlbGVnYXRpb24vIGZvciBhbiBvdmVydmll dyBvZiBteSB0aGlua2luZyBvbiBmdWxsIGRlbGVnYXRpb24gaW4gT0F1dGguIEF0IHRoZSB2ZXJ5 IGVuZCBhcmUgbGlua3MgdG8gYSBidW5jaCBvZiBvdGhlciBtdWNoIG1vcmUgaW4tZGVwdGggYXJ0 aWNsZXMgb24gcGFydGljdWxhciBzdWJqZWN0cyB0b3VjaGVkIG9uIGluIHRoZSBtYWluIGFydGlj bGUuDQoNClsyXSBJIGRlZmluZSAnZnVsbCBkZWxlZ2F0aW9uJyBhcyAiVXNlciBYIG9mIFNlcnZp Y2UgWSBncmFudHMgcGVybWlzc2lvbiBaIHRvIFVzZXIgQSBvZiBTZXJ2aWNlIEIiLiBDdXJyZW50 bHkgT0F1dGggcmVxdWlyZXMgWCA9PSBBLiBJbiB0aGUgZnV0dXJlIEkgaG9wZSB0byBzZWUgZXh0 ZW5zaW9ucyB0byBPQXV0aCB0aGF0IGVuYWJsZSB3aGF0IEknbSB0ZXJtaW5nICdmdWxsIGRlbGVn YXRpb24nLiBCdXQgcGVyc29uYWxseSBJJ20gcmVhbGx5IGhhcHB5IHRoYXQgT0F1dGggaGFzIHRo ZSBYPT1BIHJlc3RyaWN0aW9uLiBJdCBzaW1wbGlmaWVzIGEgd2hvbGUgaG9zdCBvZiBpc3N1ZXMg YW5kIHNhdGlzZmllcyBhIHJlYWxseSBpbXBvcnRhbnQgdXNlIGNhc2UuDQoNCj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogb2F1dGgtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86 b2F1dGgtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYNCj4gT2YgRXJhbiBIYW1tZXItTGFoYXYNCj4gU2VudDogTW9uZGF5LCBKdW5lIDIx LCAyMDEwIDk6NTAgUE0NCj4gVG86IE1hbmdlciwgSmFtZXMgSDsgT0F1dGggV0cgKG9hdXRoQGll dGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4pDQo+IFN1YmplY3Q6IFJlOiBbT0FVVEgtV0dd IE9BdXRoIGRpc2NvdmVyeSBkcmFmdD8NCj4NCj4gWWVzLCBpdCdzIG9uIG15IGRlc2sgYW5kIG5v dCB5ZXQgcmVhZHksIGJ1dCBJIGFtIHdvcmtpbmcgb24gb25lLiBJdCBpbmNsdWRlcw0KPiB5b3Vy IHNpdGVzIHByb3Bvc2FsIGFtb25nIG90aGVyIHRoaW5ncy4gSSBhbSB0cnlpbmcgdG8gZ2V0IHRo ZSBjb3JlIHNwZWMNCj4gc3RhYmxlIHRoaXMgd2VlayBhbmQgZm9jdXMgb24gdGhhdCBuZXh0Lg0K Pg0KPiBFSEwNCj4NCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IE1h bmdlciwgSmFtZXMgSCBbbWFpbHRvOkphbWVzLkguTWFuZ2VyQHRlYW0udGVsc3RyYS5jb21dDQo+ ID4gU2VudDogTW9uZGF5LCBKdW5lIDIxLCAyMDEwIDg6MDMgUE0NCj4gPiBUbzogRXJhbiBIYW1t ZXItTGFoYXY7IE9BdXRoIFdHIChvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+ KQ0KPiA+IFN1YmplY3Q6IE9BdXRoIGRpc2NvdmVyeSBkcmFmdD8NCj4gPg0KPiA+IEVyYW4sDQo+ ID4NCj4gPiBUaGVyZSBoYXZlIGJlZW4gYSBmZXcgbWVudGlvbnMgcmVjZW50bHkgb2YgYW4gT0F1 dGggZGlzY292ZXJ5IGRyYWZ0Lg0KPiA+IElzIHRoZXJlIGFueSBzdWNoIGRyYWZ0IHlldCwgb3Ig aXMgdGhpcyBqdXN0IGEgcGFydCB0aGF0IHdlIGtub3cgbmVlZHMNCj4gPiB0byBiZSBkb25lPw0K PiA+DQo+ID4gVGhlIGVtYWlsIG9uICJPQXV0aCBtZWV0aW5nIG5vdGVzIG9uIC0wNSAod2l0aCB1 cGRhdGVzKSIgc2FpZDoNCj4gPg0KPiA+ID4+IDYuMS4xLiAtIGRlc2NyaWJpbmcgdGhlIFdXVy1B dXRoZW50aWNhdGUgcmVzcG9uc2UgaGVhZGVyDQo+ID4gPj4NCj4gPiA+PiAtIERpc2NvdmVyeSBu ZWVkZWQgZm9yIHZhcmlvdXMgZWxlbWVudHMNCj4gPiA+DQo+ID4gPiBZZXMuIFRoYXQncyBmb3Ig dGhlIGRpc2NvdmVyeSBkcmFmdC4NCj4gPg0KPiA+DQo+ID4gQSB3aWtpIHBhZ2Ugb24gIkZ1dHVy ZSBPcGVuSUQgVGVjaG5pY2FsIFJlcXVpcmVtZW50cyINCj4gPiA8aHR0cDovL3dpa2kub3Blbmlk Lm5ldC9GdXR1cmUtT3BlbklELVRlY2huaWNhbC1SZXF1aXJlbWVudHM+IHNheXM6DQo+ID4NCj4g PiA+IDYpIElkUCBEaXNjb3ZlcnkNCj4gPiA+DQo+ID4gPiAgICAqIE11Y2ggb2YgdGhpcyB3aWxs IGJlIGNvdmVyZWQgYnkgT0F1dGgyIERpc2NvdmVyeSwNCj4gPiA+ICAgICAgaG93ZXZlciBPSUMg bWF5IG5lZWQgdG8gZGVmaW5lIE9wZW5JRCBzcGVjaWZpYyBmZWF0dXJlcy4NCj4gPiA+4oCmDQo+ ID4gPiAxNykgU2ltcGxlciBkaXNjb3ZlcnkNCj4gPiA+DQo+ID4gPiAgICAqIFNlZSBFcmFuJ3Mg T0F1dGggRGlzY292ZXJ5IHByb3Bvc2FsDQo+ID4NCj4gPg0KPiA+IFRoZXJlIHdhcyBhbiBPQXV0 aCAxLjAgRGlzY292ZXJ5IGRyYWZ0IG92ZXIgMiB5ZWFycyBhZ28sIGJ1dCB0aGF0IGlzIHRhZ2dl ZDoNCj4gPiAiZXhwaXJlZCIsICJtYXJrZWQgYXMgb2Jzb2xldGUgYnkgaXRzIGF1dGhvciIsICJk aXNjb3VyYWdlZCBmcm9tDQo+ID4gaW1wbGVtZW50aW5nIiwgIm5vIHVwZGF0ZSBpcyBleHBlY3Rl ZCIsICJyZXBsYWNlZCBieSB0aGUgT0F1dGggMi4wDQo+IGVmZm9ydCIuDQo+ID4NCj4gPiBJIGtu b3cgSSBzaG91bGQgd3JpdGUgYSBkaXNjb3ZlcnkgZHJhZnQgbXlzZWxmLg0KPiA+DQo+ID4gLS0N Cj4gPiBKYW1lcyBNYW5nZXINCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gT0F1dGggbWFpbGluZyBsaXN0DQo+IE9BdXRoQGlldGYub3JnPG1haWx0 bzpPQXV0aEBpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9vYXV0aA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Ck9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3Jn Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0K --_000_7C01E631FF4B654FA1E783F1C0265F8C579D0FEDTK5EX14MBXC117r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uYXBwbGUtc3R5bGUtc3Bhbg0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1z dHlsZS1zcGFuO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFG NDk3RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBU ZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFs bG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBw dDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEu MGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+SSBiZWxpZXZlIHRoYXQgR0VUIHNob3VsZCBiZSB1c2VkIHRvIHJldHVybiB0aGUgcmVz b3VyY2XigJlzIHN0YXRlIGFuZCBpdHMgT0F1dGggdG9rZW4gZW5kcG9pbnQgaXMganVzdCBhIHRp bnkgcGFydCBvZiB0aGF0IHN0YXRlLiBXaGVuIHdlIHdhbnQgdG8gcmV0dXJuIHBhcnQNCiBvZiB0 aGUgc3RhdGUgd2UgdHlwaWNhbGx5IHVzZSBlaXRoZXIgZXhwbGljaXQgaGVhZGVycyAoYSBsYSBi eXRlIHJhbmdlcykgb3IgYSBxdWVyeSBwYXJhbWV0ZXIuIENvbnRlbnQtdHlwZXMgc2hvdWxkLCBJ IHRoaW5rLCBqdXN0IGNvbnRyb2wgdGhlIHN5bnRheCBvZiB3aGF0IGlzIHJldHVybmVkLCBub3Qg dGhlIHN1YnNldCBvZiBkYXRhIGl0IGNvbnRhaW5zLiBTbyBJIGhhdmUgdG8gYWRtaXQgdGhhdCBJ IHJlYWxseSBkb27igJl0IGxpa2UgdXNpbmcNCiBHRVQgZm9yIHRoaXMgc29ydCBvZiBzY2VuYXJp by48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPk9QVElPTlMgaXMgYWN0dWFsbHkgdGhlIG9mZmljaWFsbHkgYmxlc3NlZCB3 YXkgdG8gd2FsayB1cCB0byBhIHJlc291cmNlLCBrbm9jayBvbiB0aGUgZnJvbnQgZG9vciBhbmQg YXNrIOKAmHdoYXQgYXJlIHlvdSBhbmQgd2hhdCBjYW4geW91IGRvP+KAmSBTbyBpdCBzZWVtcyB0 bw0KIG1lIHdlIHNob3VsZCBzdGFydCB3aXRoIE9QVElPTlMuIEJ1dCB0aGlzIGRvZXMgYnJpbmcg dXAgYSBwcm9ibGVtIOKAkyBub2JvZHkgZXZlciByZWFsbHkgZGVmaW5lZCBhIHJlc3BvbnNlIGJv ZHkgZm9yIE9QVElPTlMuIFJGQyAyNjE2IGV4cGxpY2l0bHkgZGVmaW5lZCB0aGUgbGVnYWxpdHkg b2Ygc3VjaCBhIGJvZHkgYnV0IG5vIHN0YW5kYXJkIHdhcyBkZWZpbmVkIGZvciB3aGF0IHRoZSBi b2R5IHNob3VsZCBsb29rIGxpa2UuIFRoaXMgaXMgYW4gaXNzdWUNCiBiZWNhdXNlIGlmIHNvbWVv bmUgZG9lcyBkZWZpbmUgYSBib2R5IGZvciBPUFRJT05TIHRoZW4gdGhleSByZWFsbHkgbmVlZCB0 byBkbyBzbyBpbiBhIHdheSB0aGF0IG90aGVyIHN0YW5kYXJkcyBjYW4gYnVpbGQgb24gdG9wIG9m LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+U28gd2UgaGF2ZSBhIGNob2ljZSB3aGVuIGl0IGNvbWVzIHRvIHVzaW5nIE9Q VElPTlMuIFdlIGNhbiByZXR1cm4gZGF0YSBpbiB0aGUgaGVhZGVyIGluIHdoaWNoIGNhc2UgYWxs IHdlIGhhdmUgdG8gZG8gaXMganVzdCBkZWZpbmUgdGhlIGhlYWRlciwgc3VibWl0IHRoZSBSRkMN CiBhbmQgY2FsbCBpdCBkYXkuIE9yIHdlIGNhbiB1c2UgdGhlIGJvZHkgYnV0IGluIHRoYXQgY2Fz ZSB3ZSBwcm9iYWJseSBuZWVkIHRvIHdyaXRlIG9uZSBzcGVjIHRvIGRlZmluZSBhIGdlbmVyaWMg d2F5IHRvIHJldHVybiBkYXRhIGluIE9QVElPTlMgcmVzcG9uc2UgYm9kaWVzIChlLmcuIGhvdyBk byBkaWZmZXJlbnQgT1BUSU9OUyByZXNwb25zZXMgbGl2ZSB0b2dldGhlcj8pIGFuZCBnZXQgdGhh dCBzdGFuZGFyZGl6ZWQuIFRoZW4gd2UgY2FuIHdyaXRlDQogYSBzZWNvbmQgUkZDIHRvIGRlZmlu ZSBob3cgb3VyIHNwZWNpZmljIGRhdGEgd291bGQgYmUgY2FycmllZCBpbiBPUFRJT05TLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRob3VnaHRzPzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IFlhcm9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+IFRvcnN0ZW4gTG9kZGVyc3RlZHQgW21haWx0bzp0b3JzdGVuQGxvZGRlcnN0 ZWR0Lm5ldF0NCjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEp1bmUgMjUsIDIwMTAgMTE6MDkg UE08YnI+DQo8Yj5Ubzo8L2I+IFlhcm9uIEdvbGFuZDxicj4NCjxiPkNjOjwvYj4gRXJhbiBIYW1t ZXItTGFoYXY7IEphbWVzIE1hbmdlcjsgT0F1dGggV0c8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6 IFtPQVVUSC1XR10gT0F1dGggZGlzY292ZXJ5IGRyYWZ0PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIGl0IHNob3VsZCBiZSBwb3Nz aWJsZSB0byBkaXNjb3ZlciBhIHJlc291cmNlJ3MgT0F1dGggc2VydmVyIGFuZCBpdHMgY2FwYWJp bGl0aWVzIHVzaW5nIGEgZGlyZWN0IERpc2NvdmVyeSByZXF1ZXN0LiBJIGRvbid0IHRoaW5rIGEg V1dXLUF1dGhlbnRpY2F0ZSBIZWFkZXIgaXMgdGhlIHJpZ2h0IHJlcHJlc2VudGF0aW9uIGZvciB0 aGlzIGtpbmQgb2YgZGF0YS4gV2hhdCBhYm91dCBhIEpTT04gb3IgWE1MDQogZG9jdW1lbnQgcmV0 dXJuZWQgaW4gcmVzcG9uc2UgdG8gYW4gT1BUSU9OUyByPHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxl LXNwYW4iPmVxdWVzdCAoYXMgeW91IHN1Z2dlc3RlZCkgb3IgYSBHRVQgcmVxdWVzdCB3aXRoIGEg Y2VydGFpbiBjb250ZW50IHR5cGUgaW4gaXRzIEFDQ0VQVCBIZWFkZXI/PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5yZWdhcmRzLDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5Ub3JzdGVuLiZuYnNwOzxicj4NCjxicj4NCjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij48YnI+DQpBbSAyMy4wNi4yMDEwIHVtIDIwOjIwIHNjaHJpZWIgWWFy b24gR29sYW5kICZsdDs8YSBocmVmPSJtYWlsdG86eWFyb25nQG1pY3Jvc29mdC5jb20iPnlhcm9u Z0BtaWNyb3NvZnQuY29tPC9hPiZndDs6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5ObyBvYmplY3Rpb25zIG9uIG15IHBhcnQuIEkgd291bGQgcmF0aGVy IGhhdmUgYSBzbWFsbGVyIGNvcmUgc3BlYyB3aXRoIGZlYXR1cmVzIHRoYXQgZXZlcnlvbmUgYWdy ZWVzDQogb24uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QlRXLCBhIHRob3VnaHQgZm9yIHRoZSBkaXNjb3Zlcnkg ZHJhZnQg4oCTIFJGQyAyNjE2LzI2MTcgb25seSBkZWZpbmVzIHd3dy1hdXRoZW50aWNhdGXigJlz IHNlbWFudGljcw0KIGluIHRoZSBjb250ZXh0IG9mIGEgNDAxLiBJdOKAmXMgdW5jbGVhciBmcm9t IHRoZSBkcmFmdCB3aGF0IGl0IHdvdWxkIG1lYW4gdG8gcmV0dXJuIGEgd3d3LWF1dGhlbnRpY2F0 ZSBoZWFkZXIgb24gYSAyMDAgcmVzcG9uc2UuIFRoZSByZWFzb24gSSBjYXJlIGFib3V0IHRoaXMg aXMgdGhhdCBJIHRoaW5rIGl0IG1ha2VzIHNlbnNlIHRoYXQgaWYgc29tZW9uZSB3YW50cyB0byB0 YWxrIHRvIGFuIGVuZHBvaW50IHRoZXkga25vdyBzdXBwb3J0cyBPQXV0aA0KIGFuZCBuZWVkIHRv IGtub3cgd2hlcmUgdGhlaXIgdG9rZW4gaXNzdWVyIGxvY2F0aW9uIGlzIHRoZXkgd291bGQgd2Fu dCB0byBmaXJlIG9mZiBhbiBPUFRJT05TIHJlcXVlc3QgdG8gdGhlIHJlc291cmNlIGFuZCBmaW5k IG91dCBmcm9tIHRoZSByZXNwb25zZSB3aGVyZSB0aGUgaXNzdWVyIGlzIGFuZCB3aGF0IHJlYWxt IGlzIGJlaW5nIHVzZWQuIEl0IHNlZW1zIHRvIG1lIHRoYXQgdGhlIHNpbXBsZXN0IHdheSB0byBz b2x2ZSB0aGlzIHByb2JsZW0NCiBpcyB0byBqdXN0IHJldHVybiB3d3ctYXV0aGVudGljYXRlIG9u IGEgMjAwIHJlc3BvbnNlIHRvIGFuIE9QVElPTlMgcmVxdWVzdC4gPC9zcGFuPg0KPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhvdWdodHM/PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IFRoYW5rcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgWWFyb248L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBp biAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEVyYW4gSGFtbWVyLUxhaGF2IFttYWls dG86ZXJhbkBodWVuaXZlcnNlLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEp1 bmUgMjMsIDIwMTAgMTE6MDQgQU08YnI+DQo8Yj5Ubzo8L2I+IFlhcm9uIEdvbGFuZDsgSmFtZXMg TWFuZ2VyOyBPQXV0aCBXRzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogT0F1dGggZGlzY292ZXJ5 IGRyYWZ0Pzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkkgdGhpbmsgdGhlIGNvcmUgd29yayBpcyBwcmV0dHkg c3RhYmxlIG5vdywgdW5saWtlIHRoZSBkaXNjb3ZlcnkgYml0cyB3aGljaCAod2hpbGUgc2ltcGxl KSBhcmUgbm90IGVuam95aW5nIHRoZSBzYW1lDQogbGV2ZWwgb2YgY29uc2Vuc3VzLiBJIHRoaW5r IGl0IGlzIG11Y2ggbW9yZSBwcmFjdGljYWwgdG8gcHJvcG9zZSB0aGVtIGFzIGEgc2VwYXJhdGUg ZG9jdW1lbnQgYW5kIHBlcmhhcHMgY29uc2lkZXIgbWVyZ2luZyB0aGVtIGxhdGVyIG9uIHdoZW4g dGhleSByZWFjaCBhbiBlcXVhbCBsZXZlbCBvZiBzdGFiaWxpdHkuIEJ1dCBvdmVyYWxsLCBJ4oCZ bSBub3QgdG9vIHdvcnJpZXMgYWJvdXQgbXVsdGlwbGUgZG9jdW1lbnRzLjxicj4NCjxicj4NCkVI TDxicj4NCjxicj4NCjxicj4NCk9uIDYvMjMvMTAgMTE6MDAgQU0sICZxdW90O1lhcm9uIEdvbGFu ZCZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnlhcm9uZ0BtaWNyb3NvZnQuY29tIj55YXJvbmdA bWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90 dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JJ3ZlIGJlZW4gbm9vZGxp bmcgWzFdIGEgbG90IGFib3V0IGZ1bGwgZGVsZWdhdGlvbiBpbiBPQXV0aCBbMl0gYW5kIG9uZSBv ZiB0aGUgaXNzdWVzIHRoYXQgY2FtZSBvdXQgb2YgdGhhdCB3YXMgdGhlIG5lZWQNCiBmb3IgZGlz Y292ZXJpbmcgYm90aCB0aGUgbG9jYXRpb24gYW5kIHJlYWxtIG9mIGFuIGVuZHBvaW50J3MgdG9r ZW4gc2VydmVyLiBCdXQgYXQgbGVhc3QgZm9yIG15IHVzZSBjYXNlcyAod2hpY2ggY29uc2lzdCBv ZiB3YWxraW5nIHVwIHRvIGEgc2VydmljZSBhbmQgbWFraW5nIGFuIG9wdGlvbnMgcmVxdWVzdCBh bmQgZ2V0dGluZyBiYWNrIGEgd3d3LWF1dGhlbnRpY2F0ZSBoZWFkZXIpIGFsbCBJIG5lZWQgYmFj ayBpcyBhIHJlYWxtIGFuZCBhIHRva2VuDQogc2VydmVyIFVSTC4gSW4gb3RoZXIgd29yZHMganVz dCBoYXZpbmcgb25lIGFyZ3VtZW50IGFkZGVkIHRvIG91ciB3d3ctYXV0aGVudGljYXRlIGhlYWRl ciB3b3VsZCBiZSBlbm91Z2ggdG8gc29sdmUgdGhlIGNhc2Ugd2hlcmUgc29tZW9uZSB3YW50cyB0 byB3YWxrIHVwIHRvIGEgc2VydmljZSBhbmQgZmluZCBvdXQgd2hlcmUgaXRzIHRva2VuIHNlcnZl ciBpcy4gRG9lcyB0aGF0IHJlYWxseSBuZWVkIGl0cyBvd24gc3BlYz8gT3IgY2FuIHdlIGp1c3QN CiBhZGQgYW4gYXJndW1lbnQgdG8gd3d3LWF1dGhlbnRpY2F0ZSBpbiB0aGUgY3VycmVudCBzcGVj Pzxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1Ro YW5rcyw8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtZYXJvbjxi cj4NCjxicj4NClsxXSBTZWUgPGEgaHJlZj0iaHR0cDovL3d3dy5nb2xhbmQub3JnL29hdXRoZ2Vu ZXJpY2RlbGVnYXRpb24vIj5odHRwOi8vd3d3LmdvbGFuZC5vcmcvb2F1dGhnZW5lcmljZGVsZWdh dGlvbi88L2E+IGZvciBhbiBvdmVydmlldyBvZiBteSB0aGlua2luZyBvbiBmdWxsIGRlbGVnYXRp b24gaW4gT0F1dGguIEF0IHRoZSB2ZXJ5IGVuZCBhcmUgbGlua3MgdG8gYSBidW5jaCBvZiBvdGhl ciBtdWNoIG1vcmUgaW4tZGVwdGggYXJ0aWNsZXMgb24gcGFydGljdWxhcg0KIHN1YmplY3RzIHRv dWNoZWQgb24gaW4gdGhlIG1haW4gYXJ0aWNsZS48YnI+DQo8YnI+DQpbMl0gSSBkZWZpbmUgJ2Z1 bGwgZGVsZWdhdGlvbicgYXMgJnF1b3Q7VXNlciBYIG9mIFNlcnZpY2UgWSBncmFudHMgcGVybWlz c2lvbiBaIHRvIFVzZXIgQSBvZiBTZXJ2aWNlIEImcXVvdDsuIEN1cnJlbnRseSBPQXV0aCByZXF1 aXJlcyBYID09IEEuIEluIHRoZSBmdXR1cmUgSSBob3BlIHRvIHNlZSBleHRlbnNpb25zIHRvIE9B dXRoIHRoYXQgZW5hYmxlIHdoYXQgSSdtIHRlcm1pbmcgJ2Z1bGwgZGVsZWdhdGlvbicuIEJ1dCBw ZXJzb25hbGx5IEknbSByZWFsbHkgaGFwcHkNCiB0aGF0IE9BdXRoIGhhcyB0aGUgWD09QSByZXN0 cmljdGlvbi4gSXQgc2ltcGxpZmllcyBhIHdob2xlIGhvc3Qgb2YgaXNzdWVzIGFuZCBzYXRpc2Zp ZXMgYSByZWFsbHkgaW1wb3J0YW50IHVzZSBjYXNlLjxicj4NCjxicj4NCiZndDsgLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7IEZyb206IDxhIGhyZWY9Im1haWx0bzpvYXV0aC1i b3VuY2VzQGlldGYub3JnIj5vYXV0aC1ib3VuY2VzQGlldGYub3JnPC9hPiBbPGEgaHJlZj0ibWFp bHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3Jn PC9hPl0gT24gQmVoYWxmPGJyPg0KJmd0OyBPZiBFcmFuIEhhbW1lci1MYWhhdjxicj4NCiZndDsg U2VudDogTW9uZGF5LCBKdW5lIDIxLCAyMDEwIDk6NTAgUE08YnI+DQomZ3Q7IFRvOiBNYW5nZXIs IEphbWVzIEg7IE9BdXRoIFdHICg8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9hdXRo QGlldGYub3JnPC9hPik8YnI+DQomZ3Q7IFN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE9BdXRoIGRp c2NvdmVyeSBkcmFmdD88YnI+DQomZ3Q7PGJyPg0KJmd0OyBZZXMsIGl0J3Mgb24gbXkgZGVzayBh bmQgbm90IHlldCByZWFkeSwgYnV0IEkgYW0gd29ya2luZyBvbiBvbmUuIEl0IGluY2x1ZGVzPGJy Pg0KJmd0OyB5b3VyIHNpdGVzIHByb3Bvc2FsIGFtb25nIG90aGVyIHRoaW5ncy4gSSBhbSB0cnlp bmcgdG8gZ2V0IHRoZSBjb3JlIHNwZWM8YnI+DQomZ3Q7IHN0YWJsZSB0aGlzIHdlZWsgYW5kIGZv Y3VzIG9uIHRoYXQgbmV4dC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBFSEw8YnI+DQomZ3Q7PGJyPg0K Jmd0OyAmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyAmZ3Q7IEZyb206 IE1hbmdlciwgSmFtZXMgSCBbPGEgaHJlZj0ibWFpbHRvOkphbWVzLkguTWFuZ2VyQHRlYW0udGVs c3RyYS5jb20iPm1haWx0bzpKYW1lcy5ILk1hbmdlckB0ZWFtLnRlbHN0cmEuY29tPC9hPl08YnI+ DQomZ3Q7ICZndDsgU2VudDogTW9uZGF5LCBKdW5lIDIxLCAyMDEwIDg6MDMgUE08YnI+DQomZ3Q7 ICZndDsgVG86IEVyYW4gSGFtbWVyLUxhaGF2OyBPQXV0aCBXRyAoPGEgaHJlZj0ibWFpbHRvOm9h dXRoQGlldGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT4pPGJyPg0KJmd0OyAmZ3Q7IFN1YmplY3Q6 IE9BdXRoIGRpc2NvdmVyeSBkcmFmdD88YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgRXJh biw8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgVGhlcmUgaGF2ZSBiZWVuIGEgZmV3IG1l bnRpb25zIHJlY2VudGx5IG9mIGFuIE9BdXRoIGRpc2NvdmVyeSBkcmFmdC48YnI+DQomZ3Q7ICZn dDsgSXMgdGhlcmUgYW55IHN1Y2ggZHJhZnQgeWV0LCBvciBpcyB0aGlzIGp1c3QgYSBwYXJ0IHRo YXQgd2Uga25vdyBuZWVkczxicj4NCiZndDsgJmd0OyB0byBiZSBkb25lPzxicj4NCiZndDsgJmd0 Ozxicj4NCiZndDsgJmd0OyBUaGUgZW1haWwgb24gJnF1b3Q7T0F1dGggbWVldGluZyBub3RlcyBv biAtMDUgKHdpdGggdXBkYXRlcykmcXVvdDsgc2FpZDo8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7 ICZndDsgJmd0OyZndDsgNi4xLjEuIC0gZGVzY3JpYmluZyB0aGUgV1dXLUF1dGhlbnRpY2F0ZSBy ZXNwb25zZSBoZWFkZXI8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsgJmd0 OyZndDsgLSBEaXNjb3ZlcnkgbmVlZGVkIGZvciB2YXJpb3VzIGVsZW1lbnRzPGJyPg0KJmd0OyAm Z3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyBZZXMuIFRoYXQncyBmb3IgdGhlIGRpc2NvdmVy eSBkcmFmdC48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgQSB3 aWtpIHBhZ2Ugb24gJnF1b3Q7RnV0dXJlIE9wZW5JRCBUZWNobmljYWwgUmVxdWlyZW1lbnRzJnF1 b3Q7PGJyPg0KJmd0OyAmZ3Q7ICZsdDs8YSBocmVmPSJodHRwOi8vd2lraS5vcGVuaWQubmV0L0Z1 dHVyZS1PcGVuSUQtVGVjaG5pY2FsLVJlcXVpcmVtZW50cyI+aHR0cDovL3dpa2kub3BlbmlkLm5l dC9GdXR1cmUtT3BlbklELVRlY2huaWNhbC1SZXF1aXJlbWVudHM8L2E+Jmd0OyBzYXlzOjxicj4N CiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IDYpIElkUCBEaXNjb3Zlcnk8YnI+DQomZ3Q7 ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyogTXVjaCBv ZiB0aGlzIHdpbGwgYmUgY292ZXJlZCBieSBPQXV0aDIgRGlzY292ZXJ5LDxicj4NCiZndDsgJmd0 OyAmZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2hvd2V2ZXIgT0lDIG1heSBuZWVk IHRvIGRlZmluZSBPcGVuSUQgc3BlY2lmaWMgZmVhdHVyZXMuPGJyPg0KJmd0OyAmZ3Q7ICZndDvi gKY8YnI+DQomZ3Q7ICZndDsgJmd0OyAxNykgU2ltcGxlciBkaXNjb3Zlcnk8YnI+DQomZ3Q7ICZn dDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyogU2VlIEVyYW4n cyBPQXV0aCBEaXNjb3ZlcnkgcHJvcG9zYWw8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8 YnI+DQomZ3Q7ICZndDsgVGhlcmUgd2FzIGFuIE9BdXRoIDEuMCBEaXNjb3ZlcnkgZHJhZnQgb3Zl ciAyIHllYXJzIGFnbywgYnV0IHRoYXQgaXMgdGFnZ2VkOjxicj4NCiZndDsgJmd0OyAmcXVvdDtl eHBpcmVkJnF1b3Q7LCAmcXVvdDttYXJrZWQgYXMgb2Jzb2xldGUgYnkgaXRzIGF1dGhvciZxdW90 OywgJnF1b3Q7ZGlzY291cmFnZWQgZnJvbTxicj4NCiZndDsgJmd0OyBpbXBsZW1lbnRpbmcmcXVv dDssICZxdW90O25vIHVwZGF0ZSBpcyBleHBlY3RlZCZxdW90OywgJnF1b3Q7cmVwbGFjZWQgYnkg dGhlIE9BdXRoIDIuMDxicj4NCiZndDsgZWZmb3J0JnF1b3Q7Ljxicj4NCiZndDsgJmd0Ozxicj4N CiZndDsgJmd0OyBJIGtub3cgSSBzaG91bGQgd3JpdGUgYSBkaXNjb3ZlcnkgZHJhZnQgbXlzZWxm Ljxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAtLTxicj4NCiZndDsgJmd0OyBKYW1lcyBN YW5nZXI8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KJmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IDxhIGhyZWY9Im1h aWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyA8YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRo QGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_7C01E631FF4B654FA1E783F1C0265F8C579D0FEDTK5EX14MBXC117r_-- From yarong@microsoft.com Mon Jun 28 15:12:51 2010 Return-Path: <yarong@microsoft.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51B293A67FA for <oauth@core3.amsl.com>; Mon, 28 Jun 2010 15:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.855 X-Spam-Level: X-Spam-Status: No, score=-9.855 tagged_above=-999 required=5 tests=[AWL=0.743, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FCS10eKLKXFQ for <oauth@core3.amsl.com>; Mon, 28 Jun 2010 15:12:45 -0700 (PDT) Received: from smtp.microsoft.com (maila.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id AB4393A6892 for <oauth@ietf.org>; Mon, 28 Jun 2010 15:12:45 -0700 (PDT) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 28 Jun 2010 15:12:57 -0700 Received: from TK5EX14MBXC117.redmond.corp.microsoft.com ([169.254.8.23]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.01.0160.007; Mon, 28 Jun 2010 15:12:55 -0700 From: Yaron Goland <yarong@microsoft.com> To: Torsten Lodderstedt <torsten@lodderstedt.net>, Dick Hardt <dick.hardt@gmail.com> Thread-Topic: [OAUTH-WG] What to do about 'realm' Thread-Index: AcsWZA3VaAGfBKT6Rq+fJ1qCaXCqogAWqIAAABozBAAABh2zIA== Date: Mon, 28 Jun 2010 22:12:52 +0000 Message-ID: <7C01E631FF4B654FA1E783F1C0265F8C579D103B@TK5EX14MBXC117.redmond.corp.microsoft.com> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EC84ADE@P3PW5EX1MB01.EX1.SECURESERVER.NET> <269A7D01-CB98-46F3-9D17-C0AAA31041E4@gmail.com> <4C28E4F2.6060605@lodderstedt.net> In-Reply-To: <4C28E4F2.6060605@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7C01E631FF4B654FA1E783F1C0265F8C579D103BTK5EX14MBXC117r_" MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] What to do about 'realm' X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 28 Jun 2010 22:12:51 -0000 --_000_7C01E631FF4B654FA1E783F1C0265F8C579D103BTK5EX14MBXC117r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 (for #3->#4) From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of T= orsten Lodderstedt Sent: Monday, June 28, 2010 11:08 AM To: Dick Hardt Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] What to do about 'realm' +1 Am 28.06.2010 07:37, schrieb Dick Hardt: I vote for (3) unless a good (4) is suggested. On 2010-06-27, at 6:51 PM, Eran Hammer-Lahav wrote: Over the past year many people expressed concerns about the use of the 'rea= lm' WWW-Authenticate header parameter. The parameter is defined in RFC 2617= as required, and is allowed to have scheme-specific structure. We have a few options: 1. Leave it as required under the definition of RFC 2617 (i.e. provide no h= elp, developers will need to ready 2617 and figure out what to do with it). 2. Update 2617 to remove the requirement - this is not going to be easy or = possible to predict success. 3. Provide specific guidance as to what to do with the realm parameter. 4. Something else. Comments? EHL _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth --_000_7C01E631FF4B654FA1E783F1C0265F8C579D103BTK5EX14MBXC117r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"> <base href=3D"x-msg://96/"><style><!-- /* Font Definitions */ @font-face {font-family:Helvetica; panose-1:2 11 6 4 2 2 2 2 2 4;} @font-face {font-family:Helvetica; panose-1:2 11 6 4 2 2 2 2 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} @font-face {font-family:Consolas; panose-1:2 11 6 9 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif"; color:black;} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} pre {mso-style-priority:99; mso-style-link:"HTML Preformatted Char"; margin:0in; margin-bottom:.0001pt; font-size:10.0pt; font-family:"Courier New"; color:black;} span.apple-style-span {mso-style-name:apple-style-span;} span.HTMLPreformattedChar {mso-style-name:"HTML Preformatted Char"; mso-style-priority:99; mso-style-link:"HTML Preformatted"; font-family:Consolas; color:black;} span.EmailStyle20 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body bgcolor=3D"white" lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">+1 (for #3->#4)<o:= p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in = 4.0pt"> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:"= ;Tahoma","sans-serif";color:windowtext">From:</span></b><spa= n style=3D"font-size:10.0pt;font-family:"Tahoma","sans-serif= ";color:windowtext"> oauth-bounces@ietf.org [mailto:oauth-bounces@ietf= .org] <b>On Behalf Of </b>Torsten Lodderstedt<br> <b>Sent:</b> Monday, June 28, 2010 11:08 AM<br> <b>To:</b> Dick Hardt<br> <b>Cc:</b> OAuth WG (oauth@ietf.org)<br> <b>Subject:</b> Re: [OAUTH-WG] What to do about 'realm'<o:p></o:p></span></= p> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">+1<br> <br> Am 28.06.2010 07:37, schrieb Dick Hardt: <o:p></o:p></p> <p class=3D"MsoNormal">I vote for (3) unless a good (4) is suggested. <o:p>= </o:p></p> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> <div> <div> <p class=3D"MsoNormal">On 2010-06-27, at 6:51 PM, Eran Hammer-Lahav wrote:<= o:p></o:p></p> </div> <p class=3D"MsoNormal"><br> <br> <o:p></o:p></p> <div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif"">Over the past year many people expresse= d concerns about the use of the ‘realm’ WWW-Authenticate header= parameter. The parameter is defined in RFC 2617 as required, and is allowed to have scheme-specific structure.<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif""> <o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif"">We have a few options:<o:p></o:p></span= ></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif""> <o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif"">1. Leave it as required under the defin= ition of RFC 2617 (i.e. provide no help, developers will need to ready 2617= and figure out what to do with it).<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif"">2. Update 2617 to remove the requiremen= t – this is not going to be easy or possible to predict success.<o:p>= </o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif"">3. Provide specific guidance as to what= to do with the realm parameter.<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif"">4. Something else.<o:p></o:p></span></p= > </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif""> <o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif"">Comments?<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif""> <o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif"">EHL<o:p></o:p></span></p> </div> <p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;font-family:"He= lvetica","sans-serif"">_____________________________________= __________<br> OAuth mailing list<br> <a href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/oauth">https://www.ietf.or= g/mailman/listinfo/oauth</a><o:p></o:p></span></p> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <pre><o:p> </o:p></pre> <pre><o:p> </o:p></pre> <pre>_______________________________________________<o:p></o:p></pre> <pre>OAuth mailing list<o:p></o:p></pre> <pre><a href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a><o:p></o:p></pre> <pre><a href=3D"https://www.ietf.org/mailman/listinfo/oauth">https://www.ie= tf.org/mailman/listinfo/oauth</a><o:p></o:p></pre> <pre>  <o:p></o:p></pre> </div> </div> </body> </html> --_000_7C01E631FF4B654FA1E783F1C0265F8C579D103BTK5EX14MBXC117r_-- From yarong@microsoft.com Mon Jun 28 15:15:06 2010 Return-Path: <yarong@microsoft.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 925493A67FA for <oauth@core3.amsl.com>; Mon, 28 Jun 2010 15:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.917 X-Spam-Level: X-Spam-Status: No, score=-9.917 tagged_above=-999 required=5 tests=[AWL=0.682, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jd4BJkMEtxFC for <oauth@core3.amsl.com>; Mon, 28 Jun 2010 15:15:04 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 876E93A67CC for <oauth@ietf.org>; Mon, 28 Jun 2010 15:15:04 -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; Mon, 28 Jun 2010 15:15:14 -0700 Received: from TK5EX14MBXC117.redmond.corp.microsoft.com ([169.254.8.23]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.01.0160.007; Mon, 28 Jun 2010 15:15:14 -0700 From: Yaron Goland <yarong@microsoft.com> To: Torsten Lodderstedt <torsten@lodderstedt.net>, Marius Scurtescu <mscurtescu@google.com> Thread-Topic: [OAUTH-WG] Client credentials type Thread-Index: AcsW5Zz/FVZYBlj1T06cHdkG6yGF6wAQ7zsAAAILVAAAADaKAAAIxkVw Date: Mon, 28 Jun 2010 22:15:11 +0000 Message-ID: <7C01E631FF4B654FA1E783F1C0265F8C579D107B@TK5EX14MBXC117.redmond.corp.microsoft.com> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EC84C9D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C28E814.1060102@lodderstedt.net> <AANLkTilw0noo6qyKKXDI06Y4bIiippjvjGRFia0MwXmY@mail.gmail.com> <4C28F73A.4090800@lodderstedt.net> In-Reply-To: <4C28F73A.4090800@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Client credentials type X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 28 Jun 2010 22:15:06 -0000 We regularly deal with SAML assertions that easily go into the 100s of K. T= his is far more than most HTTP servers will accept. So we are pretty much r= equired to use the body. > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Torsten Lodderstedt > Sent: Monday, June 28, 2010 12:26 PM > To: Marius Scurtescu > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Client credentials type >=20 > what size do you expect? SPNEGO authentication headers can be up to > 12392 bytes and this does not seem to be a problem. >=20 > regards, > Torsten. >=20 > Am 28.06.2010 21:19, schrieb Marius Scurtescu: > > Only HTTP headers may not be enough. In Yaron's proposal, the > > assertion could be a SAML assertion, and these could be too large for > > headers. > > > > I think #1 makes sense. > > > > Marius > > > > > > > > On Mon, Jun 28, 2010 at 11:21 AM, Torsten Lodderstedt > > <torsten@lodderstedt.net> wrote: > > > >> I would prefer (2) since authorization headers are the natural way to > >> handle authentication in HTTP. Different client credential mechanisms > >> can be represented by different authentication scheme (even > >> custom-defined). HTTP libraries typically have special support for > >> handling such headers and it keeps the authentication mechanism > >> orthogonal of the API. Moreover, authorization headers very well work > >> together with status code 401 and WWW-Authenticate headers. Using > >> WWW-Authenticate headers, an authz server can easily signal what > >> mechanisms (multiple WWW-Authenticate headers are allowed in a single > HTTP response) it accepts for a particular request. > >> > >> regards, > >> Torsten. > >> > >> Am 28.06.2010 19:39, schrieb Eran Hammer-Lahav: > >> > >> Yaron Goland offered a proposal for an additional client credentials > >> mechanism based on assertion. His proposal raises the issue of > >> differentiating between the different kind of credentials used. When > >> it comes to access grant types, this group argued for being explicit > >> and providing a parameter declaring the grant type being used (even > >> though it is not technically necessary). > >> > >> > >> > >> While I don't believe a grant or credential type parameter is needed > >> - the type can be deduced from the other parameters present - we now > >> treat the same requirement with a different solution. I think this > >> creates a broken environment for extensibility (which is my current > focus). > >> > >> > >> > >> At the same time, introducing such a parameter can conflict with the > >> standard HTTP authentication mechanism. For example, a request > >> containing both "client_credentials_type=3Dbasic" and the HTTP > >> Authorization header seems odd. > >> > >> > >> > >> There are a few ways to address this: > >> > >> > >> > >> 1. Only use a type parameter when the credentials are passed using > >> parameters and not a header. > >> > >> 2. Only allow HTTP headers for authentication, while > >> "grandfathering-in" the client_secret parameter to simplify the most > common current practice. > >> > >> 3. Leave is underspecified, relying on the presence of extension > >> parameters or authentication headers for other credentials types. > >> > >> > >> > >> Thoughts? > >> > >> > >> > >> 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 > >> > >> > >> >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From wmills@yahoo-inc.com Mon Jun 28 15:32:12 2010 Return-Path: <wmills@yahoo-inc.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07E7F28C163 for <oauth@core3.amsl.com>; Mon, 28 Jun 2010 15:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.122 X-Spam-Level: X-Spam-Status: No, score=-17.122 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0dcLZ0NrAywI for <oauth@core3.amsl.com>; Mon, 28 Jun 2010 15:31:56 -0700 (PDT) Received: from mrout2-b.corp.re1.yahoo.com (mrout2-b.corp.re1.yahoo.com [69.147.107.21]) by core3.amsl.com (Postfix) with ESMTP id 1A14128C16A for <oauth@ietf.org>; Mon, 28 Jun 2010 15:31:45 -0700 (PDT) Received: from SNV-EXBH01.ds.corp.yahoo.com (snv-exbh01.ds.corp.yahoo.com [207.126.227.249]) by mrout2-b.corp.re1.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o5SMTc9M019194; Mon, 28 Jun 2010 15:29:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:x-mimeole:content-class:mime-version: content-type:subject:date:message-id:in-reply-to:x-ms-has-attach: x-ms-tnef-correlator:thread-topic:thread-index:references:from:to:cc:x-originalarrivaltime; b=iI8ZH2kyziW8V9wEqB7nJhoDCS3R1hRBLes8Rjp1THJbF7aqO6nSbeVoQe0dJl2m Received: from SNV-EXVS08.ds.corp.yahoo.com ([207.126.227.8]) by SNV-EXBH01.ds.corp.yahoo.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Jun 2010 15:29:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB1711.64856E44" Date: Mon, 28 Jun 2010 15:29:37 -0700 Message-ID: <012AB2B223CB3F4BB846962876F47217059B677B@SNV-EXVS08.ds.corp.yahoo.com> In-Reply-To: <7C01E631FF4B654FA1E783F1C0265F8C579D0FED@TK5EX14MBXC117.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] OAuth discovery draft? Thread-Index: AQHLEbd88ANnc80E8EanM4mdFaHtZpKN3qcAgAH2zrCAAAP3tYAAAdRggARizoCAA7n10IAAByYw References: <7C01E631FF4B654FA1E783F1C0265F8C579C6DC3@TK5EX14MBXC117.redmond.corp.microsoft.com><C8479A94.363F3%eran@hueniverse.com><7C01E631FF4B654FA1E783F1C0265F8C579C6E52@TK5EX14MBXC117.redmond.corp.microsoft.com><CDD1DDBF-BD1B-4F4E-8620-AA2FEC402C90@lodderstedt.net> <7C01E631FF4B654FA1E783F1C0265F8C579D0FED@TK5EX14MBXC117.redmond.corp.microsoft.com> From: "William Mills" <wmills@yahoo-inc.com> To: "Yaron Goland" <yarong@microsoft.com>, "Torsten Lodderstedt" <torsten@lodderstedt.net> X-OriginalArrivalTime: 28 Jun 2010 22:29:38.0278 (UTC) FILETIME=[64C62060:01CB1711] Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] OAuth discovery draft? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 28 Jun 2010 22:32:12 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB1711.64856E44 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In the SASL stuff I'm working on I was presuming I'd use the WWW-Authenticate header for returning the discovery info. ________________________________ From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Yaron Goland Sent: Monday, June 28, 2010 3:10 PM To: Torsten Lodderstedt Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth discovery draft? =09 =09 I believe that GET should be used to return the resource's state and its OAuth token endpoint is just a tiny part of that state. When we want to return part of the state we typically use either explicit headers (a la byte ranges) or a query parameter. Content-types should, I think, just control the syntax of what is returned, not the subset of data it contains. So I have to admit that I really don't like using GET for this sort of scenario. =20 OPTIONS is actually the officially blessed way to walk up to a resource, knock on the front door and ask 'what are you and what can you do?' So it seems to me we should start with OPTIONS. But this does bring up a problem - nobody ever really defined a response body for OPTIONS. RFC 2616 explicitly defined the legality of such a body but no standard was defined for what the body should look like. This is an issue because if someone does define a body for OPTIONS then they really need to do so in a way that other standards can build on top of. =20 So we have a choice when it comes to using OPTIONS. We can return data in the header in which case all we have to do is just define the header, submit the RFC and call it day. Or we can use the body but in that case we probably need to write one spec to define a generic way to return data in OPTIONS response bodies (e.g. how do different OPTIONS responses live together?) and get that standardized. Then we can write a second RFC to define how our specific data would be carried in OPTIONS. =20 Thoughts? =20 Yaron =20 From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]=20 Sent: Friday, June 25, 2010 11:09 PM To: Yaron Goland Cc: Eran Hammer-Lahav; James Manger; OAuth WG Subject: Re: [OAUTH-WG] OAuth discovery draft? =20 I think it should be possible to discover a resource's OAuth server and its capabilities using a direct Discovery request. I don't think a WWW-Authenticate Header is the right representation for this kind of data. What about a JSON or XML document returned in response to an OPTIONS request (as you suggested) or a GET request with a certain content type in its ACCEPT Header? =20 regards, Torsten.=20 =09 =09 =09 Am 23.06.2010 um 20:20 schrieb Yaron Goland <yarong@microsoft.com>: No objections on my part. I would rather have a smaller core spec with features that everyone agrees on. =20 BTW, a thought for the discovery draft - RFC 2616/2617 only defines www-authenticate's semantics in the context of a 401. It's unclear from the draft what it would mean to return a www-authenticate header on a 200 response. The reason I care about this is that I think it makes sense that if someone wants to talk to an endpoint they know supports OAuth and need to know where their token issuer location is they would want to fire off an OPTIONS request to the resource and find out from the response where the issuer is and what realm is being used. It seems to me that the simplest way to solve this problem is to just return www-authenticate on a 200 response to an OPTIONS request.=20 =20 Thoughts? =20 Thanks, =20 Yaron =20 From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]=20 Sent: Wednesday, June 23, 2010 11:04 AM To: Yaron Goland; James Manger; OAuth WG Subject: Re: OAuth discovery draft? =20 I think the core work is pretty stable now, unlike the discovery bits which (while simple) are not enjoying the same level of consensus. I think it is much more practical to propose them as a separate document and perhaps consider merging them later on when they reach an equal level of stability. But overall, I'm not too worries about multiple documents. =09 EHL =09 =09 On 6/23/10 11:00 AM, "Yaron Goland" <yarong@microsoft.com> wrote: I've been noodling [1] a lot about full delegation in OAuth [2] and one of the issues that came out of that was the need for discovering both the location and realm of an endpoint's token server. But at least for my use cases (which consist of walking up to a service and making an options request and getting back a www-authenticate header) all I need back is a realm and a token server URL. In other words just having one argument added to our www-authenticate header would be enough to solve the case where someone wants to walk up to a service and find out where its token server is. Does that really need its own spec? Or can we just add an argument to www-authenticate in the current spec? Thanks, Yaron =09 [1] See http://www.goland.org/oauthgenericdelegation/ for an overview of my thinking on full delegation in OAuth. At the very end are links to a bunch of other much more in-depth articles on particular subjects touched on in the main article. =09 [2] I define 'full delegation' as "User X of Service Y grants permission Z to User A of Service B". Currently OAuth requires X =3D=3D A. In the future I hope to see extensions to OAuth that enable = what I'm terming 'full delegation'. But personally I'm really happy that OAuth has the X=3D=3DA restriction. It simplifies a whole host of issues = and satisfies a really important use case. =09 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Eran Hammer-Lahav > Sent: Monday, June 21, 2010 9:50 PM > To: Manger, James H; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] OAuth discovery draft? > > Yes, it's on my desk and not yet ready, but I am working on one. It includes > your sites proposal among other things. I am trying to get the core spec > stable this week and focus on that next. > > EHL > > > -----Original Message----- > > From: Manger, James H [mailto:James.H.Manger@team.telstra.com] > > Sent: Monday, June 21, 2010 8:03 PM > > To: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org) > > Subject: OAuth discovery draft? > > > > Eran, > > > > There have been a few mentions recently of an OAuth discovery draft. > > Is there any such draft yet, or is this just a part that we know needs > > to be done? > > > > The email on "OAuth meeting notes on -05 (with updates)" said: > > > > >> 6.1.1. - describing the WWW-Authenticate response header > > >> > > >> - Discovery needed for various elements > > > > > > Yes. That's for the discovery draft. > > > > > > A wiki page on "Future OpenID Technical Requirements" > > <http://wiki.openid.net/Future-OpenID-Technical-Requirements> says: > > > > > 6) IdP Discovery > > > > > > * Much of this will be covered by OAuth2 Discovery, > > > however OIC may need to define OpenID specific features. > > >... > > > 17) Simpler discovery > > > > > > * See Eran's OAuth Discovery proposal > > > > > > There was an OAuth 1.0 Discovery draft over 2 years ago, but that is tagged: > > "expired", "marked as obsolete by its author", "discouraged from > > implementing", "no update is expected", "replaced by the OAuth 2.0 > effort". > > > > I know I should write a discovery draft myself. > > > > -- > > James Manger > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ------_=_NextPart_001_01CB1711.64856E44 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20 "urn:schemas-microsoft-com:vml" xmlns:o =3D=20 "urn:schemas-microsoft-com:office:office" xmlns:w =3D=20 "urn:schemas-microsoft-com:office:word" xmlns:m =3D=20 "http://schemas.microsoft.com/office/2004/12/omml"><HEAD> <META content=3D"text/html; charset=3Dus-ascii" = http-equiv=3DContent-Type> <META name=3DGENERATOR content=3D"MSHTML 8.00.6001.18904"> <STYLE>@font-face { font-family: Calibri; } @font-face { font-family: Tahoma; } @page WordSection1 {size: 8.5in 11.0in; margin: 1.0in 1.0in 1.0in 1.0in; = } P.MsoNormal { MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman","serif"; FONT-SIZE: = 12pt } LI.MsoNormal { MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman","serif"; FONT-SIZE: = 12pt } DIV.MsoNormal { MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman","serif"; FONT-SIZE: = 12pt } A:link { COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99 } SPAN.MsoHyperlink { COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99 } A:visited { COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99 } SPAN.MsoHyperlinkFollowed { COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99 } P.MsoAcetate { MARGIN: 0in 0in 0pt; FONT-FAMILY: "Tahoma","sans-serif"; FONT-SIZE: = 8pt; mso-style-priority: 99; mso-style-link: "Balloon Text Char" } LI.MsoAcetate { MARGIN: 0in 0in 0pt; FONT-FAMILY: "Tahoma","sans-serif"; FONT-SIZE: = 8pt; mso-style-priority: 99; mso-style-link: "Balloon Text Char" } DIV.MsoAcetate { MARGIN: 0in 0in 0pt; FONT-FAMILY: "Tahoma","sans-serif"; FONT-SIZE: = 8pt; mso-style-priority: 99; mso-style-link: "Balloon Text Char" } SPAN.apple-style-span { mso-style-name: apple-style-span } SPAN.EmailStyle18 { FONT-FAMILY: "Calibri","sans-serif"; COLOR: #1f497d; mso-style-type: = personal-reply } SPAN.BalloonTextChar { FONT-FAMILY: "Tahoma","sans-serif"; mso-style-priority: 99; = mso-style-link: "Balloon Text"; mso-style-name: "Balloon Text Char" } .MsoChpDefault { FONT-SIZE: 10pt; mso-style-type: export-only } DIV.WordSection1 { page: WordSection1 } </STYLE> <!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--></HEAD> <BODY lang=3DEN-US link=3Dblue bgColor=3Dwhite vLink=3Dpurple> <DIV dir=3Dltr align=3Dleft><SPAN class=3D338572822-28062010><FONT = color=3D#0000ff=20 size=3D2 face=3DArial>In the SASL stuff I'm working on I was presuming = I'd use the=20 WWW-Authenticate header for returning the discovery=20 info.</FONT></SPAN></DIV><BR> <BLOCKQUOTE=20 style=3D"BORDER-LEFT: #0000ff 2px solid; PADDING-LEFT: 5px; MARGIN-LEFT: = 5px; MARGIN-RIGHT: 0px"=20 dir=3Dltr> <DIV dir=3Dltr lang=3Den-us class=3DOutlookMessageHeader align=3Dleft> <HR tabIndex=3D-1> <FONT size=3D2 face=3DTahoma><B>From:</B> oauth-bounces@ietf.org=20 [mailto:oauth-bounces@ietf.org] <B>On Behalf Of </B>Yaron=20 Goland<BR><B>Sent:</B> Monday, June 28, 2010 3:10 PM<BR><B>To:</B> = Torsten=20 Lodderstedt<BR><B>Cc:</B> OAuth WG<BR><B>Subject:</B> Re: [OAUTH-WG] = OAuth=20 discovery draft?<BR></FONT><BR></DIV> <DIV></DIV> <DIV class=3DWordSection1> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; = FONT-SIZE: 11pt">I=20 believe that GET should be used to return the resource’s state = and its OAuth=20 token endpoint is just a tiny part of that state. When we want to = return part=20 of the state we typically use either explicit headers (a la byte = ranges) or a=20 query parameter. Content-types should, I think, just control the = syntax of=20 what is returned, not the subset of data it contains. So I have to = admit that=20 I really don’t like using GET for this sort of = scenario.<o:p></o:p></SPAN></P> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; = FONT-SIZE: 11pt"><o:p> </o:p></SPAN></P> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; = FONT-SIZE: 11pt">OPTIONS=20 is actually the officially blessed way to walk up to a resource, knock = on the=20 front door and ask ‘what are you and what can you do?’ So = it seems to me we=20 should start with OPTIONS. But this does bring up a problem – = nobody ever=20 really defined a response body for OPTIONS. RFC 2616 explicitly = defined the=20 legality of such a body but no standard was defined for what the body = should=20 look like. This is an issue because if someone does define a body for = OPTIONS=20 then they really need to do so in a way that other standards can build = on top=20 of.<o:p></o:p></SPAN></P> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; = FONT-SIZE: 11pt"><o:p> </o:p></SPAN></P> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; = FONT-SIZE: 11pt">So=20 we have a choice when it comes to using OPTIONS. We can return data in = the=20 header in which case all we have to do is just define the header, = submit the=20 RFC and call it day. Or we can use the body but in that case we = probably need=20 to write one spec to define a generic way to return data in OPTIONS = response=20 bodies (e.g. how do different OPTIONS responses live together?) and = get that=20 standardized. Then we can write a second RFC to define how our = specific data=20 would be carried in OPTIONS.<o:p></o:p></SPAN></P> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; = FONT-SIZE: 11pt"><o:p> </o:p></SPAN></P> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; = FONT-SIZE: = 11pt">           &= nbsp;   =20 Thoughts?<o:p></o:p></SPAN></P> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; = FONT-SIZE: 11pt"><o:p> </o:p></SPAN></P> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; = FONT-SIZE: = 11pt">           &= nbsp;           &n= bsp;       =20 Yaron<o:p></o:p></SPAN></P> <P class=3DMsoNormal><SPAN=20 style=3D"FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; = FONT-SIZE: 11pt"><o:p> </o:p></SPAN></P> <DIV=20 style=3D"BORDER-BOTTOM: medium none; BORDER-LEFT: blue 1.5pt solid; = PADDING-BOTTOM: 0in; PADDING-LEFT: 4pt; PADDING-RIGHT: 0in; BORDER-TOP: = medium none; BORDER-RIGHT: medium none; PADDING-TOP: 0in"> <DIV> <DIV=20 style=3D"BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; = PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: = #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt"> <P class=3DMsoNormal><B><SPAN=20 style=3D"FONT-FAMILY: 'Tahoma','sans-serif'; FONT-SIZE: = 10pt">From:</SPAN></B><SPAN=20 style=3D"FONT-FAMILY: 'Tahoma','sans-serif'; FONT-SIZE: 10pt"> Torsten = Lodderstedt [mailto:torsten@lodderstedt.net] <BR><B>Sent:</B> Friday, = June 25,=20 2010 11:09 PM<BR><B>To:</B> Yaron Goland<BR><B>Cc:</B> Eran = Hammer-Lahav;=20 James Manger; OAuth WG<BR><B>Subject:</B> Re: [OAUTH-WG] OAuth = discovery=20 draft?<o:p></o:p></SPAN></P></DIV></DIV> <P class=3DMsoNormal><o:p> </o:p></P> <DIV> <P class=3DMsoNormal>I think it should be possible to discover a = resource's=20 OAuth server and its capabilities using a direct Discovery request. I = don't=20 think a WWW-Authenticate Header is the right representation for this = kind of=20 data. What about a JSON or XML document returned in response to an = OPTIONS=20 r<SPAN class=3Dapple-style-span>equest (as you suggested) or a GET = request with=20 a certain content type in its ACCEPT = Header?</SPAN><o:p></o:p></P></DIV> <DIV> <P class=3DMsoNormal><o:p> </o:p></P></DIV> <DIV> <P class=3DMsoNormal>regards,<o:p></o:p></P></DIV> <DIV> <P style=3D"MARGIN-BOTTOM: 12pt"=20 class=3DMsoNormal>Torsten. <BR><BR><o:p></o:p></P></DIV> <DIV> <P style=3D"MARGIN-BOTTOM: 12pt" class=3DMsoNormal><BR>Am 23.06.2010 = um 20:20=20 schrieb Yaron Goland <<A=20 = href=3D"mailto:yarong@microsoft.com">yarong@microsoft.com</A>>:<o:p></= o:p></P></DIV> <BLOCKQUOTE style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt"> <DIV> <DIV> <P style=3D"mso-margin-top-alt: auto; mso-margin-bottom-alt: auto"=20 class=3DMsoNormal><SPAN=20 style=3D"FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; = FONT-SIZE: 11pt">No=20 objections on my part. I would rather have a smaller core spec with = features=20 that everyone agrees on.</SPAN><o:p></o:p></P> <P style=3D"mso-margin-top-alt: auto; mso-margin-bottom-alt: auto"=20 class=3DMsoNormal><SPAN=20 style=3D"FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; = FONT-SIZE: 11pt"> </SPAN><o:p></o:p></P> <P style=3D"mso-margin-top-alt: auto; mso-margin-bottom-alt: auto"=20 class=3DMsoNormal><SPAN=20 style=3D"FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; = FONT-SIZE: 11pt">BTW,=20 a thought for the discovery draft – RFC 2616/2617 only defines = www-authenticate’s semantics in the context of a 401. = It’s unclear from the=20 draft what it would mean to return a www-authenticate header on a = 200=20 response. The reason I care about this is that I think it makes = sense that=20 if someone wants to talk to an endpoint they know supports OAuth and = need to=20 know where their token issuer location is they would want to fire = off an=20 OPTIONS request to the resource and find out from the response where = the=20 issuer is and what realm is being used. It seems to me that the = simplest way=20 to solve this problem is to just return www-authenticate on a 200 = response=20 to an OPTIONS request. </SPAN><o:p></o:p></P> <P style=3D"mso-margin-top-alt: auto; mso-margin-bottom-alt: auto"=20 class=3DMsoNormal><SPAN=20 style=3D"FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; = FONT-SIZE: 11pt"> </SPAN><o:p></o:p></P> <P style=3D"mso-margin-top-alt: auto; mso-margin-bottom-alt: auto"=20 class=3DMsoNormal><SPAN=20 style=3D"FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; = FONT-SIZE: = 11pt">           &= nbsp;   =20 Thoughts?</SPAN><o:p></o:p></P> <P style=3D"mso-margin-top-alt: auto; mso-margin-bottom-alt: auto"=20 class=3DMsoNormal><SPAN=20 style=3D"FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; = FONT-SIZE: 11pt"> </SPAN><o:p></o:p></P> <P style=3D"mso-margin-top-alt: auto; mso-margin-bottom-alt: auto"=20 class=3DMsoNormal><SPAN=20 style=3D"FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; = FONT-SIZE: = 11pt">           &= nbsp;           &n= bsp;       =20 Thanks,</SPAN><o:p></o:p></P> <P style=3D"mso-margin-top-alt: auto; mso-margin-bottom-alt: auto"=20 class=3DMsoNormal><SPAN=20 style=3D"FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; = FONT-SIZE: 11pt"> </SPAN><o:p></o:p></P> <P style=3D"mso-margin-top-alt: auto; mso-margin-bottom-alt: auto"=20 class=3DMsoNormal><SPAN=20 style=3D"FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; = FONT-SIZE: = 11pt">           &= nbsp;           &n= bsp;           &nb= sp;           =20 Yaron</SPAN><o:p></o:p></P> <P style=3D"mso-margin-top-alt: auto; mso-margin-bottom-alt: auto"=20 class=3DMsoNormal><SPAN=20 style=3D"FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; = FONT-SIZE: 11pt"> </SPAN><o:p></o:p></P> <DIV=20 style=3D"BORDER-BOTTOM: medium none; BORDER-LEFT: blue 1.5pt solid; = PADDING-BOTTOM: 0in; PADDING-LEFT: 4pt; PADDING-RIGHT: 0in; BORDER-TOP: = medium none; BORDER-RIGHT: medium none; PADDING-TOP: 0in"> <DIV> <DIV=20 style=3D"BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; = PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: = #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt"> <P style=3D"mso-margin-top-alt: auto; mso-margin-bottom-alt: auto"=20 class=3DMsoNormal><B><SPAN=20 style=3D"FONT-FAMILY: 'Tahoma','sans-serif'; FONT-SIZE: = 10pt">From:</SPAN></B><SPAN=20 style=3D"FONT-FAMILY: 'Tahoma','sans-serif'; FONT-SIZE: 10pt"> Eran=20 Hammer-Lahav [mailto:eran@hueniverse.com] <BR><B>Sent:</B> = Wednesday, June=20 23, 2010 11:04 AM<BR><B>To:</B> Yaron Goland; James Manger; OAuth=20 WG<BR><B>Subject:</B> Re: OAuth discovery=20 draft?</SPAN><o:p></o:p></P></DIV></DIV> <P style=3D"mso-margin-top-alt: auto; mso-margin-bottom-alt: auto"=20 class=3DMsoNormal> <o:p></o:p></P> <P style=3D"MARGIN-BOTTOM: 12pt; mso-margin-top-alt: auto"=20 class=3DMsoNormal><SPAN=20 style=3D"FONT-FAMILY: 'Calibri','sans-serif'; FONT-SIZE: 11pt">I = think the=20 core work is pretty stable now, unlike the discovery bits which = (while=20 simple) are not enjoying the same level of consensus. I think it is = much=20 more practical to propose them as a separate document and perhaps = consider=20 merging them later on when they reach an equal level of stability. = But=20 overall, I’m not too worries about multiple=20 documents.<BR><BR>EHL<BR><BR><BR>On 6/23/10 11:00 AM, "Yaron Goland" = <<A=20 href=3D"mailto:yarong@microsoft.com">yarong@microsoft.com</A>>=20 wrote:</SPAN><o:p></o:p></P> <P style=3D"MARGIN-BOTTOM: 12pt; mso-margin-top-alt: auto"=20 class=3DMsoNormal><SPAN=20 style=3D"FONT-FAMILY: 'Calibri','sans-serif'; FONT-SIZE: 11pt">I've = been=20 noodling [1] a lot about full delegation in OAuth [2] and one of the = issues=20 that came out of that was the need for discovering both the location = and=20 realm of an endpoint's token server. But at least for my use cases = (which=20 consist of walking up to a service and making an options request and = getting=20 back a www-authenticate header) all I need back is a realm and a = token=20 server URL. In other words just having one argument added to our=20 www-authenticate header would be enough to solve the case where = someone=20 wants to walk up to a service and find out where its token server = is. Does=20 that really need its own spec? Or can we just add an argument to=20 www-authenticate in the current=20 = spec?<BR>        Thanks,<BR> = ;            =    Yaron<BR><BR>[1]=20 See <A=20 = href=3D"http://www.goland.org/oauthgenericdelegation/">http://www.goland.= org/oauthgenericdelegation/</A>=20 for an overview of my thinking on full delegation in OAuth. At the = very end=20 are links to a bunch of other much more in-depth articles on = particular=20 subjects touched on in the main article.<BR><BR>[2] I define 'full=20 delegation' as "User X of Service Y grants permission Z to User A of = Service=20 B". Currently OAuth requires X =3D=3D A. In the future I hope to see = extensions=20 to OAuth that enable what I'm terming 'full delegation'. But = personally I'm=20 really happy that OAuth has the X=3D=3DA restriction. It simplifies = a whole host=20 of issues and satisfies a really important use case.<BR><BR>>=20 -----Original Message-----<BR>> From: <A=20 href=3D"mailto:oauth-bounces@ietf.org">oauth-bounces@ietf.org</A> = [<A=20 = href=3D"mailto:oauth-bounces@ietf.org">mailto:oauth-bounces@ietf.org</A>]= On=20 Behalf<BR>> Of Eran Hammer-Lahav<BR>> Sent: Monday, June 21, = 2010 9:50=20 PM<BR>> To: Manger, James H; OAuth WG (<A=20 href=3D"mailto:oauth@ietf.org">oauth@ietf.org</A>)<BR>> Subject: = Re:=20 [OAUTH-WG] OAuth discovery draft?<BR>><BR>> Yes, it's on my = desk and=20 not yet ready, but I am working on one. It includes<BR>> your = sites=20 proposal among other things. I am trying to get the core = spec<BR>> stable=20 this week and focus on that next.<BR>><BR>> = EHL<BR>><BR>> >=20 -----Original Message-----<BR>> > From: Manger, James H [<A=20 = href=3D"mailto:James.H.Manger@team.telstra.com">mailto:James.H.Manger@tea= m.telstra.com</A>]<BR>>=20 > Sent: Monday, June 21, 2010 8:03 PM<BR>> > To: Eran = Hammer-Lahav;=20 OAuth WG (<A = href=3D"mailto:oauth@ietf.org">oauth@ietf.org</A>)<BR>> >=20 Subject: OAuth discovery draft?<BR>> ><BR>> > = Eran,<BR>>=20 ><BR>> > There have been a few mentions recently of an = OAuth=20 discovery draft.<BR>> > Is there any such draft yet, or is = this just a=20 part that we know needs<BR>> > to be done?<BR>> = ><BR>> >=20 The email on "OAuth meeting notes on -05 (with updates)" = said:<BR>>=20 ><BR>> > >> 6.1.1. - describing the WWW-Authenticate = response=20 header<BR>> > >><BR>> > >> - Discovery = needed for=20 various elements<BR>> > ><BR>> > > Yes. That's for = the=20 discovery draft.<BR>> ><BR>> ><BR>> > A wiki page = on=20 "Future OpenID Technical Requirements"<BR>> > <<A=20 = href=3D"http://wiki.openid.net/Future-OpenID-Technical-Requirements">http= ://wiki.openid.net/Future-OpenID-Technical-Requirements</A>>=20 says:<BR>> ><BR>> > > 6) IdP Discovery<BR>> >=20 ><BR>> > >    * Much of this will be = covered by=20 OAuth2 Discovery,<BR>> > > =      however=20 OIC may need to define OpenID specific features.<BR>> > = >…<BR>>=20 > > 17) Simpler discovery<BR>> > ><BR>> > >=20    * See Eran's OAuth Discovery proposal<BR>> = ><BR>>=20 ><BR>> > There was an OAuth 1.0 Discovery draft over 2 = years ago,=20 but that is tagged:<BR>> > "expired", "marked as obsolete by = its=20 author", "discouraged from<BR>> > implementing", "no update is = expected", "replaced by the OAuth 2.0<BR>> effort".<BR>> = ><BR>>=20 > I know I should write a discovery draft myself.<BR>> = ><BR>>=20 > --<BR>> > James Manger<BR>>=20 _______________________________________________<BR>> OAuth = mailing=20 list<BR>> <A = href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</A><BR>> <A=20 = href=3D"https://www.ietf.org/mailman/listinfo/oauth">https://www.ietf.org= /mailman/listinfo/oauth</A></SPAN><o:p></o:p></P></DIV></DIV></DIV></BLOC= KQUOTE> <BLOCKQUOTE style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt"> <DIV> <P = class=3DMsoNormal>_______________________________________________<BR>OAut= h=20 mailing list<BR><A = href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</A><BR><A=20 = href=3D"https://www.ietf.org/mailman/listinfo/oauth">https://www.ietf.org= /mailman/listinfo/oauth</A><o:p></o:p></P></DIV></BLOCKQUOTE></DIV></DIV>= </BLOCKQUOTE></BODY></HTML> ------_=_NextPart_001_01CB1711.64856E44-- From ian@mckellar.org Mon Jun 28 16:33:02 2010 Return-Path: <ian@mckellar.org> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 389353A687D for <oauth@core3.amsl.com>; Mon, 28 Jun 2010 16:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.437 X-Spam-Level: X-Spam-Status: No, score=0.437 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drvLFvPmHSAE for <oauth@core3.amsl.com>; Mon, 28 Jun 2010 16:32:59 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 513EE3A6949 for <oauth@ietf.org>; Mon, 28 Jun 2010 16:32:59 -0700 (PDT) Received: by vws7 with SMTP id 7so2129458vws.31 for <oauth@ietf.org>; Mon, 28 Jun 2010 16:33:05 -0700 (PDT) Received: by 10.220.47.220 with SMTP id o28mr3345256vcf.78.1277767985269; Mon, 28 Jun 2010 16:33:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.201.77 with HTTP; Mon, 28 Jun 2010 16:32:45 -0700 (PDT) In-Reply-To: <7C01E631FF4B654FA1E783F1C0265F8C579D0F52@TK5EX14MBXC117.redmond.corp.microsoft.com> References: <7C01E631FF4B654FA1E783F1C0265F8C579D0F52@TK5EX14MBXC117.redmond.corp.microsoft.com> From: Ian McKellar <ian@mckellar.org> Date: Tue, 29 Jun 2010 11:32:45 +1200 Message-ID: <AANLkTimJ7E4Pk-H_P0hUo1n66e_iFI-vQs09MRdz5WvK@mail.gmail.com> To: Yaron Goland <yarong@microsoft.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "oauth@ietf.org" <oauth@ietf.org> Subject: Re: [OAUTH-WG] How do we deal with unrecognized elements in requests and responses? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 28 Jun 2010 23:36:51 -0000 If we define that unrecognized arguments / elements are ignored then we can define extensions such that if their arguments / elements are ignored they don't introduce insecurity. Ian On Tue, Jun 29, 2010 at 10:01 AM, Yaron Goland <yarong@microsoft.com> wrote= : > In a private thread with Eran an issue came up regarding how to handle > unrecognized arguments in OAuth requests and responses. > > > > For example, if a token endpoint receives an access token request that > contains both a client_id and a client_foo_bar argument, what should it d= o? > Should it reject the request since it doesn=E2=80=99t recognize client_fo= o_bar? > Should it ignore client_foo_bar and just process the request based on > client_id? > > > > Similarly imagine that a response to an access token request contains a J= SON > member with some unrecognized name. What=E2=80=99s the right behavior? Ig= nore the > unrecognized value? Or treat the response as badly formatted and fail out= ? > > > > We need to define in the spec how to deal with unrecognized extensions. > Typically the rule is =E2=80=98ignore what you don=E2=80=99t recognize=E2= =80=99 but there is a > countervailing rule which applies here which is =E2=80=9Csecurity is diff= erent=E2=80=9D. > Typically ignoring unrecognized elements in a security context can lead t= o > security holes. > > > > Just looking at the history of OAuth I suspect we need to go with the ign= ore > rule and then explore ad nauseam in the security considerations section a= ll > the ways that the ignore rule can go wrong if extensions aren=E2=80=99t h= andled > carefully. > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Thoughts? > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Thanks, > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --=20 Ian McKellar <http://ian.mckellar.org/> ian@mckellar.org: email | jabber | msn ianloic: flickr | aim | yahoo | skype | linkedin | etc. From ian@mckellar.org Mon Jun 28 16:39:18 2010 Return-Path: <ian@mckellar.org> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 812EC3A6A94 for <oauth@core3.amsl.com>; Mon, 28 Jun 2010 16:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.629 X-Spam-Level: X-Spam-Status: No, score=-0.629 tagged_above=-999 required=5 tests=[AWL=-0.141, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lszZ+QkN8JbV for <oauth@core3.amsl.com>; Mon, 28 Jun 2010 16:39:17 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 8285D3A69FE for <oauth@ietf.org>; Mon, 28 Jun 2010 16:39:17 -0700 (PDT) Received: by vws7 with SMTP id 7so2136422vws.31 for <oauth@ietf.org>; Mon, 28 Jun 2010 16:39:24 -0700 (PDT) Received: by 10.220.166.71 with SMTP id l7mr804606vcy.9.1277768364157; Mon, 28 Jun 2010 16:39:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.201.77 with HTTP; Mon, 28 Jun 2010 16:39:04 -0700 (PDT) In-Reply-To: <AANLkTilYLA2AktwMv3ZIHTHFMwvDOOsOTxANhKzYhyrZ@mail.gmail.com> References: <AANLkTimgJSdxjfz7kY1a3zSaK9QQCtxVzVcICoseo3V6@mail.gmail.com> <AANLkTilYLA2AktwMv3ZIHTHFMwvDOOsOTxANhKzYhyrZ@mail.gmail.com> From: Ian McKellar <ian@mckellar.org> Date: Tue, 29 Jun 2010 11:39:04 +1200 Message-ID: <AANLkTikI3Nm7jEZSZuNH8WCz9K5t5P9fCDPULuM2Argz@mail.gmail.com> To: Evan Gilbert <uidude@google.com> Content-Type: text/plain; charset=UTF-8 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] JSON parsing in the browser (was: Proposal for single JSON response format) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 28 Jun 2010 23:39:18 -0000 On Tue, Jun 29, 2010 at 5:53 AM, Evan Gilbert <uidude@google.com> wrote: > > > What specifically don't you agree with? I agree that the RegEx match or a > library will fix the security hole. > The problem is that the insecure behavior - "eval(json)" - will just work, > is obvious for developers to try, and non-obvious why this is a security > hole. I disagree that developers will blindly eval things to see if they can parse. They're most likely to use a JSON library or the JSON functionality of their favorite JS library. All of these will be safe. If they're the kind of developer who will start evaling strings send from the server then there's not much hope of their application being secure, regardless of OAuth. Ian -- Ian McKellar <http://ian.mckellar.org/> ian@mckellar.org: email | jabber | msn ianloic: flickr | aim | yahoo | skype | linkedin | etc. From eran@hueniverse.com Mon Jun 28 17:59:33 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47A853A6892 for <oauth@core3.amsl.com>; Mon, 28 Jun 2010 17:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.239 X-Spam-Level: X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[AWL=0.359, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qlCFE-H+4qO for <oauth@core3.amsl.com>; Mon, 28 Jun 2010 17:59:27 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 7EB563A68E4 for <oauth@ietf.org>; Mon, 28 Jun 2010 17:59:27 -0700 (PDT) Received: (qmail 17716 invoked from network); 29 Jun 2010 00:59:37 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 29 Jun 2010 00:59:37 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 28 Jun 2010 17:59:37 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: Yaron Goland <yarong@microsoft.com> Date: Mon, 28 Jun 2010 17:59:40 -0700 Thread-Topic: [OAUTH-WG] How do we deal with unrecognized elements in requests and responses? Thread-Index: AcsXDNz7BtsGZbPiSvu5gteEiVcThwAGKrXg Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4BCB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <7C01E631FF4B654FA1E783F1C0265F8C579D0F52@TK5EX14MBXC117.redmond.corp.microsoft.com> In-Reply-To: <7C01E631FF4B654FA1E783F1C0265F8C579D0F52@TK5EX14MBXC117.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_90C41DD21FB7C64BB94121FBBC2E72343B3ED4BCB0P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] How do we deal with unrecognized elements in requests and responses? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 29 Jun 2010 00:59:33 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3ED4BCB0P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There are 3 general ways to deal with this: 1. Break on unrecognized parameters - this tends to make the use of extensi= ons hard, and at a minimum requires an error to include the bad parameter i= n a machine readable way (so a library can figure out an extension is not s= upported). 2. Ignore unrecognized parameters - this is the usual way of dealing with e= xtensible protocols. It has security implications when extension parameters= must not be ignored. However, the workaround is simply to break something = else (i.e. replace the client_id with something else that will cause the no= rmal flow to break). 3. Same as #2 but include a directive which means 'must not ignore any para= meter; return error if any parameter is unknown'. XRD used to include such = a 'must-support' attribute for properties but was dropped due to lack of us= e cases. I think #2 offers a good enough balance here, but am happy to discuss #3 if= people have actual use cases where ignoring an extension will cause securi= ty issues. Note that with the expectation of error codes, my upcoming exten= sibility proposal does not allow adding any new parameter values (only new = parameters). EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Y= aron Goland Sent: Monday, June 28, 2010 3:02 PM To: oauth@ietf.org Subject: [OAUTH-WG] How do we deal with unrecognized elements in requests a= nd responses? In a private thread with Eran an issue came up regarding how to handle unre= cognized arguments in OAuth requests and responses. For example, if a token endpoint receives an access token request that cont= ains both a client_id and a client_foo_bar argument, what should it do? Sho= uld it reject the request since it doesn't recognize client_foo_bar? Should= it ignore client_foo_bar and just process the request based on client_id? Similarly imagine that a response to an access token request contains a JSO= N member with some unrecognized name. What's the right behavior? Ignore the= unrecognized value? Or treat the response as badly formatted and fail out? We need to define in the spec how to deal with unrecognized extensions. Typ= ically the rule is 'ignore what you don't recognize' but there is a counter= vailing rule which applies here which is "security is different". Typically= ignoring unrecognized elements in a security context can lead to security = holes. Just looking at the history of OAuth I suspect we need to go with the ignor= e rule and then explore ad nauseam in the security considerations section a= ll the ways that the ignore rule can go wrong if extensions aren't handled = carefully. Thoughts? Thanks, Yaron --_000_90C41DD21FB7C64BB94121FBBC2E72343B3ED4BCB0P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV=3D"Content-Type" CONTENT= =3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros= oft Word 14 (filtered medium)"><style><!-- /* Font Definitions */ @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {mso-style-priority:34; margin-top:0in; margin-right:0in; margin-bottom:0in; margin-left:.5in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} span.EmailStyle17 {mso-style-type:personal; font-family:"Calibri","sans-serif"; color:windowtext;} span.EmailStyle18 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue vli= nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><span style=3D'c= olor:#1F497D'>There are 3 general ways to deal with this:<o:p></o:p></span>= </p><p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p> </o:p></s= pan></p><p class=3DMsoNormal><span style=3D'color:#1F497D'>1. Break on unre= cognized parameters – this tends to make the use of extensions hard, = and at a minimum requires an error to include the bad parameter in a machin= e readable way (so a library can figure out an extension is not supported).= <o:p></o:p></span></p><p class=3DMsoNormal><span style=3D'color:#1F497D'><o= :p> </o:p></span></p><p class=3DMsoNormal><span style=3D'color:#1F497D= '>2. Ignore unrecognized parameters – this is the usual way of dealin= g with extensible protocols. It has security implications when extension pa= rameters must not be ignored. However, the workaround is simply to break so= mething else (i.e. replace the client_id with something else that will caus= e the normal flow to break).<o:p></o:p></span></p><p class=3DMsoNormal><spa= n style=3D'color:#1F497D'><o:p> </o:p></span></p><p class=3DMsoNormal>= <span style=3D'color:#1F497D'>3. Same as #2 but include a directive which m= eans ‘must not ignore any parameter; return error if any parameter is= unknown’. XRD used to include such a ‘must-support’ attr= ibute for properties but was dropped due to lack of use cases.<o:p></o:p></= span></p><p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p> </o:= p></span></p><p class=3DMsoNormal><span style=3D'color:#1F497D'>I think #2 = offers a good enough balance here, but am happy to discuss #3 if people hav= e actual use cases where ignoring an extension will cause security issues. = Note that with the expectation of error codes, my upcoming extensibility pr= oposal does not allow adding any new parameter values (only new parameters)= .<o:p></o:p></span></p><p class=3DMsoNormal><span style=3D'color:#1F497D'><= o:p> </o:p></span></p><p class=3DMsoNormal><span style=3D'color:#1F497= D'>EHL<o:p></o:p></span></p><p class=3DMsoNormal><span style=3D'color:#1F49= 7D'><o:p> </o:p></span></p><div style=3D'border:none;border-left:solid= blue 1.5pt;padding:0in 0in 0in 4.0pt'><div><div style=3D'border:none;borde= r-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=3DMsoNormal><= b><span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:<= /span></b><span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"= '> oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] <b>On Behalf Of <= /b>Yaron Goland<br><b>Sent:</b> Monday, June 28, 2010 3:02 PM<br><b>To:</b>= oauth@ietf.org<br><b>Subject:</b> [OAUTH-WG] How do we deal with unrecogni= zed elements in requests and responses?<o:p></o:p></span></p></div></div><p= class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>In a private t= hread with Eran an issue came up regarding how to handle unrecognized argum= ents in OAuth requests and responses.<o:p></o:p></p><p class=3DMsoNormal><o= :p> </o:p></p><p class=3DMsoNormal>For example, if a token endpoint re= ceives an access token request that contains both a client_id and a client_= foo_bar argument, what should it do? Should it reject the request since it = doesn’t recognize client_foo_bar? Should it ignore client_foo_bar and= just process the request based on client_id?<o:p></o:p></p><p class=3DMsoN= ormal><o:p> </o:p></p><p class=3DMsoNormal>Similarly imagine that a re= sponse to an access token request contains a JSON member with some unrecogn= ized name. What’s the right behavior? Ignore the unrecognized value? = Or treat the response as badly formatted and fail out?<o:p></o:p></p><p cla= ss=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>We need to define = in the spec how to deal with unrecognized extensions. Typically the rule is= ‘ignore what you don’t recognize’ but there is a counter= vailing rule which applies here which is “security is different”= ;. Typically ignoring unrecognized elements in a security context can lead = to security holes.<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p>= <p class=3DMsoNormal>Just looking at the history of OAuth I suspect we need= to go with the ignore rule and then explore ad nauseam in the security con= siderations section all the ways that the ignore rule can go wrong if exten= sions aren’t handled carefully.<o:p></o:p></p><p class=3DMsoNormal><o= :p> </o:p></p><p class=3DMsoNormal>      = ;          Thoughts?<o:p></o:p= ></p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal> &= nbsp;           &nbs= p;            &= nbsp;     Thanks,<o:p></o:p></p><p class=3DMsoNormal><o= :p> </o:p></p><p class=3DMsoNormal>      = ;            &n= bsp;            = ;            &n= bsp;    Yaron<o:p></o:p></p></div></div></body></html>= --_000_90C41DD21FB7C64BB94121FBBC2E72343B3ED4BCB0P3PW5EX1MB01E_-- From recordond@gmail.com Mon Jun 28 18:11:20 2010 Return-Path: <recordond@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC7CB3A680F for <oauth@core3.amsl.com>; Mon, 28 Jun 2010 18:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.185 X-Spam-Level: X-Spam-Status: No, score=-2.185 tagged_above=-999 required=5 tests=[AWL=0.413, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wjlc7jnepbKF for <oauth@core3.amsl.com>; Mon, 28 Jun 2010 18:11:19 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id ECF2D3A6767 for <oauth@ietf.org>; Mon, 28 Jun 2010 18:11:18 -0700 (PDT) Received: by iwn40 with SMTP id 40so412224iwn.31 for <oauth@ietf.org>; Mon, 28 Jun 2010 18:11:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=uYx8NFJ3xtTBKAdCEUin/IWj+o0bl5yRWD+D6NSL8FE=; b=SCUfA1h4egpayzb2HWx0KO0U5DIuJcDwrnzY9QFtjYEJUUsemaKS3g8QjF9rNL8dY4 qtmryks88Qw3eddADxsbikbsH94PXsimiBd/PObvyMrJda9WwYpe6II+h/N2B3JyJH4u dxukf/kLaQpZQY4cspHyqiQka1HdKp3ssA2XA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ULEtN3eAoWdsVLoBbMeZx5zqLijYikw2TZjfU3jU7vu/80qG/c/jd1tORi+AIGefuZ FFd7J7+nC/aMY91auGzEZz+0H0lzp5X/lcePUU+mJDflpoMDqvahbgKy36fq+fWNdbZX giV4Rih/Iu6pCU+bdifoE4M5Ay4j2yXbRqi/w= MIME-Version: 1.0 Received: by 10.231.13.203 with SMTP id d11mr5440972iba.131.1277773889001; Mon, 28 Jun 2010 18:11:29 -0700 (PDT) Received: by 10.231.191.81 with HTTP; Mon, 28 Jun 2010 18:11:28 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4BCB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <7C01E631FF4B654FA1E783F1C0265F8C579D0F52@TK5EX14MBXC117.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4BCB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 28 Jun 2010 18:11:28 -0700 Message-ID: <AANLkTin2cvQnXB7x9abGLF4xQyfrv9IzZCzxOHnJqlHQ@mail.gmail.com> From: David Recordon <recordond@gmail.com> To: Eran Hammer-Lahav <eran@hueniverse.com> Content-Type: multipart/alternative; boundary=000325573422c1d812048a20eab0 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] How do we deal with unrecognized elements in requests and responses? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 29 Jun 2010 01:11:22 -0000 --000325573422c1d812048a20eab0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable For #2, if an extension defines required parameters then you're not supporting the extension if you ignore them. Or am I missing something? On Mon, Jun 28, 2010 at 5:59 PM, Eran Hammer-Lahav <eran@hueniverse.com>wro= te: > There are 3 general ways to deal with this: > > > > 1. Break on unrecognized parameters =96 this tends to make the use of > extensions hard, and at a minimum requires an error to include the bad > parameter in a machine readable way (so a library can figure out an > extension is not supported). > > > > 2. Ignore unrecognized parameters =96 this is the usual way of dealing wi= th > extensible protocols. It has security implications when extension paramet= ers > must not be ignored. However, the workaround is simply to break something > else (i.e. replace the client_id with something else that will cause the > normal flow to break). > > > > 3. Same as #2 but include a directive which means =91must not ignore any > parameter; return error if any parameter is unknown=92. XRD used to inclu= de > such a =91must-support=92 attribute for properties but was dropped due to= lack > of use cases. > > > > I think #2 offers a good enough balance here, but am happy to discuss #3 = if > people have actual use cases where ignoring an extension will cause secur= ity > issues. Note that with the expectation of error codes, my upcoming > extensibility proposal does not allow adding any new parameter values (on= ly > new parameters). > > > > EHL > > > > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf > Of *Yaron Goland > *Sent:* Monday, June 28, 2010 3:02 PM > *To:* oauth@ietf.org > *Subject:* [OAUTH-WG] How do we deal with unrecognized elements in > requests and responses? > > > > In a private thread with Eran an issue came up regarding how to handle > unrecognized arguments in OAuth requests and responses. > > > > For example, if a token endpoint receives an access token request that > contains both a client_id and a client_foo_bar argument, what should it d= o? > Should it reject the request since it doesn=92t recognize client_foo_bar? > Should it ignore client_foo_bar and just process the request based on > client_id? > > > > Similarly imagine that a response to an access token request contains a > JSON member with some unrecognized name. What=92s the right behavior? Ign= ore > the unrecognized value? Or treat the response as badly formatted and fail > out? > > > > We need to define in the spec how to deal with unrecognized extensions. > Typically the rule is =91ignore what you don=92t recognize=92 but there i= s a > countervailing rule which applies here which is =93security is different= =94. > Typically ignoring unrecognized elements in a security context can lead t= o > security holes. > > > > Just looking at the history of OAuth I suspect we need to go with the > ignore rule and then explore ad nauseam in the security considerations > section all the ways that the ignore rule can go wrong if extensions aren= =92t > handled carefully. > > > > Thoughts? > > > > Thanks, > > > > Yaron > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --000325573422c1d812048a20eab0 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable For #2, if an extension defines required parameters then you're not sup= porting the extension if you ignore them. Or am I missing something?<div><b= r><br><div class=3D"gmail_quote">On Mon, Jun 28, 2010 at 5:59 PM, Eran Hamm= er-Lahav <span dir=3D"ltr"><<a href=3D"mailto:eran@hueniverse.com">eran@= hueniverse.com</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex;"><div lang=3D"EN-US" link=3D"blue" vlink=3D"= purple"><div><p class=3D"MsoNormal"><span style=3D"color:#1F497D">There are= 3 general ways to deal with this:</span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">=A0</span></p><p class= =3D"MsoNormal"><span style=3D"color:#1F497D">1. Break on unrecognized param= eters =96 this tends to make the use of extensions hard, and at a minimum r= equires an error to include the bad parameter in a machine readable way (so= a library can figure out an extension is not supported).</span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">=A0</span></p><p class= =3D"MsoNormal"><span style=3D"color:#1F497D">2. Ignore unrecognized paramet= ers =96 this is the usual way of dealing with extensible protocols. It has = security implications when extension parameters must not be ignored. Howeve= r, the workaround is simply to break something else (i.e. replace the clien= t_id with something else that will cause the normal flow to break).</span><= /p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">=A0</span></p><p class= =3D"MsoNormal"><span style=3D"color:#1F497D">3. Same as #2 but include a di= rective which means =91must not ignore any parameter; return error if any p= arameter is unknown=92. XRD used to include such a =91must-support=92 attri= bute for properties but was dropped due to lack of use cases.</span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">=A0</span></p><p class= =3D"MsoNormal"><span style=3D"color:#1F497D">I think #2 offers a good enoug= h balance here, but am happy to discuss #3 if people have actual use cases = where ignoring an extension will cause security issues. Note that with the = expectation of error codes, my upcoming extensibility proposal does not all= ow adding any new parameter values (only new parameters).</span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">=A0</span></p><p class= =3D"MsoNormal"><span style=3D"color:#1F497D">EHL</span></p><p class=3D"MsoN= ormal"><span style=3D"color:#1F497D">=A0</span></p><div style=3D"border:non= e;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt"> <div><div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt= 0in 0in 0in"><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt">Fr= om:</span></b><span style=3D"font-size:10.0pt"> <a href=3D"mailto:oauth-bou= nces@ietf.org" target=3D"_blank">oauth-bounces@ietf.org</a> [mailto:<a href= =3D"mailto:oauth-bounces@ietf.org" target=3D"_blank">oauth-bounces@ietf.org= </a>] <b>On Behalf Of </b>Yaron Goland<br> <b>Sent:</b> Monday, June 28, 2010 3:02 PM<br><b>To:</b> <a href=3D"mailto:= oauth@ietf.org" target=3D"_blank">oauth@ietf.org</a><br><b>Subject:</b> [OA= UTH-WG] How do we deal with unrecognized elements in requests and responses= ?</span></p> </div></div><div><div></div><div class=3D"h5"><p class=3D"MsoNormal">=A0</p= ><p class=3D"MsoNormal">In a private thread with Eran an issue came up rega= rding how to handle unrecognized arguments in OAuth requests and responses.= </p> <p class=3D"MsoNormal">=A0</p><p class=3D"MsoNormal">For example, if a toke= n endpoint receives an access token request that contains both a client_id = and a client_foo_bar argument, what should it do? Should it reject the requ= est since it doesn=92t recognize client_foo_bar? Should it ignore client_fo= o_bar and just process the request based on client_id?</p> <p class=3D"MsoNormal">=A0</p><p class=3D"MsoNormal">Similarly imagine that= a response to an access token request contains a JSON member with some unr= ecognized name. What=92s the right behavior? Ignore the unrecognized value?= Or treat the response as badly formatted and fail out?</p> <p class=3D"MsoNormal">=A0</p><p class=3D"MsoNormal">We need to define in t= he spec how to deal with unrecognized extensions. Typically the rule is =91= ignore what you don=92t recognize=92 but there is a countervailing rule whi= ch applies here which is =93security is different=94. Typically ignoring un= recognized elements in a security context can lead to security holes.</p> <p class=3D"MsoNormal">=A0</p><p class=3D"MsoNormal">Just looking at the hi= story of OAuth I suspect we need to go with the ignore rule and then explor= e ad nauseam in the security considerations section all the ways that the i= gnore rule can go wrong if extensions aren=92t handled carefully.</p> <p class=3D"MsoNormal">=A0</p><p class=3D"MsoNormal">=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 Thoughts?</p><p class=3D"MsoNormal">=A0</p><p clas= s=3D"MsoNormal">=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,</p><p class=3D"MsoNormal">=A0<= /p><p class=3D"MsoNormal">=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 Yaron</p> </div></div></div></div></div><br>_________________________________________= ______<br> OAuth mailing list<br> <a href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_blank">h= ttps://www.ietf.org/mailman/listinfo/oauth</a><br> <br></blockquote></div><br></div> --000325573422c1d812048a20eab0-- From eran@hueniverse.com Mon Jun 28 18:17:08 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 368F23A67D3 for <oauth@core3.amsl.com>; Mon, 28 Jun 2010 18:17:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.242 X-Spam-Level: X-Spam-Status: No, score=-2.242 tagged_above=-999 required=5 tests=[AWL=0.356, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6NXFWuPouXnn for <oauth@core3.amsl.com>; Mon, 28 Jun 2010 18:17:00 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 8DDA13A69BF for <oauth@ietf.org>; Mon, 28 Jun 2010 18:17:00 -0700 (PDT) Received: (qmail 2383 invoked from network); 29 Jun 2010 01:17:11 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 29 Jun 2010 01:17:10 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Mon, 28 Jun 2010 18:17:10 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: David Recordon <recordond@gmail.com> Date: Mon, 28 Jun 2010 18:17:13 -0700 Thread-Topic: [OAUTH-WG] How do we deal with unrecognized elements in requests and responses? Thread-Index: AcsXKAG7CuyP/x6CTjmONEAb0pfY2wAAGDLw Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4BCB4@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <7C01E631FF4B654FA1E783F1C0265F8C579D0F52@TK5EX14MBXC117.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4BCB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTin2cvQnXB7x9abGLF4xQyfrv9IzZCzxOHnJqlHQ@mail.gmail.com> In-Reply-To: <AANLkTin2cvQnXB7x9abGLF4xQyfrv9IzZCzxOHnJqlHQ@mail.gmail.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_90C41DD21FB7C64BB94121FBBC2E72343B3ED4BCB4P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] How do we deal with unrecognized elements in requests and responses? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 29 Jun 2010 01:17:08 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3ED4BCB4P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There are times when the client wants the server to fail if it doesn't supp= ort an extension. The client developer might consider the server as being l= ess secure without the added protection of the extension and would like the= server to be able to tell it was making such a request and fail. This clearly belongs in the use cases driving discovery, as in the core spe= cification, the client is expected to be familiar with the details of the s= erver. So we just need to make sure that we don't prevent such use cases. #= 2 doesn't prevent it, but requires the client to break something else. For = example, an extension having to do with client identity should replace the = client_id parameter with something else, making a server unaware of this ex= tension fail (because the required client_id parameter will be missing). EHL From: David Recordon [mailto:recordond@gmail.com] Sent: Monday, June 28, 2010 6:11 PM To: Eran Hammer-Lahav Cc: Yaron Goland; OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] How do we deal with unrecognized elements in reques= ts and responses? For #2, if an extension defines required parameters then you're not support= ing the extension if you ignore them. Or am I missing something? On Mon, Jun 28, 2010 at 5:59 PM, Eran Hammer-Lahav <eran@hueniverse.com<mai= lto:eran@hueniverse.com>> wrote: There are 3 general ways to deal with this: 1. Break on unrecognized parameters - this tends to make the use of extensi= ons hard, and at a minimum requires an error to include the bad parameter i= n a machine readable way (so a library can figure out an extension is not s= upported). 2. Ignore unrecognized parameters - this is the usual way of dealing with e= xtensible protocols. It has security implications when extension parameters= must not be ignored. However, the workaround is simply to break something = else (i.e. replace the client_id with something else that will cause the no= rmal flow to break). 3. Same as #2 but include a directive which means 'must not ignore any para= meter; return error if any parameter is unknown'. XRD used to include such = a 'must-support' attribute for properties but was dropped due to lack of us= e cases. I think #2 offers a good enough balance here, but am happy to discuss #3 if= people have actual use cases where ignoring an extension will cause securi= ty issues. Note that with the expectation of error codes, my upcoming exten= sibility proposal does not allow adding any new parameter values (only new = parameters). EHL From: oauth-bounces@ietf.org<mailto:oauth-bounces@ietf.org> [mailto:oauth-b= ounces@ietf.org<mailto:oauth-bounces@ietf.org>] On Behalf Of Yaron Goland Sent: Monday, June 28, 2010 3:02 PM To: oauth@ietf.org<mailto:oauth@ietf.org> Subject: [OAUTH-WG] How do we deal with unrecognized elements in requests a= nd responses? In a private thread with Eran an issue came up regarding how to handle unre= cognized arguments in OAuth requests and responses. For example, if a token endpoint receives an access token request that cont= ains both a client_id and a client_foo_bar argument, what should it do? Sho= uld it reject the request since it doesn't recognize client_foo_bar? Should= it ignore client_foo_bar and just process the request based on client_id? Similarly imagine that a response to an access token request contains a JSO= N member with some unrecognized name. What's the right behavior? Ignore the= unrecognized value? Or treat the response as badly formatted and fail out? We need to define in the spec how to deal with unrecognized extensions. Typ= ically the rule is 'ignore what you don't recognize' but there is a counter= vailing rule which applies here which is "security is different". Typically= ignoring unrecognized elements in a security context can lead to security = holes. Just looking at the history of OAuth I suspect we need to go with the ignor= e rule and then explore ad nauseam in the security considerations section a= ll the ways that the ignore rule can go wrong if extensions aren't handled = carefully. Thoughts? Thanks, Yaron _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth --_000_90C41DD21FB7C64BB94121FBBC2E72343B3ED4BCB4P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV=3D"Content-Type" CONTENT= =3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros= oft Word 14 (filtered medium)"><style><!-- /* Font Definitions */ @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} p.MsoAcetate, li.MsoAcetate, div.MsoAcetate {mso-style-priority:99; mso-style-link:"Balloon Text Char"; margin:0in; margin-bottom:.0001pt; font-size:8.0pt; font-family:"Tahoma","sans-serif";} span.EmailStyle17 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} span.BalloonTextChar {mso-style-name:"Balloon Text Char"; mso-style-priority:99; mso-style-link:"Balloon Text"; font-family:"Tahoma","sans-serif";} .MsoChpDefault {mso-style-type:export-only; font-family:"Calibri","sans-serif";} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue vli= nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><span style=3D'f= ont-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>There are= times when the client wants the server to fail if it doesn’t support= an extension. The client developer might consider the server as being less= secure without the added protection of the extension and would like the se= rver to be able to tell it was making such a request and fail.<o:p></o:p></= span></p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"= Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class= =3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri","sans-se= rif";color:#1F497D'>This clearly belongs in the use cases driving discovery= , as in the core specification, the client is expected to be familiar with = the details of the server. So we just need to make sure that we don’t= prevent such use cases. #2 doesn’t prevent it, but requires the clie= nt to break something else. For example, an extension having to do with cli= ent identity should replace the client_id parameter with something else, ma= king a server unaware of this extension fail (because the required client_i= d parameter will be missing).<o:p></o:p></span></p><p class=3DMsoNormal><sp= an style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F49= 7D'><o:p> </o:p></span></p><p class=3DMsoNormal><span style=3D'font-si= ze:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>EHL<o:p></o:p><= /span></p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:= "Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div styl= e=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><d= iv><div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0= in 0in 0in'><p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;font-fa= mily:"Tahoma","sans-serif"'>From:</span></b><span style=3D'font-size:10.0pt= ;font-family:"Tahoma","sans-serif"'> David Recordon [mailto:recordond@gmail= .com] <br><b>Sent:</b> Monday, June 28, 2010 6:11 PM<br><b>To:</b> Eran Ham= mer-Lahav<br><b>Cc:</b> Yaron Goland; OAuth WG (oauth@ietf.org)<br><b>Subje= ct:</b> Re: [OAUTH-WG] How do we deal with unrecognized elements in request= s and responses?<o:p></o:p></span></p></div></div><p class=3DMsoNormal><o:p= > </o:p></p><p class=3DMsoNormal>For #2, if an extension defines requi= red parameters then you're not supporting the extension if you ignore them.= Or am I missing something?<o:p></o:p></p><div><p class=3DMsoNormal style= =3D'margin-bottom:12.0pt'><o:p> </o:p></p><div><p class=3DMsoNormal>On= Mon, Jun 28, 2010 at 5:59 PM, Eran Hammer-Lahav <<a href=3D"mailto:eran= @hueniverse.com">eran@hueniverse.com</a>> wrote:<o:p></o:p></p><div><div= ><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-al= t:auto'><span style=3D'color:#1F497D'>There are 3 general ways to deal with= this:</span><o:p></o:p></p><p class=3DMsoNormal style=3D'mso-margin-top-al= t:auto;mso-margin-bottom-alt:auto'><span style=3D'color:#1F497D'> </sp= an><o:p></o:p></p><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso= -margin-bottom-alt:auto'><span style=3D'color:#1F497D'>1. Break on unrecogn= ized parameters – this tends to make the use of extensions hard, and = at a minimum requires an error to include the bad parameter in a machine re= adable way (so a library can figure out an extension is not supported).</sp= an><o:p></o:p></p><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso= -margin-bottom-alt:auto'><span style=3D'color:#1F497D'> </span><o:p></= o:p></p><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bo= ttom-alt:auto'><span style=3D'color:#1F497D'>2. Ignore unrecognized paramet= ers – this is the usual way of dealing with extensible protocols. It = has security implications when extension parameters must not be ignored. Ho= wever, the workaround is simply to break something else (i.e. replace the c= lient_id with something else that will cause the normal flow to break).</sp= an><o:p></o:p></p><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso= -margin-bottom-alt:auto'><span style=3D'color:#1F497D'> </span><o:p></= o:p></p><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bo= ttom-alt:auto'><span style=3D'color:#1F497D'>3. Same as #2 but include a di= rective which means ‘must not ignore any parameter; return error if a= ny parameter is unknown’. XRD used to include such a ‘must-supp= ort’ attribute for properties but was dropped due to lack of use case= s.</span><o:p></o:p></p><p class=3DMsoNormal style=3D'mso-margin-top-alt:au= to;mso-margin-bottom-alt:auto'><span style=3D'color:#1F497D'> </span><= o:p></o:p></p><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-mar= gin-bottom-alt:auto'><span style=3D'color:#1F497D'>I think #2 offers a good= enough balance here, but am happy to discuss #3 if people have actual use = cases where ignoring an extension will cause security issues. Note that wit= h the expectation of error codes, my upcoming extensibility proposal does n= ot allow adding any new parameter values (only new parameters).</span><o:p>= </o:p></p><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-= bottom-alt:auto'><span style=3D'color:#1F497D'> </span><o:p></o:p></p>= <p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt= :auto'><span style=3D'color:#1F497D'>EHL</span><o:p></o:p></p><p class=3DMs= oNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span = style=3D'color:#1F497D'> </span><o:p></o:p></p><div style=3D'border:no= ne;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><div><div style= =3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:= auto'><b><span style=3D'font-size:10.0pt'>From:</span></b><span style=3D'fo= nt-size:10.0pt'> <a href=3D"mailto:oauth-bounces@ietf.org" target=3D"_blank= ">oauth-bounces@ietf.org</a> [mailto:<a href=3D"mailto:oauth-bounces@ietf.o= rg" target=3D"_blank">oauth-bounces@ietf.org</a>] <b>On Behalf Of </b>Yaron= Goland<br><b>Sent:</b> Monday, June 28, 2010 3:02 PM<br><b>To:</b> <a href= =3D"mailto:oauth@ietf.org" target=3D"_blank">oauth@ietf.org</a><br><b>Subje= ct:</b> [OAUTH-WG] How do we deal with unrecognized elements in requests an= d responses?</span><o:p></o:p></p></div></div><div><div><p class=3DMsoNorma= l style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p><= /o:p></p><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-b= ottom-alt:auto'>In a private thread with Eran an issue came up regarding ho= w to handle unrecognized arguments in OAuth requests and responses.<o:p></o= :p></p><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bot= tom-alt:auto'> <o:p></o:p></p><p class=3DMsoNormal style=3D'mso-margin= -top-alt:auto;mso-margin-bottom-alt:auto'>For example, if a token endpoint = receives an access token request that contains both a client_id and a clien= t_foo_bar argument, what should it do? Should it reject the request since i= t doesn’t recognize client_foo_bar? Should it ignore client_foo_bar a= nd just process the request based on client_id?<o:p></o:p></p><p class=3DMs= oNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> = <o:p></o:p></p><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-ma= rgin-bottom-alt:auto'>Similarly imagine that a response to an access token = request contains a JSON member with some unrecognized name. What’s th= e right behavior? Ignore the unrecognized value? Or treat the response as b= adly formatted and fail out?<o:p></o:p></p><p class=3DMsoNormal style=3D'ms= o-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p c= lass=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:aut= o'>We need to define in the spec how to deal with unrecognized extensions. = Typically the rule is ‘ignore what you don’t recognize’ b= ut there is a countervailing rule which applies here which is “securi= ty is different”. Typically ignoring unrecognized elements in a secur= ity context can lead to security holes.<o:p></o:p></p><p class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o= :p></p><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bot= tom-alt:auto'>Just looking at the history of OAuth I suspect we need to go = with the ignore rule and then explore ad nauseam in the security considerat= ions section all the ways that the ignore rule can go wrong if extensions a= ren’t handled carefully.<o:p></o:p></p><p class=3DMsoNormal style=3D'= mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p= class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:a= uto'>           &nbs= p;    Thoughts?<o:p></o:p></p><p class=3DMsoNormal style=3D'= mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p= class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:a= uto'>           &nbs= p;            &= nbsp;       Thanks,<o:p></o:p></p><p class=3D= MsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>&nbs= p;<o:p></o:p></p><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-= margin-bottom-alt:auto'>        &nb= sp;            =             &nb= sp;            =   Yaron<o:p></o:p></p></div></div></div></div></div><p class=3DMsoNorm= al style=3D'margin-bottom:12.0pt'><br>_____________________________________= __________<br>OAuth mailing list<br><a href=3D"mailto:OAuth@ietf.org">OAuth= @ietf.org</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/oauth" ta= rget=3D"_blank">https://www.ietf.org/mailman/listinfo/oauth</a><o:p></o:p><= /p></div><p class=3DMsoNormal><o:p> </o:p></p></div></div></div></body= ></html>= --_000_90C41DD21FB7C64BB94121FBBC2E72343B3ED4BCB4P3PW5EX1MB01E_-- From eran@hueniverse.com Mon Jun 28 18:42:12 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9D2F3A6881 for <oauth@core3.amsl.com>; Mon, 28 Jun 2010 18:42:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.246 X-Spam-Level: X-Spam-Status: No, score=-2.246 tagged_above=-999 required=5 tests=[AWL=0.352, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CuBDNE0YsutU for <oauth@core3.amsl.com>; Mon, 28 Jun 2010 18:42:07 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 508163A67D1 for <oauth@ietf.org>; Mon, 28 Jun 2010 18:42:07 -0700 (PDT) Received: (qmail 16034 invoked from network); 29 Jun 2010 01:42:17 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 29 Jun 2010 01:42:17 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 28 Jun 2010 18:42:17 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: Dick Hardt <dick.hardt@gmail.com> Date: Mon, 28 Jun 2010 18:42:20 -0700 Thread-Topic: [OAUTH-WG] Client credentials type Thread-Index: AcsW95uOES/F8NIBTWmy2BVpLnjOBQANI5ww Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4BCB7@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EC84C9D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <227B14C5-25DB-43F9-8754-ECB09EB33205@gmail.com> In-Reply-To: <227B14C5-25DB-43F9-8754-ECB09EB33205@gmail.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_90C41DD21FB7C64BB94121FBBC2E72343B3ED4BCB7P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Client credentials type X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 29 Jun 2010 01:42:12 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3ED4BCB7P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I don't care about the name (type vs method). Are there any objection to de= fining a parameter for the client authentication method? Any views about us= ing this parameter with an HTTP authorization header? EHL From: Dick Hardt [mailto:dick.hardt@gmail.com] Sent: Monday, June 28, 2010 12:25 PM To: Eran Hammer-Lahav Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Client credentials type While the AS implementor can infer the request by the parameters, I prefer = the programmer explicitly state what she is doing. Thinking of it as a meth= od parameter rather than a type parameter makes more sense to me. Similiarl= y, HTTP has GET, POST, PUT etc. even though you could differentiate between= them by looking at what was passed or not passed. -- Dick On 2010-06-28, at 10:39 AM, Eran Hammer-Lahav wrote: Yaron Goland offered a proposal for an additional client credentials mechan= ism based on assertion. His proposal raises the issue of differentiating be= tween the different kind of credentials used. When it comes to access grant= types, this group argued for being explicit and providing a parameter decl= aring the grant type being used (even though it is not technically necessar= y). While I don't believe a grant or credential type parameter is needed - the = type can be deduced from the other parameters present - we now treat the sa= me requirement with a different solution. I think this creates a broken env= ironment for extensibility (which is my current focus). At the same time, introducing such a parameter can conflict with the standa= rd HTTP authentication mechanism. For example, a request containing both "c= lient_credentials_type=3Dbasic" and the HTTP Authorization header seems odd= . There are a few ways to address this: 1. Only use a type parameter when the credentials are passed using paramete= rs and not a header. 2. Only allow HTTP headers for authentication, while "grandfathering-in" th= e client_secret parameter to simplify the most common current practice. 3. Leave is underspecified, relying on the presence of extension parameters= or authentication headers for other credentials types. Thoughts? EHL _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth --_000_90C41DD21FB7C64BB94121FBBC2E72343B3ED4BCB7P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV=3D"Content-Type" CONTENT= =3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros= oft Word 14 (filtered medium)"><base href=3D"x-msg://176/"><style><!-- /* Font Definitions */ @font-face {font-family:Helvetica; panose-1:2 11 6 4 2 2 2 2 2 4;} @font-face {font-family:Helvetica; panose-1:2 11 6 4 2 2 2 2 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} span.apple-style-span {mso-style-name:apple-style-span;} span.EmailStyle18 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue vli= nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><span style=3D'f= ont-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I donR= 17;t care about the name (type vs method). Are there any objection to defin= ing a parameter for the client authentication method? Any views about using= this parameter with an HTTP authorization header?<o:p></o:p></span></p><p = class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri","sa= ns-serif";color:#1F497D'><o:p> </o:p></span></p><p class=3DMsoNormal><= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'>EHL<o:p></o:p></span></p><p class=3DMsoNormal><span style=3D'font-siz= e:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p= ></span></p><div style=3D'border:none;border-left:solid blue 1.5pt;padding:= 0in 0in 0in 4.0pt'><div><div style=3D'border:none;border-top:solid #B5C4DF = 1.0pt;padding:3.0pt 0in 0in 0in'><p class=3DMsoNormal><b><span style=3D'fon= t-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span styl= e=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Dick Hardt [mailt= o:dick.hardt@gmail.com] <br><b>Sent:</b> Monday, June 28, 2010 12:25 PM<br>= <b>To:</b> Eran Hammer-Lahav<br><b>Cc:</b> OAuth WG (oauth@ietf.org)<br><b>= Subject:</b> Re: [OAUTH-WG] Client credentials type<o:p></o:p></span></p></= div></div><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>Wh= ile the AS implementor can infer the request by the parameters, I prefer th= e programmer explicitly state what she is doing. Thinking of it as a method= parameter rather than a type parameter makes more sense to me. Similiarly,= HTTP has GET, POST, PUT etc. even though you could differentiate between t= hem by looking at what was passed or not passed.<o:p></o:p></p><div><p clas= s=3DMsoNormal><o:p> </o:p></p></div><div><p class=3DMsoNormal>-- Dick<= o:p></o:p></p></div><div><p class=3DMsoNormal><o:p> </o:p></p><div><di= v><p class=3DMsoNormal>On 2010-06-28, at 10:39 AM, Eran Hammer-Lahav wrote:= <o:p></o:p></p></div><p class=3DMsoNormal><br><br><o:p></o:p></p><div><div>= <p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",= "sans-serif"'>Yaron Goland offered a proposal for an additional client cred= entials mechanism based on assertion. His proposal raises the issue of diff= erentiating between the different kind of credentials used. When it comes t= o access grant types, this group argued for being explicit and providing a = parameter declaring the grant type being used (even though it is not techni= cally necessary).<o:p></o:p></span></p></div><div><p class=3DMsoNormal><spa= n style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'> <o:p>= </o:p></span></p></div><div><p class=3DMsoNormal><span style=3D'font-size:1= 1.0pt;font-family:"Calibri","sans-serif"'>While I don’t believe a gra= nt or credential type parameter is needed – the type can be deduced f= rom the other parameters present – we now treat the same requirement = with a different solution. I think this creates a broken environment for ex= tensibility (which is my current focus).<o:p></o:p></span></p></div><div><p= class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri","s= ans-serif"'> <o:p></o:p></span></p></div><div><p class=3DMsoNormal><sp= an style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>At the sam= e time, introducing such a parameter can conflict with the standard HTTP au= thentication mechanism. For example, a request containing both “clien= t_credentials_type=3Dbasic” and the HTTP Authorization header seems o= dd.<o:p></o:p></span></p></div><div><p class=3DMsoNormal><span style=3D'fon= t-size:11.0pt;font-family:"Calibri","sans-serif"'> <o:p></o:p></span><= /p></div><div><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-fam= ily:"Calibri","sans-serif"'>There are a few ways to address this:<o:p></o:p= ></span></p></div><div><p class=3DMsoNormal><span style=3D'font-size:11.0pt= ;font-family:"Calibri","sans-serif"'> <o:p></o:p></span></p></div><div= ><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri"= ,"sans-serif"'>1. Only use a type parameter when the credentials are passed= using parameters and not a header.<o:p></o:p></span></p></div><div><p clas= s=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri","sans-s= erif"'>2. Only allow HTTP headers for authentication, while “grandfat= hering-in” the client_secret parameter to simplify the most common cu= rrent practice.<o:p></o:p></span></p></div><div><p class=3DMsoNormal><span = style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>3. Leave is u= nderspecified, relying on the presence of extension parameters or authentic= ation headers for other credentials types.<o:p></o:p></span></p></div><div>= <p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",= "sans-serif"'> <o:p></o:p></span></p></div><div><p class=3DMsoNormal><= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>Thoughts= ?<o:p></o:p></span></p></div><div><p class=3DMsoNormal><span style=3D'font-= size:11.0pt;font-family:"Calibri","sans-serif"'> <o:p></o:p></span></p= ></div><div><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-famil= y:"Calibri","sans-serif"'>EHL<o:p></o:p></span></p></div><p class=3DMsoNorm= al><span style=3D'font-size:13.5pt;font-family:"Helvetica","sans-serif"'>__= _____________________________________________<br>OAuth mailing list<br><a h= ref=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a><br><a href=3D"https://www.= ietf.org/mailman/listinfo/oauth">https://www.ietf.org/mailman/listinfo/oaut= h</a><o:p></o:p></span></p></div></div><p class=3DMsoNormal><o:p> </o:= p></p></div></div></div></body></html>= --_000_90C41DD21FB7C64BB94121FBBC2E72343B3ED4BCB7P3PW5EX1MB01E_-- From igor.faynberg@alcatel-lucent.com Mon Jun 28 19:43:34 2010 Return-Path: <igor.faynberg@alcatel-lucent.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B73D23A6774 for <oauth@core3.amsl.com>; Mon, 28 Jun 2010 19:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[AWL=1.600, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zeyNqqDBttu2 for <oauth@core3.amsl.com>; Mon, 28 Jun 2010 19:43:32 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 765003A657C for <oauth@ietf.org>; Mon, 28 Jun 2010 19:43:32 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id o5T2hd40015728 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Jun 2010 21:43:40 -0500 (CDT) Received: from [135.244.34.167] (faynberg.lra.lucent.com [135.244.34.167]) by umail.lucent.com (8.13.8/TPES) with ESMTP id o5T2hdEp015607; Mon, 28 Jun 2010 21:43:39 -0500 (CDT) Message-ID: <4C295DDA.7040106@alcatel-lucent.com> Date: Mon, 28 Jun 2010 22:43:38 -0400 From: Igor Faynberg <igor.faynberg@alcatel-lucent.com> Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Eran Hammer-Lahav <eran@hueniverse.com> References: <7C01E631FF4B654FA1E783F1C0265F8C579D0F52@TK5EX14MBXC117.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4BCB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTin2cvQnXB7x9abGLF4xQyfrv9IzZCzxOHnJqlHQ@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4BCB4@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4BCB4@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] How do we deal with unrecognized elements in requests and responses? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 29 Jun 2010 02:43:34 -0000 I agree. I think we indeed should clearly articulate the use cases driving discovery (maybe Zachary could report on those?), but I also think that we will probably need to get something like "procedures," which describe expected usages, within the protocol specification. For one thing, all extensions whose support is essential under specific circumstances should be described listing such circumstances and recommending the action. (I also think that the idea of specifying pre- and post- conditions in use cases will help.) Igor Eran Hammer-Lahav wrote: > > There are times when the client wants the server to fail if it doesn’t > support an extension. The client developer might consider the server > as being less secure without the added protection of the extension and > would like the server to be able to tell it was making such a request > and fail. > > This clearly belongs in the use cases driving discovery, as in the > core specification, the client is expected to be familiar with the > details of the server. So we just need to make sure that we don’t > prevent such use cases. #2 doesn’t prevent it, but requires the client > to break something else. For example, an extension having to do with > client identity should replace the client_id parameter with something > else, making a server unaware of this extension fail (because the > required client_id parameter will be missing). > > EHL > > *From:* David Recordon [mailto:recordond@gmail.com] > *Sent:* Monday, June 28, 2010 6:11 PM > *To:* Eran Hammer-Lahav > *Cc:* Yaron Goland; OAuth WG (oauth@ietf.org) > *Subject:* Re: [OAUTH-WG] How do we deal with unrecognized elements in > requests and responses? > > For #2, if an extension defines required parameters then you're not > supporting the extension if you ignore them. Or am I missing something? > > On Mon, Jun 28, 2010 at 5:59 PM, Eran Hammer-Lahav > <eran@hueniverse.com <mailto:eran@hueniverse.com>> wrote: > > There are 3 general ways to deal with this: > > 1. Break on unrecognized parameters – this tends to make the use of > extensions hard, and at a minimum requires an error to include the bad > parameter in a machine readable way (so a library can figure out an > extension is not supported). > > 2. Ignore unrecognized parameters – this is the usual way of dealing > with extensible protocols. It has security implications when extension > parameters must not be ignored. However, the workaround is simply to > break something else (i.e. replace the client_id with something else > that will cause the normal flow to break). > > 3. Same as #2 but include a directive which means ‘must not ignore any > parameter; return error if any parameter is unknown’. XRD used to > include such a ‘must-support’ attribute for properties but was dropped > due to lack of use cases. > > I think #2 offers a good enough balance here, but am happy to discuss > #3 if people have actual use cases where ignoring an extension will > cause security issues. Note that with the expectation of error codes, > my upcoming extensibility proposal does not allow adding any new > parameter values (only new parameters). > > EHL > > *From:* oauth-bounces@ietf.org <mailto:oauth-bounces@ietf.org> > [mailto:oauth-bounces@ietf.org <mailto:oauth-bounces@ietf.org>] *On > Behalf Of *Yaron Goland > *Sent:* Monday, June 28, 2010 3:02 PM > *To:* oauth@ietf.org <mailto:oauth@ietf.org> > *Subject:* [OAUTH-WG] How do we deal with unrecognized elements in > requests and responses? > > In a private thread with Eran an issue came up regarding how to handle > unrecognized arguments in OAuth requests and responses. > > For example, if a token endpoint receives an access token request that > contains both a client_id and a client_foo_bar argument, what should > it do? Should it reject the request since it doesn’t recognize > client_foo_bar? Should it ignore client_foo_bar and just process the > request based on client_id? > > Similarly imagine that a response to an access token request contains > a JSON member with some unrecognized name. What’s the right behavior? > Ignore the unrecognized value? Or treat the response as badly > formatted and fail out? > > We need to define in the spec how to deal with unrecognized > extensions. Typically the rule is ‘ignore what you don’t recognize’ > but there is a countervailing rule which applies here which is > “security is different”. Typically ignoring unrecognized elements in a > security context can lead to security holes. > > Just looking at the history of OAuth I suspect we need to go with the > ignore rule and then explore ad nauseam in the security considerations > section all the ways that the ignore rule can go wrong if extensions > aren’t handled carefully. > > Thoughts? > > Thanks, > > Yaron > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > > ------------------------------------------------------------------------ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From lshepard@facebook.com Mon Jun 28 20:03:21 2010 Return-Path: <lshepard@facebook.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 034613A68B6 for <oauth@core3.amsl.com>; Mon, 28 Jun 2010 20:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.679 X-Spam-Level: X-Spam-Status: No, score=0.679 tagged_above=-999 required=5 tests=[AWL=-1.295, BAYES_40=-0.185, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iUlD+4YrPvwo for <oauth@core3.amsl.com>; Mon, 28 Jun 2010 20:03:20 -0700 (PDT) Received: from mx-out.facebook.com (outmail004.snc1.tfbnw.net [69.63.178.163]) by core3.amsl.com (Postfix) with ESMTP id EF2373A688B for <oauth@ietf.org>; Mon, 28 Jun 2010 20:03:19 -0700 (PDT) Received: from [10.18.255.129] ([10.18.255.129:59737] helo=mail.thefacebook.com) by mta004.snc1.facebook.com (envelope-from <lshepard@facebook.com>) (ecelerity 2.2.2.45 r(34067)) with ESMTP id A2/63-15591-082692C4; Mon, 28 Jun 2010 20:03:28 -0700 Received: from sc-hub05.TheFacebook.com (192.168.18.82) by sc-hub03.TheFacebook.com (192.168.18.198) with Microsoft SMTP Server (TLS) id 14.0.694.1; Mon, 28 Jun 2010 20:03:28 -0700 Received: from SC-MBXC1.TheFacebook.com ([192.168.18.100]) by sc-hub05.TheFacebook.com ([192.168.18.82]) with mapi; Mon, 28 Jun 2010 20:03:27 -0700 From: Luke Shepard <lshepard@facebook.com> To: Eran Hammer-Lahav <eran@hueniverse.com> Date: Mon, 28 Jun 2010 20:02:06 -0700 Thread-Topic: [OAUTH-WG] Client credentials type Thread-Index: AcsXN6VXCMk3TMWlTlGUO1Idk70Z9Q== Message-ID: <70B36328-B644-4908-9AE8-3A071EF2C821@facebook.com> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EC84C9D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <227B14C5-25DB-43F9-8754-ECB09EB33205@gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4BCB7@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4BCB7@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_70B36328B64449089AE83A071EF2C821facebookcom_" MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Client credentials type X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 29 Jun 2010 03:03:21 -0000 --_000_70B36328B64449089AE83A071EF2C821facebookcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable For what it's worth, I (Facebook) would not require my clients to specify a= type. It's fine to discuss it in the docs and examples, but if a client pa= ssed in a request without a type, I would probably try to infer the grant t= ype from the request rather than throwing an error. Besides the purity of the spec, would anyone object to a server that tried = to play nice by its clients? On Jun 28, 2010, at 6:42 PM, Eran Hammer-Lahav wrote: I don=92t care about the name (type vs method). Are there any objection to = defining a parameter for the client authentication method? Any views about = using this parameter with an HTTP authorization header? EHL From: Dick Hardt [mailto:dick.hardt@gmail.com] Sent: Monday, June 28, 2010 12:25 PM To: Eran Hammer-Lahav Cc: OAuth WG (oauth@ietf.org<mailto:oauth@ietf.org>) Subject: Re: [OAUTH-WG] Client credentials type While the AS implementor can infer the request by the parameters, I prefer = the programmer explicitly state what she is doing. Thinking of it as a meth= od parameter rather than a type parameter makes more sense to me. Similiarl= y, HTTP has GET, POST, PUT etc. even though you could differentiate between= them by looking at what was passed or not passed. -- Dick On 2010-06-28, at 10:39 AM, Eran Hammer-Lahav wrote: Yaron Goland offered a proposal for an additional client credentials mechan= ism based on assertion. His proposal raises the issue of differentiating be= tween the different kind of credentials used. When it comes to access grant= types, this group argued for being explicit and providing a parameter decl= aring the grant type being used (even though it is not technically necessar= y). While I don=92t believe a grant or credential type parameter is needed =96 = the type can be deduced from the other parameters present =96 we now treat = the same requirement with a different solution. I think this creates a brok= en environment for extensibility (which is my current focus). At the same time, introducing such a parameter can conflict with the standa= rd HTTP authentication mechanism. For example, a request containing both = =93client_credentials_type=3Dbasic=94 and the HTTP Authorization header see= ms odd. There are a few ways to address this: 1. Only use a type parameter when the credentials are passed using paramete= rs and not a header. 2. Only allow HTTP headers for authentication, while =93grandfathering-in= =94 the client_secret parameter to simplify the most common current practic= e. 3. Leave is underspecified, relying on the presence of extension parameters= or authentication headers for other credentials types. Thoughts? EHL _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth <ATT00001..txt> --_000_70B36328B64449089AE83A071EF2C821facebookcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable <html><head><base href=3D"x-msg://176/"></head><body style=3D"word-wrap: br= eak-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; = ">For what it's worth, I (Facebook) would not require my clients to specify= a type. It's fine to discuss it in the docs and examples, but if a client = passed in a request without a type, I would probably try to infer the grant= type from the request rather than throwing an error.<div><div><br></div><d= iv>Besides the purity of the spec, would anyone object to a server that tri= ed to play nice by its clients?</div><div><br><div><div>On Jun 28, 2010, at= 6:42 PM, Eran Hammer-Lahav wrote:</div><br class=3D"Apple-interchange-newl= ine"><blockquote type=3D"cite"><span class=3D"Apple-style-span" style=3D"bo= rder-collapse: separate; font-family: Helvetica; font-style: normal; font-v= ariant: normal; font-weight: normal; letter-spacing: normal; line-height: n= ormal; orphans: 2; text-indent: 0px; text-transform: none; white-space: nor= mal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; = -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: n= one; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-s= ize: medium; "><div lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div clas= s=3D"WordSection1" style=3D"page: WordSection1; "><div style=3D"margin-top:= 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-si= ze: 12pt; font-family: 'Times New Roman', serif; "><span style=3D"font-size= : 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">I don= =92t care about the name (type vs method). Are there any objection to defin= ing a parameter for the client authentication method? Any views about using= this parameter with an HTTP authorization header?<o:p></o:p></span></div><= div style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; m= argin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; ">= <span style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: rg= b(31, 73, 125); "><o:p> </o:p></span></div><div style=3D"margin-top: 0= in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size= : 12pt; font-family: 'Times New Roman', serif; "><span style=3D"font-size: = 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">EHL<o:p>= </o:p></span></div><div style=3D"margin-top: 0in; margin-right: 0in; margin= -bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; font-family: 'Times N= ew Roman', serif; "><span style=3D"font-size: 11pt; font-family: Calibri, s= ans-serif; color: rgb(31, 73, 125); "><o:p> </o:p></span></div><div st= yle=3D"border-top-style: none; border-right-style: none; border-bottom-styl= e: none; border-width: initial; border-color: initial; border-left-style: s= olid; border-left-color: blue; border-left-width: 1.5pt; padding-top: 0in; = padding-right: 0in; padding-bottom: 0in; padding-left: 4pt; "><div><div sty= le=3D"border-right-style: none; border-bottom-style: none; border-left-styl= e: none; border-width: initial; border-color: initial; border-top-style: so= lid; border-top-color: rgb(181, 196, 223); border-top-width: 1pt; padding-t= op: 3pt; padding-right: 0in; padding-bottom: 0in; padding-left: 0in; "><div= style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; marg= in-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; "><b>= <span style=3D"font-size: 10pt; font-family: Tahoma, sans-serif; ">From:</s= pan></b><span style=3D"font-size: 10pt; font-family: Tahoma, sans-serif; ">= <span class=3D"Apple-converted-space"> </span>Dick Hardt [mailto:dick.= hardt@gmail.com]<span class=3D"Apple-converted-space"> </span><br><b>S= ent:</b><span class=3D"Apple-converted-space"> </span>Monday, June 28,= 2010 12:25 PM<br><b>To:</b><span class=3D"Apple-converted-space"> </s= pan>Eran Hammer-Lahav<br><b>Cc:</b><span class=3D"Apple-converted-space">&n= bsp;</span>OAuth WG (<a href=3D"mailto:oauth@ietf.org" style=3D"color: blue= ; text-decoration: underline; ">oauth@ietf.org</a>)<br><b>Subject:</b><span= class=3D"Apple-converted-space"> </span>Re: [OAUTH-WG] Client credent= ials type<o:p></o:p></span></div></div></div><div style=3D"margin-top: 0in;= margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 1= 2pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div><div s= tyle=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin= -left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; ">While= the AS implementor can infer the request by the parameters, I prefer the p= rogrammer explicitly state what she is doing. Thinking of it as a method pa= rameter rather than a type parameter makes more sense to me. Similiarly, HT= TP has GET, POST, PUT etc. even though you could differentiate between them= by looking at what was passed or not passed.<o:p></o:p></div><div><div sty= le=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-l= eft: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p>&n= bsp;</o:p></div></div><div><div style=3D"margin-top: 0in; margin-right: 0in= ; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; font-family: = 'Times New Roman', serif; ">-- Dick<o:p></o:p></div></div><div><div style= =3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-lef= t: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p>&nbs= p;</o:p></div><div><div><div style=3D"margin-top: 0in; margin-right: 0in; m= argin-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; font-family: 'Ti= mes New Roman', serif; ">On 2010-06-28, at 10:39 AM, Eran Hammer-Lahav wrot= e:<o:p></o:p></div></div><div style=3D"margin-top: 0in; margin-right: 0in; = margin-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; font-family: 'T= imes New Roman', serif; "><br><br><o:p></o:p></div><div><div><div style=3D"= margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0= in; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style= =3D"font-size: 11pt; font-family: Calibri, sans-serif; ">Yaron Goland offer= ed a proposal for an additional client credentials mechanism based on asser= tion. His proposal raises the issue of differentiating between the differen= t kind of credentials used. When it comes to access grant types, this group= argued for being explicit and providing a parameter declaring the grant ty= pe being used (even though it is not technically necessary).<o:p></o:p></sp= an></div></div><div><div style=3D"margin-top: 0in; margin-right: 0in; margi= n-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; font-family: 'Times = New Roman', serif; "><span style=3D"font-size: 11pt; font-family: Calibri, = sans-serif; "> <o:p></o:p></span></div></div><div><div style=3D"margin= -top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; fo= nt-size: 12pt; font-family: 'Times New Roman', serif; "><span style=3D"font= -size: 11pt; font-family: Calibri, sans-serif; ">While I don=92t believe a = grant or credential type parameter is needed =96 the type can be deduced fr= om the other parameters present =96 we now treat the same requirement with = a different solution. I think this creates a broken environment for extensi= bility (which is my current focus).<o:p></o:p></span></div></div><div><div = style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margi= n-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; "><spa= n style=3D"font-size: 11pt; font-family: Calibri, sans-serif; "> <o:p>= </o:p></span></div></div><div><div style=3D"margin-top: 0in; margin-right: = 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; font-famil= y: 'Times New Roman', serif; "><span style=3D"font-size: 11pt; font-family:= Calibri, sans-serif; ">At the same time, introducing such a parameter can = conflict with the standard HTTP authentication mechanism. For example, a re= quest containing both =93client_credentials_type=3Dbasic=94 and the HTTP Au= thorization header seems odd.<o:p></o:p></span></div></div><div><div style= =3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-lef= t: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; "><span sty= le=3D"font-size: 11pt; font-family: Calibri, sans-serif; "> <o:p></o:p= ></span></div></div><div><div style=3D"margin-top: 0in; margin-right: 0in; = margin-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; font-family: 'T= imes New Roman', serif; "><span style=3D"font-size: 11pt; font-family: Cali= bri, sans-serif; ">There are a few ways to address this:<o:p></o:p></span><= /div></div><div><div style=3D"margin-top: 0in; margin-right: 0in; margin-bo= ttom: 0.0001pt; margin-left: 0in; font-size: 12pt; font-family: 'Times New = Roman', serif; "><span style=3D"font-size: 11pt; font-family: Calibri, sans= -serif; "> <o:p></o:p></span></div></div><div><div style=3D"margin-top= : 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-s= ize: 12pt; font-family: 'Times New Roman', serif; "><span style=3D"font-siz= e: 11pt; font-family: Calibri, sans-serif; ">1. Only use a type parameter w= hen the credentials are passed using parameters and not a header.<o:p></o:p= ></span></div></div><div><div style=3D"margin-top: 0in; margin-right: 0in; = margin-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; font-family: 'T= imes New Roman', serif; "><span style=3D"font-size: 11pt; font-family: Cali= bri, sans-serif; ">2. Only allow HTTP headers for authentication, while =93= grandfathering-in=94 the client_secret parameter to simplify the most commo= n current practice.<o:p></o:p></span></div></div><div><div style=3D"margin-= top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; fon= t-size: 12pt; font-family: 'Times New Roman', serif; "><span style=3D"font-= size: 11pt; font-family: Calibri, sans-serif; ">3. Leave is underspecified,= relying on the presence of extension parameters or authentication headers = for other credentials types.<o:p></o:p></span></div></div><div><div style= =3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-lef= t: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; "><span sty= le=3D"font-size: 11pt; font-family: Calibri, sans-serif; "> <o:p></o:p= ></span></div></div><div><div style=3D"margin-top: 0in; margin-right: 0in; = margin-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; font-family: 'T= imes New Roman', serif; "><span style=3D"font-size: 11pt; font-family: Cali= bri, sans-serif; ">Thoughts?<o:p></o:p></span></div></div><div><div style= =3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-lef= t: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; "><span sty= le=3D"font-size: 11pt; font-family: Calibri, sans-serif; "> <o:p></o:p= ></span></div></div><div><div style=3D"margin-top: 0in; margin-right: 0in; = margin-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; font-family: 'T= imes New Roman', serif; "><span style=3D"font-size: 11pt; font-family: Cali= bri, sans-serif; ">EHL<o:p></o:p></span></div></div><div style=3D"margin-to= p: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-= size: 12pt; font-family: 'Times New Roman', serif; "><span style=3D"font-si= ze: 13.5pt; font-family: Helvetica, sans-serif; ">_________________________= ______________________<br>OAuth mailing list<br><a href=3D"mailto:OAuth@iet= f.org" style=3D"color: blue; text-decoration: underline; ">OAuth@ietf.org</= a><br><a href=3D"https://www.ietf.org/mailman/listinfo/oauth" style=3D"colo= r: blue; text-decoration: underline; ">https://www.ietf.org/mailman/listinf= o/oauth</a><o:p></o:p></span></div></div></div><div style=3D"margin-top: 0i= n; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size:= 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></di= v></div></div><span><ATT00001..txt></span></div></span></blockquote><= /div><br></div></div></body></html>= --_000_70B36328B64449089AE83A071EF2C821facebookcom_-- From dick.hardt@gmail.com Mon Jun 28 20:42:38 2010 Return-Path: <dick.hardt@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A4513A677D for <oauth@core3.amsl.com>; Mon, 28 Jun 2010 20:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.456 X-Spam-Level: X-Spam-Status: No, score=-2.456 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-403h4DCqUd for <oauth@core3.amsl.com>; Mon, 28 Jun 2010 20:42:37 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id 101193A6774 for <oauth@ietf.org>; Mon, 28 Jun 2010 20:42:36 -0700 (PDT) Received: by pxi16 with SMTP id 16so1781748pxi.31 for <oauth@ietf.org>; Mon, 28 Jun 2010 20:42:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:message-id:references:to :x-mailer; bh=pDrkSDk0Xk/GMJHJ4thWTR8knVONp4Zy/QxLnEFheyU=; b=BhD7vRCrMyDrNp9INZdJ/qlYos/o2ikdisTLSZ+2ObkWlcSU2AGFTTYZzdtXaXptTq aptgKHG6wTzReSi9opsYx0+D5CGWBbquDl7DhkiBlcNanrEQpvla/toPF9Md8a1sXdVv k/lw7r+0oddaYbITs6Gr/eLDatXoOAnsQkrvI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; b=UpGFWX2Axt7G6H9vn97H0IqMX3YVI53nut8cY+t//+Lk90VUm/dBfY6EDLybRHj5Lp dN2MlSKIjEoCdpjZHyTvxtadfZ5GojRq+JGMld/Be3I0j0nwrX1fhHxZv1RySYsX8Pyn 1nKIMbMe/i+sD3LFKLs2noCEIhMNmjVc9lKhQ= Received: by 10.142.66.15 with SMTP id o15mr6973003wfa.89.1277782963071; Mon, 28 Jun 2010 20:42:43 -0700 (PDT) Received: from [192.168.1.2] (c-24-130-32-55.hsd1.ca.comcast.net [24.130.32.55]) by mx.google.com with ESMTPS id 21sm3780604wfi.5.2010.06.28.20.42.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 28 Jun 2010 20:42:42 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/alternative; boundary=Apple-Mail-100-975533230 From: Dick Hardt <dick.hardt@gmail.com> In-Reply-To: <70B36328-B644-4908-9AE8-3A071EF2C821@facebook.com> Date: Mon, 28 Jun 2010 20:42:40 -0700 Message-Id: <D2001A83-5BC6-4124-BF99-F49642053285@gmail.com> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EC84C9D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <227B14C5-25DB-43F9-8754-ECB09EB33205@gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4BCB7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <70B36328-B644-4908-9AE8-3A071EF2C821@facebook.com> To: Luke Shepard <lshepard@facebook.com> X-Mailer: Apple Mail (2.1078) Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Client credentials type X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 29 Jun 2010 03:42:38 -0000 --Apple-Mail-100-975533230 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Your approach fits with the "be generous in what you accept" ethos. On 2010-06-28, at 8:02 PM, Luke Shepard wrote: > For what it's worth, I (Facebook) would not require my clients to = specify a type. It's fine to discuss it in the docs and examples, but if = a client passed in a request without a type, I would probably try to = infer the grant type from the request rather than throwing an error. >=20 > Besides the purity of the spec, would anyone object to a server that = tried to play nice by its clients? >=20 > On Jun 28, 2010, at 6:42 PM, Eran Hammer-Lahav wrote: >=20 >> I don=92t care about the name (type vs method). Are there any = objection to defining a parameter for the client authentication method? = Any views about using this parameter with an HTTP authorization header? >> =20 >> EHL >> =20 >> From: Dick Hardt [mailto:dick.hardt@gmail.com]=20 >> Sent: Monday, June 28, 2010 12:25 PM >> To: Eran Hammer-Lahav >> Cc: OAuth WG (oauth@ietf.org) >> Subject: Re: [OAUTH-WG] Client credentials type >> =20 >> While the AS implementor can infer the request by the parameters, I = prefer the programmer explicitly state what she is doing. Thinking of it = as a method parameter rather than a type parameter makes more sense to = me. Similiarly, HTTP has GET, POST, PUT etc. even though you could = differentiate between them by looking at what was passed or not passed. >> =20 >> -- Dick >> =20 >> On 2010-06-28, at 10:39 AM, Eran Hammer-Lahav wrote: >>=20 >>=20 >> Yaron Goland offered a proposal for an additional client credentials = mechanism based on assertion. His proposal raises the issue of = differentiating between the different kind of credentials used. When it = comes to access grant types, this group argued for being explicit and = providing a parameter declaring the grant type being used (even though = it is not technically necessary). >> =20 >> While I don=92t believe a grant or credential type parameter is = needed =96 the type can be deduced from the other parameters present =96 = we now treat the same requirement with a different solution. I think = this creates a broken environment for extensibility (which is my current = focus). >> =20 >> At the same time, introducing such a parameter can conflict with the = standard HTTP authentication mechanism. For example, a request = containing both =93client_credentials_type=3Dbasic=94 and the HTTP = Authorization header seems odd. >> =20 >> There are a few ways to address this: >> =20 >> 1. Only use a type parameter when the credentials are passed using = parameters and not a header. >> 2. Only allow HTTP headers for authentication, while = =93grandfathering-in=94 the client_secret parameter to simplify the most = common current practice. >> 3. Leave is underspecified, relying on the presence of extension = parameters or authentication headers for other credentials types. >> =20 >> Thoughts? >> =20 >> EHL >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> =20 >> <ATT00001..txt> >=20 --Apple-Mail-100-975533230 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 <html><head></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Your = approach fits with the "be generous in what you accept" = ethos.<div><br><div><div>On 2010-06-28, at 8:02 PM, Luke Shepard = wrote:</div><br class=3D"Apple-interchange-newline"><blockquote = type=3D"cite"><div style=3D"word-wrap: break-word; -webkit-nbsp-mode: = space; -webkit-line-break: after-white-space; ">For what it's worth, I = (Facebook) would not require my clients to specify a type. It's fine to = discuss it in the docs and examples, but if a client passed in a request = without a type, I would probably try to infer the grant type from the = request rather than throwing an error.<div><div><br></div><div>Besides = the purity of the spec, would anyone object to a server that tried to = play nice by its clients?</div><div><br><div><div>On Jun 28, 2010, at = 6:42 PM, Eran Hammer-Lahav wrote:</div><br = class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><span = class=3D"Apple-style-span" style=3D"border-collapse: separate; = font-family: Helvetica; font-style: normal; font-variant: normal; = font-weight: normal; letter-spacing: normal; line-height: normal; = orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; = widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; = -webkit-border-vertical-spacing: 0px; = -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: = auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div = lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div class=3D"WordSection1" = style=3D"page: WordSection1; "><div style=3D"margin-top: 0in; = margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: = 12pt; font-family: 'Times New Roman', serif; "><span style=3D"font-size: = 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">I = don=92t care about the name (type vs method). Are there any objection to = defining a parameter for the client authentication method? Any views = about using this parameter with an HTTP authorization = header?<o:p></o:p></span></div><div style=3D"margin-top: 0in; = margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: = 12pt; font-family: 'Times New Roman', serif; "><span style=3D"font-size: = 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); = "><o:p> </o:p></span></div><div style=3D"margin-top: 0in; = margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: = 12pt; font-family: 'Times New Roman', serif; "><span style=3D"font-size: = 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); = ">EHL<o:p></o:p></span></div><div style=3D"margin-top: 0in; = margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: = 12pt; font-family: 'Times New Roman', serif; "><span style=3D"font-size: = 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); = "><o:p> </o:p></span></div><div style=3D"border-top-style: none; = border-right-style: none; border-bottom-style: none; border-width: = initial; border-color: initial; border-left-style: solid; = border-left-color: blue; border-left-width: 1.5pt; padding-top: 0in; = padding-right: 0in; padding-bottom: 0in; padding-left: 4pt; "><div><div = style=3D"border-right-style: none; border-bottom-style: none; = border-left-style: none; border-width: initial; border-color: initial; = border-top-style: solid; border-top-color: rgb(181, 196, 223); = border-top-width: 1pt; padding-top: 3pt; padding-right: 0in; = padding-bottom: 0in; padding-left: 0in; "><div style=3D"margin-top: 0in; = margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: = 12pt; font-family: 'Times New Roman', serif; "><b><span = style=3D"font-size: 10pt; font-family: Tahoma, sans-serif; = ">From:</span></b><span style=3D"font-size: 10pt; font-family: Tahoma, = sans-serif; "><span class=3D"Apple-converted-space"> </span>Dick = Hardt [mailto:dick.hardt@gmail.com]<span = class=3D"Apple-converted-space"> </span><br><b>Sent:</b><span = class=3D"Apple-converted-space"> </span>Monday, June 28, 2010 12:25 = PM<br><b>To:</b><span class=3D"Apple-converted-space"> </span>Eran = Hammer-Lahav<br><b>Cc:</b><span = class=3D"Apple-converted-space"> </span>OAuth WG (<a = href=3D"mailto:oauth@ietf.org" style=3D"color: blue; text-decoration: = underline; ">oauth@ietf.org</a>)<br><b>Subject:</b><span = class=3D"Apple-converted-space"> </span>Re: [OAUTH-WG] Client = credentials type<o:p></o:p></span></div></div></div><div = style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; = margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', = serif; "><o:p> </o:p></div><div style=3D"margin-top: 0in; = margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: = 12pt; font-family: 'Times New Roman', serif; ">While the AS implementor = can infer the request by the parameters, I prefer the programmer = explicitly state what she is doing. Thinking of it as a method parameter = rather than a type parameter makes more sense to me. Similiarly, HTTP = has GET, POST, PUT etc. even though you could differentiate between them = by looking at what was passed or not passed.<o:p></o:p></div><div><div = style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; = margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', = serif; "><o:p> </o:p></div></div><div><div style=3D"margin-top: = 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; = font-size: 12pt; font-family: 'Times New Roman', serif; ">-- = Dick<o:p></o:p></div></div><div><div style=3D"margin-top: 0in; = margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: = 12pt; font-family: 'Times New Roman', serif; = "><o:p> </o:p></div><div><div><div style=3D"margin-top: 0in; = margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: = 12pt; font-family: 'Times New Roman', serif; ">On 2010-06-28, at 10:39 = AM, Eran Hammer-Lahav wrote:<o:p></o:p></div></div><div = style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; = margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', = serif; "><br><br><o:p></o:p></div><div><div><div style=3D"margin-top: = 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; = font-size: 12pt; font-family: 'Times New Roman', serif; "><span = style=3D"font-size: 11pt; font-family: Calibri, sans-serif; ">Yaron = Goland offered a proposal for an additional client credentials mechanism = based on assertion. His proposal raises the issue of differentiating = between the different kind of credentials used. When it comes to access = grant types, this group argued for being explicit and providing a = parameter declaring the grant type being used (even though it is not = technically necessary).<o:p></o:p></span></div></div><div><div = style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; = margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', = serif; "><span style=3D"font-size: 11pt; font-family: Calibri, = sans-serif; "> <o:p></o:p></span></div></div><div><div = style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; = margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', = serif; "><span style=3D"font-size: 11pt; font-family: Calibri, = sans-serif; ">While I don=92t believe a grant or credential type = parameter is needed =96 the type can be deduced from the other = parameters present =96 we now treat the same requirement with a = different solution. I think this creates a broken environment for = extensibility (which is my current = focus).<o:p></o:p></span></div></div><div><div style=3D"margin-top: 0in; = margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: = 12pt; font-family: 'Times New Roman', serif; "><span style=3D"font-size: = 11pt; font-family: Calibri, sans-serif; = "> <o:p></o:p></span></div></div><div><div style=3D"margin-top: = 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; = font-size: 12pt; font-family: 'Times New Roman', serif; "><span = style=3D"font-size: 11pt; font-family: Calibri, sans-serif; ">At the = same time, introducing such a parameter can conflict with the standard = HTTP authentication mechanism. For example, a request containing both = =93client_credentials_type=3Dbasic=94 and the HTTP Authorization header = seems odd.<o:p></o:p></span></div></div><div><div style=3D"margin-top: = 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; = font-size: 12pt; font-family: 'Times New Roman', serif; "><span = style=3D"font-size: 11pt; font-family: Calibri, sans-serif; = "> <o:p></o:p></span></div></div><div><div style=3D"margin-top: = 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; = font-size: 12pt; font-family: 'Times New Roman', serif; "><span = style=3D"font-size: 11pt; font-family: Calibri, sans-serif; ">There are = a few ways to address this:<o:p></o:p></span></div></div><div><div = style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; = margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', = serif; "><span style=3D"font-size: 11pt; font-family: Calibri, = sans-serif; "> <o:p></o:p></span></div></div><div><div = style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; = margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', = serif; "><span style=3D"font-size: 11pt; font-family: Calibri, = sans-serif; ">1. Only use a type parameter when the credentials are = passed using parameters and not a = header.<o:p></o:p></span></div></div><div><div style=3D"margin-top: 0in; = margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: = 12pt; font-family: 'Times New Roman', serif; "><span style=3D"font-size: = 11pt; font-family: Calibri, sans-serif; ">2. Only allow HTTP headers for = authentication, while =93grandfathering-in=94 the client_secret = parameter to simplify the most common current = practice.<o:p></o:p></span></div></div><div><div style=3D"margin-top: = 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; = font-size: 12pt; font-family: 'Times New Roman', serif; "><span = style=3D"font-size: 11pt; font-family: Calibri, sans-serif; ">3. Leave = is underspecified, relying on the presence of extension parameters or = authentication headers for other credentials = types.<o:p></o:p></span></div></div><div><div style=3D"margin-top: 0in; = margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: = 12pt; font-family: 'Times New Roman', serif; "><span style=3D"font-size: = 11pt; font-family: Calibri, sans-serif; = "> <o:p></o:p></span></div></div><div><div style=3D"margin-top: = 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; = font-size: 12pt; font-family: 'Times New Roman', serif; "><span = style=3D"font-size: 11pt; font-family: Calibri, sans-serif; = ">Thoughts?<o:p></o:p></span></div></div><div><div style=3D"margin-top: = 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; = font-size: 12pt; font-family: 'Times New Roman', serif; "><span = style=3D"font-size: 11pt; font-family: Calibri, sans-serif; = "> <o:p></o:p></span></div></div><div><div style=3D"margin-top: = 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; = font-size: 12pt; font-family: 'Times New Roman', serif; "><span = style=3D"font-size: 11pt; font-family: Calibri, sans-serif; = ">EHL<o:p></o:p></span></div></div><div style=3D"margin-top: 0in; = margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: = 12pt; font-family: 'Times New Roman', serif; "><span style=3D"font-size: = 13.5pt; font-family: Helvetica, sans-serif; = ">_______________________________________________<br>OAuth mailing = list<br><a href=3D"mailto:OAuth@ietf.org" style=3D"color: blue; = text-decoration: underline; ">OAuth@ietf.org</a><br><a = href=3D"https://www.ietf.org/mailman/listinfo/oauth" style=3D"color: = blue; text-decoration: underline; = ">https://www.ietf.org/mailman/listinfo/oauth</a><o:p></o:p></span></div><= /div></div><div style=3D"margin-top: 0in; margin-right: 0in; = margin-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; font-family: = 'Times New Roman', serif; = "><o:p> </o:p></div></div></div></div><span><ATT00001..txt></sp= an></div></span></blockquote></div><br></div></div></div></blockquote></di= v><br></div></body></html>= --Apple-Mail-100-975533230-- From James.H.Manger@team.telstra.com Mon Jun 28 21:38:01 2010 Return-Path: <James.H.Manger@team.telstra.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7E0E3A67D7 for <oauth@core3.amsl.com>; Mon, 28 Jun 2010 21:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.173 X-Spam-Level: X-Spam-Status: No, score=0.173 tagged_above=-999 required=5 tests=[AWL=1.073, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QcUOQFCiL5Nw for <oauth@core3.amsl.com>; Mon, 28 Jun 2010 21:37:53 -0700 (PDT) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by core3.amsl.com (Postfix) with ESMTP id B3FFD3A67A5 for <oauth@ietf.org>; Mon, 28 Jun 2010 21:37:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,502,1272808800"; d="scan'208,217";a="5204611" Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipoavi.tcif.telstra.com.au with ESMTP; 29 Jun 2010 14:37:58 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6027"; a="3769138" Received: from wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) by ipccvi.tcif.telstra.com.au with ESMTP; 29 Jun 2010 14:38:00 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) with mapi; Tue, 29 Jun 2010 14:37:59 +1000 From: "Manger, James H" <James.H.Manger@team.telstra.com> To: Yaron Goland <yarong@microsoft.com>, "oauth@ietf.org" <oauth@ietf.org> Date: Tue, 29 Jun 2010 14:37:57 +1000 Thread-Topic: Proposal for text for section 2 Thread-Index: AcsUm7O3+LYTofkOQ6CsKuFeuynp2ACcJnPgAAxyEYA= Message-ID: <255B9BB34FB7D647A506DC292726F6E11265A5FC9D@WSMSG3153V.srv.dir.telstra.com> References: <7C01E631FF4B654FA1E783F1C0265F8C579CC0C3@TK5EX14MBXC117.redmond.corp.microsoft.com> <7C01E631FF4B654FA1E783F1C0265F8C579D0F31@TK5EX14MBXC117.redmond.corp.microsoft.com> In-Reply-To: <7C01E631FF4B654FA1E783F1C0265F8C579D0F31@TK5EX14MBXC117.redmond.corp.microsoft.com> 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: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E11265A5FC9DWSMSG3153Vsrv_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Proposal for text for section 2 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 29 Jun 2010 04:38:02 -0000 --_000_255B9BB34FB7D647A506DC292726F6E11265A5FC9DWSMSG3153Vsrv_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yaron, "Assertion Client Credentials" is too much of a hack. It only works for POS= Ts, and only when the body is form-encoded. It could not be used, for instance, to delete a token with an HTTP DELETE r= equest to a token URI. Though that specific idea has not been accepted yet,= it is a reasonable possibility. We shouldn't introduce a client authentica= tion mechanisms incapable of working with such ideas. The 1st and 2nd proposed paragraphs are not specific to OAuth at all. The 3= rd paragraph mentions authorization codes and refresh tokens, but the clien= t assertion is independent of those. I would prefer to see a standalone des= cription of how to authenticate any HTTP request with a client SAML asserti= on - then that could apply to the OAuth2 token management API, just as easi= ly as it applies to any other API, and just as easily as any client auth me= chanism works with OAuth2. For instance, why not define a SAML HTTP authentication mechanism: Authorization: SAML a=3D<base64url-encoded SAML assertion> It is obvious how it can be used to authenticate/authorize client requests = to an OAuth2 token endpoint. It works with GET, HEAD, POST, PUT, DELETE.... It works with XML, JSON, form-encoded... messages. You don't need special rules about avoiding duplicate authentication mechan= isms. There is a standard way to do discovery: return WWW-Authenticate: SAML real= m=3D"Token Management". Finally, the proposal keeps client_id as a separate parameter. However, I g= uess that a SAML assertion would often include a client id inside the asser= tion. This means we have two client ids. At best it is slightly inefficient= ; it introduces more code paths (eg if they mismatch); at worst it causes s= ecurity bugs when the "wrong" client id is used at different points in syst= ems. -- James Manger From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Y= aron Goland Sent: Tuesday, 29 June 2010 7:56 AM To: Eran Hammer-Lahav; oauth@ietf.org Subject: Re: [OAUTH-WG] Proposal for text for section 2 The following is proposed language for a new section, 2.2, in the spec. Thi= s is part of the spec that deals with client authentication. This proposal = is completely orthogonal to anything in section 4 such as grant types. At E= ran's suggestion I added in an example into the text to help readers unders= tand both what the feature is for and how it is used. Eran also suggested that we should probably introduce a client_cred_type pa= rameter (since we are explicitly support multiple types of client parameter= s) just to be consistent with grant_type. I don't have strong feelings on t= he subject and am happy to go with whatever the group wants. Thoughts? Thanks, Yaron 2.2 Assertion Client Credentials In scenarios where security is at a premium one wants to avoid sending secr= ets across the Internet, even on encrypted connections. Instead one wants t= o send values derived from the secret that prove to the receiver that the s= ender is in possession of the secret without actually sending the secret. T= ypically the way derived values are created is by generating an assertion t= hat is then either HMAC'd or digitally signed using an agreed upon secret. = By validating the HMAC or digital signature on the assertion the receiver o= f the assertion can prove to themselves that the entity that generated the = assertion was in possession of the secret without actually communicating th= e secret directly. So, for example, a client can establish a secret using an out of band mecha= nism with a resource server. As part of this out of band communication the = client and resource server agree that the client will authenticate itself u= sing a SAML assertion with agreed upon parameters that will be signed by th= e provisioned secret. Later on the client interacts with an end-user and uses the end-user author= ization process with the resource server to get an authorization code. The = client then sends an access token request to the token endpoint for the res= ource server and includes, along with the authorization code, a SAML assert= ion it signed with the previously agreed key and parameters. The SAML asser= tion proves to the token endpoint the identity of the client and the author= ization code provides the link to the end-user authorization. If the access= token request comes back with a refresh token then in the future the clien= t can get new access tokens by submitting an access token request containin= g both a properly signed and formatted SAML assertion as well as the refres= h token. The following defines how to send an assertion as client credentials. If th= e assertion client credentials are used then the client MUST include the cr= edentials using the following request parameters: client_id REQUIRED. The client identifier. client_assertion_type REQUIRED. The format of the assertion as defined by the aut= horization server. The value MUST be an absolute URI. client_assertion REQUIRED. The client assertion. For example (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=3Drefresh_token&client_id=3Ds6BhdRkqt3& client_assertion=3DPHNhbWxwOl...[omitted for brevity]...ZT4= %3D& client_assertion_type=3Durn%3Aoasis%3Anames%sAtc%3ASAML%3A2= .0%3Aassertion& refresh_token=3Dn4E90119d The client MUST NOT include the client credentials using more than one mech= anism. If more than one mechanism is used regardless whether the credential= s are identical or valid, the server MUST reply with an HTTP 400 status cod= e (Bad Request) and include the "multiple_credentials" error code. Token endpoints can differentiate between client assertion credentials and = other client credential types by looking for the presence of the client_ass= ertion and client_assertion_type attributes which will only be present with= client assertion credentials. --_000_255B9BB34FB7D647A506DC292726F6E11265A5FC9DWSMSG3153Vsrv_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m= icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office= :access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"= uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof= t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co= m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee= t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns= :odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro= soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" = xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc=3D"http://m= icrosoft.com/officenet/conferencing" xmlns:D=3D"DAV:" xmlns:Repl=3D"http://= schemas.microsoft.com/repl/" xmlns:mt=3D"http://schemas.microsoft.com/share= point/soap/meetings/" xmlns:x2=3D"http://schemas.microsoft.com/office/excel= /2003/xml" xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" xmlns:ois= =3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://= schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3= .org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint= /dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http= ://www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sha= repoint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#"= xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://= schemas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001= /XMLSchema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/so= ap" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udc= p2p=3D"http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http:/= /schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://sche= mas.microsoft.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.mi= crosoft.com/office/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformat= s.org/package/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlf= ormats.org/markup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.c= om/office/2004/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/pa= ckage/2006/relationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/web= partpages" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/20= 06/types" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/200= 6/messages" xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/Sli= deLibrary/" xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortal= Server/PublishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:= st=3D"" xmlns=3D"http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)"> <style> <!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0cm; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} pre {mso-style-priority:99; mso-style-link:"HTML Preformatted Char"; margin:0cm; margin-bottom:.0001pt; font-size:10.0pt; font-family:"Courier New";} p.MsoAcetate, li.MsoAcetate, div.MsoAcetate {mso-style-priority:99; mso-style-link:"Balloon Text Char"; margin:0cm; margin-bottom:.0001pt; font-size:8.0pt; font-family:"Tahoma","sans-serif";} span.HTMLPreformattedChar {mso-style-name:"HTML Preformatted Char"; mso-style-priority:99; mso-style-link:"HTML Preformatted"; font-family:"Courier New";} span.BalloonTextChar {mso-style-name:"Balloon Text Char"; mso-style-priority:99; mso-style-link:"Balloon Text"; font-family:"Tahoma","sans-serif";} span.EmailStyle21 {mso-style-type:personal; font-family:"Calibri","sans-serif"; color:windowtext;} span.EmailStyle22 {mso-style-type:personal; font-family:"Calibri","sans-serif"; color:#1F497D;} span.EmailStyle23 {mso-style-type:personal; font-family:"Calibri","sans-serif"; color:#1F497D;} span.grey {mso-style-name:grey;} span.EmailStyle25 {mso-style-type:personal; font-family:"Calibri","sans-serif"; color:#1F497D;} span.EmailStyle26 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page Section1 {size:612.0pt 792.0pt; margin:72.0pt 72.0pt 72.0pt 72.0pt;} div.Section1 {page:Section1;} --> </style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3D"EN-AU" link=3D"blue" vlink=3D"purple"> <div class=3D"Section1"> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">Yaron,<o:p></o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">“Assertion Clien= t Credentials” is too much of a hack. It only works for POSTs, and on= ly when the body is form-encoded.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">It could not be used, = for instance, to delete a token with an HTTP DELETE request to a token URI.= Though that specific idea has not been accepted yet, it is a reasonable po= ssibility. We shouldn’t introduce a client authentication mechanisms incapable of working with such ideas.<o:p= ></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">The 1<sup>st</sup> and= 2<sup>nd</sup> proposed paragraphs are not specific to OAuth at all. The 3= <sup>rd</sup> paragraph mentions authorization codes and refresh tokens, bu= t the client assertion is independent of those. I would prefer to see a standalone description of how to authent= icate any HTTP request with a client SAML assertion — then that could= apply to the OAuth2 token management API, just as easily as it applies to = any other API, and just as easily as any client auth mechanism works with OAuth2.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">For instance, why not = define a SAML HTTP authentication mechanism:<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">   Authoriza= tion: SAML a=3D<base64url-encoded SAML assertion><o:p></o:p></span></= p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">It is obvious how it c= an be used to authenticate/authorize client requests to an OAuth2 token end= point.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">It works with GET, HEA= D, POST, PUT, DELETE….<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">It works with XML, JSO= N, form-encoded… messages.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">You don’t need s= pecial rules about avoiding duplicate authentication mechanisms.<o:p></o:p>= </span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">There is a standard wa= y to do discovery: return WWW-Authenticate: SAML realm=3D”Token Manag= ement”.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">Finally, the proposal = keeps client_id as a separate parameter. However, I guess that a SAML asser= tion would often include a client id inside the assertion. This means we ha= ve two client ids. At best it is slightly inefficient; it introduces more code paths (eg if they mismatch); at worst= it causes security bugs when the “wrong” client id is used at = different points in systems.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <div> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">-- <o:p></o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">James Manger<o:p></o:p= ></span></p> </div> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm = 0cm 0cm"> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><b><span lang=3D"EN-US"= style=3D"font-size:10.0pt;font-family:"Tahoma","sans-serif&= quot;">From:</span></b><span lang=3D"EN-US" style=3D"font-size:10.0pt;font-= family:"Tahoma","sans-serif""> oauth-bounces@ietf.org [= mailto:oauth-bounces@ietf.org] <b>On Behalf Of </b>Yaron Goland<br> <b>Sent:</b> Tuesday, 29 June 2010 7:56 AM<br> <b>To:</b> Eran Hammer-Lahav; oauth@ietf.org<br> <b>Subject:</b> Re: [OAUTH-WG] Proposal for text for section 2<o:p></o:p></= span></p> </div> </div> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><o:p> </o:p></p> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span lang=3D"EN-US" st= yle=3D"color:#1F497D">The following is proposed language for a new section,= 2.2, in the spec. This is part of the spec that deals with client authenti= cation. This proposal is completely orthogonal to anything in section 4 such as grant types. At Eran’s suggestion I= added in an example into the text to help readers understand both what the= feature is for and how it is used. <o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span lang=3D"EN-US" st= yle=3D"color:#1F497D"><o:p> </o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span lang=3D"EN-US" st= yle=3D"color:#1F497D">Eran also suggested that we should probably introduce= a client_cred_type parameter (since we are explicitly support multiple typ= es of client parameters) just to be consistent with grant_type. I don’t have strong feelings on the subject and am = happy to go with whatever the group wants.<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span lang=3D"EN-US" st= yle=3D"color:#1F497D"><o:p> </o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span lang=3D"EN-US" st= yle=3D"color:#1F497D">         = ;       Thoughts?<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span lang=3D"EN-US" st= yle=3D"color:#1F497D"><o:p> </o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span lang=3D"EN-US" st= yle=3D"color:#1F497D">         = ;            &n= bsp;          Thanks,<o:p></o:= p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span lang=3D"EN-US" st= yle=3D"color:#1F497D"><o:p> </o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span lang=3D"EN-US" st= yle=3D"color:#1F497D">         = ;            &n= bsp;            = ;            &n= bsp; Yaron<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span lang=3D"EN-US" st= yle=3D"color:#1F497D"><o:p> </o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span lang=3D"EN-US" st= yle=3D"color:#1F497D">2.2 Assertion Client Credentials<o:p></o:p></span></p= > <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span lang=3D"EN-US" st= yle=3D"color:#1F497D"><o:p> </o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span lang=3D"EN-US" st= yle=3D"color:#1F497D">In scenarios where security is at a premium one wants= to avoid sending secrets across the Internet, even on encrypted connection= s. Instead one wants to send values derived from the secret that prove to the receiver that the sender is in possessio= n of the secret without actually sending the secret. Typically the way deri= ved values are created is by generating an assertion that is then either HM= AC’d or digitally signed using an agreed upon secret. By validating the HMAC or digital signature on the ass= ertion the receiver of the assertion can prove to themselves that the entit= y that generated the assertion was in possession of the secret without actu= ally communicating the secret directly.<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span lang=3D"EN-US" st= yle=3D"color:#1F497D"><o:p> </o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span lang=3D"EN-US" st= yle=3D"color:#1F497D">So, for example, a client can establish a secret usin= g an out of band mechanism with a resource server. As part of this out of b= and communication the client and resource server agree that the client will authenticate itself using a SAML asserti= on with agreed upon parameters that will be signed by the provisioned secre= t. <o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span lang=3D"EN-US" st= yle=3D"color:#1F497D"><o:p> </o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span lang=3D"EN-US" st= yle=3D"color:#1F497D">Later on the client interacts with an end-user and us= es the end-user authorization process with the resource server to get an au= thorization code. The client then sends an access token request to the token endpoint for the resource server and = includes, along with the authorization code, a SAML assertion it signed wit= h the previously agreed key and parameters. The SAML assertion proves to th= e token endpoint the identity of the client and the authorization code provides the link to the end-user au= thorization. If the access token request comes back with a refresh token th= en in the future the client can get new access tokens by submitting an acce= ss token request containing both a properly signed and formatted SAML assertion as well as the refresh toke= n. <o:p> </o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span lang=3D"EN-US" st= yle=3D"color:#1F497D"><o:p> </o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span lang=3D"EN-US" st= yle=3D"color:#1F497D">The following defines how to send an assertion as cli= ent credentials. If the assertion client credentials are used then the clie= nt MUST include the credentials using the following request parameters:<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span lang=3D"EN-US" st= yle=3D"color:#1F497D"><o:p> </o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span lang=3D"EN-US" st= yle=3D"color:#1F497D">client_id<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span lang=3D"EN-US" st= yle=3D"color:#1F497D">         = ;       REQUIRED. The client identifier.<o:p>= </o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span lang=3D"EN-US" st= yle=3D"color:#1F497D">client_assertion_type<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span lang=3D"EN-US" st= yle=3D"color:#1F497D">         = ;       REQUIRED. The format of the assertion= as defined by the authorization server.  The value MUST be an absolut= e URI.<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span lang=3D"EN-US" st= yle=3D"color:#1F497D">client_assertion<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span lang=3D"EN-US" st= yle=3D"color:#1F497D">         = ;       REQUIRED. The client assertion.<o:p><= /o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span lang=3D"EN-US" st= yle=3D"color:#1F497D"><o:p> </o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span lang=3D"EN-US" st= yle=3D"color:#1F497D">For example (line breaks are for display purposes onl= y):<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span lang=3D"EN-US" st= yle=3D"color:#1F497D"><o:p> </o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span lang=3D"EN-US" st= yle=3D"color:#1F497D">         = ;       POST /token HTTP/1.1<o:p></o:p></span= ></p> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span lang=3D"EN-US" st= yle=3D"color:#1F497D">         = ;       Host: server.example.com<o:p></o:p></= span></p> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span lang=3D"EN-US" st= yle=3D"color:#1F497D">         = ;       Content-Type: application/x-www-form-= urlencoded<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span lang=3D"EN-US" st= yle=3D"color:#1F497D"><o:p> </o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span lang=3D"EN-US" st= yle=3D"color:#1F497D">         = ;       grant_type=3Drefresh_token&client= _id=3Ds6BhdRkqt3&<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span lang=3D"EN-US" st= yle=3D"color:#1F497D">         = ;       client_assertion=3DPHNhbWxwOl...[omit= ted for brevity]...ZT4%3D&<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span lang=3D"EN-US" st= yle=3D"color:#1F497D">         = ;       client_assertion_type=3Durn%3Aoasis%3= Anames%sAtc%3ASAML%3A2.0%3Aassertion&<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span lang=3D"EN-US" st= yle=3D"color:#1F497D">         = ;       refresh_token=3Dn4E90119d<o:p></o:p><= /span></p> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span lang=3D"EN-US" st= yle=3D"color:#1F497D"><o:p> </o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span lang=3D"EN-US" st= yle=3D"color:#1F497D">The client MUST NOT include the client credentials us= ing more than one mechanism. If more than one mechanism is used regardless = whether the credentials are identical or valid, the server MUST reply with an HTTP 400 status code (Bad Request) an= d include the “multiple_credentials” error code.<o:p></o:p></sp= an></p> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span lang=3D"EN-US" st= yle=3D"color:#1F497D"><o:p> </o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:36.0pt"><span lang=3D"EN-US" st= yle=3D"color:#1F497D">Token endpoints can differentiate between client asse= rtion credentials and other client credential types by looking for the pres= ence of the client_assertion and client_assertion_type attributes which will only be present with client assertion credentials.<o= :p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"color:#1F497D"><o:p>&n= bsp;</o:p></span></p> </div> </body> </html> --_000_255B9BB34FB7D647A506DC292726F6E11265A5FC9DWSMSG3153Vsrv_-- From root@core3.amsl.com Mon Jun 28 23:45:02 2010 Return-Path: <root@core3.amsl.com> X-Original-To: oauth@ietf.org Delivered-To: oauth@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 694B83A67F7; Mon, 28 Jun 2010 23:45:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100629064502.694B83A67F7@core3.amsl.com> Date: Mon, 28 Jun 2010 23:45:02 -0700 (PDT) Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-09.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 29 Jun 2010 06:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Authentication Protocol Working Group of the IETF. Title : The OAuth 2.0 Protocol Author(s) : E. Hammer-Lahav, et al. Filename : draft-ietf-oauth-v2-09.txt Pages : 42 Date : 2010-06-28 This specification describes the OAuth 2.0 protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-oauth-v2-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-06-28234157.I-D@ietf.org> --NextPart-- From eran@hueniverse.com Mon Jun 28 23:55:48 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A67F13A6966 for <oauth@core3.amsl.com>; Mon, 28 Jun 2010 23:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.949 X-Spam-Level: X-Spam-Status: No, score=-0.949 tagged_above=-999 required=5 tests=[AWL=-0.951, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F9DPCUjrfrVF for <oauth@core3.amsl.com>; Mon, 28 Jun 2010 23:55:47 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id B820F3A68B2 for <oauth@ietf.org>; Mon, 28 Jun 2010 23:55:47 -0700 (PDT) Received: (qmail 12698 invoked from network); 29 Jun 2010 06:55:57 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 29 Jun 2010 06:55:57 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 28 Jun 2010 23:55:58 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org> Date: Mon, 28 Jun 2010 23:56:00 -0700 Thread-Topic: Draft -09 Thread-Index: AcsXVmRrsO6Hfs/LQgKeY82EBJQ0Kw== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4BCCC@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_90C41DD21FB7C64BB94121FBBC2E72343B3ED4BCCCP3PW5EX1MB01E_" MIME-Version: 1.0 Subject: [OAUTH-WG] Draft -09 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 29 Jun 2010 06:55:48 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3ED4BCCCP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Draft -09 is now posted. Main changes include: o Fixed typos, editorial changes. Thanks to Dick for his useful feedback. o Added token expiration example. o Added scope parameter to end-user authorization endpoint response and WW= W-Authenticate header. o Added note about parameters with empty values (same as omitted). o Changed parameter values to use '-' instead of '_'. Parameter names sti= ll use '_'. o Changed authorization endpoint client type to response type with values:= code, token, or both. o Complete cleanup of error codes. Added support for error description an= d URI. o Add initial extensibility support. Draft -09 represents what I consider to be the first feature complete propo= sal. While it still needs much work, it has notes for open issues and missi= ng parts. I plan to give people 2 weeks to review and provide extensive fee= dback, and will post one more draft before the 7/12 cutoff date for the mee= ting. My goal is to collect enough feedback to declare the next draft (-10) stabl= e for wider implementation. If you were waiting for a stable draft to study= and provide extensive feedback, this is the draft! When giving feedback pr= etend this is your last chance to making a significant contribution or chan= ges to the core specification. Please submit feedback by 7/9. When submitting feedback please start a new thread for each item. Editorial= commentary can be collected in one post (and please send to the list, even= if it is minor, because I tend to get the same typo correction many times)= . Thanks, EHL --_000_90C41DD21FB7C64BB94121FBBC2E72343B3ED4BCCCP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"><head><meta http-equiv=3DContent-Type content= =3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros= oft Word 14 (filtered medium)"><style><!-- /* Font Definitions */ @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Consolas; panose-1:2 11 6 9 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {mso-style-priority:34; margin-top:0in; margin-right:0in; margin-bottom:0in; margin-left:.5in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} span.EmailStyle17 {mso-style-type:personal-compose; font-family:"Calibri","sans-serif"; color:windowtext;} .MsoChpDefault {mso-style-type:export-only; font-family:"Calibri","sans-serif";} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue vli= nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal>Draft -09 is now= posted. Main changes include:<o:p></o:p></p><p class=3DMsoNormal><o:p>&nbs= p;</o:p></p><p class=3DMsoNormal style=3D'text-autospace:none'><span style= =3D'font-size:9.5pt;font-family:Consolas'> o  Fixed typos, editorial c= hanges. Thanks to Dick for his useful feedback.<o:p></o:p></span></p><p cla= ss=3DMsoNormal style=3D'text-autospace:none'><span style=3D'font-size:9.5pt= ;font-family:Consolas'> o  Added token expiration example.<o:p></o:p><= /span></p><p class=3DMsoNormal style=3D'text-autospace:none'><span style=3D= 'font-size:9.5pt;font-family:Consolas'> o  Added scope parameter to en= d-user authorization endpoint response and WWW-Authenticate header.<o:p></o= :p></span></p><p class=3DMsoNormal style=3D'text-autospace:none'><span styl= e=3D'font-size:9.5pt;font-family:Consolas'> o  Added note about parame= ters with empty values (same as omitted).<o:p></o:p></span></p><p class=3DM= soNormal style=3D'text-autospace:none'><span style=3D'font-size:9.5pt;font-= family:Consolas'> o  Changed parameter values to use '-' instead of '_= '.  Parameter names still use '_'.<o:p></o:p></span></p><p class=3DMso= Normal style=3D'text-autospace:none'><span style=3D'font-size:9.5pt;font-fa= mily:Consolas'> o  Changed authorization endpoint client type to respo= nse type with values: code, token, or both.<o:p></o:p></span></p><p class= =3DMsoNormal style=3D'text-autospace:none'><span style=3D'font-size:9.5pt;f= ont-family:Consolas'> o  Complete cleanup of error codes.  Added = support for error description and URI.<o:p></o:p></span></p><p class=3DMsoN= ormal style=3D'text-autospace:none'><span style=3D'font-size:9.5pt;font-fam= ily:Consolas'> o  Add initial extensibility support.<o:p></o:p></span>= </p><p class=3DMsoNormal style=3D'text-autospace:none'><span style=3D'font-= size:9.5pt;font-family:Consolas'><o:p> </o:p></span></p><p class=3DMso= Normal style=3D'text-autospace:none'><span style=3D'font-size:9.5pt;font-fa= mily:Consolas'>Draft -09 represents what I consider to be the first feature= complete proposal. While it still needs much work, it has notes for open i= ssues and missing parts. I plan to give people 2 weeks to review and provid= e extensive feedback, and will post one more draft before the 7/12 cutoff d= ate for the meeting.<o:p></o:p></span></p><p class=3DMsoNormal style=3D'tex= t-autospace:none'><span style=3D'font-size:9.5pt;font-family:Consolas'><o:p= > </o:p></span></p><p class=3DMsoNormal style=3D'text-autospace:none'>= <span style=3D'font-size:9.5pt;font-family:Consolas'>My goal is to collect = enough feedback to declare the next draft (-10) stable for wider implementa= tion. If you were waiting for a stable draft to study and provide extensive= feedback, this is the draft! When giving feedback pretend this is your las= t chance to making a significant contribution or changes to the core specif= ication.<o:p></o:p></span></p><p class=3DMsoNormal style=3D'text-autospace:= none'><span style=3D'font-size:9.5pt;font-family:Consolas'><o:p> </o:p= ></span></p><p class=3DMsoNormal style=3D'text-autospace:none'><span style= =3D'font-size:9.5pt;font-family:Consolas'>Please submit feedback by 7/9.<o:= p></o:p></span></p><p class=3DMsoNormal style=3D'text-autospace:none'><span= style=3D'font-size:9.5pt;font-family:Consolas'><o:p> </o:p></span></p= ><p class=3DMsoNormal style=3D'text-autospace:none'><span style=3D'font-siz= e:9.5pt;font-family:Consolas'>When submitting feedback please start a new t= hread for each item. Editorial commentary can be collected in one post (and= please send to the list, even if it is minor, because I tend to get the sa= me typo correction many times).<o:p></o:p></span></p><p class=3DMsoNormal s= tyle=3D'text-autospace:none'><span style=3D'font-size:9.5pt;font-family:Con= solas'><o:p> </o:p></span></p><p class=3DMsoNormal style=3D'text-autos= pace:none'><span style=3D'font-size:9.5pt;font-family:Consolas'>Thanks,<o:p= ></o:p></span></p><p class=3DMsoNormal style=3D'text-autospace:none'><span = style=3D'font-size:9.5pt;font-family:Consolas'><o:p> </o:p></span></p>= <p class=3DMsoNormal style=3D'text-autospace:none'><span style=3D'font-size= :9.5pt;font-family:Consolas'>EHL<o:p></o:p></span></p><p class=3DMsoNormal = style=3D'text-autospace:none'><span style=3D'font-size:9.5pt;font-family:Co= nsolas'><o:p> </o:p></span></p><p class=3DMsoNormal><o:p> </o:p><= /p></div></body></html>= --_000_90C41DD21FB7C64BB94121FBBC2E72343B3ED4BCCCP3PW5EX1MB01E_-- From eran@hueniverse.com Tue Jun 29 00:10:59 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CC2A3A63EC for <oauth@core3.amsl.com>; Tue, 29 Jun 2010 00:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.496 X-Spam-Level: X-Spam-Status: No, score=-1.496 tagged_above=-999 required=5 tests=[AWL=-0.387, BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DA47p2Od1kvw for <oauth@core3.amsl.com>; Tue, 29 Jun 2010 00:10:53 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id B253E3A68B2 for <oauth@ietf.org>; Tue, 29 Jun 2010 00:10:51 -0700 (PDT) Received: (qmail 14866 invoked from network); 29 Jun 2010 07:11:00 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 29 Jun 2010 07:11:00 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 29 Jun 2010 00:10:59 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org> Date: Tue, 29 Jun 2010 00:11:03 -0700 Thread-Topic: Draft -09 Thread-Index: AcsXVmRrsO6Hfs/LQgKeY82EBJQ0KwAA86rw Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4BCCE@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4BCCC@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4BCCC@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_90C41DD21FB7C64BB94121FBBC2E72343B3ED4BCCEP3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Draft -09 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 29 Jun 2010 07:10:59 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3ED4BCCEP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable For editorial feedback, I am going to try something new and use SharedCopy.= com (no install required). Try it out at: http://r6.sharedcopy.com/6bnqq8v If this doesn't work, I'll let people know and cancel it. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Monday, June 28, 2010 11:56 PM To: OAuth WG (oauth@ietf.org) Subject: [OAUTH-WG] Draft -09 Draft -09 is now posted. Main changes include: o Fixed typos, editorial changes. Thanks to Dick for his useful feedback. o Added token expiration example. o Added scope parameter to end-user authorization endpoint response and WW= W-Authenticate header. o Added note about parameters with empty values (same as omitted). o Changed parameter values to use '-' instead of '_'. Parameter names sti= ll use '_'. o Changed authorization endpoint client type to response type with values:= code, token, or both. o Complete cleanup of error codes. Added support for error description an= d URI. o Add initial extensibility support. Draft -09 represents what I consider to be the first feature complete propo= sal. While it still needs much work, it has notes for open issues and missi= ng parts. I plan to give people 2 weeks to review and provide extensive fee= dback, and will post one more draft before the 7/12 cutoff date for the mee= ting. My goal is to collect enough feedback to declare the next draft (-10) stabl= e for wider implementation. If you were waiting for a stable draft to study= and provide extensive feedback, this is the draft! When giving feedback pr= etend this is your last chance to making a significant contribution or chan= ges to the core specification. Please submit feedback by 7/9. When submitting feedback please start a new thread for each item. Editorial= commentary can be collected in one post (and please send to the list, even= if it is minor, because I tend to get the same typo correction many times)= . Thanks, EHL --_000_90C41DD21FB7C64BB94121FBBC2E72343B3ED4BCCEP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV=3D"Content-Type" CONTENT= =3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros= oft Word 14 (filtered medium)"><style><!-- /* Font Definitions */ @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} @font-face {font-family:Consolas; panose-1:2 11 6 9 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {mso-style-priority:34; margin-top:0in; margin-right:0in; margin-bottom:0in; margin-left:.5in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} span.EmailStyle18 {mso-style-type:personal; font-family:"Calibri","sans-serif"; color:windowtext;} span.EmailStyle19 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue vli= nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><span style=3D'c= olor:#1F497D'>For editorial feedback, I am going to try something new and u= se SharedCopy.com (no install required).<o:p></o:p></span></p><p class=3DMs= oNormal><span style=3D'color:#1F497D'><o:p> </o:p></span></p><p class= =3DMsoNormal><span style=3D'color:#1F497D'>Try it out at: <a href=3D"http:/= /r6.sharedcopy.com/6bnqq8v">http://r6.sharedcopy.com/6bnqq8v</a><o:p></o:p>= </span></p><p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p> </= o:p></span></p><p class=3DMsoNormal><span style=3D'color:#1F497D'>If this d= oesn’t work, I’ll let people know and cancel it.<o:p></o:p></sp= an></p><p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p> </o:p>= </span></p><p class=3DMsoNormal><span style=3D'color:#1F497D'>EHL<o:p></o:p= ></span></p><p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p> <= /o:p></span></p><p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nb= sp;</o:p></span></p><div style=3D'border:none;border-left:solid blue 1.5pt;= padding:0in 0in 0in 4.0pt'><div><div style=3D'border:none;border-top:solid = #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=3DMsoNormal><b><span styl= e=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><s= pan style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> oauth-bou= nces@ietf.org [mailto:oauth-bounces@ietf.org] <b>On Behalf Of </b>Eran Hamm= er-Lahav<br><b>Sent:</b> Monday, June 28, 2010 11:56 PM<br><b>To:</b> OAuth= WG (oauth@ietf.org)<br><b>Subject:</b> [OAUTH-WG] Draft -09<o:p></o:p></sp= an></p></div></div><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMso= Normal>Draft -09 is now posted. Main changes include:<o:p></o:p></p><p clas= s=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal style=3D'text-autos= pace:none'><span style=3D'font-size:9.5pt;font-family:Consolas'>o  Fix= ed typos, editorial changes. Thanks to Dick for his useful feedback.<o:p></= o:p></span></p><p class=3DMsoNormal style=3D'text-autospace:none'><span sty= le=3D'font-size:9.5pt;font-family:Consolas'>o  Added token expiration = example.<o:p></o:p></span></p><p class=3DMsoNormal style=3D'text-autospace:= none'><span style=3D'font-size:9.5pt;font-family:Consolas'>o  Added sc= ope parameter to end-user authorization endpoint response and WWW-Authentic= ate header.<o:p></o:p></span></p><p class=3DMsoNormal style=3D'text-autospa= ce:none'><span style=3D'font-size:9.5pt;font-family:Consolas'>o  Added= note about parameters with empty values (same as omitted).<o:p></o:p></spa= n></p><p class=3DMsoNormal style=3D'text-autospace:none'><span style=3D'fon= t-size:9.5pt;font-family:Consolas'>o  Changed parameter values to use = '-' instead of '_'.  Parameter names still use '_'.<o:p></o:p></span><= /p><p class=3DMsoNormal style=3D'text-autospace:none'><span style=3D'font-s= ize:9.5pt;font-family:Consolas'>o  Changed authorization endpoint clie= nt type to response type with values: code, token, or both.<o:p></o:p></spa= n></p><p class=3DMsoNormal style=3D'text-autospace:none'><span style=3D'fon= t-size:9.5pt;font-family:Consolas'>o  Complete cleanup of error codes.=   Added support for error description and URI.<o:p></o:p></span></p><p= class=3DMsoNormal style=3D'text-autospace:none'><span style=3D'font-size:9= .5pt;font-family:Consolas'>o  Add initial extensibility support.<o:p><= /o:p></span></p><p class=3DMsoNormal style=3D'text-autospace:none'><span st= yle=3D'font-size:9.5pt;font-family:Consolas'><o:p> </o:p></span></p><p= class=3DMsoNormal style=3D'text-autospace:none'><span style=3D'font-size:9= .5pt;font-family:Consolas'>Draft -09 represents what I consider to be the f= irst feature complete proposal. While it still needs much work, it has note= s for open issues and missing parts. I plan to give people 2 weeks to revie= w and provide extensive feedback, and will post one more draft before the 7= /12 cutoff date for the meeting.<o:p></o:p></span></p><p class=3DMsoNormal = style=3D'text-autospace:none'><span style=3D'font-size:9.5pt;font-family:Co= nsolas'><o:p> </o:p></span></p><p class=3DMsoNormal style=3D'text-auto= space:none'><span style=3D'font-size:9.5pt;font-family:Consolas'>My goal is= to collect enough feedback to declare the next draft (-10) stable for wide= r implementation. If you were waiting for a stable draft to study and provi= de extensive feedback, this is the draft! When giving feedback pretend this= is your last chance to making a significant contribution or changes to the= core specification.<o:p></o:p></span></p><p class=3DMsoNormal style=3D'tex= t-autospace:none'><span style=3D'font-size:9.5pt;font-family:Consolas'><o:p= > </o:p></span></p><p class=3DMsoNormal style=3D'text-autospace:none'>= <span style=3D'font-size:9.5pt;font-family:Consolas'>Please submit feedback= by 7/9.<o:p></o:p></span></p><p class=3DMsoNormal style=3D'text-autospace:= none'><span style=3D'font-size:9.5pt;font-family:Consolas'><o:p> </o:p= ></span></p><p class=3DMsoNormal style=3D'text-autospace:none'><span style= =3D'font-size:9.5pt;font-family:Consolas'>When submitting feedback please s= tart a new thread for each item. Editorial commentary can be collected in o= ne post (and please send to the list, even if it is minor, because I tend t= o get the same typo correction many times).<o:p></o:p></span></p><p class= =3DMsoNormal style=3D'text-autospace:none'><span style=3D'font-size:9.5pt;f= ont-family:Consolas'><o:p> </o:p></span></p><p class=3DMsoNormal style= =3D'text-autospace:none'><span style=3D'font-size:9.5pt;font-family:Consola= s'>Thanks,<o:p></o:p></span></p><p class=3DMsoNormal style=3D'text-autospac= e:none'><span style=3D'font-size:9.5pt;font-family:Consolas'><o:p> </o= :p></span></p><p class=3DMsoNormal style=3D'text-autospace:none'><span styl= e=3D'font-size:9.5pt;font-family:Consolas'>EHL<o:p></o:p></span></p><p clas= s=3DMsoNormal style=3D'text-autospace:none'><span style=3D'font-size:9.5pt;= font-family:Consolas'><o:p> </o:p></span></p><p class=3DMsoNormal><o:p= > </o:p></p></div></div></body></html>= --_000_90C41DD21FB7C64BB94121FBBC2E72343B3ED4BCCEP3PW5EX1MB01E_-- From pelleb@gmail.com Tue Jun 29 07:42:26 2010 Return-Path: <pelleb@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55CEF3A6850 for <oauth@core3.amsl.com>; Tue, 29 Jun 2010 07:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.488 X-Spam-Level: X-Spam-Status: No, score=-0.488 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1oCilDdrdfQH for <oauth@core3.amsl.com>; Tue, 29 Jun 2010 07:42:25 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id AD7BB3A6972 for <oauth@ietf.org>; Tue, 29 Jun 2010 07:42:24 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id d26so165022eyd.51 for <oauth@ietf.org>; Tue, 29 Jun 2010 07:42:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=qoMt3m/Bc5rD8QlhIzXCxJHpoTqmV51kxq+pW/0G4TI=; b=iSbfCuhFBQUvZDNDCchy5VzVUY+sR8rMJbs43wNrIipEH1Cx1LV9f5FnUw+vXUrSy1 OVC+QK+C6ZktcQp000C3LXz5PV11teG8X/1XtAXoHK1EvliyUwy4T0MeZU2FIUYMCRsS X1QSnLRVv7Yw9i2A0TDKPHi9LuGYL0Nfd1seY= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=CAWU/Vu1mngYF4M/0lj3V0ZnDHZbLelZocMK9VJOSH3CixXDnyiNFLP9txtcNQHr27 yksLqd6BXKtsjS/se0PEwuqfEufSGb1W1HdekYH9hwSm9wveaxVvNJ68EgyLeQIacu+A lQVMxCIo9eAFhNx6oaxZQl7uDe/z6CnYcZOyw= MIME-Version: 1.0 Received: by 10.102.129.14 with SMTP id b14mr1929949mud.133.1277822550597; Tue, 29 Jun 2010 07:42:30 -0700 (PDT) Sender: pelleb@gmail.com Received: by 10.42.1.18 with HTTP; Tue, 29 Jun 2010 07:42:30 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4BCCE@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4BCCC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4BCCE@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Tue, 29 Jun 2010 10:42:30 -0400 X-Google-Sender-Auth: CJsJLMPTV5XQL3dXlcW-C8Jdn1M Message-ID: <AANLkTilGGTjOTw8yhiqLyf9hQknWEpeL_17tKnE7T8VY@mail.gmail.com> From: Pelle Braendgaard <pelle@stakeventures.com> To: Eran Hammer-Lahav <eran@hueniverse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Draft -09 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 29 Jun 2010 14:42:26 -0000 I found one small error in 3.1 for the "code" parameter. It mistakenly says "token" and not "code": http://r6.sharedcopy.com/6bnqq8v Anyway I hadn't seen any of the changes since 2.05 which I just implemented for the Ruby on Rails OAuth Plugin and I have to say the changes look great. I will have to rewrite a fair amount of code now, but the changes in general are excellent and simplify things a lot. My only comment is on the assertions part. I am sure this will be useful for Enterprise type of people but I have know what kind of support there is for these kind of things in say the Ruby, Python and PHP world. So my guess is that libraries probably wont be supporting them from the get go. It would be useful for us implementers if someone provided resources with information on how to implement this. P On Tue, Jun 29, 2010 at 3:11 AM, Eran Hammer-Lahav <eran@hueniverse.com> wr= ote: > For editorial feedback, I am going to try something new and use > SharedCopy.com (no install required). > > > > Try it out at: http://r6.sharedcopy.com/6bnqq8v > > > > If this doesn=E2=80=99t work, I=E2=80=99ll let people know and cancel it. > > > > EHL > > > > > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of > Eran Hammer-Lahav > Sent: Monday, June 28, 2010 11:56 PM > To: OAuth WG (oauth@ietf.org) > Subject: [OAUTH-WG] Draft -09 > > > > Draft -09 is now posted. Main changes include: > > > > o=C2=A0 Fixed typos, editorial changes. Thanks to Dick for his useful fee= dback. > > o=C2=A0 Added token expiration example. > > o=C2=A0 Added scope parameter to end-user authorization endpoint response= and > WWW-Authenticate header. > > o=C2=A0 Added note about parameters with empty values (same as omitted). > > o=C2=A0 Changed parameter values to use '-' instead of '_'.=C2=A0 Paramet= er names > still use '_'. > > o=C2=A0 Changed authorization endpoint client type to response type with = values: > code, token, or both. > > o=C2=A0 Complete cleanup of error codes.=C2=A0 Added support for error de= scription and > URI. > > o=C2=A0 Add initial extensibility support. > > > > Draft -09 represents what I consider to be the first feature complete > proposal. While it still needs much work, it has notes for open issues an= d > missing parts. I plan to give people 2 weeks to review and provide extens= ive > feedback, and will post one more draft before the 7/12 cutoff date for th= e > meeting. > > > > My goal is to collect enough feedback to declare the next draft (-10) sta= ble > for wider implementation. If you were waiting for a stable draft to study > and provide extensive feedback, this is the draft! When giving feedback > pretend this is your last chance to making a significant contribution or > changes to the core specification. > > > > Please submit feedback by 7/9. > > > > When submitting feedback please start a new thread for each item. Editori= al > commentary can be collected in one post (and please send to the list, eve= n > if it is minor, because I tend to get the same typo correction many times= ). > > > > Thanks, > > > > EHL > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --=20 http://agree2.com - Reach Agreement! http://stakeventures.com - My blog about startups and agile banking From eran@hueniverse.com Tue Jun 29 08:22:10 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C3FF3A6BAD for <oauth@core3.amsl.com>; Tue, 29 Jun 2010 08:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.307 X-Spam-Level: X-Spam-Status: No, score=-1.307 tagged_above=-999 required=5 tests=[AWL=-0.567, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HWdpy39A5AkQ for <oauth@core3.amsl.com>; Tue, 29 Jun 2010 08:22:04 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 57A6E3A6877 for <oauth@ietf.org>; Tue, 29 Jun 2010 08:22:03 -0700 (PDT) Received: (qmail 15210 invoked from network); 29 Jun 2010 15:22:13 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 29 Jun 2010 15:22:12 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 29 Jun 2010 08:22:09 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: Pelle Braendgaard <pelle@stakeventures.com> Date: Tue, 29 Jun 2010 08:22:14 -0700 Thread-Topic: [OAUTH-WG] Draft -09 Thread-Index: AcsXmVI9FxmSy/F5R1mgws3KiyZnDQABPIrg Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4BD88@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4BCCC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4BCCE@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTilGGTjOTw8yhiqLyf9hQknWEpeL_17tKnE7T8VY@mail.gmail.com> In-Reply-To: <AANLkTilGGTjOTw8yhiqLyf9hQknWEpeL_17tKnE7T8VY@mail.gmail.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 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Draft -09 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 29 Jun 2010 15:22:10 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogcGVsbGViQGdtYWlsLmNv bSBbbWFpbHRvOnBlbGxlYkBnbWFpbC5jb21dIE9uIEJlaGFsZiBPZiBQZWxsZQ0KPiBCcmFlbmRn YWFyZA0KPiBTZW50OiBUdWVzZGF5LCBKdW5lIDI5LCAyMDEwIDc6NDMgQU0NCj4gVG86IEVyYW4g SGFtbWVyLUxhaGF2DQo+IENjOiBPQXV0aCBXRyAob2F1dGhAaWV0Zi5vcmcpDQo+IFN1YmplY3Q6 IFJlOiBbT0FVVEgtV0ddIERyYWZ0IC0wOQ0KPiANCj4gSSBmb3VuZCBvbmUgc21hbGwgZXJyb3Ig aW4gMy4xIGZvciB0aGUgImNvZGUiIHBhcmFtZXRlci4gSXQgbWlzdGFrZW5seSBzYXlzDQo+ICJ0 b2tlbiIgYW5kIG5vdCAiY29kZSI6DQo+IA0KPiBodHRwOi8vcjYuc2hhcmVkY29weS5jb20vNmJu cXE4dg0KDQpUaGFua3MuDQoNCj4gQW55d2F5IEkgaGFkbid0IHNlZW4gYW55IG9mIHRoZSBjaGFu Z2VzIHNpbmNlIDIuMDUgd2hpY2ggSSBqdXN0IGltcGxlbWVudGVkDQo+IGZvciB0aGUgUnVieSBv biBSYWlscyBPQXV0aCBQbHVnaW4gYW5kIEkgaGF2ZSB0byBzYXkgdGhlIGNoYW5nZXMgbG9vayBn cmVhdC4gSQ0KPiB3aWxsIGhhdmUgdG8gcmV3cml0ZSBhIGZhaXIgYW1vdW50IG9mIGNvZGUgbm93 LCBidXQgdGhlIGNoYW5nZXMgaW4gZ2VuZXJhbA0KPiBhcmUgZXhjZWxsZW50IGFuZCBzaW1wbGlm eSB0aGluZ3MgYSBsb3QuDQo+IA0KPiBNeSBvbmx5IGNvbW1lbnQgaXMgb24gdGhlIGFzc2VydGlv bnMgcGFydC4gSSBhbSBzdXJlIHRoaXMgd2lsbCBiZSB1c2VmdWwgZm9yDQo+IEVudGVycHJpc2Ug dHlwZSBvZiBwZW9wbGUgYnV0IEkgaGF2ZSBrbm93IHdoYXQga2luZCBvZiBzdXBwb3J0IHRoZXJl IGlzIGZvcg0KPiB0aGVzZSBraW5kIG9mIHRoaW5ncyBpbiBzYXkgdGhlIFJ1YnksIFB5dGhvbiBh bmQgUEhQIHdvcmxkLiBTbyBteSBndWVzcyBpcw0KPiB0aGF0IGxpYnJhcmllcyBwcm9iYWJseSB3 b250IGJlIHN1cHBvcnRpbmcgdGhlbSBmcm9tIHRoZSBnZXQgZ28uIEl0IHdvdWxkIGJlDQo+IHVz ZWZ1bCBmb3IgdXMgaW1wbGVtZW50ZXJzIGlmIHNvbWVvbmUgcHJvdmlkZWQgcmVzb3VyY2VzIHdp dGggaW5mb3JtYXRpb24NCj4gb24gaG93IHRvIGltcGxlbWVudCB0aGlzLg0KDQpUaGUgYXNzZXJ0 aW9uIGdyYW50IHR5cGUgaXMgcmVhbGx5IHRoZSBncmFudCB0eXBlIGV4dGVuc2lvbiBwb2ludC4g TGlicmFyaWVzIHNob3VsZCB0cmVhdCBpdCBhcyBhIHdheSB0byBzdXBwb3J0IGN1c3RvbSBncmFu dCB0eXBlcy4gT25lIG9mIHRoZSB0aGluZ3MgSSB3b3VsZCBsaWtlIHRvIHNlZSBzb21lb25lIGRy YWZ0IGlzIGhvdyB0byB1c2UgT0F1dGggMS4wIHRva2VucyB0byBvYnRhaW4gT0F1dGggMi4wIHRv a2VucyB1c2luZyB0aGUgYXNzZXJ0aW9uIHR5cGUuIEZvciBleGFtcGxlLCB0aGUgYXNzZXJ0aW9u IHR5cGUgY2FuIGJlICJodHRwOi8vb2F1dGgubmV0LzEuMC90b2tlbiIgLCBhbmQgdGhlIGFzc2Vy dGlvbiBpdHNlbGYgaXMgc29tZSBmb3JtIG9mIHRoZSB0b2tlbiBhbmQgc2lnbmF0dXJlIChvciBz ZWNyZXRzKSBjb25jYXRlbmF0ZWQgaW50byBhIHN0cmluZyAodGhpcyB3aWxsIG1haW50YWluIHRo ZSAxLjAgc2VjdXJpdHkgd2hpbGUgdHJhbnNpdGlvbmluZyB0byAyLjApLiBUaGlzIGlzIGp1c3Qg YSBzdHJhdyBtYW4uDQoNCkl0IGlzIGltcG9ydGFudCB0aGF0IGxpYnJhcmllcyBzdXBwb3J0IHRo aXMgZXh0ZW5zaWJpbGl0eSB3aXRoIHNvbWUgZm9ybSBvZiBhIGhvb2sgb3IgaGFuZGxlciBzbyB0 aGF0IGNsaWVudHMgY2FuIG1ha2UgcmVxdWVzdHMgdXNpbmcgYXNzZXJ0aW9ucyBmcm9tIG91dHNp ZGUgdGhlIGxpYnJhcnkuDQoNCkVITA0KDQo+IFANCj4gDQo+IE9uIFR1ZSwgSnVuIDI5LCAyMDEw IGF0IDM6MTEgQU0sIEVyYW4gSGFtbWVyLUxhaGF2DQo+IDxlcmFuQGh1ZW5pdmVyc2UuY29tPiB3 cm90ZToNCj4gPiBGb3IgZWRpdG9yaWFsIGZlZWRiYWNrLCBJIGFtIGdvaW5nIHRvIHRyeSBzb21l dGhpbmcgbmV3IGFuZCB1c2UNCj4gPiBTaGFyZWRDb3B5LmNvbSAobm8gaW5zdGFsbCByZXF1aXJl ZCkuDQo+ID4NCj4gPg0KPiA+DQo+ID4gVHJ5IGl0IG91dCBhdDogaHR0cDovL3I2LnNoYXJlZGNv cHkuY29tLzZibnFxOHYNCj4gPg0KPiA+DQo+ID4NCj4gPiBJZiB0aGlzIGRvZXNu4oCZdCB3b3Jr LCBJ4oCZbGwgbGV0IHBlb3BsZSBrbm93IGFuZCBjYW5jZWwgaXQuDQo+ID4NCj4gPg0KPiA+DQo+ ID4gRUhMDQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+IEZyb206IG9hdXRoLWJvdW5jZXNA aWV0Zi5vcmcgW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4gPiBP ZiBFcmFuIEhhbW1lci1MYWhhdg0KPiA+IFNlbnQ6IE1vbmRheSwgSnVuZSAyOCwgMjAxMCAxMTo1 NiBQTQ0KPiA+IFRvOiBPQXV0aCBXRyAob2F1dGhAaWV0Zi5vcmcpDQo+ID4gU3ViamVjdDogW09B VVRILVdHXSBEcmFmdCAtMDkNCj4gPg0KPiA+DQo+ID4NCj4gPiBEcmFmdCAtMDkgaXMgbm93IHBv c3RlZC4gTWFpbiBjaGFuZ2VzIGluY2x1ZGU6DQo+ID4NCj4gPg0KPiA+DQo+ID4gb8KgIEZpeGVk IHR5cG9zLCBlZGl0b3JpYWwgY2hhbmdlcy4gVGhhbmtzIHRvIERpY2sgZm9yIGhpcyB1c2VmdWwg ZmVlZGJhY2suDQo+ID4NCj4gPiBvwqAgQWRkZWQgdG9rZW4gZXhwaXJhdGlvbiBleGFtcGxlLg0K PiA+DQo+ID4gb8KgIEFkZGVkIHNjb3BlIHBhcmFtZXRlciB0byBlbmQtdXNlciBhdXRob3JpemF0 aW9uIGVuZHBvaW50IHJlc3BvbnNlDQo+ID4gYW5kIFdXVy1BdXRoZW50aWNhdGUgaGVhZGVyLg0K PiA+DQo+ID4gb8KgIEFkZGVkIG5vdGUgYWJvdXQgcGFyYW1ldGVycyB3aXRoIGVtcHR5IHZhbHVl cyAoc2FtZSBhcyBvbWl0dGVkKS4NCj4gPg0KPiA+IG/CoCBDaGFuZ2VkIHBhcmFtZXRlciB2YWx1 ZXMgdG8gdXNlICctJyBpbnN0ZWFkIG9mICdfJy7CoCBQYXJhbWV0ZXINCj4gPiBuYW1lcyBzdGls bCB1c2UgJ18nLg0KPiA+DQo+ID4gb8KgIENoYW5nZWQgYXV0aG9yaXphdGlvbiBlbmRwb2ludCBj bGllbnQgdHlwZSB0byByZXNwb25zZSB0eXBlIHdpdGgNCj4gdmFsdWVzOg0KPiA+IGNvZGUsIHRv a2VuLCBvciBib3RoLg0KPiA+DQo+ID4gb8KgIENvbXBsZXRlIGNsZWFudXAgb2YgZXJyb3IgY29k ZXMuwqAgQWRkZWQgc3VwcG9ydCBmb3IgZXJyb3INCj4gPiBkZXNjcmlwdGlvbiBhbmQgVVJJLg0K PiA+DQo+ID4gb8KgIEFkZCBpbml0aWFsIGV4dGVuc2liaWxpdHkgc3VwcG9ydC4NCj4gPg0KPiA+ DQo+ID4NCj4gPiBEcmFmdCAtMDkgcmVwcmVzZW50cyB3aGF0IEkgY29uc2lkZXIgdG8gYmUgdGhl IGZpcnN0IGZlYXR1cmUgY29tcGxldGUNCj4gPiBwcm9wb3NhbC4gV2hpbGUgaXQgc3RpbGwgbmVl ZHMgbXVjaCB3b3JrLCBpdCBoYXMgbm90ZXMgZm9yIG9wZW4gaXNzdWVzDQo+ID4gYW5kIG1pc3Np bmcgcGFydHMuIEkgcGxhbiB0byBnaXZlIHBlb3BsZSAyIHdlZWtzIHRvIHJldmlldyBhbmQgcHJv dmlkZQ0KPiA+IGV4dGVuc2l2ZSBmZWVkYmFjaywgYW5kIHdpbGwgcG9zdCBvbmUgbW9yZSBkcmFm dCBiZWZvcmUgdGhlIDcvMTINCj4gPiBjdXRvZmYgZGF0ZSBmb3IgdGhlIG1lZXRpbmcuDQo+ID4N Cj4gPg0KPiA+DQo+ID4gTXkgZ29hbCBpcyB0byBjb2xsZWN0IGVub3VnaCBmZWVkYmFjayB0byBk ZWNsYXJlIHRoZSBuZXh0IGRyYWZ0ICgtMTApDQo+ID4gc3RhYmxlIGZvciB3aWRlciBpbXBsZW1l bnRhdGlvbi4gSWYgeW91IHdlcmUgd2FpdGluZyBmb3IgYSBzdGFibGUNCj4gPiBkcmFmdCB0byBz dHVkeSBhbmQgcHJvdmlkZSBleHRlbnNpdmUgZmVlZGJhY2ssIHRoaXMgaXMgdGhlIGRyYWZ0ISBX aGVuDQo+ID4gZ2l2aW5nIGZlZWRiYWNrIHByZXRlbmQgdGhpcyBpcyB5b3VyIGxhc3QgY2hhbmNl IHRvIG1ha2luZyBhDQo+ID4gc2lnbmlmaWNhbnQgY29udHJpYnV0aW9uIG9yIGNoYW5nZXMgdG8g dGhlIGNvcmUgc3BlY2lmaWNhdGlvbi4NCj4gPg0KPiA+DQo+ID4NCj4gPiBQbGVhc2Ugc3VibWl0 IGZlZWRiYWNrIGJ5IDcvOS4NCj4gPg0KPiA+DQo+ID4NCj4gPiBXaGVuIHN1Ym1pdHRpbmcgZmVl ZGJhY2sgcGxlYXNlIHN0YXJ0IGEgbmV3IHRocmVhZCBmb3IgZWFjaCBpdGVtLg0KPiA+IEVkaXRv cmlhbCBjb21tZW50YXJ5IGNhbiBiZSBjb2xsZWN0ZWQgaW4gb25lIHBvc3QgKGFuZCBwbGVhc2Ug c2VuZCB0bw0KPiA+IHRoZSBsaXN0LCBldmVuIGlmIGl0IGlzIG1pbm9yLCBiZWNhdXNlIEkgdGVu ZCB0byBnZXQgdGhlIHNhbWUgdHlwbyBjb3JyZWN0aW9uDQo+IG1hbnkgdGltZXMpLg0KPiA+DQo+ ID4NCj4gPg0KPiA+IFRoYW5rcywNCj4gPg0KPiA+DQo+ID4NCj4gPiBFSEwNCj4gPg0KPiA+DQo+ ID4NCj4gPg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gPiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4gPiBPQXV0aEBpZXRmLm9yZw0KPiA+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCj4gPg0KPiA+DQo+ IA0KPiANCj4gDQo+IC0tDQo+IGh0dHA6Ly9hZ3JlZTIuY29tIC0gUmVhY2ggQWdyZWVtZW50IQ0K PiBodHRwOi8vc3Rha2V2ZW50dXJlcy5jb20gLSBNeSBibG9nIGFib3V0IHN0YXJ0dXBzIGFuZCBh Z2lsZSBiYW5raW5nDQo= From mscurtescu@google.com Tue Jun 29 09:58:47 2010 Return-Path: <mscurtescu@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A06B3A6848 for <oauth@core3.amsl.com>; Tue, 29 Jun 2010 09:58:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.358 X-Spam-Level: X-Spam-Status: No, score=-105.358 tagged_above=-999 required=5 tests=[AWL=0.619, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OXqRy7wPXYoG for <oauth@core3.amsl.com>; Tue, 29 Jun 2010 09:58:46 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 8D61B3A6813 for <oauth@ietf.org>; Tue, 29 Jun 2010 09:58:46 -0700 (PDT) Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id o5TGwukv008104 for <oauth@ietf.org>; Tue, 29 Jun 2010 09:58:56 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1277830736; bh=H2qjrR8TbU2U5mo0zNDm0NM/LGY=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=jJDRI4rtqW+MYkPdVix9xTayWxGGkPeZeqmTh7A1VgG03zQHQq0mCro8dURqaULRG ZaodWn6lVAvigIB58TkTg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding:x-system-of-record; b=SCzagrvsL/nOH/akAwvyYxDA8mcglptKRzPeanNGNMFux105Ab/k4Zhlbo9MtewvT BiIYR+lnPSPmE6KxlOJkA== Received: from gwb11 (gwb11.prod.google.com [10.200.2.11]) by wpaz24.hot.corp.google.com with ESMTP id o5TGwDTO019026 for <oauth@ietf.org>; Tue, 29 Jun 2010 09:58:55 -0700 Received: by gwb11 with SMTP id 11so657336gwb.1 for <oauth@ietf.org>; Tue, 29 Jun 2010 09:58:54 -0700 (PDT) Received: by 10.101.156.18 with SMTP id i18mr8781971ano.180.1277830734116; Tue, 29 Jun 2010 09:58:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.132.22 with HTTP; Tue, 29 Jun 2010 09:58:34 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11265A5FC9D@WSMSG3153V.srv.dir.telstra.com> References: <7C01E631FF4B654FA1E783F1C0265F8C579CC0C3@TK5EX14MBXC117.redmond.corp.microsoft.com> <7C01E631FF4B654FA1E783F1C0265F8C579D0F31@TK5EX14MBXC117.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E11265A5FC9D@WSMSG3153V.srv.dir.telstra.com> From: Marius Scurtescu <mscurtescu@google.com> Date: Tue, 29 Jun 2010 09:58:34 -0700 Message-ID: <AANLkTilrSUMEjsF-3RHuit6aoAPRe0DAqR6Uz2ldrd_l@mail.gmail.com> To: "Manger, James H" <James.H.Manger@team.telstra.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "oauth@ietf.org" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Proposal for text for section 2 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 29 Jun 2010 16:58:47 -0000 On Mon, Jun 28, 2010 at 9:37 PM, Manger, James H <James.H.Manger@team.telstra.com> wrote: > > For instance, why not define a SAML HTTP authentication mechanism: > > =A0=A0 Authorization: SAML a=3D<base64url-encoded SAML assertion> This came up in another thread, but SAML assertions could be too large to be passed through an HTTP header. Other than that, your suggestion really simplifies things. Marius From yarong@microsoft.com Tue Jun 29 12:17:44 2010 Return-Path: <yarong@microsoft.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 579013A693C for <oauth@core3.amsl.com>; Tue, 29 Jun 2010 12:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.669 X-Spam-Level: X-Spam-Status: No, score=-8.669 tagged_above=-999 required=5 tests=[AWL=-0.671, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltFu3LHGsCQq for <oauth@core3.amsl.com>; Tue, 29 Jun 2010 12:17:34 -0700 (PDT) Received: from smtp.microsoft.com (mail1.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 5A9133A68B3 for <oauth@ietf.org>; Tue, 29 Jun 2010 12:17:33 -0700 (PDT) Received: from TK5EX14CASC130.redmond.corp.microsoft.com (157.54.52.9) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 29 Jun 2010 12:17:39 -0700 Received: from TK5EX14MBXC117.redmond.corp.microsoft.com ([169.254.8.23]) by TK5EX14CASC130.redmond.corp.microsoft.com ([157.54.52.9]) with mapi id 14.01.0160.006; Tue, 29 Jun 2010 12:17:37 -0700 From: Yaron Goland <yarong@microsoft.com> To: "Manger, James H" <James.H.Manger@team.telstra.com>, "oauth@ietf.org" <oauth@ietf.org> Thread-Topic: Proposal for text for section 2 Thread-Index: AcsUm7O3+LYTofkOQ6CsKuFeuynp2ACcJnPgAAxyEYAAH/FooA== Date: Tue, 29 Jun 2010 19:17:32 +0000 Message-ID: <7C01E631FF4B654FA1E783F1C0265F8C579D20CB@TK5EX14MBXC117.redmond.corp.microsoft.com> References: <7C01E631FF4B654FA1E783F1C0265F8C579CC0C3@TK5EX14MBXC117.redmond.corp.microsoft.com> <7C01E631FF4B654FA1E783F1C0265F8C579D0F31@TK5EX14MBXC117.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E11265A5FC9D@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11265A5FC9D@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7C01E631FF4B654FA1E783F1C0265F8C579D20CBTK5EX14MBXC117r_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Proposal for text for section 2 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 29 Jun 2010 19:17:44 -0000 --_000_7C01E631FF4B654FA1E783F1C0265F8C579D20CBTK5EX14MBXC117r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable SAML assertions routinely run into the 10s and even 100s of K. This exceeds= the practical limit that most HTTP servers and proxies put on the size of = the HTTP request headers they are willing to accept. So we cannot rely on t= he HTTP authorization header as a means of transporting SAML assertions. We= are thus, as a practical matter, forced into using the request body. From: Manger, James H [mailto:James.H.Manger@team.telstra.com] Sent: Monday, June 28, 2010 9:38 PM To: Yaron Goland; oauth@ietf.org Subject: RE: Proposal for text for section 2 Yaron, "Assertion Client Credentials" is too much of a hack. It only works for POS= Ts, and only when the body is form-encoded. It could not be used, for instance, to delete a token with an HTTP DELETE r= equest to a token URI. Though that specific idea has not been accepted yet,= it is a reasonable possibility. We shouldn't introduce a client authentica= tion mechanisms incapable of working with such ideas. The 1st and 2nd proposed paragraphs are not specific to OAuth at all. The 3= rd paragraph mentions authorization codes and refresh tokens, but the clien= t assertion is independent of those. I would prefer to see a standalone des= cription of how to authenticate any HTTP request with a client SAML asserti= on - then that could apply to the OAuth2 token management API, just as easi= ly as it applies to any other API, and just as easily as any client auth me= chanism works with OAuth2. For instance, why not define a SAML HTTP authentication mechanism: Authorization: SAML a=3D<base64url-encoded SAML assertion> It is obvious how it can be used to authenticate/authorize client requests = to an OAuth2 token endpoint. It works with GET, HEAD, POST, PUT, DELETE.... It works with XML, JSON, form-encoded... messages. You don't need special rules about avoiding duplicate authentication mechan= isms. There is a standard way to do discovery: return WWW-Authenticate: SAML real= m=3D"Token Management". Finally, the proposal keeps client_id as a separate parameter. However, I g= uess that a SAML assertion would often include a client id inside the asser= tion. This means we have two client ids. At best it is slightly inefficient= ; it introduces more code paths (eg if they mismatch); at worst it causes s= ecurity bugs when the "wrong" client id is used at different points in syst= ems. -- James Manger From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Y= aron Goland Sent: Tuesday, 29 June 2010 7:56 AM To: Eran Hammer-Lahav; oauth@ietf.org Subject: Re: [OAUTH-WG] Proposal for text for section 2 The following is proposed language for a new section, 2.2, in the spec. Thi= s is part of the spec that deals with client authentication. This proposal = is completely orthogonal to anything in section 4 such as grant types. At E= ran's suggestion I added in an example into the text to help readers unders= tand both what the feature is for and how it is used. Eran also suggested that we should probably introduce a client_cred_type pa= rameter (since we are explicitly support multiple types of client parameter= s) just to be consistent with grant_type. I don't have strong feelings on t= he subject and am happy to go with whatever the group wants. Thoughts? Thanks, Yaron 2.2 Assertion Client Credentials In scenarios where security is at a premium one wants to avoid sending secr= ets across the Internet, even on encrypted connections. Instead one wants t= o send values derived from the secret that prove to the receiver that the s= ender is in possession of the secret without actually sending the secret. T= ypically the way derived values are created is by generating an assertion t= hat is then either HMAC'd or digitally signed using an agreed upon secret. = By validating the HMAC or digital signature on the assertion the receiver o= f the assertion can prove to themselves that the entity that generated the = assertion was in possession of the secret without actually communicating th= e secret directly. So, for example, a client can establish a secret using an out of band mecha= nism with a resource server. As part of this out of band communication the = client and resource server agree that the client will authenticate itself u= sing a SAML assertion with agreed upon parameters that will be signed by th= e provisioned secret. Later on the client interacts with an end-user and uses the end-user author= ization process with the resource server to get an authorization code. The = client then sends an access token request to the token endpoint for the res= ource server and includes, along with the authorization code, a SAML assert= ion it signed with the previously agreed key and parameters. The SAML asser= tion proves to the token endpoint the identity of the client and the author= ization code provides the link to the end-user authorization. If the access= token request comes back with a refresh token then in the future the clien= t can get new access tokens by submitting an access token request containin= g both a properly signed and formatted SAML assertion as well as the refres= h token. The following defines how to send an assertion as client credentials. If th= e assertion client credentials are used then the client MUST include the cr= edentials using the following request parameters: client_id REQUIRED. The client identifier. client_assertion_type REQUIRED. The format of the assertion as defined by the aut= horization server. The value MUST be an absolute URI. client_assertion REQUIRED. The client assertion. For example (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=3Drefresh_token&client_id=3Ds6BhdRkqt3& client_assertion=3DPHNhbWxwOl...[omitted for brevity]...ZT4= %3D& client_assertion_type=3Durn%3Aoasis%3Anames%sAtc%3ASAML%3A2= .0%3Aassertion& refresh_token=3Dn4E90119d The client MUST NOT include the client credentials using more than one mech= anism. If more than one mechanism is used regardless whether the credential= s are identical or valid, the server MUST reply with an HTTP 400 status cod= e (Bad Request) and include the "multiple_credentials" error code. Token endpoints can differentiate between client assertion credentials and = other client credential types by looking for the presence of the client_ass= ertion and client_assertion_type attributes which will only be present with= client assertion credentials. --_000_7C01E631FF4B654FA1E783F1C0265F8C579D20CBTK5EX14MBXC117r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"> <style><!-- /* Font Definitions */ @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} pre {mso-style-priority:99; mso-style-link:"HTML Preformatted Char"; margin:0in; margin-bottom:.0001pt; font-size:10.0pt; font-family:"Courier New";} p.MsoAcetate, li.MsoAcetate, div.MsoAcetate {mso-style-priority:99; mso-style-link:"Balloon Text Char"; margin:0in; margin-bottom:.0001pt; font-size:8.0pt; font-family:"Tahoma","sans-serif";} span.HTMLPreformattedChar {mso-style-name:"HTML Preformatted Char"; mso-style-priority:99; mso-style-link:"HTML Preformatted"; font-family:"Courier New";} span.BalloonTextChar {mso-style-name:"Balloon Text Char"; mso-style-priority:99; mso-style-link:"Balloon Text"; font-family:"Tahoma","sans-serif";} span.EmailStyle21 {mso-style-type:personal; font-family:"Calibri","sans-serif"; color:windowtext;} span.EmailStyle22 {mso-style-type:personal; font-family:"Calibri","sans-serif"; color:#1F497D;} span.EmailStyle23 {mso-style-type:personal; font-family:"Calibri","sans-serif"; color:#1F497D;} span.grey {mso-style-name:grey;} span.EmailStyle25 {mso-style-type:personal; font-family:"Calibri","sans-serif"; color:#1F497D;} span.EmailStyle26 {mso-style-type:personal; font-family:"Calibri","sans-serif"; color:#1F497D;} span.EmailStyle27 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">SAML assertions routin= ely run into the 10s and even 100s of K. This exceeds the practical limit t= hat most HTTP servers and proxies put on the size of the HTTP request heade= rs they are willing to accept. So we cannot rely on the HTTP authorization header as a means of transporting SA= ML assertions. We are thus, as a practical matter, forced into using the re= quest body.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in = 4.0pt"> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:"= ;Tahoma","sans-serif"">From:</span></b><span style=3D"font-s= ize:10.0pt;font-family:"Tahoma","sans-serif""> Manger, = James H [mailto:James.H.Manger@team.telstra.com] <br> <b>Sent:</b> Monday, June 28, 2010 9:38 PM<br> <b>To:</b> Yaron Goland; oauth@ietf.org<br> <b>Subject:</b> RE: Proposal for text for section 2<o:p></o:p></span></p> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal"><span lang=3D"EN-AU" style=3D"color:#1F497D">Yaron,<= o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-AU" style=3D"color:#1F497D"><o:p>&n= bsp;</o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-AU" style=3D"color:#1F497D">“= Assertion Client Credentials” is too much of a hack. It only works fo= r POSTs, and only when the body is form-encoded.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-AU" style=3D"color:#1F497D"><o:p>&n= bsp;</o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-AU" style=3D"color:#1F497D">It coul= d not be used, for instance, to delete a token with an HTTP DELETE request = to a token URI. Though that specific idea has not been accepted yet, it is = a reasonable possibility. We shouldn’t introduce a client authentication mechanisms incapable of working with suc= h ideas.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-AU" style=3D"color:#1F497D"><o:p>&n= bsp;</o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-AU" style=3D"color:#1F497D">The 1<s= up>st</sup> and 2<sup>nd</sup> proposed paragraphs are not specific to OAut= h at all. The 3<sup>rd</sup> paragraph mentions authorization codes and ref= resh tokens, but the client assertion is independent of those. I would prefer to see a standalone description of= how to authenticate any HTTP request with a client SAML assertion — = then that could apply to the OAuth2 token management API, just as easily as= it applies to any other API, and just as easily as any client auth mechanism works with OAuth2.<o:p></o:p></span= ></p> <p class=3D"MsoNormal"><span lang=3D"EN-AU" style=3D"color:#1F497D"><o:p>&n= bsp;</o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-AU" style=3D"color:#1F497D">For ins= tance, why not define a SAML HTTP authentication mechanism:<o:p></o:p></spa= n></p> <p class=3D"MsoNormal"><span lang=3D"EN-AU" style=3D"color:#1F497D"><o:p>&n= bsp;</o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-AU" style=3D"color:#1F497D"> &= nbsp; Authorization: SAML a=3D<base64url-encoded SAML assertion><o:p>= </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-AU" style=3D"color:#1F497D"><o:p>&n= bsp;</o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-AU" style=3D"color:#1F497D">It is o= bvious how it can be used to authenticate/authorize client requests to an O= Auth2 token endpoint.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-AU" style=3D"color:#1F497D">It work= s with GET, HEAD, POST, PUT, DELETE….<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-AU" style=3D"color:#1F497D">It work= s with XML, JSON, form-encoded… messages.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-AU" style=3D"color:#1F497D">You don= ’t need special rules about avoiding duplicate authentication mechani= sms.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-AU" style=3D"color:#1F497D">There i= s a standard way to do discovery: return WWW-Authenticate: SAML realm=3D= 221;Token Management”.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-AU" style=3D"color:#1F497D"><o:p>&n= bsp;</o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-AU" style=3D"color:#1F497D">Finally= , the proposal keeps client_id as a separate parameter. However, I guess th= at a SAML assertion would often include a client id inside the assertion. T= his means we have two client ids. At best it is slightly inefficient; it introduces more code paths (eg if they mism= atch); at worst it causes security bugs when the “wrong” client= id is used at different points in systems.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-AU" style=3D"color:#1F497D"><o:p>&n= bsp;</o:p></span></p> <div> <p class=3D"MsoNormal"><span lang=3D"EN-AU" style=3D"color:#1F497D">-- <o:p= ></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-AU" style=3D"color:#1F497D">James M= anger<o:p></o:p></span></p> </div> <p class=3D"MsoNormal"><span lang=3D"EN-AU" style=3D"color:#1F497D"><o:p>&n= bsp;</o:p></span></p> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal" style=3D"margin-left:.5in"><b><span style=3D"font-si= ze:10.0pt;font-family:"Tahoma","sans-serif"">From:</spa= n></b><span style=3D"font-size:10.0pt;font-family:"Tahoma","= sans-serif""> oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] <b>On Behalf Of </b>Yaron Goland<br> <b>Sent:</b> Tuesday, 29 June 2010 7:56 AM<br> <b>To:</b> Eran Hammer-Lahav; oauth@ietf.org<br> <b>Subject:</b> Re: [OAUTH-WG] Proposal for text for section 2<o:p></o:p></= span></p> </div> </div> <p class=3D"MsoNormal" style=3D"margin-left:.5in"><span lang=3D"EN-AU"><o:p= > </o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"color:#1F4= 97D">The following is proposed language for a new section, 2.2, in the spec= . This is part of the spec that deals with client authentication. This prop= osal is completely orthogonal to anything in section 4 such as grant types. At Eran’s suggestion I added in an= example into the text to help readers understand both what the feature is = for and how it is used. <o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"color:#1F4= 97D"><o:p> </o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"color:#1F4= 97D">Eran also suggested that we should probably introduce a client_cred_ty= pe parameter (since we are explicitly support multiple types of client para= meters) just to be consistent with grant_type. I don’t have strong feelings on the subject and am happy to go with = whatever the group wants.<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"color:#1F4= 97D"><o:p> </o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"color:#1F4= 97D">           &nbs= p;    Thoughts?<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"color:#1F4= 97D"><o:p> </o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"color:#1F4= 97D">           &nbs= p;            &= nbsp;       Thanks,<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"color:#1F4= 97D"><o:p> </o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"color:#1F4= 97D">           &nbs= p;            &= nbsp;           &nbs= p;           Yaron<o:p></= o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"color:#1F4= 97D"><o:p> </o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"color:#1F4= 97D">2.2 Assertion Client Credentials<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"color:#1F4= 97D"><o:p> </o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"color:#1F4= 97D">In scenarios where security is at a premium one wants to avoid sending= secrets across the Internet, even on encrypted connections. Instead one wa= nts to send values derived from the secret that prove to the receiver that the sender is in possession of the secret = without actually sending the secret. Typically the way derived values are c= reated is by generating an assertion that is then either HMAC’d or di= gitally signed using an agreed upon secret. By validating the HMAC or digital signature on the assertion the receiver = of the assertion can prove to themselves that the entity that generated the= assertion was in possession of the secret without actually communicating t= he secret directly.<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"color:#1F4= 97D"><o:p> </o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"color:#1F4= 97D">So, for example, a client can establish a secret using an out of band = mechanism with a resource server. As part of this out of band communication= the client and resource server agree that the client will authenticate itself using a SAML assertion with agree= d upon parameters that will be signed by the provisioned secret. <o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"color:#1F4= 97D"><o:p> </o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"color:#1F4= 97D">Later on the client interacts with an end-user and uses the end-user a= uthorization process with the resource server to get an authorization code.= The client then sends an access token request to the token endpoint for the resource server and includes, along = with the authorization code, a SAML assertion it signed with the previously= agreed key and parameters. The SAML assertion proves to the token endpoint= the identity of the client and the authorization code provides the link to the end-user authorization. If= the access token request comes back with a refresh token then in the futur= e the client can get new access tokens by submitting an access token reques= t containing both a properly signed and formatted SAML assertion as well as the refresh token. <o:p></o:p></sp= an></p> <p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"color:#1F4= 97D"><o:p> </o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"color:#1F4= 97D">The following defines how to send an assertion as client credentials. = If the assertion client credentials are used then the client MUST include t= he credentials using the following request parameters:<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"color:#1F4= 97D"><o:p> </o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"color:#1F4= 97D">client_id<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"color:#1F4= 97D">           &nbs= p;    REQUIRED. The client identifier.<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"color:#1F4= 97D">client_assertion_type<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"color:#1F4= 97D">           &nbs= p;    REQUIRED. The format of the assertion as defined by th= e authorization server.  The value MUST be an absolute URI.<o:p></o:p>= </span></p> <p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"color:#1F4= 97D">client_assertion<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"color:#1F4= 97D">           &nbs= p;    REQUIRED. The client assertion.<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"color:#1F4= 97D"><o:p> </o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"color:#1F4= 97D">For example (line breaks are for display purposes only):<o:p></o:p></s= pan></p> <p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"color:#1F4= 97D"><o:p> </o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"color:#1F4= 97D">           &nbs= p;    POST /token HTTP/1.1<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"color:#1F4= 97D">           &nbs= p;    Host: server.example.com<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"color:#1F4= 97D">           &nbs= p;    Content-Type: application/x-www-form-urlencoded<o:p></= o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"color:#1F4= 97D"><o:p> </o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"color:#1F4= 97D">           &nbs= p;    grant_type=3Drefresh_token&client_id=3Ds6BhdRkqt3&= amp;<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"color:#1F4= 97D">           &nbs= p;    client_assertion=3DPHNhbWxwOl...[omitted for brevity].= ..ZT4%3D&<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"color:#1F4= 97D">           &nbs= p;    client_assertion_type=3Durn%3Aoasis%3Anames%sAtc%3ASAM= L%3A2.0%3Aassertion&<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"color:#1F4= 97D">           &nbs= p;    refresh_token=3Dn4E90119d<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"color:#1F4= 97D"><o:p> </o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"color:#1F4= 97D">The client MUST NOT include the client credentials using more than one= mechanism. If more than one mechanism is used regardless whether the crede= ntials are identical or valid, the server MUST reply with an HTTP 400 status code (Bad Request) and include the R= 20;multiple_credentials” error code.<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"color:#1F4= 97D"><o:p> </o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-left:.5in"><span style=3D"color:#1F4= 97D">Token endpoints can differentiate between client assertion credentials= and other client credential types by looking for the presence of the clien= t_assertion and client_assertion_type attributes which will only be present with client assertion credentials.<o= :p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> </div> </div> </body> </html> --_000_7C01E631FF4B654FA1E783F1C0265F8C579D20CBTK5EX14MBXC117r_-- From yarong@microsoft.com Tue Jun 29 12:28:38 2010 Return-Path: <yarong@microsoft.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0AD73A6A3E for <oauth@core3.amsl.com>; Tue, 29 Jun 2010 12:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.921 X-Spam-Level: X-Spam-Status: No, score=-9.921 tagged_above=-999 required=5 tests=[AWL=0.677, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UsFmCWRpxK7Y for <oauth@core3.amsl.com>; Tue, 29 Jun 2010 12:28:27 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id AB3EA3A686D for <oauth@ietf.org>; Tue, 29 Jun 2010 12:28:26 -0700 (PDT) Received: from TK5EX14CASC130.redmond.corp.microsoft.com (157.54.52.9) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 29 Jun 2010 12:28:37 -0700 Received: from TK5EX14MBXC117.redmond.corp.microsoft.com ([169.254.8.23]) by TK5EX14CASC130.redmond.corp.microsoft.com ([157.54.52.9]) with mapi id 14.01.0160.006; Tue, 29 Jun 2010 12:28:36 -0700 From: Yaron Goland <yarong@microsoft.com> To: William Mills <wmills@yahoo-inc.com>, Torsten Lodderstedt <torsten@lodderstedt.net> Thread-Topic: [OAUTH-WG] OAuth discovery draft? Thread-Index: AQHLEbd88ANnc80E8EanM4mdFaHtZpKN3qcAgAH2zrCAAAP3tYAAAdRggARizoCAA7n10IAAByYwgAFfxjA= Date: Tue, 29 Jun 2010 19:28:29 +0000 Message-ID: <7C01E631FF4B654FA1E783F1C0265F8C579D21BD@TK5EX14MBXC117.redmond.corp.microsoft.com> References: <7C01E631FF4B654FA1E783F1C0265F8C579C6DC3@TK5EX14MBXC117.redmond.corp.microsoft.com><C8479A94.363F3%eran@hueniverse.com><7C01E631FF4B654FA1E783F1C0265F8C579C6E52@TK5EX14MBXC117.redmond.corp.microsoft.com><CDD1DDBF-BD1B-4F4E-8620-AA2FEC402C90@lodderstedt.net> <7C01E631FF4B654FA1E783F1C0265F8C579D0FED@TK5EX14MBXC117.redmond.corp.microsoft.com> <012AB2B223CB3F4BB846962876F47217059B677B@SNV-EXVS08.ds.corp.yahoo.com> In-Reply-To: <012AB2B223CB3F4BB846962876F47217059B677B@SNV-EXVS08.ds.corp.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7C01E631FF4B654FA1E783F1C0265F8C579D21BDTK5EX14MBXC117r_" MIME-Version: 1.0 Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] OAuth discovery draft? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 29 Jun 2010 19:28:39 -0000 --_000_7C01E631FF4B654FA1E783F1C0265F8C579D21BDTK5EX14MBXC117r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This then goes back to one of my original posts which is - Is www-authentic= ate legal on a non-401 response? I honestly don't know. From: William Mills [mailto:wmills@yahoo-inc.com] Sent: Monday, June 28, 2010 3:30 PM To: Yaron Goland; Torsten Lodderstedt Cc: OAuth WG Subject: RE: [OAUTH-WG] OAuth discovery draft? In the SASL stuff I'm working on I was presuming I'd use the WWW-Authentica= te header for returning the discovery info. ________________________________ From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Y= aron Goland Sent: Monday, June 28, 2010 3:10 PM To: Torsten Lodderstedt Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth discovery draft? I believe that GET should be used to return the resource's state and its OA= uth token endpoint is just a tiny part of that state. When we want to retur= n part of the state we typically use either explicit headers (a la byte ran= ges) or a query parameter. Content-types should, I think, just control the = syntax of what is returned, not the subset of data it contains. So I have t= o admit that I really don't like using GET for this sort of scenario. OPTIONS is actually the officially blessed way to walk up to a resource, kn= ock on the front door and ask 'what are you and what can you do?' So it see= ms to me we should start with OPTIONS. But this does bring up a problem - n= obody ever really defined a response body for OPTIONS. RFC 2616 explicitly = defined the legality of such a body but no standard was defined for what th= e body should look like. This is an issue because if someone does define a = body for OPTIONS then they really need to do so in a way that other standar= ds can build on top of. So we have a choice when it comes to using OPTIONS. We can return data in t= he header in which case all we have to do is just define the header, submit= the RFC and call it day. Or we can use the body but in that case we probab= ly need to write one spec to define a generic way to return data in OPTIONS= response bodies (e.g. how do different OPTIONS responses live together?) a= nd get that standardized. Then we can write a second RFC to define how our = specific data would be carried in OPTIONS. Thoughts? Yaron From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] Sent: Friday, June 25, 2010 11:09 PM To: Yaron Goland Cc: Eran Hammer-Lahav; James Manger; OAuth WG Subject: Re: [OAUTH-WG] OAuth discovery draft? I think it should be possible to discover a resource's OAuth server and its= capabilities using a direct Discovery request. I don't think a WWW-Authent= icate Header is the right representation for this kind of data. What about = a JSON or XML document returned in response to an OPTIONS request (as you s= uggested) or a GET request with a certain content type in its ACCEPT Header= ? regards, Torsten. Am 23.06.2010 um 20:20 schrieb Yaron Goland <yarong@microsoft.com<mailto:ya= rong@microsoft.com>>: No objections on my part. I would rather have a smaller core spec with feat= ures that everyone agrees on. BTW, a thought for the discovery draft - RFC 2616/2617 only defines www-aut= henticate's semantics in the context of a 401. It's unclear from the draft = what it would mean to return a www-authenticate header on a 200 response. T= he reason I care about this is that I think it makes sense that if someone = wants to talk to an endpoint they know supports OAuth and need to know wher= e their token issuer location is they would want to fire off an OPTIONS req= uest to the resource and find out from the response where the issuer is and= what realm is being used. It seems to me that the simplest way to solve th= is problem is to just return www-authenticate on a 200 response to an OPTIO= NS request. Thoughts? Thanks, Yaron From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Wednesday, June 23, 2010 11:04 AM To: Yaron Goland; James Manger; OAuth WG Subject: Re: OAuth discovery draft? I think the core work is pretty stable now, unlike the discovery bits which= (while simple) are not enjoying the same level of consensus. I think it is= much more practical to propose them as a separate document and perhaps con= sider merging them later on when they reach an equal level of stability. Bu= t overall, I'm not too worries about multiple documents. EHL On 6/23/10 11:00 AM, "Yaron Goland" <yarong@microsoft.com<mailto:yarong@mic= rosoft.com>> wrote: I've been noodling [1] a lot about full delegation in OAuth [2] and one of = the issues that came out of that was the need for discovering both the loca= tion and realm of an endpoint's token server. But at least for my use cases= (which consist of walking up to a service and making an options request an= d getting back a www-authenticate header) all I need back is a realm and a = token server URL. In other words just having one argument added to our www-= authenticate header would be enough to solve the case where someone wants t= o walk up to a service and find out where its token server is. Does that re= ally need its own spec? Or can we just add an argument to www-authenticate = in the current spec? Thanks, Yaron [1] See http://www.goland.org/oauthgenericdelegation/ for an overview of my= thinking on full delegation in OAuth. At the very end are links to a bunch= of other much more in-depth articles on particular subjects touched on in = the main article. [2] I define 'full delegation' as "User X of Service Y grants permission Z = to User A of Service B". Currently OAuth requires X =3D=3D A. In the future= I hope to see extensions to OAuth that enable what I'm terming 'full deleg= ation'. But personally I'm really happy that OAuth has the X=3D=3DA restric= tion. It simplifies a whole host of issues and satisfies a really important= use case. > -----Original Message----- > From: oauth-bounces@ietf.org<mailto:oauth-bounces@ietf.org> [mailto:oauth= -bounces@ietf.org] On Behalf > Of Eran Hammer-Lahav > Sent: Monday, June 21, 2010 9:50 PM > To: Manger, James H; OAuth WG (oauth@ietf.org<mailto:oauth@ietf.org>) > Subject: Re: [OAUTH-WG] OAuth discovery draft? > > Yes, it's on my desk and not yet ready, but I am working on one. It inclu= des > your sites proposal among other things. I am trying to get the core spec > stable this week and focus on that next. > > EHL > > > -----Original Message----- > > From: Manger, James H [mailto:James.H.Manger@team.telstra.com] > > Sent: Monday, June 21, 2010 8:03 PM > > To: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org<mailto:oauth@ietf.org>) > > Subject: OAuth discovery draft? > > > > Eran, > > > > There have been a few mentions recently of an OAuth discovery draft. > > Is there any such draft yet, or is this just a part that we know needs > > to be done? > > > > The email on "OAuth meeting notes on -05 (with updates)" said: > > > > >> 6.1.1. - describing the WWW-Authenticate response header > > >> > > >> - Discovery needed for various elements > > > > > > Yes. That's for the discovery draft. > > > > > > A wiki page on "Future OpenID Technical Requirements" > > <http://wiki.openid.net/Future-OpenID-Technical-Requirements> says: > > > > > 6) IdP Discovery > > > > > > * Much of this will be covered by OAuth2 Discovery, > > > however OIC may need to define OpenID specific features. > > >... > > > 17) Simpler discovery > > > > > > * See Eran's OAuth Discovery proposal > > > > > > There was an OAuth 1.0 Discovery draft over 2 years ago, but that is ta= gged: > > "expired", "marked as obsolete by its author", "discouraged from > > implementing", "no update is expected", "replaced by the OAuth 2.0 > effort". > > > > I know I should write a discovery draft myself. > > > > -- > > James Manger > _______________________________________________ > OAuth mailing list > OAuth@ietf.org<mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth --_000_7C01E631FF4B654FA1E783F1C0265F8C579D21BDTK5EX14MBXC117r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"> <!--[if !mso]><style>v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} </style><![endif]--><style><!-- /* Font Definitions */ @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} p.MsoAcetate, li.MsoAcetate, div.MsoAcetate {mso-style-priority:99; mso-style-link:"Balloon Text Char"; margin:0in; margin-bottom:.0001pt; font-size:8.0pt; font-family:"Tahoma","sans-serif";} span.BalloonTextChar {mso-style-name:"Balloon Text Char"; mso-style-priority:99; mso-style-link:"Balloon Text"; font-family:"Tahoma","sans-serif";} span.apple-style-span {mso-style-name:apple-style-span;} span.EmailStyle20 {mso-style-type:personal; font-family:"Calibri","sans-serif"; color:#1F497D;} span.EmailStyle21 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body bgcolor=3D"white" lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">This then goes back to on= e of my original posts which is – Is www-authenticate legal on a non-= 401 response? I honestly don’t know.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in = 4.0pt"> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:"= ;Tahoma","sans-serif"">From:</span></b><span style=3D"font-s= ize:10.0pt;font-family:"Tahoma","sans-serif""> William = Mills [mailto:wmills@yahoo-inc.com] <br> <b>Sent:</b> Monday, June 28, 2010 3:30 PM<br> <b>To:</b> Yaron Goland; Torsten Lodderstedt<br> <b>Cc:</b> OAuth WG<br> <b>Subject:</b> RE: [OAUTH-WG] OAuth discovery draft?<o:p></o:p></span></p> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Ar= ial","sans-serif";color:blue">In the SASL stuff I'm working = on I was presuming I'd use the WWW-Authenticate header for returning the di= scovery info.</span><o:p></o:p></p> <blockquote style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0= in 0in 4.0pt;margin-left:3.75pt;margin-top:5.0pt;margin-right:0in;margin-bo= ttom:5.0pt"> <p class=3D"MsoNormal"><o:p> </o:p></p> <div class=3D"MsoNormal" align=3D"center" style=3D"text-align:center"> <hr size=3D"2" width=3D"100%" align=3D"center"> </div> <p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b><span style=3D"fon= t-size:10.0pt;font-family:"Tahoma","sans-serif"">From:<= /span></b><span style=3D"font-size:10.0pt;font-family:"Tahoma",&q= uot;sans-serif""> oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.or= g] <b>On Behalf Of </b>Yaron Goland<br> <b>Sent:</b> Monday, June 28, 2010 3:10 PM<br> <b>To:</b> Torsten Lodderstedt<br> <b>Cc:</b> OAuth WG<br> <b>Subject:</b> Re: [OAUTH-WG] OAuth discovery draft?</span><o:p></o:p></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">I believe that GET should= be used to return the resource’s state and its OAuth token endpoint = is just a tiny part of that state. When we want to return part of the state we typically use either explicit headers (a la byte ranges) o= r a query parameter. Content-types should, I think, just control the syntax= of what is returned, not the subset of data it contains. So I have to admi= t that I really don’t like using GET for this sort of scenario.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">OPTIONS is actually the o= fficially blessed way to walk up to a resource, knock on the front door and= ask ‘what are you and what can you do?’ So it seems to me we should start with OPTIONS. But this does bring up a problem – = nobody ever really defined a response body for OPTIONS. RFC 2616 explicitly= defined the legality of such a body but no standard was defined for what t= he body should look like. This is an issue because if someone does define a body for OPTIONS then they really need to= do so in a way that other standards can build on top of.<o:p></o:p></span>= </p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">So we have a choice when = it comes to using OPTIONS. We can return data in the header in which case a= ll we have to do is just define the header, submit the RFC and call it day. Or we can use the body but in that case we probably need = to write one spec to define a generic way to return data in OPTIONS respons= e bodies (e.g. how do different OPTIONS responses live together?) and get t= hat standardized. Then we can write a second RFC to define how our specific data would be carried in OPTIONS.<= o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">    &= nbsp;           Thoughts?= <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">    &= nbsp;           &nbs= p;            &= nbsp;  Yaron<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in = 4.0pt"> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:"= ;Tahoma","sans-serif"">From:</span></b><span style=3D"font-s= ize:10.0pt;font-family:"Tahoma","sans-serif""> Torsten = Lodderstedt [mailto:torsten@lodderstedt.net] <br> <b>Sent:</b> Friday, June 25, 2010 11:09 PM<br> <b>To:</b> Yaron Goland<br> <b>Cc:</b> Eran Hammer-Lahav; James Manger; OAuth WG<br> <b>Subject:</b> Re: [OAUTH-WG] OAuth discovery draft?<o:p></o:p></span></p> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <div> <p class=3D"MsoNormal">I think it should be possible to discover a resource= 's OAuth server and its capabilities using a direct Discovery request. I do= n't think a WWW-Authenticate Header is the right representation for this ki= nd of data. What about a JSON or XML document returned in response to an OPTIONS r<span class=3D"apple-style-sp= an">equest (as you suggested) or a GET request with a certain content type = in its ACCEPT Header?</span><o:p></o:p></p> </div> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal">regards,<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">Torsten. <o:p></= o:p></p> </div> <div> <p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br> Am 23.06.2010 um 20:20 schrieb Yaron Goland <<a href=3D"mailto:yarong@mi= crosoft.com">yarong@microsoft.com</a>>:<o:p></o:p></p> </div> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <div> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"><span style=3D"font-size:11.0pt;font-family:"Calibri",&q= uot;sans-serif";color:#1F497D">No objections on my part. I would rathe= r have a smaller core spec with features that everyone agrees on.</span><o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"><span style=3D"font-size:11.0pt;font-family:"Calibri",&q= uot;sans-serif";color:#1F497D"> </span><o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"><span style=3D"font-size:11.0pt;font-family:"Calibri",&q= uot;sans-serif";color:#1F497D">BTW, a thought for the discovery draft = – RFC 2616/2617 only defines www-authenticate’s semantics in the context of a 401. It’s unclear from the draft what it would m= ean to return a www-authenticate header on a 200 response. The reason I car= e about this is that I think it makes sense that if someone wants to talk t= o an endpoint they know supports OAuth and need to know where their token issuer location is they would want to f= ire off an OPTIONS request to the resource and find out from the response w= here the issuer is and what realm is being used. It seems to me that the si= mplest way to solve this problem is to just return www-authenticate on a 200 response to an OPTIONS request= . </span> <o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"><span style=3D"font-size:11.0pt;font-family:"Calibri",&q= uot;sans-serif";color:#1F497D"> </span><o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"><span style=3D"font-size:11.0pt;font-family:"Calibri",&q= uot;sans-serif";color:#1F497D">      &nb= sp;         Thoughts?</span><o:p></= o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"><span style=3D"font-size:11.0pt;font-family:"Calibri",&q= uot;sans-serif";color:#1F497D"> </span><o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"><span style=3D"font-size:11.0pt;font-family:"Calibri",&q= uot;sans-serif";color:#1F497D">      &nb= sp;            =              Th= anks,</span><o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"><span style=3D"font-size:11.0pt;font-family:"Calibri",&q= uot;sans-serif";color:#1F497D"> </span><o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"><span style=3D"font-size:11.0pt;font-family:"Calibri",&q= uot;sans-serif";color:#1F497D">      &nb= sp;            =             &nb= sp;            =     Yaron</span><o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"><span style=3D"font-size:11.0pt;font-family:"Calibri",&q= uot;sans-serif";color:#1F497D"> </span><o:p></o:p></p> <div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in = 4.0pt"> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"><b><span style=3D"font-size:10.0pt;font-family:"Tahoma",= "sans-serif"">From:</span></b><span style=3D"font-size:10.0pt;fon= t-family:"Tahoma","sans-serif""> Eran Hammer-Lahav [mai= lto:eran@hueniverse.com] <br> <b>Sent:</b> Wednesday, June 23, 2010 11:04 AM<br> <b>To:</b> Yaron Goland; James Manger; OAuth WG<br> <b>Subject:</b> Re: OAuth discovery draft?</span><o:p></o:p></p> </div> </div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p= t"><span style=3D"font-size:11.0pt;font-family:"Calibri","sa= ns-serif"">I think the core work is pretty stable now, unlike the disc= overy bits which (while simple) are not enjoying the same level of consensus. I think it is much more practical to propose them as a= separate document and perhaps consider merging them later on when they rea= ch an equal level of stability. But overall, I’m not too worries abou= t multiple documents.<br> <br> EHL<br> <br> <br> On 6/23/10 11:00 AM, "Yaron Goland" <<a href=3D"mailto:yarong@= microsoft.com">yarong@microsoft.com</a>> wrote:</span><o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p= t"><span style=3D"font-size:11.0pt;font-family:"Calibri","sa= ns-serif"">I've been noodling [1] a lot about full delegation in OAuth= [2] and one of the issues that came out of that was the need for discovering both the location and realm of an endpoint's token server.= But at least for my use cases (which consist of walking up to a service an= d making an options request and getting back a www-authenticate header) all= I need back is a realm and a token server URL. In other words just having one argument added to our www-authe= nticate header would be enough to solve the case where someone wants to wal= k up to a service and find out where its token server is. Does that really = need its own spec? Or can we just add an argument to www-authenticate in the current spec?<br>         Thanks,<br>             &nb= sp;   Yaron<br> <br> [1] See <a href=3D"http://www.goland.org/oauthgenericdelegation/">http://ww= w.goland.org/oauthgenericdelegation/</a> for an overview of my thinking on = full delegation in OAuth. At the very end are links to a bunch of other muc= h more in-depth articles on particular subjects touched on in the main article.<br> <br> [2] I define 'full delegation' as "User X of Service Y grants permissi= on Z to User A of Service B". Currently OAuth requires X =3D=3D A. In = the future I hope to see extensions to OAuth that enable what I'm terming '= full delegation'. But personally I'm really happy that OAuth has the X=3D=3DA restriction. It simplifies a whole host of iss= ues and satisfies a really important use case.<br> <br> > -----Original Message-----<br> > From: <a href=3D"mailto:oauth-bounces@ietf.org">oauth-bounces@ietf.org= </a> [<a href=3D"mailto:oauth-bounces@ietf.org">mailto:oauth-bounces@ietf.o= rg</a>] On Behalf<br> > Of Eran Hammer-Lahav<br> > Sent: Monday, June 21, 2010 9:50 PM<br> > To: Manger, James H; OAuth WG (<a href=3D"mailto:oauth@ietf.org">oauth= @ietf.org</a>)<br> > Subject: Re: [OAUTH-WG] OAuth discovery draft?<br> ><br> > Yes, it's on my desk and not yet ready, but I am working on one. It in= cludes<br> > your sites proposal among other things. I am trying to get the core sp= ec<br> > stable this week and focus on that next.<br> ><br> > EHL<br> ><br> > > -----Original Message-----<br> > > From: Manger, James H [<a href=3D"mailto:James.H.Manger@team.tels= tra.com">mailto:James.H.Manger@team.telstra.com</a>]<br> > > Sent: Monday, June 21, 2010 8:03 PM<br> > > To: Eran Hammer-Lahav; OAuth WG (<a href=3D"mailto:oauth@ietf.org= ">oauth@ietf.org</a>)<br> > > Subject: OAuth discovery draft?<br> > ><br> > > Eran,<br> > ><br> > > There have been a few mentions recently of an OAuth discovery dra= ft.<br> > > Is there any such draft yet, or is this just a part that we know = needs<br> > > to be done?<br> > ><br> > > The email on "OAuth meeting notes on -05 (with updates)"= ; said:<br> > ><br> > > >> 6.1.1. - describing the WWW-Authenticate response header= <br> > > >><br> > > >> - Discovery needed for various elements<br> > > ><br> > > > Yes. That's for the discovery draft.<br> > ><br> > ><br> > > A wiki page on "Future OpenID Technical Requirements"<b= r> > > <<a href=3D"http://wiki.openid.net/Future-OpenID-Technical-Req= uirements">http://wiki.openid.net/Future-OpenID-Technical-Requirements</a>&= gt; says:<br> > ><br> > > > 6) IdP Discovery<br> > > ><br> > > >    * Much of this will be covered by OAuth2 D= iscovery,<br> > > >      however OIC may need to define= OpenID specific features.<br> > > >…<br> > > > 17) Simpler discovery<br> > > ><br> > > >    * See Eran's OAuth Discovery proposal<br> > ><br> > ><br> > > There was an OAuth 1.0 Discovery draft over 2 years ago, but that= is tagged:<br> > > "expired", "marked as obsolete by its author"= , "discouraged from<br> > > implementing", "no update is expected", "repl= aced by the OAuth 2.0<br> > effort".<br> > ><br> > > I know I should write a discovery draft myself.<br> > ><br> > > --<br> > > James Manger<br> > _______________________________________________<br> > OAuth mailing list<br> > <a href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a><br> > <a href=3D"https://www.ietf.org/mailman/listinfo/oauth">https://www.ie= tf.org/mailman/listinfo/oauth</a></span><o:p></o:p></p> </div> </div> </div> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <div> <p class=3D"MsoNormal">_______________________________________________<br> OAuth mailing list<br> <a href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/oauth">https://www.ietf.or= g/mailman/listinfo/oauth</a><o:p></o:p></p> </div> </blockquote> </div> </blockquote> </div> </div> </body> </html> --_000_7C01E631FF4B654FA1E783F1C0265F8C579D21BDTK5EX14MBXC117r_-- From eran@hueniverse.com Tue Jun 29 12:32:02 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DCA63A6C33 for <oauth@core3.amsl.com>; Tue, 29 Jun 2010 12:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.231 X-Spam-Level: X-Spam-Status: No, score=-2.231 tagged_above=-999 required=5 tests=[AWL=0.367, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NRT8WA8PXGUp for <oauth@core3.amsl.com>; Tue, 29 Jun 2010 12:31:37 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 2DE063A6C07 for <oauth@ietf.org>; Tue, 29 Jun 2010 12:31:29 -0700 (PDT) Received: (qmail 3700 invoked from network); 29 Jun 2010 19:31:24 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 29 Jun 2010 19:31:21 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Tue, 29 Jun 2010 12:31:11 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: Yaron Goland <yarong@microsoft.com>, William Mills <wmills@yahoo-inc.com>, Torsten Lodderstedt <torsten@lodderstedt.net> Date: Tue, 29 Jun 2010 12:31:16 -0700 Thread-Topic: [OAUTH-WG] OAuth discovery draft? Thread-Index: AQHLEbd88ANnc80E8EanM4mdFaHtZpKN3qcAgAH2zrCAAAP3tYAAAdRggARizoCAA7n10IAAByYwgAFfxjCAAAC4UA== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4BE95@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <7C01E631FF4B654FA1E783F1C0265F8C579C6DC3@TK5EX14MBXC117.redmond.corp.microsoft.com><C8479A94.363F3%eran@hueniverse.com><7C01E631FF4B654FA1E783F1C0265F8C579C6E52@TK5EX14MBXC117.redmond.corp.microsoft.com><CDD1DDBF-BD1B-4F4E-8620-AA2FEC402C90@lodderstedt.net> <7C01E631FF4B654FA1E783F1C0265F8C579D0FED@TK5EX14MBXC117.redmond.corp.microsoft.com> <012AB2B223CB3F4BB846962876F47217059B677B@SNV-EXVS08.ds.corp.yahoo.com> <7C01E631FF4B654FA1E783F1C0265F8C579D21BD@TK5EX14MBXC117.redmond.corp.microsoft.com> In-Reply-To: <7C01E631FF4B654FA1E783F1C0265F8C579D21BD@TK5EX14MBXC117.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_90C41DD21FB7C64BB94121FBBC2E72343B3ED4BE95P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] OAuth discovery draft? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 29 Jun 2010 19:32:02 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3ED4BE95P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It is. 401 without it is not. The discovery spec should spell out how to include it with a 200 response w= hen additional, private data is available. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Y= aron Goland Sent: Tuesday, June 29, 2010 12:28 PM To: William Mills; Torsten Lodderstedt Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth discovery draft? This then goes back to one of my original posts which is - Is www-authentic= ate legal on a non-401 response? I honestly don't know. From: William Mills [mailto:wmills@yahoo-inc.com] Sent: Monday, June 28, 2010 3:30 PM To: Yaron Goland; Torsten Lodderstedt Cc: OAuth WG Subject: RE: [OAUTH-WG] OAuth discovery draft? In the SASL stuff I'm working on I was presuming I'd use the WWW-Authentica= te header for returning the discovery info. ________________________________ From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Y= aron Goland Sent: Monday, June 28, 2010 3:10 PM To: Torsten Lodderstedt Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth discovery draft? I believe that GET should be used to return the resource's state and its OA= uth token endpoint is just a tiny part of that state. When we want to retur= n part of the state we typically use either explicit headers (a la byte ran= ges) or a query parameter. Content-types should, I think, just control the = syntax of what is returned, not the subset of data it contains. So I have t= o admit that I really don't like using GET for this sort of scenario. OPTIONS is actually the officially blessed way to walk up to a resource, kn= ock on the front door and ask 'what are you and what can you do?' So it see= ms to me we should start with OPTIONS. But this does bring up a problem - n= obody ever really defined a response body for OPTIONS. RFC 2616 explicitly = defined the legality of such a body but no standard was defined for what th= e body should look like. This is an issue because if someone does define a = body for OPTIONS then they really need to do so in a way that other standar= ds can build on top of. So we have a choice when it comes to using OPTIONS. We can return data in t= he header in which case all we have to do is just define the header, submit= the RFC and call it day. Or we can use the body but in that case we probab= ly need to write one spec to define a generic way to return data in OPTIONS= response bodies (e.g. how do different OPTIONS responses live together?) a= nd get that standardized. Then we can write a second RFC to define how our = specific data would be carried in OPTIONS. Thoughts? Yaron From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] Sent: Friday, June 25, 2010 11:09 PM To: Yaron Goland Cc: Eran Hammer-Lahav; James Manger; OAuth WG Subject: Re: [OAUTH-WG] OAuth discovery draft? I think it should be possible to discover a resource's OAuth server and its= capabilities using a direct Discovery request. I don't think a WWW-Authent= icate Header is the right representation for this kind of data. What about = a JSON or XML document returned in response to an OPTIONS request (as you s= uggested) or a GET request with a certain content type in its ACCEPT Header= ? regards, Torsten. Am 23.06.2010 um 20:20 schrieb Yaron Goland <yarong@microsoft.com<mailto:ya= rong@microsoft.com>>: No objections on my part. I would rather have a smaller core spec with feat= ures that everyone agrees on. BTW, a thought for the discovery draft - RFC 2616/2617 only defines www-aut= henticate's semantics in the context of a 401. It's unclear from the draft = what it would mean to return a www-authenticate header on a 200 response. T= he reason I care about this is that I think it makes sense that if someone = wants to talk to an endpoint they know supports OAuth and need to know wher= e their token issuer location is they would want to fire off an OPTIONS req= uest to the resource and find out from the response where the issuer is and= what realm is being used. It seems to me that the simplest way to solve th= is problem is to just return www-authenticate on a 200 response to an OPTIO= NS request. Thoughts? Thanks, Yaron From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Wednesday, June 23, 2010 11:04 AM To: Yaron Goland; James Manger; OAuth WG Subject: Re: OAuth discovery draft? I think the core work is pretty stable now, unlike the discovery bits which= (while simple) are not enjoying the same level of consensus. I think it is= much more practical to propose them as a separate document and perhaps con= sider merging them later on when they reach an equal level of stability. Bu= t overall, I'm not too worries about multiple documents. EHL On 6/23/10 11:00 AM, "Yaron Goland" <yarong@microsoft.com<mailto:yarong@mic= rosoft.com>> wrote: I've been noodling [1] a lot about full delegation in OAuth [2] and one of = the issues that came out of that was the need for discovering both the loca= tion and realm of an endpoint's token server. But at least for my use cases= (which consist of walking up to a service and making an options request an= d getting back a www-authenticate header) all I need back is a realm and a = token server URL. In other words just having one argument added to our www-= authenticate header would be enough to solve the case where someone wants t= o walk up to a service and find out where its token server is. Does that re= ally need its own spec? Or can we just add an argument to www-authenticate = in the current spec? Thanks, Yaron [1] See http://www.goland.org/oauthgenericdelegation/ for an overview of my= thinking on full delegation in OAuth. At the very end are links to a bunch= of other much more in-depth articles on particular subjects touched on in = the main article. [2] I define 'full delegation' as "User X of Service Y grants permission Z = to User A of Service B". Currently OAuth requires X =3D=3D A. In the future= I hope to see extensions to OAuth that enable what I'm terming 'full deleg= ation'. But personally I'm really happy that OAuth has the X=3D=3DA restric= tion. It simplifies a whole host of issues and satisfies a really important= use case. > -----Original Message----- > From: oauth-bounces@ietf.org<mailto:oauth-bounces@ietf.org> [mailto:oauth= -bounces@ietf.org] On Behalf > Of Eran Hammer-Lahav > Sent: Monday, June 21, 2010 9:50 PM > To: Manger, James H; OAuth WG (oauth@ietf.org<mailto:oauth@ietf.org>) > Subject: Re: [OAUTH-WG] OAuth discovery draft? > > Yes, it's on my desk and not yet ready, but I am working on one. It inclu= des > your sites proposal among other things. I am trying to get the core spec > stable this week and focus on that next. > > EHL > > > -----Original Message----- > > From: Manger, James H [mailto:James.H.Manger@team.telstra.com] > > Sent: Monday, June 21, 2010 8:03 PM > > To: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org<mailto:oauth@ietf.org>) > > Subject: OAuth discovery draft? > > > > Eran, > > > > There have been a few mentions recently of an OAuth discovery draft. > > Is there any such draft yet, or is this just a part that we know needs > > to be done? > > > > The email on "OAuth meeting notes on -05 (with updates)" said: > > > > >> 6.1.1. - describing the WWW-Authenticate response header > > >> > > >> - Discovery needed for various elements > > > > > > Yes. That's for the discovery draft. > > > > > > A wiki page on "Future OpenID Technical Requirements" > > <http://wiki.openid.net/Future-OpenID-Technical-Requirements> says: > > > > > 6) IdP Discovery > > > > > > * Much of this will be covered by OAuth2 Discovery, > > > however OIC may need to define OpenID specific features. > > >... > > > 17) Simpler discovery > > > > > > * See Eran's OAuth Discovery proposal > > > > > > There was an OAuth 1.0 Discovery draft over 2 years ago, but that is ta= gged: > > "expired", "marked as obsolete by its author", "discouraged from > > implementing", "no update is expected", "replaced by the OAuth 2.0 > effort". > > > > I know I should write a discovery draft myself. > > > > -- > > James Manger > _______________________________________________ > OAuth mailing list > OAuth@ietf.org<mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth --_000_90C41DD21FB7C64BB94121FBBC2E72343B3ED4BE95P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV=3D"Content-Type" CONTENT= =3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros= oft Word 14 (filtered medium)"><!--[if !mso]><style>v\:* {behavior:url(#def= ault#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} </style><![endif]--><style><!-- /* Font Definitions */ @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} p.MsoAcetate, li.MsoAcetate, div.MsoAcetate {mso-style-priority:99; mso-style-link:"Balloon Text Char"; margin:0in; margin-bottom:.0001pt; font-size:8.0pt; font-family:"Tahoma","sans-serif";} span.BalloonTextChar {mso-style-name:"Balloon Text Char"; mso-style-priority:99; mso-style-link:"Balloon Text"; font-family:"Tahoma","sans-serif";} span.apple-style-span {mso-style-name:apple-style-span;} span.EmailStyle20 {mso-style-type:personal; font-family:"Calibri","sans-serif"; color:#1F497D;} span.EmailStyle21 {mso-style-type:personal; font-family:"Calibri","sans-serif"; color:#1F497D;} span.EmailStyle22 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--></head><body bgcolor=3Dwhite lang=3DEN-US= link=3Dblue vlink=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal>= <span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1= F497D'>It is. 401 without it is not.<o:p></o:p></span></p><p class=3DMsoNor= mal><span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";colo= r:#1F497D'><o:p> </o:p></span></p><p class=3DMsoNormal><span style=3D'= font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>The disc= overy spec should spell out how to include it with a 200 response when addi= tional, private data is available.<o:p></o:p></span></p><p class=3DMsoNorma= l><span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:= #1F497D'><o:p> </o:p></span></p><p class=3DMsoNormal><span style=3D'fo= nt-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>EHL<o:p></= o:p></span></p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-fa= mily:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div= style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0p= t'><div><div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.= 0pt 0in 0in 0in'><p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;fo= nt-family:"Tahoma","sans-serif"'>From:</span></b><span style=3D'font-size:1= 0.0pt;font-family:"Tahoma","sans-serif"'> oauth-bounces@ietf.org [mailto:oa= uth-bounces@ietf.org] <b>On Behalf Of </b>Yaron Goland<br><b>Sent:</b> Tues= day, June 29, 2010 12:28 PM<br><b>To:</b> William Mills; Torsten Loddersted= t<br><b>Cc:</b> OAuth WG<br><b>Subject:</b> Re: [OAUTH-WG] OAuth discovery = draft?<o:p></o:p></span></p></div></div><p class=3DMsoNormal><o:p> </o= :p></p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D'>This then goes back to one of my origina= l posts which is – Is www-authenticate legal on a non-401 response? I= honestly don’t know.<o:p></o:p></span></p><p class=3DMsoNormal><span= style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D= '><o:p> </o:p></span></p><div style=3D'border:none;border-left:solid b= lue 1.5pt;padding:0in 0in 0in 4.0pt'><div><div style=3D'border:none;border-= top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=3DMsoNormal><b>= <span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</s= pan></b><span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>= William Mills [mailto:wmills@yahoo-inc.com] <br><b>Sent:</b> Monday, June = 28, 2010 3:30 PM<br><b>To:</b> Yaron Goland; Torsten Lodderstedt<br><b>Cc:<= /b> OAuth WG<br><b>Subject:</b> RE: [OAUTH-WG] OAuth discovery draft?<o:p><= /o:p></span></p></div></div><p class=3DMsoNormal><o:p> </o:p></p><p cl= ass=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","sans-s= erif";color:blue'>In the SASL stuff I'm working on I was presuming I'd use = the WWW-Authenticate header for returning the discovery info.</span><o:p></= o:p></p><blockquote style=3D'border:none;border-left:solid blue 1.5pt;paddi= ng:0in 0in 0in 4.0pt;margin-left:3.75pt;margin-top:5.0pt;margin-right:0in;m= argin-bottom:5.0pt'><p class=3DMsoNormal><o:p> </o:p></p><div class=3D= MsoNormal align=3Dcenter style=3D'text-align:center'><hr size=3D2 width=3D"= 100%" align=3Dcenter></div><p class=3DMsoNormal style=3D'margin-bottom:12.0= pt'><b><span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>F= rom:</span></b><span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-s= erif"'> oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] <b>On Behalf= Of </b>Yaron Goland<br><b>Sent:</b> Monday, June 28, 2010 3:10 PM<br><b>To= :</b> Torsten Lodderstedt<br><b>Cc:</b> OAuth WG<br><b>Subject:</b> Re: [OA= UTH-WG] OAuth discovery draft?</span><o:p></o:p></p><p class=3DMsoNormal><s= pan style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F4= 97D'>I believe that GET should be used to return the resource’s state= and its OAuth token endpoint is just a tiny part of that state. When we wa= nt to return part of the state we typically use either explicit headers (a = la byte ranges) or a query parameter. Content-types should, I think, just c= ontrol the syntax of what is returned, not the subset of data it contains. = So I have to admit that I really don’t like using GET for this sort o= f scenario.<o:p></o:p></span></p><p class=3DMsoNormal><span style=3D'font-s= ize:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o= :p></span></p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-fam= ily:"Calibri","sans-serif";color:#1F497D'>OPTIONS is actually the officiall= y blessed way to walk up to a resource, knock on the front door and ask = 216;what are you and what can you do?’ So it seems to me we should st= art with OPTIONS. But this does bring up a problem – nobody ever real= ly defined a response body for OPTIONS. RFC 2616 explicitly defined the leg= ality of such a body but no standard was defined for what the body should l= ook like. This is an issue because if someone does define a body for OPTION= S then they really need to do so in a way that other standards can build on= top of.<o:p></o:p></span></p><p class=3DMsoNormal><span style=3D'font-size= :11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p>= </span></p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family= :"Calibri","sans-serif";color:#1F497D'>So we have a choice when it comes to= using OPTIONS. We can return data in the header in which case all we have = to do is just define the header, submit the RFC and call it day. Or we can = use the body but in that case we probably need to write one spec to define = a generic way to return data in OPTIONS response bodies (e.g. how do differ= ent OPTIONS responses live together?) and get that standardized. Then we ca= n write a second RFC to define how our specific data would be carried in OP= TIONS.<o:p></o:p></span></p><p class=3DMsoNormal><span style=3D'font-size:1= 1.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></= span></p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"= Calibri","sans-serif";color:#1F497D'>      &n= bsp;         Thoughts?<o:p></o:p></= span></p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"= Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class= =3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri","sans-se= rif";color:#1F497D'>         &= nbsp;           &nbs= p;          Yaron<o:p></o:p></= span></p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"= Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div style= =3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><di= v><div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0i= n 0in 0in'><p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;font-fam= ily:"Tahoma","sans-serif"'>From:</span></b><span style=3D'font-size:10.0pt;= font-family:"Tahoma","sans-serif"'> Torsten Lodderstedt [mailto:torsten@lod= derstedt.net] <br><b>Sent:</b> Friday, June 25, 2010 11:09 PM<br><b>To:</b>= Yaron Goland<br><b>Cc:</b> Eran Hammer-Lahav; James Manger; OAuth WG<br><b= >Subject:</b> Re: [OAUTH-WG] OAuth discovery draft?<o:p></o:p></span></p></= div></div><p class=3DMsoNormal><o:p> </o:p></p><div><p class=3DMsoNorm= al>I think it should be possible to discover a resource's OAuth server and = its capabilities using a direct Discovery request. I don't think a WWW-Auth= enticate Header is the right representation for this kind of data. What abo= ut a JSON or XML document returned in response to an OPTIONS r<span class= =3Dapple-style-span>equest (as you suggested) or a GET request with a certa= in content type in its ACCEPT Header?</span><o:p></o:p></p></div><div><p cl= ass=3DMsoNormal><o:p> </o:p></p></div><div><p class=3DMsoNormal>regard= s,<o:p></o:p></p></div><div><p class=3DMsoNormal style=3D'margin-bottom:12.= 0pt'>Torsten. <o:p></o:p></p></div><div><p class=3DMsoNormal style=3D'= margin-bottom:12.0pt'><br>Am 23.06.2010 um 20:20 schrieb Yaron Goland <<= a href=3D"mailto:yarong@microsoft.com">yarong@microsoft.com</a>>:<o:p></= o:p></p></div><blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt'><d= iv><div><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bo= ttom-alt:auto'><span style=3D'font-size:11.0pt;font-family:"Calibri","sans-= serif";color:#1F497D'>No objections on my part. I would rather have a small= er core spec with features that everyone agrees on.</span><o:p></o:p></p><p= class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:a= uto'><span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";col= or:#1F497D'> </span><o:p></o:p></p><p class=3DMsoNormal style=3D'mso-m= argin-top-alt:auto;mso-margin-bottom-alt:auto'><span style=3D'font-size:11.= 0pt;font-family:"Calibri","sans-serif";color:#1F497D'>BTW, a thought for th= e discovery draft – RFC 2616/2617 only defines www-authenticate’= ;s semantics in the context of a 401. It’s unclear from the draft wha= t it would mean to return a www-authenticate header on a 200 response. The = reason I care about this is that I think it makes sense that if someone wan= ts to talk to an endpoint they know supports OAuth and need to know where t= heir token issuer location is they would want to fire off an OPTIONS reques= t to the resource and find out from the response where the issuer is and wh= at realm is being used. It seems to me that the simplest way to solve this = problem is to just return www-authenticate on a 200 response to an OPTIONS = request. </span><o:p></o:p></p><p class=3DMsoNormal style=3D'mso-margin-top= -alt:auto;mso-margin-bottom-alt:auto'><span style=3D'font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p= class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:a= uto'><span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";col= or:#1F497D'>          &nb= sp;     Thoughts?</span><o:p></o:p></p><p class=3DMsoNo= rmal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span sty= le=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>&n= bsp;</span><o:p></o:p></p><p class=3DMsoNormal style=3D'mso-margin-top-alt:= auto;mso-margin-bottom-alt:auto'><span style=3D'font-size:11.0pt;font-famil= y:"Calibri","sans-serif";color:#1F497D'>      = ;            &n= bsp;            = ; Thanks,</span><o:p></o:p></p><p class=3DMsoNormal style=3D'mso-margin-top= -alt:auto;mso-margin-bottom-alt:auto'><span style=3D'font-size:11.0pt;font-= family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p= class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:a= uto'><span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";col= or:#1F497D'>          &nb= sp;            =             &nb= sp;            Yaron= </span><o:p></o:p></p><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto= ;mso-margin-bottom-alt:auto'><span style=3D'font-size:11.0pt;font-family:"C= alibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><div style= =3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><di= v><div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0i= n 0in 0in'><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin= -bottom-alt:auto'><b><span style=3D'font-size:10.0pt;font-family:"Tahoma","= sans-serif"'>From:</span></b><span style=3D'font-size:10.0pt;font-family:"T= ahoma","sans-serif"'> Eran Hammer-Lahav [mailto:eran@hueniverse.com] <br><b= >Sent:</b> Wednesday, June 23, 2010 11:04 AM<br><b>To:</b> Yaron Goland; Ja= mes Manger; OAuth WG<br><b>Subject:</b> Re: OAuth discovery draft?</span><o= :p></o:p></p></div></div><p class=3DMsoNormal style=3D'mso-margin-top-alt:a= uto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=3DMsoNormal s= tyle=3D'mso-margin-top-alt:auto;margin-bottom:12.0pt'><span style=3D'font-s= ize:11.0pt;font-family:"Calibri","sans-serif"'>I think the core work is pre= tty stable now, unlike the discovery bits which (while simple) are not enjo= ying the same level of consensus. I think it is much more practical to prop= ose them as a separate document and perhaps consider merging them later on = when they reach an equal level of stability. But overall, I’m not too= worries about multiple documents.<br><br>EHL<br><br><br>On 6/23/10 11:00 A= M, "Yaron Goland" <<a href=3D"mailto:yarong@microsoft.com">yar= ong@microsoft.com</a>> wrote:</span><o:p></o:p></p><p class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;margin-bottom:12.0pt'><span style=3D'font-= size:11.0pt;font-family:"Calibri","sans-serif"'>I've been noodling [1] a lo= t about full delegation in OAuth [2] and one of the issues that came out of= that was the need for discovering both the location and realm of an endpoi= nt's token server. But at least for my use cases (which consist of walking = up to a service and making an options request and getting back a www-authen= ticate header) all I need back is a realm and a token server URL. In other = words just having one argument added to our www-authenticate header would b= e enough to solve the case where someone wants to walk up to a service and = find out where its token server is. Does that really need its own spec? Or = can we just add an argument to www-authenticate in the current spec?<br>&nb= sp;       Thanks,<br>   &= nbsp;           &nbs= p;Yaron<br><br>[1] See <a href=3D"http://www.goland.org/oauthgenericdelegat= ion/">http://www.goland.org/oauthgenericdelegation/</a> for an overview of = my thinking on full delegation in OAuth. At the very end are links to a bun= ch of other much more in-depth articles on particular subjects touched on i= n the main article.<br><br>[2] I define 'full delegation' as "User X o= f Service Y grants permission Z to User A of Service B". Currently OAu= th requires X =3D=3D A. In the future I hope to see extensions to OAuth tha= t enable what I'm terming 'full delegation'. But personally I'm really happ= y that OAuth has the X=3D=3DA restriction. It simplifies a whole host of is= sues and satisfies a really important use case.<br><br>> -----Original M= essage-----<br>> From: <a href=3D"mailto:oauth-bounces@ietf.org">oauth-b= ounces@ietf.org</a> [<a href=3D"mailto:oauth-bounces@ietf.org">mailto:oauth= -bounces@ietf.org</a>] On Behalf<br>> Of Eran Hammer-Lahav<br>> Sent:= Monday, June 21, 2010 9:50 PM<br>> To: Manger, James H; OAuth WG (<a hr= ef=3D"mailto:oauth@ietf.org">oauth@ietf.org</a>)<br>> Subject: Re: [OAUT= H-WG] OAuth discovery draft?<br>><br>> Yes, it's on my desk and not y= et ready, but I am working on one. It includes<br>> your sites proposal = among other things. I am trying to get the core spec<br>> stable this we= ek and focus on that next.<br>><br>> EHL<br>><br>> > -----Or= iginal Message-----<br>> > From: Manger, James H [<a href=3D"mailto:J= ames.H.Manger@team.telstra.com">mailto:James.H.Manger@team.telstra.com</a>]= <br>> > Sent: Monday, June 21, 2010 8:03 PM<br>> > To: Eran Ham= mer-Lahav; OAuth WG (<a href=3D"mailto:oauth@ietf.org">oauth@ietf.org</a>)<= br>> > Subject: OAuth discovery draft?<br>> ><br>> > Eran= ,<br>> ><br>> > There have been a few mentions recently of an O= Auth discovery draft.<br>> > Is there any such draft yet, or is this = just a part that we know needs<br>> > to be done?<br>> ><br>>= ; > The email on "OAuth meeting notes on -05 (with updates)" s= aid:<br>> ><br>> > >> 6.1.1. - describing the WWW-Authent= icate response header<br>> > >><br>> > >> - Discove= ry needed for various elements<br>> > ><br>> > > Yes. Tha= t's for the discovery draft.<br>> ><br>> ><br>> > A wiki = page on "Future OpenID Technical Requirements"<br>> > <<= a href=3D"http://wiki.openid.net/Future-OpenID-Technical-Requirements">http= ://wiki.openid.net/Future-OpenID-Technical-Requirements</a>> says:<br>&g= t; ><br>> > > 6) IdP Discovery<br>> > ><br>> > &= gt;    * Much of this will be covered by OAuth2 Discovery,<b= r>> > >      however OIC may need to defi= ne OpenID specific features.<br>> > >…<br>> > > 17)= Simpler discovery<br>> > ><br>> > >    * = See Eran's OAuth Discovery proposal<br>> ><br>> ><br>> > = There was an OAuth 1.0 Discovery draft over 2 years ago, but that is tagged= :<br>> > "expired", "marked as obsolete by its author&= quot;, "discouraged from<br>> > implementing", "no upd= ate is expected", "replaced by the OAuth 2.0<br>> effort"= .<br>> ><br>> > I know I should write a discovery draft myself.= <br>> ><br>> > --<br>> > James Manger<br>> ___________= ____________________________________<br>> OAuth mailing list<br>> <a = href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a><br>> <a href=3D"https:= //www.ietf.org/mailman/listinfo/oauth">https://www.ietf.org/mailman/listinf= o/oauth</a></span><o:p></o:p></p></div></div></div></blockquote><blockquote= style=3D'margin-top:5.0pt;margin-bottom:5.0pt'><div><p class=3DMsoNormal>_= ______________________________________________<br>OAuth mailing list<br><a = href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a><br><a href=3D"https://www= .ietf.org/mailman/listinfo/oauth">https://www.ietf.org/mailman/listinfo/oau= th</a><o:p></o:p></p></div></blockquote></div></blockquote></div></div></di= v></body></html>= --_000_90C41DD21FB7C64BB94121FBBC2E72343B3ED4BE95P3PW5EX1MB01E_-- From yarong@microsoft.com Tue Jun 29 12:33:02 2010 Return-Path: <yarong@microsoft.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8E223A6947 for <oauth@core3.amsl.com>; Tue, 29 Jun 2010 12:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.967 X-Spam-Level: X-Spam-Status: No, score=-9.967 tagged_above=-999 required=5 tests=[AWL=0.631, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lj0mPoaB+71p for <oauth@core3.amsl.com>; Tue, 29 Jun 2010 12:32:49 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 155463A6C38 for <oauth@ietf.org>; Tue, 29 Jun 2010 12:32:32 -0700 (PDT) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 29 Jun 2010 12:32:36 -0700 Received: from TK5EX14MBXC117.redmond.corp.microsoft.com ([169.254.8.23]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.01.0160.007; Tue, 29 Jun 2010 12:32:38 -0700 From: Yaron Goland <yarong@microsoft.com> To: Eran Hammer-Lahav <eran@hueniverse.com>, David Recordon <recordond@gmail.com> Thread-Topic: [OAUTH-WG] How do we deal with unrecognized elements in requests and responses? Thread-Index: AQHLFyjkSOxwQISS7UeqPRPyI6kTDpKZVRZA Date: Tue, 29 Jun 2010 19:32:31 +0000 Message-ID: <7C01E631FF4B654FA1E783F1C0265F8C579D2202@TK5EX14MBXC117.redmond.corp.microsoft.com> References: <7C01E631FF4B654FA1E783F1C0265F8C579D0F52@TK5EX14MBXC117.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4BCB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTin2cvQnXB7x9abGLF4xQyfrv9IzZCzxOHnJqlHQ@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4BCB4@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4BCB4@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7C01E631FF4B654FA1E783F1C0265F8C579D2202TK5EX14MBXC117r_" MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] How do we deal with unrecognized elements in requests and responses? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 29 Jun 2010 19:33:03 -0000 --_000_7C01E631FF4B654FA1E783F1C0265F8C579D2202TK5EX14MBXC117r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Personally I think we should go with #2. Those who need 'mandatory to implement' extensions should do exactly what E= ran suggested and implement the extension in a way that breaks the core syn= tax so they are guaranteed that those who don't support the extension will = fail. Just my two cents, Yaron From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Monday, June 28, 2010 6:17 PM To: David Recordon Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] How do we deal with unrecognized elements in reques= ts and responses? There are times when the client wants the server to fail if it doesn't supp= ort an extension. The client developer might consider the server as being l= ess secure without the added protection of the extension and would like the= server to be able to tell it was making such a request and fail. This clearly belongs in the use cases driving discovery, as in the core spe= cification, the client is expected to be familiar with the details of the s= erver. So we just need to make sure that we don't prevent such use cases. #= 2 doesn't prevent it, but requires the client to break something else. For = example, an extension having to do with client identity should replace the = client_id parameter with something else, making a server unaware of this ex= tension fail (because the required client_id parameter will be missing). EHL From: David Recordon [mailto:recordond@gmail.com] Sent: Monday, June 28, 2010 6:11 PM To: Eran Hammer-Lahav Cc: Yaron Goland; OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] How do we deal with unrecognized elements in reques= ts and responses? For #2, if an extension defines required parameters then you're not support= ing the extension if you ignore them. Or am I missing something? On Mon, Jun 28, 2010 at 5:59 PM, Eran Hammer-Lahav <eran@hueniverse.com<mai= lto:eran@hueniverse.com>> wrote: There are 3 general ways to deal with this: 1. Break on unrecognized parameters - this tends to make the use of extensi= ons hard, and at a minimum requires an error to include the bad parameter i= n a machine readable way (so a library can figure out an extension is not s= upported). 2. Ignore unrecognized parameters - this is the usual way of dealing with e= xtensible protocols. It has security implications when extension parameters= must not be ignored. However, the workaround is simply to break something = else (i.e. replace the client_id with something else that will cause the no= rmal flow to break). 3. Same as #2 but include a directive which means 'must not ignore any para= meter; return error if any parameter is unknown'. XRD used to include such = a 'must-support' attribute for properties but was dropped due to lack of us= e cases. I think #2 offers a good enough balance here, but am happy to discuss #3 if= people have actual use cases where ignoring an extension will cause securi= ty issues. Note that with the expectation of error codes, my upcoming exten= sibility proposal does not allow adding any new parameter values (only new = parameters). EHL From: oauth-bounces@ietf.org<mailto:oauth-bounces@ietf.org> [mailto:oauth-b= ounces@ietf.org<mailto:oauth-bounces@ietf.org>] On Behalf Of Yaron Goland Sent: Monday, June 28, 2010 3:02 PM To: oauth@ietf.org<mailto:oauth@ietf.org> Subject: [OAUTH-WG] How do we deal with unrecognized elements in requests a= nd responses? In a private thread with Eran an issue came up regarding how to handle unre= cognized arguments in OAuth requests and responses. For example, if a token endpoint receives an access token request that cont= ains both a client_id and a client_foo_bar argument, what should it do? Sho= uld it reject the request since it doesn't recognize client_foo_bar? Should= it ignore client_foo_bar and just process the request based on client_id? Similarly imagine that a response to an access token request contains a JSO= N member with some unrecognized name. What's the right behavior? Ignore the= unrecognized value? Or treat the response as badly formatted and fail out? We need to define in the spec how to deal with unrecognized extensions. Typ= ically the rule is 'ignore what you don't recognize' but there is a counter= vailing rule which applies here which is "security is different". Typically= ignoring unrecognized elements in a security context can lead to security = holes. Just looking at the history of OAuth I suspect we need to go with the ignor= e rule and then explore ad nauseam in the security considerations section a= ll the ways that the ignore rule can go wrong if extensions aren't handled = carefully. Thoughts? Thanks, Yaron _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth --_000_7C01E631FF4B654FA1E783F1C0265F8C579D2202TK5EX14MBXC117r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"> <style><!-- /* Font Definitions */ @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} p.MsoAcetate, li.MsoAcetate, div.MsoAcetate {mso-style-priority:99; mso-style-link:"Balloon Text Char"; margin:0in; margin-bottom:.0001pt; font-size:8.0pt; font-family:"Tahoma","sans-serif";} span.BalloonTextChar {mso-style-name:"Balloon Text Char"; mso-style-priority:99; mso-style-link:"Balloon Text"; font-family:"Tahoma","sans-serif";} span.EmailStyle19 {mso-style-type:personal; font-family:"Calibri","sans-serif"; color:#1F497D;} span.EmailStyle20 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">Personally I think we sho= uld go with #2.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">Those who need ‘man= datory to implement’ extensions should do exactly what Eran suggested= and implement the extension in a way that breaks the core syntax so they are guaranteed that those who don’t support the extension will = fail.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">    &= nbsp;           &nbs= p;            &= nbsp;  Just my two cents,<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;      Yaron<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in = 4.0pt"> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:"= ;Tahoma","sans-serif"">From:</span></b><span style=3D"font-s= ize:10.0pt;font-family:"Tahoma","sans-serif""> oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] <b>On Behalf Of </b>Eran Hammer-Lahav<br> <b>Sent:</b> Monday, June 28, 2010 6:17 PM<br> <b>To:</b> David Recordon<br> <b>Cc:</b> OAuth WG (oauth@ietf.org)<br> <b>Subject:</b> Re: [OAUTH-WG] How do we deal with unrecognized elements in= requests and responses?<o:p></o:p></span></p> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">There are times when the = client wants the server to fail if it doesn’t support an extension. T= he client developer might consider the server as being less secure without the added protection of the extension and would like the server to= be able to tell it was making such a request and fail.<o:p></o:p></span></= p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">This clearly belongs in t= he use cases driving discovery, as in the core specification, the client is= expected to be familiar with the details of the server. So we just need to make sure that we don’t prevent such use cases. #= 2 doesn’t prevent it, but requires the client to break something else= . For example, an extension having to do with client identity should replac= e the client_id parameter with something else, making a server unaware of this extension fail (because the required clien= t_id parameter will be missing).<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">EHL<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in = 4.0pt"> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:"= ;Tahoma","sans-serif"">From:</span></b><span style=3D"font-s= ize:10.0pt;font-family:"Tahoma","sans-serif""> David Re= cordon [mailto:recordond@gmail.com] <br> <b>Sent:</b> Monday, June 28, 2010 6:11 PM<br> <b>To:</b> Eran Hammer-Lahav<br> <b>Cc:</b> Yaron Goland; OAuth WG (oauth@ietf.org)<br> <b>Subject:</b> Re: [OAUTH-WG] How do we deal with unrecognized elements in= requests and responses?<o:p></o:p></span></p> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">For #2, if an extension defines required parameters = then you're not supporting the extension if you ignore them. Or am I missin= g something?<o:p></o:p></p> <div> <p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><o:p> </o:p></p> <div> <p class=3D"MsoNormal">On Mon, Jun 28, 2010 at 5:59 PM, Eran Hammer-Lahav &= lt;<a href=3D"mailto:eran@hueniverse.com">eran@hueniverse.com</a>> wrote= :<o:p></o:p></p> <div> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"><span style=3D"color:#1F497D">There are 3 general ways to deal wit= h this:</span><o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"><span style=3D"color:#1F497D"> </span><o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"><span style=3D"color:#1F497D">1. Break on unrecognized parameters = – this tends to make the use of extensions hard, and at a minimum req= uires an error to include the bad parameter in a machine readable way (so a library can figure out an extension is not= supported).</span><o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"><span style=3D"color:#1F497D"> </span><o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"><span style=3D"color:#1F497D">2. Ignore unrecognized parameters &#= 8211; this is the usual way of dealing with extensible protocols. It has se= curity implications when extension parameters must not be ignored. However, the workaround is simply to break something = else (i.e. replace the client_id with something else that will cause the no= rmal flow to break).</span><o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"><span style=3D"color:#1F497D"> </span><o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"><span style=3D"color:#1F497D">3. Same as #2 but include a directiv= e which means ‘must not ignore any parameter; return error if any par= ameter is unknown’. XRD used to include such a ‘must-support’ attribute for properties but was dropped due = to lack of use cases.</span><o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"><span style=3D"color:#1F497D"> </span><o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"><span style=3D"color:#1F497D">I think #2 offers a good enough bala= nce here, but am happy to discuss #3 if people have actual use cases where = ignoring an extension will cause security issues. Note that with the expectation of error codes, my upcoming extensi= bility proposal does not allow adding any new parameter values (only new pa= rameters).</span><o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"><span style=3D"color:#1F497D"> </span><o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"><span style=3D"color:#1F497D">EHL</span><o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"><span style=3D"color:#1F497D"> </span><o:p></o:p></p> <div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in = 4.0pt"> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"><b><span style=3D"font-size:10.0pt">From:</span></b><span style=3D= "font-size:10.0pt"> <a href=3D"mailto:oauth-bounces@ietf.org" target=3D"_blank">oauth-bounces@i= etf.org</a> [mailto:<a href=3D"mailto:oauth-bounces@ietf.org" target=3D"_bl= ank">oauth-bounces@ietf.org</a>] <b>On Behalf Of </b>Yaron Goland<br> <b>Sent:</b> Monday, June 28, 2010 3:02 PM<br> <b>To:</b> <a href=3D"mailto:oauth@ietf.org" target=3D"_blank">oauth@ietf.o= rg</a><br> <b>Subject:</b> [OAUTH-WG] How do we deal with unrecognized elements in req= uests and responses?</span><o:p></o:p></p> </div> </div> <div> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto">In a private thread with Eran an issue came up regarding how to ha= ndle unrecognized arguments in OAuth requests and responses.<o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto">For example, if a token endpoint receives an access token request = that contains both a client_id and a client_foo_bar argument, what should i= t do? Should it reject the request since it doesn’t recognize client_foo_bar? Should it ignore client_foo_bar= and just process the request based on client_id?<o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto">Similarly imagine that a response to an access token request conta= ins a JSON member with some unrecognized name. What’s the right behav= ior? Ignore the unrecognized value? Or treat the response as badly formatted and fail out?<o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto">We need to define in the spec how to deal with unrecognized extens= ions. Typically the rule is ‘ignore what you don’t recognize= 217; but there is a countervailing rule which applies here which is “security is different”. Typically ignoring unre= cognized elements in a security context can lead to security holes.<o:p></o= :p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto">Just looking at the history of OAuth I suspect we need to go with = the ignore rule and then explore ad nauseam in the security considerations = section all the ways that the ignore rule can go wrong if extensions aren’t handled carefully.<o:p></o:p>= </p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto">           =      Thoughts?<o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto">           =             &nb= sp;        Thanks,<o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto"> <o:p></o:p></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto">           =             &nb= sp;            =             Yaron<o:= p></o:p></p> </div> </div> </div> </div> </div> <p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br> _______________________________________________<br> OAuth mailing list<br> <a href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_blank">h= ttps://www.ietf.org/mailman/listinfo/oauth</a><o:p></o:p></p> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> </div> </div> </div> </body> </html> --_000_7C01E631FF4B654FA1E783F1C0265F8C579D2202TK5EX14MBXC117r_-- From tim.ridgely@gmail.com Tue Jun 29 14:56:52 2010 Return-Path: <tim.ridgely@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D35593A69ED for <oauth@core3.amsl.com>; Tue, 29 Jun 2010 14:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TFpKt3UYGiG2 for <oauth@core3.amsl.com>; Tue, 29 Jun 2010 14:56:51 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id B67F428C0E1 for <oauth@ietf.org>; Tue, 29 Jun 2010 14:56:50 -0700 (PDT) Received: by ewy22 with SMTP id 22so40376ewy.31 for <oauth@ietf.org>; Tue, 29 Jun 2010 14:56:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=atJ3CHbfHS0sTLVlDswaZVgtO8ap3XzrWJZGch6OlLE=; b=YbFCkNjWLN6kUDaopuo9xoZzyOXbrAuGzQ9XlleqXOobO8kY0HUvzi/AuPd2ZWF6Wa lhrL1yqOTUG5yYk2wwBQ/AxgLEBTXe7112SvSKt5lpbRanhlO51plizrOxggES/lyxSK m+YhdsQs3P3uPTeI9VZDDWfiaep+Xj6VYXbfE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=bfM7QgPKW1lBkP7KfNY3Ob7wu3R7KVpNcp8J1zdzpUEunNHZyT3NleAHNzE8yE2fpQ RPfU2yYvQPqbkALWfPIjLy1UQYlmRl7759+j2aTEy0HPKaliB8kZYxlzDT1oTpBO71lG YIS71ooPZsU5dmhbtyaz0mRm/a3zN8zC+l1do= MIME-Version: 1.0 Received: by 10.216.90.8 with SMTP id d8mr5890677wef.52.1277848616343; Tue, 29 Jun 2010 14:56:56 -0700 (PDT) Received: by 10.216.70.199 with HTTP; Tue, 29 Jun 2010 14:56:56 -0700 (PDT) Date: Tue, 29 Jun 2010 17:56:56 -0400 Message-ID: <AANLkTilvvdxoNRn2QEMMS5ltabIfW_rW02JrXUdMyEPP@mail.gmail.com> From: Tim Ridgely <tim.ridgely@gmail.com> To: oauth@ietf.org Content-Type: multipart/alternative; boundary=0016e6d778beda99bd048a325072 Subject: [OAUTH-WG] OAuth 2.0 PHP Library - Updated for v9 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 29 Jun 2010 21:56:52 -0000 --0016e6d778beda99bd048a325072 Content-Type: text/plain; charset=ISO-8859-1 Hi everybody, I updated the PHP library to include the changes in draft v9; hopefully I read everything correctly. Feedback always welcome! I also added a sample PHP Data Objects (PDO) implementation, so you can see how it'd work with MySQL, MSSQL, etc. Blog: http://www.opendining.net/category/blog/oauth/ Repo: http://code.google.com/p/oauth2-php/ Thanks! Tim Ridgely http://www.opendining.net --0016e6d778beda99bd048a325072 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi everybody,<div><br></div><div>I updated the PHP library to include the c= hanges in draft v9; hopefully I read everything correctly. =A0Feedback alwa= ys welcome!</div><div><br></div><div>I also added a sample PHP Data Objects= (PDO) implementation, so you can see how it'd work with MySQL, MSSQL, = etc.</div> <div><br></div><div>Blog:=A0<a href=3D"http://www.opendining.net/category/b= log/oauth/">http://www.opendining.net/category/blog/oauth/</a></div><div>Re= po:=A0<a href=3D"http://code.google.com/p/oauth2-php/">http://code.google.c= om/p/oauth2-php/</a></div> <div><br></div><div>Thanks!</div><div>Tim Ridgely</div><div><a href=3D"http= ://www.opendining.net">http://www.opendining.net</a></div> --0016e6d778beda99bd048a325072-- From James.H.Manger@team.telstra.com Tue Jun 29 17:07:30 2010 Return-Path: <James.H.Manger@team.telstra.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE8E53A6A51 for <oauth@core3.amsl.com>; Tue, 29 Jun 2010 17:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.09 X-Spam-Level: X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[AWL=0.991, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lB6yZPJNdTSI for <oauth@core3.amsl.com>; Tue, 29 Jun 2010 17:07:30 -0700 (PDT) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by core3.amsl.com (Postfix) with ESMTP id D5DFB3A68A7 for <oauth@ietf.org>; Tue, 29 Jun 2010 17:07:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,508,1272808800"; d="scan'208";a="5115681" Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipobvi.tcif.telstra.com.au with ESMTP; 30 Jun 2010 10:07:35 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6028"; a="3799139" Received: from wsmsg3755.srv.dir.telstra.com ([172.49.40.196]) by ipccvi.tcif.telstra.com.au with ESMTP; 30 Jun 2010 10:07:36 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3755.srv.dir.telstra.com ([172.49.40.196]) with mapi; Wed, 30 Jun 2010 10:07:36 +1000 From: "Manger, James H" <James.H.Manger@team.telstra.com> To: Marius Scurtescu <mscurtescu@google.com> Date: Wed, 30 Jun 2010 10:07:34 +1000 Thread-Topic: [OAUTH-WG] Proposal for text for section 2 Thread-Index: AcsXrGDU+cOkXD6yQpS4lCbUJEfEswANljAA Message-ID: <255B9BB34FB7D647A506DC292726F6E11265B7E474@WSMSG3153V.srv.dir.telstra.com> References: <7C01E631FF4B654FA1E783F1C0265F8C579CC0C3@TK5EX14MBXC117.redmond.corp.microsoft.com> <7C01E631FF4B654FA1E783F1C0265F8C579D0F31@TK5EX14MBXC117.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E11265A5FC9D@WSMSG3153V.srv.dir.telstra.com> <AANLkTilrSUMEjsF-3RHuit6aoAPRe0DAqR6Uz2ldrd_l@mail.gmail.com> In-Reply-To: <AANLkTilrSUMEjsF-3RHuit6aoAPRe0DAqR6Uz2ldrd_l@mail.gmail.com> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Proposal for text for section 2 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 30 Jun 2010 00:07:31 -0000 Marius, >> For instance, why not define a SAML HTTP authentication mechanism: >> >> =A0=A0 Authorization: SAML a=3D<base64url-encoded SAML assertion> > This came up in another thread, but SAML assertions could be too large > to be passed through an HTTP header. Other than that, your suggestion > really simplifies things. What are the limits on HTTP headers? I don't think there are any in the HTTP spec. <http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-09#section-3.2> A comment in the other thread said SPNEGO headers can be up to 12392 bytes = and do not seem to be a problem. <http://www.ietf.org/mail-archive/web/oauth/current/msg03359.html> I is hard to support a POST-and-form-only method when there is an alternati= ve that "really simplifies things" without more concrete information on wha= t the actual HTTP limits are (& how hard it is to increase them), and what = practical assertion sizes are. -- James Manger From eran@hueniverse.com Tue Jun 29 17:14:26 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 041FC3A69C0 for <oauth@core3.amsl.com>; Tue, 29 Jun 2010 17:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.235 X-Spam-Level: X-Spam-Status: No, score=-2.235 tagged_above=-999 required=5 tests=[AWL=0.364, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dZF+CG5OW9nY for <oauth@core3.amsl.com>; Tue, 29 Jun 2010 17:14:19 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id EBEAD3A68AC for <oauth@ietf.org>; Tue, 29 Jun 2010 17:14:17 -0700 (PDT) Received: (qmail 27431 invoked from network); 30 Jun 2010 00:14:27 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 30 Jun 2010 00:14:26 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Tue, 29 Jun 2010 17:14:25 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: "Manger, James H" <James.H.Manger@team.telstra.com>, Marius Scurtescu <mscurtescu@google.com> Date: Tue, 29 Jun 2010 17:14:30 -0700 Thread-Topic: [OAUTH-WG] Proposal for text for section 2 Thread-Index: AcsXrGDU+cOkXD6yQpS4lCbUJEfEswANljAAAAGUYGA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4BF7C@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <7C01E631FF4B654FA1E783F1C0265F8C579CC0C3@TK5EX14MBXC117.redmond.corp.microsoft.com> <7C01E631FF4B654FA1E783F1C0265F8C579D0F31@TK5EX14MBXC117.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E11265A5FC9D@WSMSG3153V.srv.dir.telstra.com> <AANLkTilrSUMEjsF-3RHuit6aoAPRe0DAqR6Uz2ldrd_l@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E11265B7E474@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11265B7E474@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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Proposal for text for section 2 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 30 Jun 2010 00:14:27 -0000 More precisely, what are the actual deployed limits on HTTP *request* heade= rs in popular HTTP servers like Apache and IIS, and in popular client platf= orm likely to use this size assertions? EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Manger, James H > Sent: Tuesday, June 29, 2010 5:08 PM > To: Marius Scurtescu > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Proposal for text for section 2 >=20 > Marius, >=20 > >> For instance, why not define a SAML HTTP authentication mechanism: > >> > >> =A0=A0 Authorization: SAML a=3D<base64url-encoded SAML assertion> >=20 > > This came up in another thread, but SAML assertions could be too large > > to be passed through an HTTP header. Other than that, your suggestion > > really simplifies things. >=20 > What are the limits on HTTP headers? > I don't think there are any in the HTTP spec. > <http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-09#section-3.= 2> > A comment in the other thread said SPNEGO headers can be up to 12392 > bytes and do not seem to be a problem. > <http://www.ietf.org/mail-archive/web/oauth/current/msg03359.html> >=20 > I is hard to support a POST-and-form-only method when there is an > alternative that "really simplifies things" without more concrete informa= tion > on what the actual HTTP limits are (& how hard it is to increase them), a= nd > what practical assertion sizes are. >=20 >=20 > -- > James Manger > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From mscurtescu@google.com Tue Jun 29 18:13:05 2010 Return-Path: <mscurtescu@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B3363A6A72 for <oauth@core3.amsl.com>; Tue, 29 Jun 2010 18:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.393 X-Spam-Level: X-Spam-Status: No, score=-105.393 tagged_above=-999 required=5 tests=[AWL=0.584, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aPY3IuIr2Qlj for <oauth@core3.amsl.com>; Tue, 29 Jun 2010 18:13:03 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 1A8833A69E3 for <oauth@ietf.org>; Tue, 29 Jun 2010 18:13:01 -0700 (PDT) Received: from wpaz37.hot.corp.google.com (wpaz37.hot.corp.google.com [172.24.198.101]) by smtp-out.google.com with ESMTP id o5U1DBLV012450 for <oauth@ietf.org>; Tue, 29 Jun 2010 18:13:11 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1277860392; bh=Jj2aDc3TZu7l5t3Nc6394aVp6CM=; h=MIME-Version:From:Date:Message-ID:Subject:To:Cc:Content-Type: Content-Transfer-Encoding; b=qcciMwSGVCWDeJTEQ/je4uAiWhiqz8cQWgRwdveL00CoBNASfmzgRcOExV3ow7z+3 SI+P+DQpxV0NXdvSecxNw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:from:date:message-id:subject:to:cc: content-type:content-transfer-encoding:x-system-of-record; b=Z2QHeNgfIRdzJngTJ1z7UOn111nA924MzGv7OPPqN2wjcihp624fvzaqyKW4iZlIk AphI2MNAZjySSme/j9Ldg== Received: from vws11 (vws11.prod.google.com [10.241.21.139]) by wpaz37.hot.corp.google.com with ESMTP id o5U1DARA008057 for <oauth@ietf.org>; Tue, 29 Jun 2010 18:13:11 -0700 Received: by vws11 with SMTP id 11so300711vws.10 for <oauth@ietf.org>; Tue, 29 Jun 2010 18:13:10 -0700 (PDT) Received: by 10.220.75.200 with SMTP id z8mr3479257vcj.197.1277860390378; Tue, 29 Jun 2010 18:13:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.83.100 with HTTP; Tue, 29 Jun 2010 18:12:50 -0700 (PDT) From: Marius Scurtescu <mscurtescu@google.com> Date: Tue, 29 Jun 2010 18:12:50 -0700 Message-ID: <AANLkTikMuFIaJ1bnL3FOSzsRmO0Ix9xzyyzQG0hcWVcV@mail.gmail.com> To: Eran Hammer-Lahav <eran@hueniverse.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: [OAUTH-WG] OAuth 1.0 token assertion to OAuth 2.0 token (was: Draft -09) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 30 Jun 2010 01:13:05 -0000 On Tue, Jun 29, 2010 at 8:22 AM, Eran Hammer-Lahav <eran@hueniverse.com> wr= ote: > > The assertion grant type is really the grant type extension point. Librar= ies should treat it as a way to support custom grant types. One of the thin= gs I would like to see someone draft is how to use OAuth 1.0 tokens to obta= in OAuth 2.0 tokens using the assertion type. For example, the assertion ty= pe can be "http://oauth.net/1.0/token" , and the assertion itself is some f= orm of the token and signature (or secrets) concatenated into a string (thi= s will maintain the 1.0 security while transitioning to 2.0). This is just = a straw man. > > It is important that libraries support this extensibility with some form = of a hook or handler so that clients can make requests using assertions fro= m outside the library. An OAuth 1 token assertion as described above would achieve the same thing as the suggested bridge endpoint. Do you see any advantages on using an assertion as opposed to a standard OAuth 1 signed request? Marius From lshepard@facebook.com Tue Jun 29 18:29:59 2010 Return-Path: <lshepard@facebook.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 320443A69FD for <oauth@core3.amsl.com>; Tue, 29 Jun 2010 18:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.646 X-Spam-Level: X-Spam-Status: No, score=-0.646 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_05=-1.11, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ioPpLSAZCuz for <oauth@core3.amsl.com>; Tue, 29 Jun 2010 18:29:57 -0700 (PDT) Received: from mx-out.facebook.com (outmail025.snc1.tfbnw.net [69.63.178.184]) by core3.amsl.com (Postfix) with ESMTP id 536423A680C for <oauth@ietf.org>; Tue, 29 Jun 2010 18:29:57 -0700 (PDT) Received: from [10.18.255.124] ([10.18.255.124:52206] helo=mail.thefacebook.com) by mta011.snc1.facebook.com (envelope-from <lshepard@facebook.com>) (ecelerity 2.2.2.45 r(34067)) with ESMTP id 8E/F0-30982-E1E9A2C4; Tue, 29 Jun 2010 18:30:06 -0700 Received: from sc-hub05.TheFacebook.com (192.168.18.82) by sc-hub04.TheFacebook.com (192.168.18.212) with Microsoft SMTP Server (TLS) id 14.0.694.1; Tue, 29 Jun 2010 18:30:05 -0700 Received: from SC-MBXC1.TheFacebook.com ([192.168.18.100]) by sc-hub05.TheFacebook.com ([192.168.18.82]) with mapi; Tue, 29 Jun 2010 18:30:05 -0700 From: Luke Shepard <lshepard@facebook.com> To: Marius Scurtescu <mscurtescu@google.com> Date: Tue, 29 Jun 2010 18:30:04 -0700 Thread-Topic: [OAUTH-WG] OAuth 1.0 token assertion to OAuth 2.0 token (was: Draft -09) Thread-Index: AcsX88RqNqJmOh2SRl2mA86LIa7NKw== Message-ID: <1B9AF9A1-697C-4C21-A8A2-0D94B90EB599@facebook.com> References: <AANLkTikMuFIaJ1bnL3FOSzsRmO0Ix9xzyyzQG0hcWVcV@mail.gmail.com> In-Reply-To: <AANLkTikMuFIaJ1bnL3FOSzsRmO0Ix9xzyyzQG0hcWVcV@mail.gmail.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 \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] OAuth 1.0 token assertion to OAuth 2.0 token (was: Draft -09) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 30 Jun 2010 01:29:59 -0000 One reason is that you may want to exchange tokens in a batch, whereas you = typically can only sign requests individually. On Jun 29, 2010, at 6:12 PM, Marius Scurtescu wrote: > On Tue, Jun 29, 2010 at 8:22 AM, Eran Hammer-Lahav <eran@hueniverse.com> = wrote: >>=20 >> The assertion grant type is really the grant type extension point. Libra= ries should treat it as a way to support custom grant types. One of the thi= ngs I would like to see someone draft is how to use OAuth 1.0 tokens to obt= ain OAuth 2.0 tokens using the assertion type. For example, the assertion t= ype can be "http://oauth.net/1.0/token" , and the assertion itself is some = form of the token and signature (or secrets) concatenated into a string (th= is will maintain the 1.0 security while transitioning to 2.0). This is just= a straw man. >>=20 >> It is important that libraries support this extensibility with some form= of a hook or handler so that clients can make requests using assertions fr= om outside the library. >=20 > An OAuth 1 token assertion as described above would achieve the same > thing as the suggested bridge endpoint. Do you see any advantages on > using an assertion as opposed to a standard OAuth 1 signed request? >=20 > Marius > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From mscurtescu@google.com Tue Jun 29 18:50:27 2010 Return-Path: <mscurtescu@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 864523A68D4 for <oauth@core3.amsl.com>; Tue, 29 Jun 2010 18:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.488 X-Spam-Level: X-Spam-Status: No, score=-101.488 tagged_above=-999 required=5 tests=[AWL=0.489, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d3B9g38Vz1-Z for <oauth@core3.amsl.com>; Tue, 29 Jun 2010 18:50:24 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 6BF783A6844 for <oauth@ietf.org>; Tue, 29 Jun 2010 18:50:24 -0700 (PDT) Received: from wpaz33.hot.corp.google.com (wpaz33.hot.corp.google.com [172.24.198.97]) by smtp-out.google.com with ESMTP id o5U1oY5w008159 for <oauth@ietf.org>; Tue, 29 Jun 2010 18:50:34 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1277862634; bh=CKAyIcOjA9UDTLydDdEAHlHP/Y4=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=Kq5zlUp2j+gvQ2FHW0oLz0BGaLOseUFb07C1VsPm8pPceKrH0MjQDdCgR6XJ3yn9N QR7rQmFKWKSsKMIQnfx5A== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding:x-system-of-record; b=pA39UMoVIWk6Vr8Lhfsvt+oqfl+4UZKtfhjMxs03y143r94tF77PYAh4sw8M/UHVO 1AXzerBGCae1attN+bCSw== Received: from vws13 (vws13.prod.google.com [10.241.21.141]) by wpaz33.hot.corp.google.com with ESMTP id o5U1oWGG009952 for <oauth@ietf.org>; Tue, 29 Jun 2010 18:50:33 -0700 Received: by vws13 with SMTP id 13so505985vws.27 for <oauth@ietf.org>; Tue, 29 Jun 2010 18:50:32 -0700 (PDT) Received: by 10.220.126.197 with SMTP id d5mr4317201vcs.29.1277862632405; Tue, 29 Jun 2010 18:50:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.83.100 with HTTP; Tue, 29 Jun 2010 18:50:12 -0700 (PDT) In-Reply-To: <1B9AF9A1-697C-4C21-A8A2-0D94B90EB599@facebook.com> References: <AANLkTikMuFIaJ1bnL3FOSzsRmO0Ix9xzyyzQG0hcWVcV@mail.gmail.com> <1B9AF9A1-697C-4C21-A8A2-0D94B90EB599@facebook.com> From: Marius Scurtescu <mscurtescu@google.com> Date: Tue, 29 Jun 2010 18:50:12 -0700 Message-ID: <AANLkTiklDiFsOyponWyRdPVZoKGL4zPV5KJt9txW-gqL@mail.gmail.com> To: Luke Shepard <lshepard@facebook.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] OAuth 1.0 token assertion to OAuth 2.0 token (was: Draft -09) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 30 Jun 2010 01:50:27 -0000 On Tue, Jun 29, 2010 at 6:30 PM, Luke Shepard <lshepard@facebook.com> wrote= : > One reason is that you may want to exchange tokens in a batch, whereas yo= u typically can only sign requests individually. How does the assertion grant type help in this case? As far as I can tell this also allows you to exchange only one token. Marius > > On Jun 29, 2010, at 6:12 PM, Marius Scurtescu wrote: > >> On Tue, Jun 29, 2010 at 8:22 AM, Eran Hammer-Lahav <eran@hueniverse.com>= wrote: >>> >>> The assertion grant type is really the grant type extension point. Libr= aries should treat it as a way to support custom grant types. One of the th= ings I would like to see someone draft is how to use OAuth 1.0 tokens to ob= tain OAuth 2.0 tokens using the assertion type. For example, the assertion = type can be "http://oauth.net/1.0/token" , and the assertion itself is some= form of the token and signature (or secrets) concatenated into a string (t= his will maintain the 1.0 security while transitioning to 2.0). This is jus= t a straw man. >>> >>> It is important that libraries support this extensibility with some for= m of a hook or handler so that clients can make requests using assertions f= rom outside the library. >> >> An OAuth 1 token assertion as described above would achieve the same >> thing as the suggested bridge endpoint. Do you see any advantages on >> using an assertion as opposed to a standard OAuth 1 signed request? >> >> Marius >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > From James.H.Manger@team.telstra.com Tue Jun 29 19:29:25 2010 Return-Path: <James.H.Manger@team.telstra.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DCC928C0E4 for <oauth@core3.amsl.com>; Tue, 29 Jun 2010 19:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.019 X-Spam-Level: X-Spam-Status: No, score=0.019 tagged_above=-999 required=5 tests=[AWL=0.920, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2N6IWGA311I1 for <oauth@core3.amsl.com>; Tue, 29 Jun 2010 19:29:24 -0700 (PDT) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by core3.amsl.com (Postfix) with ESMTP id 392003A6867 for <oauth@ietf.org>; Tue, 29 Jun 2010 19:29:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,508,1272808800"; d="scan'208";a="5130894" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipobvi.tcif.telstra.com.au with ESMTP; 30 Jun 2010 12:29:31 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6028"; a="3816931" Received: from wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) by ipcavi.tcif.telstra.com.au with ESMTP; 30 Jun 2010 12:29:33 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) with mapi; Wed, 30 Jun 2010 12:29:32 +1000 From: "Manger, James H" <James.H.Manger@team.telstra.com> To: Yaron Goland <yarong@microsoft.com>, "oauth@ietf.org" <oauth@ietf.org> Date: Wed, 30 Jun 2010 12:29:31 +1000 Thread-Topic: Proposal for text for section 2 Thread-Index: AcsUm7O3+LYTofkOQ6CsKuFeuynp2ACcJnPgAAxyEYAAH/FooAAMQp/w Message-ID: <255B9BB34FB7D647A506DC292726F6E11265B7E872@WSMSG3153V.srv.dir.telstra.com> References: <7C01E631FF4B654FA1E783F1C0265F8C579CC0C3@TK5EX14MBXC117.redmond.corp.microsoft.com> <7C01E631FF4B654FA1E783F1C0265F8C579D0F31@TK5EX14MBXC117.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E11265A5FC9D@WSMSG3153V.srv.dir.telstra.com> <7C01E631FF4B654FA1E783F1C0265F8C579D20CB@TK5EX14MBXC117.redmond.corp.microsoft.com> In-Reply-To: <7C01E631FF4B654FA1E783F1C0265F8C579D20CB@TK5EX14MBXC117.redmond.corp.microsoft.com> 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: Re: [OAUTH-WG] Proposal for text for section 2 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 30 Jun 2010 02:29:25 -0000 Yaron, [Sorry I didn't see your response before sending my previous reply] > SAML assertions routinely run into the 10s and even 100s of K. > This exceeds the practical limit that most HTTP servers and proxies > put on the size of the HTTP request headers they are willing to accept. > So we cannot rely on the HTTP authorization header > as a means of transporting SAML assertions. > We are thus, as a practical matter, forced into using the request body. So SAML assertions are impractical for authenticating/authorizing requests = to a general HTTP API. Three options are: 1) Swap the assertion for session credentials that work with the API; or 2) Redefine the API to include the client assertion, which constrains the A= PI to only use POSTs of form-encoded requests; or 3) Shrink the assertions (eg with compression or an artefact-binding) so it= fits the HTTP model. The API in question here is the OAuth2 "token endpoint" API [section 4 of d= raft-ietf-oauth-v2-09]. You want to take option 2 -- which sort of makes sense in this case since t= his API is already about swapping credentials. This feels like a good candidate for a separate spec: "An HTTP API for obta= ining an OAuth2 token with an assertion". The proposal might jar a little less if it was part of the API definition [= section 4]. It is certainly not "completely orthogonal to anything in secti= on 4" since it adds constraints (POST and form-encoding) and applies only t= o the specific section 4 API and no others. -- James Manger From: Manger, James H [mailto:James.H.Manger@team.telstra.com]=20 Sent: Monday, June 28, 2010 9:38 PM ..."Assertion Client Credentials" is too much of a hack. It only works for = POSTs, and only when the body is form-encoded. It could not be used, for instance, to delete a token with an HTTP DELETE r= equest... From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Y= aron Goland Sent: Tuesday, 29 June 2010 7:56 AM The following is proposed language for a new section, 2.2, in the spec. Thi= s is part of the spec that deals with client authentication. This proposal = is completely orthogonal to anything in section 4 such as grant types... 2.2 Assertion Client Credentials ... From kris.selden@gmail.com Tue Jun 29 20:17:51 2010 Return-Path: <kris.selden@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FA223A6801 for <oauth@core3.amsl.com>; Tue, 29 Jun 2010 20:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id giv8iHspdq6F for <oauth@core3.amsl.com>; Tue, 29 Jun 2010 20:17:50 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 37FFD3A63CA for <oauth@ietf.org>; Tue, 29 Jun 2010 20:17:50 -0700 (PDT) Received: by pwj2 with SMTP id 2so98254pwj.31 for <oauth@ietf.org>; Tue, 29 Jun 2010 20:17:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:in-reply-to :mime-version:content-transfer-encoding:content-type:message-id:cc :x-mailer:from:subject:date:to; bh=CaLbZRiPDWE3k6ez5oFFw/Twk+LydIYFpCaEgiANacE=; b=cLM6SogJo6oJAgjSGNRsrf9Fus3n7bTT163UaZ4fbrZFAU29izDbszv5CNbqtCxk8+ w3jbuA5duQDwbF7uiFa+iFFIEXUujNcT+L2WyqIR5P+YN0n2+8LzEDzywgGDtaB3b1du qlh2tNZtl8q9p96zGbTt1y5fdxBXd7xB0+S0A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; b=OEV6stQQOm1ljdbKH0MUf8QI8H+oakyQwLDhhSA68KQirSNHtR55kXxS+kB7fbwB0k Xc9Q0W2OjW83S1Wy+OsLon+lIT6qmj4OG0o70w6Jscv2CVm8RdfNoxQiqDnIcsnkqYBp 4U6X/uQnrYXLOJchUHetCDzoz/tqChKnw+RF4= Received: by 10.115.64.21 with SMTP id r21mr8754935wak.23.1277867877990; Tue, 29 Jun 2010 20:17:57 -0700 (PDT) Received: from [172.16.2.9] (c-76-121-106-185.hsd1.wa.comcast.net [76.121.106.185]) by mx.google.com with ESMTPS id c16sm5358679rvn.1.2010.06.29.20.17.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 29 Jun 2010 20:17:56 -0700 (PDT) References: <7C01E631FF4B654FA1E783F1C0265F8C579CC0C3@TK5EX14MBXC117.redmond.corp.microsoft.com> <7C01E631FF4B654FA1E783F1C0265F8C579D0F31@TK5EX14MBXC117.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E11265A5FC9D@WSMSG3153V.srv.dir.telstra.com> <AANLkTilrSUMEjsF-3RHuit6aoAPRe0DAqR6Uz2ldrd_l@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E11265B7E474@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4BF7C@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4BF7C@P3PW5EX1MB01.EX1.SECURESERVER.NET> Mime-Version: 1.0 (iPhone Mail 8A293) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <4AB71D81-6285-46D6-9D4A-99966616E0F1@gmail.com> X-Mailer: iPhone Mail (8A293) From: Kris Selden <kris.selden@gmail.com> Date: Tue, 29 Jun 2010 20:17:58 -0700 To: Eran Hammer-Lahav <eran@hueniverse.com> Cc: "oauth@ietf.org" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Proposal for text for section 2 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 30 Jun 2010 03:17:51 -0000 This is configurable in IIS, Apache and Nginx but the default ranges from 4k= to 16k. Don't know if there are issues with buffer sizes on the client side. On Jun 29, 2010, at 5:14 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote: > More precisely, what are the actual deployed limits on HTTP *request* head= ers in popular HTTP servers like Apache and IIS, and in popular client platf= orm likely to use this size assertions? >=20 > EHL >=20 >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Manger, James H >> Sent: Tuesday, June 29, 2010 5:08 PM >> To: Marius Scurtescu >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] Proposal for text for section 2 >>=20 >> Marius, >>=20 >>>> For instance, why not define a SAML HTTP authentication mechanism: >>>>=20 >>>> Authorization: SAML a=3D<base64url-encoded SAML assertion> >>=20 >>> This came up in another thread, but SAML assertions could be too large >>> to be passed through an HTTP header. Other than that, your suggestion >>> really simplifies things. >>=20 >> What are the limits on HTTP headers? >> I don't think there are any in the HTTP spec. >> <http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-09#section-3.= 2> >> A comment in the other thread said SPNEGO headers can be up to 12392 >> bytes and do not seem to be a problem. >> <http://www.ietf.org/mail-archive/web/oauth/current/msg03359.html> >>=20 >> I is hard to support a POST-and-form-only method when there is an >> alternative that "really simplifies things" without more concrete informa= tion >> on what the actual HTTP limits are (& how hard it is to increase them), a= nd >> what practical assertion sizes are. >>=20 >>=20 >> -- >> James Manger >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 From lshepard@facebook.com Tue Jun 29 21:39:18 2010 Return-Path: <lshepard@facebook.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 253A53A6AB5 for <oauth@core3.amsl.com>; Tue, 29 Jun 2010 21:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.668 X-Spam-Level: X-Spam-Status: No, score=-0.668 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_05=-1.11, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uoa55h4ante5 for <oauth@core3.amsl.com>; Tue, 29 Jun 2010 21:39:17 -0700 (PDT) Received: from mx-out.facebook.com (outmail007.ash1.tfbnw.net [69.63.184.107]) by core3.amsl.com (Postfix) with ESMTP id 9ADC13A68F0 for <oauth@ietf.org>; Tue, 29 Jun 2010 21:39:16 -0700 (PDT) Received: from [10.18.255.178] ([10.18.255.178:2895] helo=mail.thefacebook.com) by mta002.ash1.facebook.com (envelope-from <lshepard@facebook.com>) (ecelerity 2.2.2.45 r(34067)) with ESMTP id B7/6A-04303-618CA2C4; Tue, 29 Jun 2010 21:29:10 -0700 Received: from sc-hub02.TheFacebook.com (192.168.18.105) by sc-hub03.TheFacebook.com (192.168.18.198) with Microsoft SMTP Server (TLS) id 14.0.694.1; Tue, 29 Jun 2010 21:29:09 -0700 Received: from SC-MBXC1.TheFacebook.com ([192.168.18.100]) by sc-hub02.TheFacebook.com ([192.168.18.105]) with mapi; Tue, 29 Jun 2010 21:29:09 -0700 From: Luke Shepard <lshepard@facebook.com> To: Marius Scurtescu <mscurtescu@google.com> Date: Tue, 29 Jun 2010 21:29:08 -0700 Thread-Topic: [OAUTH-WG] OAuth 1.0 token assertion to OAuth 2.0 token (was: Draft -09) Thread-Index: AcsYDMg72V4OBCSJSv6hbYQVk3S2Xw== Message-ID: <5153DDB2-845F-4F95-907C-350BD1560D9A@facebook.com> References: <AANLkTikMuFIaJ1bnL3FOSzsRmO0Ix9xzyyzQG0hcWVcV@mail.gmail.com> <1B9AF9A1-697C-4C21-A8A2-0D94B90EB599@facebook.com> <AANLkTiklDiFsOyponWyRdPVZoKGL4zPV5KJt9txW-gqL@mail.gmail.com> In-Reply-To: <AANLkTiklDiFsOyponWyRdPVZoKGL4zPV5KJt9txW-gqL@mail.gmail.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 \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] OAuth 1.0 token assertion to OAuth 2.0 token (was: Draft -09) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 30 Jun 2010 04:39:18 -0000 That's a good point :) We may want to allow batch exchanges for an upgrade = flow, but you're right, then that doesn't really apply here. On Jun 29, 2010, at 6:50 PM, Marius Scurtescu wrote: > On Tue, Jun 29, 2010 at 6:30 PM, Luke Shepard <lshepard@facebook.com> wro= te: >> One reason is that you may want to exchange tokens in a batch, whereas y= ou typically can only sign requests individually. >=20 > How does the assertion grant type help in this case? As far as I can > tell this also allows you to exchange only one token. >=20 > Marius >=20 >=20 >>=20 >> On Jun 29, 2010, at 6:12 PM, Marius Scurtescu wrote: >>=20 >>> On Tue, Jun 29, 2010 at 8:22 AM, Eran Hammer-Lahav <eran@hueniverse.com= > wrote: >>>>=20 >>>> The assertion grant type is really the grant type extension point. Lib= raries should treat it as a way to support custom grant types. One of the t= hings I would like to see someone draft is how to use OAuth 1.0 tokens to o= btain OAuth 2.0 tokens using the assertion type. For example, the assertion= type can be "http://oauth.net/1.0/token" , and the assertion itself is som= e form of the token and signature (or secrets) concatenated into a string (= this will maintain the 1.0 security while transitioning to 2.0). This is ju= st a straw man. >>>>=20 >>>> It is important that libraries support this extensibility with some fo= rm of a hook or handler so that clients can make requests using assertions = from outside the library. >>>=20 >>> An OAuth 1 token assertion as described above would achieve the same >>> thing as the suggested bridge endpoint. Do you see any advantages on >>> using an assertion as opposed to a standard OAuth 1 signed request? >>>=20 >>> Marius >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 From torsten@lodderstedt.net Tue Jun 29 22:28:14 2010 Return-Path: <torsten@lodderstedt.net> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10B773A6939 for <oauth@core3.amsl.com>; Tue, 29 Jun 2010 22:28:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.655 X-Spam-Level: X-Spam-Status: No, score=-0.655 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_05=-1.11, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l5ECXffZXQJZ for <oauth@core3.amsl.com>; Tue, 29 Jun 2010 22:28:13 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.27]) by core3.amsl.com (Postfix) with ESMTP id 9DA4C3A6933 for <oauth@ietf.org>; Tue, 29 Jun 2010 22:28:12 -0700 (PDT) Received: from p4fff049c.dip.t-dialin.net ([79.255.4.156] helo=[127.0.0.1]) by smtprelay04.ispgateway.de with esmtpa (Exim 4.68) (envelope-from <torsten@lodderstedt.net>) id 1OTpqP-000801-Sh; Wed, 30 Jun 2010 07:28:21 +0200 Message-ID: <4C2AD5F4.2010306@lodderstedt.net> Date: Wed, 30 Jun 2010 07:28:20 +0200 From: Torsten Lodderstedt <torsten@lodderstedt.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Eran Hammer-Lahav <eran@hueniverse.com> References: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4BCCC@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4BCCC@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: multipart/alternative; boundary="------------060803090809080000020308" X-Df-Sender: 141509 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Draft -09 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 30 Jun 2010 05:28:14 -0000 This is a multi-part message in MIME format. --------------060803090809080000020308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Eran, what about token revocation? Will you include it? regards, Torsten. Am 29.06.2010 08:56, schrieb Eran Hammer-Lahav: > > Draft -09 is now posted. Main changes include: > > o Fixed typos, editorial changes. Thanks to Dick for his useful feedback. > > o Added token expiration example. > > o Added scope parameter to end-user authorization endpoint response > and WWW-Authenticate header. > > o Added note about parameters with empty values (same as omitted). > > o Changed parameter values to use '-' instead of '_'. Parameter > names still use '_'. > > o Changed authorization endpoint client type to response type with > values: code, token, or both. > > o Complete cleanup of error codes. Added support for error > description and URI. > > o Add initial extensibility support. > > Draft -09 represents what I consider to be the first feature complete > proposal. While it still needs much work, it has notes for open issues > and missing parts. I plan to give people 2 weeks to review and provide > extensive feedback, and will post one more draft before the 7/12 > cutoff date for the meeting. > > My goal is to collect enough feedback to declare the next draft (-10) > stable for wider implementation. If you were waiting for a stable > draft to study and provide extensive feedback, this is the draft! When > giving feedback pretend this is your last chance to making a > significant contribution or changes to the core specification. > > Please submit feedback by 7/9. > > When submitting feedback please start a new thread for each item. > Editorial commentary can be collected in one post (and please send to > the list, even if it is minor, because I tend to get the same typo > correction many times). > > Thanks, > > EHL > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --------------060803090809080000020308 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> Hi Eran,<br> <br> what about token revocation? Will you include it?<br> <br> regards,<br> Torsten.<br> <br> Am 29.06.2010 08:56, schrieb Eran Hammer-Lahav: <blockquote cite="mid:90C41DD21FB7C64BB94121FBBC2E72343B3ED4BCCC@P3PW5EX1MB01.EX1.SECURESERVER.NET" type="cite"> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> <meta name="Generator" content="Microsoft Word 14 (filtered medium)"> <style><!-- /* Font Definitions */ @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Consolas; panose-1:2 11 6 9 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {mso-style-priority:34; margin-top:0in; margin-right:0in; margin-bottom:0in; margin-left:.5in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} span.EmailStyle17 {mso-style-type:personal-compose; font-family:"Calibri","sans-serif"; color:windowtext;} .MsoChpDefault {mso-style-type:export-only; font-family:"Calibri","sans-serif";} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext="edit" spidmax="1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext="edit"> <o:idmap v:ext="edit" data="1" /> </o:shapelayout></xml><![endif]--> <div class="WordSection1"> <p class="MsoNormal">Draft -09 is now posted. Main changes include:<o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal" style=""><span style="font-size: 9.5pt; font-family: Consolas;"> o  Fixed typos, editorial changes. Thanks to Dick for his useful feedback.<o:p></o:p></span></p> <p class="MsoNormal" style=""><span style="font-size: 9.5pt; font-family: Consolas;"> o  Added token expiration example.<o:p></o:p></span></p> <p class="MsoNormal" style=""><span style="font-size: 9.5pt; font-family: Consolas;"> o  Added scope parameter to end-user authorization endpoint response and WWW-Authenticate header.<o:p></o:p></span></p> <p class="MsoNormal" style=""><span style="font-size: 9.5pt; font-family: Consolas;"> o  Added note about parameters with empty values (same as omitted).<o:p></o:p></span></p> <p class="MsoNormal" style=""><span style="font-size: 9.5pt; font-family: Consolas;"> o  Changed parameter values to use '-' instead of '_'.  Parameter names still use '_'.<o:p></o:p></span></p> <p class="MsoNormal" style=""><span style="font-size: 9.5pt; font-family: Consolas;"> o  Changed authorization endpoint client type to response type with values: code, token, or both.<o:p></o:p></span></p> <p class="MsoNormal" style=""><span style="font-size: 9.5pt; font-family: Consolas;"> o  Complete cleanup of error codes.  Added support for error description and URI.<o:p></o:p></span></p> <p class="MsoNormal" style=""><span style="font-size: 9.5pt; font-family: Consolas;"> o  Add initial extensibility support.<o:p></o:p></span></p> <p class="MsoNormal" style=""><span style="font-size: 9.5pt; font-family: Consolas;"><o:p> </o:p></span></p> <p class="MsoNormal" style=""><span style="font-size: 9.5pt; font-family: Consolas;">Draft -09 represents what I consider to be the first feature complete proposal. While it still needs much work, it has notes for open issues and missing parts. I plan to give people 2 weeks to review and provide extensive feedback, and will post one more draft before the 7/12 cutoff date for the meeting.<o:p></o:p></span></p> <p class="MsoNormal" style=""><span style="font-size: 9.5pt; font-family: Consolas;"><o:p> </o:p></span></p> <p class="MsoNormal" style=""><span style="font-size: 9.5pt; font-family: Consolas;">My goal is to collect enough feedback to declare the next draft (-10) stable for wider implementation. If you were waiting for a stable draft to study and provide extensive feedback, this is the draft! When giving feedback pretend this is your last chance to making a significant contribution or changes to the core specification.<o:p></o:p></span></p> <p class="MsoNormal" style=""><span style="font-size: 9.5pt; font-family: Consolas;"><o:p> </o:p></span></p> <p class="MsoNormal" style=""><span style="font-size: 9.5pt; font-family: Consolas;">Please submit feedback by 7/9.<o:p></o:p></span></p> <p class="MsoNormal" style=""><span style="font-size: 9.5pt; font-family: Consolas;"><o:p> </o:p></span></p> <p class="MsoNormal" style=""><span style="font-size: 9.5pt; font-family: Consolas;">When submitting feedback please start a new thread for each item. Editorial commentary can be collected in one post (and please send to the list, even if it is minor, because I tend to get the same typo correction many times).<o:p></o:p></span></p> <p class="MsoNormal" style=""><span style="font-size: 9.5pt; font-family: Consolas;"><o:p> </o:p></span></p> <p class="MsoNormal" style=""><span style="font-size: 9.5pt; font-family: Consolas;">Thanks,<o:p></o:p></span></p> <p class="MsoNormal" style=""><span style="font-size: 9.5pt; font-family: Consolas;"><o:p> </o:p></span></p> <p class="MsoNormal" style=""><span style="font-size: 9.5pt; font-family: Consolas;">EHL<o:p></o:p></span></p> <p class="MsoNormal" style=""><span style="font-size: 9.5pt; font-family: Consolas;"><o:p> </o:p></span></p> <p class="MsoNormal"><o:p> </o:p></p> </div> <pre wrap=""> <fieldset class="mimeAttachmentHeader"></fieldset> _______________________________________________ OAuth mailing list <a class="moz-txt-link-abbreviated" href="mailto:OAuth@ietf.org">OAuth@ietf.org</a> <a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/oauth">https://www.ietf.org/mailman/listinfo/oauth</a> </pre> </blockquote> </body> </html> --------------060803090809080000020308-- From torsten@lodderstedt.net Tue Jun 29 23:49:14 2010 Return-Path: <torsten@lodderstedt.net> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1582D3A6C34 for <oauth@core3.amsl.com>; Tue, 29 Jun 2010 23:49:14 -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=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kO+Owq6FlYbA for <oauth@core3.amsl.com>; Tue, 29 Jun 2010 23:49:13 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.18.13]) by core3.amsl.com (Postfix) with ESMTP id D5C593A6A8B for <oauth@ietf.org>; Tue, 29 Jun 2010 23:49:12 -0700 (PDT) Received: from [80.67.16.117] (helo=localhost) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from <torsten@lodderstedt.net>) id 1OTr6n-0002dg-UU; Wed, 30 Jun 2010 08:49:21 +0200 Received: from proxy2.t-online.net (proxy2.t-online.net [195.243.113.251]) by webmail.df.eu (Horde Framework) with HTTP; Wed, 30 Jun 2010 08:49:21 +0200 Message-ID: <20100630084921.12976ty3y7wuz6cc@webmail.df.eu> Date: Wed, 30 Jun 2010 08:49:21 +0200 From: Torsten Lodderstedt <torsten@lodderstedt.net> To: Yaron Goland <yarong@microsoft.com> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EC84C9D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C28E814.1060102@lodderstedt.net> <AANLkTilw0noo6qyKKXDI06Y4bIiippjvjGRFia0MwXmY@mail.gmail.com> <4C28F73A.4090800@lodderstedt.net> <7C01E631FF4B654FA1E783F1C0265F8C579D107B@TK5EX14MBXC117.redmond.corp.microsoft.com> In-Reply-To: <7C01E631FF4B654FA1E783F1C0265F8C579D107B@TK5EX14MBXC117.redmond.corp.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.2) X-Originating-IP: 195.243.113.251 X-Df-Sender: 141509 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Client credentials type X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 30 Jun 2010 06:49:14 -0000 that's pretty big! Can you please explain what kind of client you authenticate with such assertions? They must contain hundreds of attributes. regards, Torsten. Zitat von Yaron Goland <yarong@microsoft.com>: > We regularly deal with SAML assertions that easily go into the 100s > of K. This is far more than most HTTP servers will accept. So we are > pretty much required to use the body. > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Torsten Lodderstedt >> Sent: Monday, June 28, 2010 12:26 PM >> To: Marius Scurtescu >> Cc: OAuth WG (oauth@ietf.org) >> Subject: Re: [OAUTH-WG] Client credentials type >> >> what size do you expect? SPNEGO authentication headers can be up to >> 12392 bytes and this does not seem to be a problem. >> >> regards, >> Torsten. >> >> Am 28.06.2010 21:19, schrieb Marius Scurtescu: >> > Only HTTP headers may not be enough. In Yaron's proposal, the >> > assertion could be a SAML assertion, and these could be too large for >> > headers. >> > >> > I think #1 makes sense. >> > >> > Marius >> > >> > >> > >> > On Mon, Jun 28, 2010 at 11:21 AM, Torsten Lodderstedt >> > <torsten@lodderstedt.net> wrote: >> > >> >> I would prefer (2) since authorization headers are the natural way to >> >> handle authentication in HTTP. Different client credential mechanisms >> >> can be represented by different authentication scheme (even >> >> custom-defined). HTTP libraries typically have special support for >> >> handling such headers and it keeps the authentication mechanism >> >> orthogonal of the API. Moreover, authorization headers very well work >> >> together with status code 401 and WWW-Authenticate headers. Using >> >> WWW-Authenticate headers, an authz server can easily signal what >> >> mechanisms (multiple WWW-Authenticate headers are allowed in a single >> HTTP response) it accepts for a particular request. >> >> >> >> regards, >> >> Torsten. >> >> >> >> Am 28.06.2010 19:39, schrieb Eran Hammer-Lahav: >> >> >> >> Yaron Goland offered a proposal for an additional client credentials >> >> mechanism based on assertion. His proposal raises the issue of >> >> differentiating between the different kind of credentials used. When >> >> it comes to access grant types, this group argued for being explicit >> >> and providing a parameter declaring the grant type being used (even >> >> though it is not technically necessary). >> >> >> >> >> >> >> >> While I don't believe a grant or credential type parameter is needed >> >> - the type can be deduced from the other parameters present - we now >> >> treat the same requirement with a different solution. I think this >> >> creates a broken environment for extensibility (which is my current >> focus). >> >> >> >> >> >> >> >> At the same time, introducing such a parameter can conflict with the >> >> standard HTTP authentication mechanism. For example, a request >> >> containing both "client_credentials_type=basic" and the HTTP >> >> Authorization header seems odd. >> >> >> >> >> >> >> >> There are a few ways to address this: >> >> >> >> >> >> >> >> 1. Only use a type parameter when the credentials are passed using >> >> parameters and not a header. >> >> >> >> 2. Only allow HTTP headers for authentication, while >> >> "grandfathering-in" the client_secret parameter to simplify the most >> common current practice. >> >> >> >> 3. Leave is underspecified, relying on the presence of extension >> >> parameters or authentication headers for other credentials types. >> >> >> >> >> >> >> >> Thoughts? >> >> >> >> >> >> >> >> 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 > > From chris.messina@gmail.com Wed Jun 30 07:54:50 2010 Return-Path: <chris.messina@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56BA93A685C for <oauth@core3.amsl.com>; Wed, 30 Jun 2010 07:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JU3M4WmQW-EE for <oauth@core3.amsl.com>; Wed, 30 Jun 2010 07:54:49 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id E5FB53A65A5 for <oauth@ietf.org>; Wed, 30 Jun 2010 07:54:48 -0700 (PDT) Received: by gwb10 with SMTP id 10so483220gwb.31 for <oauth@ietf.org>; Wed, 30 Jun 2010 07:54:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=kUsxfZKW4AWG0RNoWSP4aPiIwD6yQdJp0MZRsqj5TPQ=; b=w3t4gskPT/NHeHQUSs+SfmEAeuitUP2YzDgqSOyE2aV6nJ+U5bkbFNCj9yKsqesMUl AcqJeYR4lenaEagCf/iqvSoH5fvNqidWUjdVsUmHjSrY+DH2WWJq7qfQuPoF6T7N6uXB EzPCtWDnO+IKnLRjx8ZcywG5DR04LCijFIuNA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Z74szGKfhVMI4xi0BjO2U63AVpNCSiEBB6eqkFOLK5yKISxHCsMjSyu8oL/16aCkc4 BbxxTtS3QH9KX5QZ56JjSF8aez6x0gZxUCmxIUY/dx4YPXUgKVhaIqih1PoZm4bWW2c4 U1Q/zuXUbhXIGcysEeaeWOhkzXIVFjx/zkL90= MIME-Version: 1.0 Received: by 10.229.191.147 with SMTP id dm19mr5126027qcb.204.1277909695472; Wed, 30 Jun 2010 07:54:55 -0700 (PDT) Received: by 10.229.188.11 with HTTP; Wed, 30 Jun 2010 07:54:55 -0700 (PDT) In-Reply-To: <AANLkTinXrAKxkciklJPUEgDdN3bcEDWmZ18b3ADPGgjs@mail.gmail.com> References: <AANLkTinXrAKxkciklJPUEgDdN3bcEDWmZ18b3ADPGgjs@mail.gmail.com> Date: Wed, 30 Jun 2010 07:54:55 -0700 Message-ID: <AANLkTinWwnVNRfR4r_nEf0WaZ3co4lsjd8ODXQiN1Vb7@mail.gmail.com> From: Chris Messina <chris.messina@gmail.com> To: Sarah Faulkner <sarahfaulkner3@gmail.com> Content-Type: multipart/alternative; boundary=00163628419e742422048a40890b Cc: OAuth WG <oauth@ietf.org>, Angus Logan <Angus.Logan@microsoft.com> Subject: Re: [OAUTH-WG] Messenger Connect ships today X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 30 Jun 2010 14:54:50 -0000 --00163628419e742422048a40890b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Congrats Sarah =97 big news, and great progress! Chris On Mon, Jun 28, 2010 at 11:29 AM, Sarah Faulkner <sarahfaulkner3@gmail.com>wrote: > Windows Live just shipped a beta of our Messenger Connect platform. The > platform uses OAuth WRAP (among other standards<https://mail.exchange.mic= rosoft.com/owa/redir.aspx?C=3Dd58070642ea545469fe36f1c5485feff&URL=3Dhttp%3= a%2f%2fwindowsteamblog.com%2fwindows_live%2fb%2fdeveloper%2farchive%2f2010%= 2f06%2f27%2fdeveloping-with-messenger-connect.aspx>) > and a new consent dialogue<https://mail.exchange.microsoft.com/owa/redir.= aspx?C=3Dd58070642ea545469fe36f1c5485feff&URL=3Dhttp%3a%2f%2fwindowsteamblo= g.com%2fcfs-filesystemfile.ashx%2f__key%2fCommunityServer-Blogs-Components-= WeblogFiles%2f00-00-00-53-82-metablogapi%2f8585.image_5F00_60058FEB.png>to = enable third party websites to access a user=92s Windows Live data. Some of > the data that Messenger Connect beta will give third party websites acces= s > to is: contacts, activity streams, calendar, and photos. Messenger Connec= t > will also support sign-up and sign-in with a Windows Live ID and chat > through web messenger on the third party site. > > For more information, read our blog post<https://mail.exchange.microsoft.= com/owa/redir.aspx?C=3Dd58070642ea545469fe36f1c5485feff&URL=3Dhttp%3a%2f%2f= windowsteamblog.com%2fwindows_live%2fb%2fwindowslive%2farchive%2f2010%2f06%= 2f28%2fmessenger-connect-is-now-available.aspx>announcing the release, and = check out the > documentation<https://mail.exchange.microsoft.com/owa/redir.aspx?C=3Dd580= 70642ea545469fe36f1c5485feff&URL=3Dhttp%3a%2f%2fmsdn.microsoft.com%2fen-us%= 2flibrary%2fff749458.aspx>. > If you want to try it out, here are the instructions<https://mail.exchang= e.microsoft.com/owa/redir.aspx?C=3Dd58070642ea545469fe36f1c5485feff&URL=3Dh= ttp%3a%2f%2fsocial.msdn.microsoft.com%2fForums%2fen-US%2fmessengerconnect%2= fthread%2f6a63b5b9-3603-4662-8996-929b83eaa1f9>for how to sign up for the M= essenger Connect beta and get access to the > libraries. We=92d love to hear your feedback through the forums, e-mail, = etc. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --=20 Chris Messina Open Web Advocate, Google Personal: http://factoryjoe.com Follow me on Buzz: http://buzz.google.com/chrismessina ...or Twitter: http://twitter.com/chrismessina This email is: [ ] shareable [X] ask first [ ] private --00163628419e742422048a40890b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Congrats Sarah =97 big news, and great progress!<div><br></div><div>Chris<b= r><br><div class=3D"gmail_quote">On Mon, Jun 28, 2010 at 11:29 AM, Sarah Fa= ulkner <span dir=3D"ltr"><<a href=3D"mailto:sarahfaulkner3@gmail.com">sa= rahfaulkner3@gmail.com</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex;"><div class=3D"MsoNormal"><span style=3D"col= or:#002060">Windows Live just shipped a beta of our Messenger Connect platf= orm. The platform uses OAuth WRAP (among <a href=3D"https://mail.exchange.m= icrosoft.com/owa/redir.aspx?C=3Dd58070642ea545469fe36f1c5485feff&URL=3D= http%3a%2f%2fwindowsteamblog.com%2fwindows_live%2fb%2fdeveloper%2farchive%2= f2010%2f06%2f27%2fdeveloping-with-messenger-connect.aspx" target=3D"_blank"= ><font color=3D"#0000ff">other standards</font></a>) and a new <a href=3D"h= ttps://mail.exchange.microsoft.com/owa/redir.aspx?C=3Dd58070642ea545469fe36= f1c5485feff&URL=3Dhttp%3a%2f%2fwindowsteamblog.com%2fcfs-filesystemfile= .ashx%2f__key%2fCommunityServer-Blogs-Components-WeblogFiles%2f00-00-00-53-= 82-metablogapi%2f8585.image_5F00_60058FEB.png" target=3D"_blank"><font colo= r=3D"#0000ff">consent dialogue</font></a> to enable third party websites to= access a user=92s Windows Live data. Some of the data that Messenger Conne= ct beta will give third party websites access to is: contacts, activity str= eams, calendar, and photos. Messenger Connect will also support sign-up and= sign-in with a Windows Live ID and chat through web messenger on the third= party site.</span></div> <div class=3D"MsoNormal"><span style=3D"color:#002060"></span>=A0</div> <div class=3D"MsoNormal"><span style=3D"color:#002060"></span><span style= =3D"color:#002060">For more information, read our <a href=3D"https://mail.e= xchange.microsoft.com/owa/redir.aspx?C=3Dd58070642ea545469fe36f1c5485feff&a= mp;URL=3Dhttp%3a%2f%2fwindowsteamblog.com%2fwindows_live%2fb%2fwindowslive%= 2farchive%2f2010%2f06%2f28%2fmessenger-connect-is-now-available.aspx" targe= t=3D"_blank"><font color=3D"#0000ff">blog post</font></a> announcing the re= lease, and check out the <a href=3D"https://mail.exchange.microsoft.com/owa= /redir.aspx?C=3Dd58070642ea545469fe36f1c5485feff&URL=3Dhttp%3a%2f%2fmsd= n.microsoft.com%2fen-us%2flibrary%2fff749458.aspx" target=3D"_blank"><font = color=3D"#0000ff">documentation</font></a>. If you want to try it out, here= are the <a href=3D"https://mail.exchange.microsoft.com/owa/redir.aspx?C=3D= d58070642ea545469fe36f1c5485feff&URL=3Dhttp%3a%2f%2fsocial.msdn.microso= ft.com%2fForums%2fen-US%2fmessengerconnect%2fthread%2f6a63b5b9-3603-4662-89= 96-929b83eaa1f9" target=3D"_blank"><font color=3D"#0000ff">instructions</fo= nt></a> for how to sign up for the Messenger Connect beta and get access to= the libraries. We=92d love to hear your feedback through the forums, e-mai= l, etc.</span></div> <br>_______________________________________________<br> OAuth mailing list<br> <a href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_blank">h= ttps://www.ietf.org/mailman/listinfo/oauth</a><br> <br></blockquote></div><br><br clear=3D"all"><br>-- <br>Chris Messina<br>Op= en Web Advocate, Google<br><br>Personal: <a href=3D"http://factoryjoe.com">= http://factoryjoe.com</a><br>Follow me on Buzz: <a href=3D"http://buzz.goog= le.com/chrismessina">http://buzz.google.com/chrismessina</a> <br> ...or Twitter: <a href=3D"http://twitter.com/chrismessina">http://twitter.c= om/chrismessina</a> <br><br>This email is: =A0 [ ] shareable =A0 =A0[X] ask= first =A0 [ ] private<br> </div> --00163628419e742422048a40890b-- From eran@hueniverse.com Wed Jun 30 08:13:48 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 360523A6A5B for <oauth@core3.amsl.com>; Wed, 30 Jun 2010 08:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.238 X-Spam-Level: X-Spam-Status: No, score=-2.238 tagged_above=-999 required=5 tests=[AWL=0.361, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQq4aC7+Sst2 for <oauth@core3.amsl.com>; Wed, 30 Jun 2010 08:13:46 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id D4FCE3A6AD8 for <oauth@ietf.org>; Wed, 30 Jun 2010 08:13:46 -0700 (PDT) Received: (qmail 24784 invoked from network); 30 Jun 2010 15:13:57 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 30 Jun 2010 15:13:57 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 30 Jun 2010 08:13:51 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: Marius Scurtescu <mscurtescu@google.com> Date: Wed, 30 Jun 2010 08:13:59 -0700 Thread-Topic: OAuth 1.0 token assertion to OAuth 2.0 token (was: Draft -09) Thread-Index: AcsX8WoUMoaYLtYVSFmii7C6BqSdNQAdWawQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C068@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <AANLkTikMuFIaJ1bnL3FOSzsRmO0Ix9xzyyzQG0hcWVcV@mail.gmail.com> In-Reply-To: <AANLkTikMuFIaJ1bnL3FOSzsRmO0Ix9xzyyzQG0hcWVcV@mail.gmail.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 \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] OAuth 1.0 token assertion to OAuth 2.0 token (was: Draft -09) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 30 Jun 2010 15:13:48 -0000 No benefit. This would just be the "2.0 way" of doing it. EHL > -----Original Message----- > From: Marius Scurtescu [mailto:mscurtescu@google.com] > Sent: Tuesday, June 29, 2010 6:13 PM > To: Eran Hammer-Lahav > Cc: OAuth WG (oauth@ietf.org) > Subject: OAuth 1.0 token assertion to OAuth 2.0 token (was: Draft -09) >=20 > On Tue, Jun 29, 2010 at 8:22 AM, Eran Hammer-Lahav > <eran@hueniverse.com> wrote: > > > > The assertion grant type is really the grant type extension point. Libr= aries > should treat it as a way to support custom grant types. One of the things= I > would like to see someone draft is how to use OAuth 1.0 tokens to obtain > OAuth 2.0 tokens using the assertion type. For example, the assertion typ= e > can be "http://oauth.net/1.0/token" , and the assertion itself is some fo= rm > of the token and signature (or secrets) concatenated into a string (this = will > maintain the 1.0 security while transitioning to 2.0). This is just a str= aw man. > > > > It is important that libraries support this extensibility with some for= m of a > hook or handler so that clients can make requests using assertions from > outside the library. >=20 > An OAuth 1 token assertion as described above would achieve the same > thing as the suggested bridge endpoint. Do you see any advantages on usin= g > an assertion as opposed to a standard OAuth 1 signed request? >=20 > Marius From eran@hueniverse.com Wed Jun 30 08:40:54 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26FA53A6848 for <oauth@core3.amsl.com>; Wed, 30 Jun 2010 08:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.312 X-Spam-Level: X-Spam-Status: No, score=-1.312 tagged_above=-999 required=5 tests=[AWL=-0.573, BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxi5N0Mh+1fh for <oauth@core3.amsl.com>; Wed, 30 Jun 2010 08:40:46 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id E406E3A659A for <oauth@ietf.org>; Wed, 30 Jun 2010 08:40:44 -0700 (PDT) Received: (qmail 13546 invoked from network); 30 Jun 2010 15:40:56 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 30 Jun 2010 15:40:55 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 30 Jun 2010 08:40:54 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org> Date: Wed, 30 Jun 2010 08:41:01 -0700 Thread-Topic: Draft -09 Thread-Index: AcsXVmRrsO6Hfs/LQgKeY82EBJQ0KwAA86rwAEPvUvA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C088@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4BCCC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4BCCE@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4BCCE@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_90C41DD21FB7C64BB94121FBBC2E72343B3ED4C088P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Draft -09 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 30 Jun 2010 15:40:54 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3ED4C088P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The SharedCopy experiment is working great (at least for me). However, they= have a bug where the sticky notes move so please always highlight the text= in addition to leaving a note. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Tuesday, June 29, 2010 12:11 AM To: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Draft -09 For editorial feedback, I am going to try something new and use SharedCopy.= com (no install required). Try it out at: http://r6.sharedcopy.com/6bnqq8v If this doesn't work, I'll let people know and cancel it. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Monday, June 28, 2010 11:56 PM To: OAuth WG (oauth@ietf.org) Subject: [OAUTH-WG] Draft -09 Draft -09 is now posted. Main changes include: o Fixed typos, editorial changes. Thanks to Dick for his useful feedback. o Added token expiration example. o Added scope parameter to end-user authorization endpoint response and WW= W-Authenticate header. o Added note about parameters with empty values (same as omitted). o Changed parameter values to use '-' instead of '_'. Parameter names sti= ll use '_'. o Changed authorization endpoint client type to response type with values:= code, token, or both. o Complete cleanup of error codes. Added support for error description an= d URI. o Add initial extensibility support. Draft -09 represents what I consider to be the first feature complete propo= sal. While it still needs much work, it has notes for open issues and missi= ng parts. I plan to give people 2 weeks to review and provide extensive fee= dback, and will post one more draft before the 7/12 cutoff date for the mee= ting. My goal is to collect enough feedback to declare the next draft (-10) stabl= e for wider implementation. If you were waiting for a stable draft to study= and provide extensive feedback, this is the draft! When giving feedback pr= etend this is your last chance to making a significant contribution or chan= ges to the core specification. Please submit feedback by 7/9. When submitting feedback please start a new thread for each item. Editorial= commentary can be collected in one post (and please send to the list, even= if it is minor, because I tend to get the same typo correction many times)= . Thanks, EHL --_000_90C41DD21FB7C64BB94121FBBC2E72343B3ED4C088P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"><head><meta http-equiv=3DContent-Type content= =3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros= oft Word 14 (filtered medium)"><style><!-- /* Font Definitions */ @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} @font-face {font-family:Consolas; panose-1:2 11 6 9 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} p.MsoAcetate, li.MsoAcetate, div.MsoAcetate {mso-style-priority:99; mso-style-link:"Balloon Text Char"; margin:0in; margin-bottom:.0001pt; font-size:8.0pt; font-family:"Tahoma","sans-serif";} p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {mso-style-priority:34; margin-top:0in; margin-right:0in; margin-bottom:0in; margin-left:.5in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} span.EmailStyle18 {mso-style-type:personal; font-family:"Calibri","sans-serif"; color:windowtext;} span.EmailStyle19 {mso-style-type:personal; font-family:"Calibri","sans-serif"; color:#1F497D;} span.EmailStyle20 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} span.BalloonTextChar {mso-style-name:"Balloon Text Char"; mso-style-priority:99; mso-style-link:"Balloon Text"; font-family:"Tahoma","sans-serif";} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue vli= nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><span style=3D'c= olor:#1F497D'>The SharedCopy experiment is working great (at least for me).= However, they have a bug where the sticky notes move so please always high= light the text in addition to leaving a note.<o:p></o:p></span></p><p class= =3DMsoNormal><span style=3D'color:#1F497D'><o:p> </o:p></span></p><p c= lass=3DMsoNormal><span style=3D'color:#1F497D'>EHL<o:p></o:p></span></p><p = class=3DMsoNormal><span style=3D'color:#1F497D'><o:p> </o:p></span></p= ><div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in= 4.0pt'><div><div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;paddi= ng:3.0pt 0in 0in 0in'><p class=3DMsoNormal><b><span style=3D'font-size:10.0= pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style=3D'font-s= ize:10.0pt;font-family:"Tahoma","sans-serif"'> oauth-bounces@ietf.org [mail= to:oauth-bounces@ietf.org] <b>On Behalf Of </b>Eran Hammer-Lahav<br><b>Sent= :</b> Tuesday, June 29, 2010 12:11 AM<br><b>To:</b> OAuth WG (oauth@ietf.or= g)<br><b>Subject:</b> Re: [OAUTH-WG] Draft -09<o:p></o:p></span></p></div><= /div><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal><span s= tyle=3D'color:#1F497D'>For editorial feedback, I am going to try something = new and use SharedCopy.com (no install required).<o:p></o:p></span></p><p c= lass=3DMsoNormal><span style=3D'color:#1F497D'><o:p> </o:p></span></p>= <p class=3DMsoNormal><span style=3D'color:#1F497D'>Try it out at: <a href= =3D"http://r6.sharedcopy.com/6bnqq8v">http://r6.sharedcopy.com/6bnqq8v</a><= o:p></o:p></span></p><p class=3DMsoNormal><span style=3D'color:#1F497D'><o:= p> </o:p></span></p><p class=3DMsoNormal><span style=3D'color:#1F497D'= >If this doesn’t work, I’ll let people know and cancel it.<o:p>= </o:p></span></p><p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&n= bsp;</o:p></span></p><p class=3DMsoNormal><span style=3D'color:#1F497D'>EHL= <o:p></o:p></span></p><p class=3DMsoNormal><span style=3D'color:#1F497D'><o= :p> </o:p></span></p><p class=3DMsoNormal><span style=3D'color:#1F497D= '><o:p> </o:p></span></p><div style=3D'border:none;border-left:solid b= lue 1.5pt;padding:0in 0in 0in 4.0pt'><div><div style=3D'border:none;border-= top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=3DMsoNormal><b>= <span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</s= pan></b><span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>= oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] <b>On Behalf Of </b= >Eran Hammer-Lahav<br><b>Sent:</b> Monday, June 28, 2010 11:56 PM<br><b>To:= </b> OAuth WG (oauth@ietf.org)<br><b>Subject:</b> [OAUTH-WG] Draft -09<o:p>= </o:p></span></p></div></div><p class=3DMsoNormal><o:p> </o:p></p><p c= lass=3DMsoNormal>Draft -09 is now posted. Main changes include:<o:p></o:p><= /p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal style=3D'= text-autospace:none'><span style=3D'font-size:9.5pt;font-family:Consolas'>o=   Fixed typos, editorial changes. Thanks to Dick for his useful feedba= ck.<o:p></o:p></span></p><p class=3DMsoNormal style=3D'text-autospace:none'= ><span style=3D'font-size:9.5pt;font-family:Consolas'>o  Added token e= xpiration example.<o:p></o:p></span></p><p class=3DMsoNormal style=3D'text-= autospace:none'><span style=3D'font-size:9.5pt;font-family:Consolas'>o = ; Added scope parameter to end-user authorization endpoint response and WWW= -Authenticate header.<o:p></o:p></span></p><p class=3DMsoNormal style=3D'te= xt-autospace:none'><span style=3D'font-size:9.5pt;font-family:Consolas'>o&n= bsp; Added note about parameters with empty values (same as omitted).<o:p><= /o:p></span></p><p class=3DMsoNormal style=3D'text-autospace:none'><span st= yle=3D'font-size:9.5pt;font-family:Consolas'>o  Changed parameter valu= es to use '-' instead of '_'.  Parameter names still use '_'.<o:p></o:= p></span></p><p class=3DMsoNormal style=3D'text-autospace:none'><span style= =3D'font-size:9.5pt;font-family:Consolas'>o  Changed authorization end= point client type to response type with values: code, token, or both.<o:p><= /o:p></span></p><p class=3DMsoNormal style=3D'text-autospace:none'><span st= yle=3D'font-size:9.5pt;font-family:Consolas'>o  Complete cleanup of er= ror codes.  Added support for error description and URI.<o:p></o:p></s= pan></p><p class=3DMsoNormal style=3D'text-autospace:none'><span style=3D'f= ont-size:9.5pt;font-family:Consolas'>o  Add initial extensibility supp= ort.<o:p></o:p></span></p><p class=3DMsoNormal style=3D'text-autospace:none= '><span style=3D'font-size:9.5pt;font-family:Consolas'><o:p> </o:p></s= pan></p><p class=3DMsoNormal style=3D'text-autospace:none'><span style=3D'f= ont-size:9.5pt;font-family:Consolas'>Draft -09 represents what I consider t= o be the first feature complete proposal. While it still needs much work, i= t has notes for open issues and missing parts. I plan to give people 2 week= s to review and provide extensive feedback, and will post one more draft be= fore the 7/12 cutoff date for the meeting.<o:p></o:p></span></p><p class=3D= MsoNormal style=3D'text-autospace:none'><span style=3D'font-size:9.5pt;font= -family:Consolas'><o:p> </o:p></span></p><p class=3DMsoNormal style=3D= 'text-autospace:none'><span style=3D'font-size:9.5pt;font-family:Consolas'>= My goal is to collect enough feedback to declare the next draft (-10) stabl= e for wider implementation. If you were waiting for a stable draft to study= and provide extensive feedback, this is the draft! When giving feedback pr= etend this is your last chance to making a significant contribution or chan= ges to the core specification.<o:p></o:p></span></p><p class=3DMsoNormal st= yle=3D'text-autospace:none'><span style=3D'font-size:9.5pt;font-family:Cons= olas'><o:p> </o:p></span></p><p class=3DMsoNormal style=3D'text-autosp= ace:none'><span style=3D'font-size:9.5pt;font-family:Consolas'>Please submi= t feedback by 7/9.<o:p></o:p></span></p><p class=3DMsoNormal style=3D'text-= autospace:none'><span style=3D'font-size:9.5pt;font-family:Consolas'><o:p>&= nbsp;</o:p></span></p><p class=3DMsoNormal style=3D'text-autospace:none'><s= pan style=3D'font-size:9.5pt;font-family:Consolas'>When submitting feedback= please start a new thread for each item. Editorial commentary can be colle= cted in one post (and please send to the list, even if it is minor, because= I tend to get the same typo correction many times).<o:p></o:p></span></p><= p class=3DMsoNormal style=3D'text-autospace:none'><span style=3D'font-size:= 9.5pt;font-family:Consolas'><o:p> </o:p></span></p><p class=3DMsoNorma= l style=3D'text-autospace:none'><span style=3D'font-size:9.5pt;font-family:= Consolas'>Thanks,<o:p></o:p></span></p><p class=3DMsoNormal style=3D'text-a= utospace:none'><span style=3D'font-size:9.5pt;font-family:Consolas'><o:p>&n= bsp;</o:p></span></p><p class=3DMsoNormal style=3D'text-autospace:none'><sp= an style=3D'font-size:9.5pt;font-family:Consolas'>EHL<o:p></o:p></span></p>= <p class=3DMsoNormal style=3D'text-autospace:none'><span style=3D'font-size= :9.5pt;font-family:Consolas'><o:p> </o:p></span></p><p class=3DMsoNorm= al><o:p> </o:p></p></div></div></div></body></html>= --_000_90C41DD21FB7C64BB94121FBBC2E72343B3ED4C088P3PW5EX1MB01E_-- From eran@hueniverse.com Wed Jun 30 08:48:28 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E1133A6886 for <oauth@core3.amsl.com>; Wed, 30 Jun 2010 08:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.236 X-Spam-Level: X-Spam-Status: No, score=-2.236 tagged_above=-999 required=5 tests=[AWL=0.362, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OHtoJ0YjvzFH for <oauth@core3.amsl.com>; Wed, 30 Jun 2010 08:48:23 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id DE3473A6974 for <oauth@ietf.org>; Wed, 30 Jun 2010 08:48:22 -0700 (PDT) Received: (qmail 19574 invoked from network); 30 Jun 2010 15:48:33 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 30 Jun 2010 15:48:33 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 30 Jun 2010 08:48:33 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: Torsten Lodderstedt <torsten@lodderstedt.net> Date: Wed, 30 Jun 2010 08:48:35 -0700 Thread-Topic: [OAUTH-WG] Draft -09 Thread-Index: AcsYFRD2EkPmmgqES5qNrEXuQ/i7oQAVnw/g Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C095@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4BCCC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C2AD5F4.2010306@lodderstedt.net> In-Reply-To: <4C2AD5F4.2010306@lodderstedt.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_90C41DD21FB7C64BB94121FBBC2E72343B3ED4C095P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Draft -09 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 30 Jun 2010 15:48:28 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3ED4C095P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I didn't see consensus around it. Specifically, what should be revoked (ref= resh token, access token, both, etc.). If you build consensus, I'll gladly = include it. Also, it is not clear to me how to add it to the current token = endpoint (unless we use a DELETE method). EHL From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] Sent: Tuesday, June 29, 2010 10:28 PM To: Eran Hammer-Lahav Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Draft -09 Hi Eran, what about token revocation? Will you include it? regards, Torsten. Am 29.06.2010 08:56, schrieb Eran Hammer-Lahav: Draft -09 is now posted. Main changes include: o Fixed typos, editorial changes. Thanks to Dick for his useful feedback. o Added token expiration example. o Added scope parameter to end-user authorization endpoint response and WW= W-Authenticate header. o Added note about parameters with empty values (same as omitted). o Changed parameter values to use '-' instead of '_'. Parameter names sti= ll use '_'. o Changed authorization endpoint client type to response type with values:= code, token, or both. o Complete cleanup of error codes. Added support for error description an= d URI. o Add initial extensibility support. Draft -09 represents what I consider to be the first feature complete propo= sal. While it still needs much work, it has notes for open issues and missi= ng parts. I plan to give people 2 weeks to review and provide extensive fee= dback, and will post one more draft before the 7/12 cutoff date for the mee= ting. My goal is to collect enough feedback to declare the next draft (-10) stabl= e for wider implementation. If you were waiting for a stable draft to study= and provide extensive feedback, this is the draft! When giving feedback pr= etend this is your last chance to making a significant contribution or chan= ges to the core specification. Please submit feedback by 7/9. When submitting feedback please start a new thread for each item. Editorial= commentary can be collected in one post (and please send to the list, even= if it is minor, because I tend to get the same typo correction many times)= . Thanks, EHL _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth --_000_90C41DD21FB7C64BB94121FBBC2E72343B3ED4C095P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV=3D"Content-Type" CONTENT= =3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros= oft Word 14 (filtered medium)"><style><!-- /* Font Definitions */ @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} @font-face {font-family:Consolas; panose-1:2 11 6 9 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif"; color:black;} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} pre {mso-style-priority:99; mso-style-link:"HTML Preformatted Char"; margin:0in; margin-bottom:.0001pt; font-size:10.0pt; font-family:"Courier New"; color:black;} p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {mso-style-priority:34; margin-top:0in; margin-right:0in; margin-bottom:0in; margin-left:.5in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif"; color:black;} span.EmailStyle18 {mso-style-type:personal; font-family:"Calibri","sans-serif"; color:windowtext;} span.HTMLPreformattedChar {mso-style-name:"HTML Preformatted Char"; mso-style-priority:99; mso-style-link:"HTML Preformatted"; font-family:Consolas; color:black;} span.EmailStyle21 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--></head><body bgcolor=3Dwhite lang=3DEN-US= link=3Dblue vlink=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal>= <span style=3D'color:#1F497D'>I didn’t see consensus around it. Speci= fically, what should be revoked (refresh token, access token, both, etc.). = If you build consensus, I’ll gladly include it. Also, it is not clear= to me how to add it to the current token endpoint (unless we use a DELETE = method).<o:p></o:p></span></p><p class=3DMsoNormal><span style=3D'color:#1F= 497D'><o:p> </o:p></span></p><p class=3DMsoNormal><span style=3D'color= :#1F497D'>EHL<o:p></o:p></span></p><p class=3DMsoNormal><span style=3D'colo= r:#1F497D'><o:p> </o:p></span></p><div style=3D'border:none;border-lef= t:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><div><div style=3D'border:non= e;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=3DMsoN= ormal><b><span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";= color:windowtext'>From:</span></b><span style=3D'font-size:10.0pt;font-fami= ly:"Tahoma","sans-serif";color:windowtext'> Torsten Lodderstedt [mailto:tor= sten@lodderstedt.net] <br><b>Sent:</b> Tuesday, June 29, 2010 10:28 PM<br><= b>To:</b> Eran Hammer-Lahav<br><b>Cc:</b> OAuth WG (oauth@ietf.org)<br><b>S= ubject:</b> Re: [OAUTH-WG] Draft -09<o:p></o:p></span></p></div></div><p cl= ass=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>Hi Eran,<br><br>w= hat about token revocation? Will you include it?<br><br>regards,<br>Torsten= .<br><br>Am 29.06.2010 08:56, schrieb Eran Hammer-Lahav: <o:p></o:p></p><p = class=3DMsoNormal>Draft -09 is now posted. Main changes include:<o:p></o:p>= </p><p class=3DMsoNormal> <o:p></o:p></p><p class=3DMsoNormal><span st= yle=3D'font-size:9.5pt;font-family:Consolas'>o  Fixed typos, editorial= changes. Thanks to Dick for his useful feedback.</span><o:p></o:p></p><p c= lass=3DMsoNormal><span style=3D'font-size:9.5pt;font-family:Consolas'>o&nbs= p; Added token expiration example.</span><o:p></o:p></p><p class=3DMsoNorma= l><span style=3D'font-size:9.5pt;font-family:Consolas'>o  Added scope = parameter to end-user authorization endpoint response and WWW-Authenticate = header.</span><o:p></o:p></p><p class=3DMsoNormal><span style=3D'font-size:= 9.5pt;font-family:Consolas'>o  Added note about parameters with empty = values (same as omitted).</span><o:p></o:p></p><p class=3DMsoNormal><span s= tyle=3D'font-size:9.5pt;font-family:Consolas'>o  Changed parameter val= ues to use '-' instead of '_'.  Parameter names still use '_'.</span><= o:p></o:p></p><p class=3DMsoNormal><span style=3D'font-size:9.5pt;font-fami= ly:Consolas'>o  Changed authorization endpoint client type to response= type with values: code, token, or both.</span><o:p></o:p></p><p class=3DMs= oNormal><span style=3D'font-size:9.5pt;font-family:Consolas'>o  Comple= te cleanup of error codes.  Added support for error description and UR= I.</span><o:p></o:p></p><p class=3DMsoNormal><span style=3D'font-size:9.5pt= ;font-family:Consolas'>o  Add initial extensibility support.</span><o:= p></o:p></p><p class=3DMsoNormal><span style=3D'font-size:9.5pt;font-family= :Consolas'> </span><o:p></o:p></p><p class=3DMsoNormal><span style=3D'= font-size:9.5pt;font-family:Consolas'>Draft -09 represents what I consider = to be the first feature complete proposal. While it still needs much work, = it has notes for open issues and missing parts. I plan to give people 2 wee= ks to review and provide extensive feedback, and will post one more draft b= efore the 7/12 cutoff date for the meeting.</span><o:p></o:p></p><p class= =3DMsoNormal><span style=3D'font-size:9.5pt;font-family:Consolas'> </s= pan><o:p></o:p></p><p class=3DMsoNormal><span style=3D'font-size:9.5pt;font= -family:Consolas'>My goal is to collect enough feedback to declare the next= draft (-10) stable for wider implementation. If you were waiting for a sta= ble draft to study and provide extensive feedback, this is the draft! When = giving feedback pretend this is your last chance to making a significant co= ntribution or changes to the core specification.</span><o:p></o:p></p><p cl= ass=3DMsoNormal><span style=3D'font-size:9.5pt;font-family:Consolas'> = </span><o:p></o:p></p><p class=3DMsoNormal><span style=3D'font-size:9.5pt;f= ont-family:Consolas'>Please submit feedback by 7/9.</span><o:p></o:p></p><p= class=3DMsoNormal><span style=3D'font-size:9.5pt;font-family:Consolas'>&nb= sp;</span><o:p></o:p></p><p class=3DMsoNormal><span style=3D'font-size:9.5p= t;font-family:Consolas'>When submitting feedback please start a new thread = for each item. Editorial commentary can be collected in one post (and pleas= e send to the list, even if it is minor, because I tend to get the same typ= o correction many times).</span><o:p></o:p></p><p class=3DMsoNormal><span s= tyle=3D'font-size:9.5pt;font-family:Consolas'> </span><o:p></o:p></p><= p class=3DMsoNormal><span style=3D'font-size:9.5pt;font-family:Consolas'>Th= anks,</span><o:p></o:p></p><p class=3DMsoNormal><span style=3D'font-size:9.= 5pt;font-family:Consolas'> </span><o:p></o:p></p><p class=3DMsoNormal>= <span style=3D'font-size:9.5pt;font-family:Consolas'>EHL</span><o:p></o:p><= /p><p class=3DMsoNormal><span style=3D'font-size:9.5pt;font-family:Consolas= '> </span><o:p></o:p></p><p class=3DMsoNormal> <o:p></o:p></p><pr= e><o:p> </o:p></pre><pre><o:p> </o:p></pre><pre>_________________= ______________________________<o:p></o:p></pre><pre>OAuth mailing list<o:p>= </o:p></pre><pre><a href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org</a><o:p><= /o:p></pre><pre><a href=3D"https://www.ietf.org/mailman/listinfo/oauth">htt= ps://www.ietf.org/mailman/listinfo/oauth</a><o:p></o:p></pre><pre>  <o= :p></o:p></pre></div></div></body></html>= --_000_90C41DD21FB7C64BB94121FBBC2E72343B3ED4C095P3PW5EX1MB01E_-- From mscurtescu@google.com Wed Jun 30 10:32:05 2010 Return-Path: <mscurtescu@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F2993A6A59 for <oauth@core3.amsl.com>; Wed, 30 Jun 2010 10:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.505 X-Spam-Level: X-Spam-Status: No, score=-101.505 tagged_above=-999 required=5 tests=[AWL=0.472, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G3MX0wwNQ8be for <oauth@core3.amsl.com>; Wed, 30 Jun 2010 10:31:57 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id CBD243A6A5B for <oauth@ietf.org>; Wed, 30 Jun 2010 10:31:39 -0700 (PDT) Received: from kpbe14.cbf.corp.google.com (kpbe14.cbf.corp.google.com [172.25.105.78]) by smtp-out.google.com with ESMTP id o5UHVmhC031346 for <oauth@ietf.org>; Wed, 30 Jun 2010 10:31:49 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1277919109; bh=Jk0spbgq+oE8MHbC7zPC+gLIEGE=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=vjP6FyiEz0V6nqPGKpY2YmWoptWT7H0KefbjxwJ78wmtP8LGbDz1H7mHUjKgAFV3Z Xw1dNfE8z11X+NKEdX01Q== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=OK1lRavvpVYlwkKaPR+4yM4b212BFAM551Kp8dNapPMbozLLLwT3YGOQloBUZg1Su iuChzthw43fsxpd6FKuSw== Received: from gyg4 (gyg4.prod.google.com [10.243.50.132]) by kpbe14.cbf.corp.google.com with ESMTP id o5UHU2s8014112 for <oauth@ietf.org>; Wed, 30 Jun 2010 10:31:47 -0700 Received: by gyg4 with SMTP id 4so636805gyg.40 for <oauth@ietf.org>; Wed, 30 Jun 2010 10:31:47 -0700 (PDT) Received: by 10.101.7.36 with SMTP id k36mr10910641ani.24.1277919107246; Wed, 30 Jun 2010 10:31:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.132.22 with HTTP; Wed, 30 Jun 2010 10:31:27 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C068@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <AANLkTikMuFIaJ1bnL3FOSzsRmO0Ix9xzyyzQG0hcWVcV@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C068@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu <mscurtescu@google.com> Date: Wed, 30 Jun 2010 10:31:27 -0700 Message-ID: <AANLkTikxAcH2uLQ_dhMcBCqbriilP-5KoZcbGalGRau7@mail.gmail.com> To: Eran Hammer-Lahav <eran@hueniverse.com> Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] OAuth 1.0 token assertion to OAuth 2.0 token (was: Draft -09) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 30 Jun 2010 17:32:05 -0000 On Wed, Jun 30, 2010 at 8:13 AM, Eran Hammer-Lahav <eran@hueniverse.com> wrote: > No benefit. This would just be the "2.0 way" of doing it. I see, and that's a good point. >From an implementation perspective, clients and servers that support OAuth 1 can easily implement a signature based bridge endpoint. The OAuth 1 assertion will require both parties to implement new signature code, and that can be challenging. Marius > > EHL > >> -----Original Message----- >> From: Marius Scurtescu [mailto:mscurtescu@google.com] >> Sent: Tuesday, June 29, 2010 6:13 PM >> To: Eran Hammer-Lahav >> Cc: OAuth WG (oauth@ietf.org) >> Subject: OAuth 1.0 token assertion to OAuth 2.0 token (was: Draft -09) >> >> On Tue, Jun 29, 2010 at 8:22 AM, Eran Hammer-Lahav >> <eran@hueniverse.com> wrote: >> > >> > The assertion grant type is really the grant type extension point. Libraries >> should treat it as a way to support custom grant types. One of the things I >> would like to see someone draft is how to use OAuth 1.0 tokens to obtain >> OAuth 2.0 tokens using the assertion type. For example, the assertion type >> can be "http://oauth.net/1.0/token" , and the assertion itself is some form >> of the token and signature (or secrets) concatenated into a string (this will >> maintain the 1.0 security while transitioning to 2.0). This is just a straw man. >> > >> > It is important that libraries support this extensibility with some form of a >> hook or handler so that clients can make requests using assertions from >> outside the library. >> >> An OAuth 1 token assertion as described above would achieve the same >> thing as the suggested bridge endpoint. Do you see any advantages on using >> an assertion as opposed to a standard OAuth 1 signed request? >> >> Marius > From zachary.zeltsan@alcatel-lucent.com Wed Jun 30 15:24:25 2010 Return-Path: <zachary.zeltsan@alcatel-lucent.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 360EB3A6837 for <oauth@core3.amsl.com>; Wed, 30 Jun 2010 15:24:25 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DAuIR81LXIA5 for <oauth@core3.amsl.com>; Wed, 30 Jun 2010 15:24:22 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 964603A659C for <oauth@ietf.org>; Wed, 30 Jun 2010 15:24:22 -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 o5UMOUSt007432 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Jun 2010 17:24:31 -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 o5UMOOa6002256; Wed, 30 Jun 2010 17:24:30 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.127]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Wed, 30 Jun 2010 17:24:18 -0500 From: "Zeltsan, Zachary (Zachary)" <zachary.zeltsan@alcatel-lucent.com> To: "Faynberg, Igor (Igor)" <igor.faynberg@alcatel-lucent.com>, Eran Hammer-Lahav <eran@hueniverse.com> Date: Wed, 30 Jun 2010 17:24:16 -0500 Thread-Topic: [OAUTH-WG] How do we deal with unrecognized elements in requests and responses? Thread-Index: AcsXNOcxfZMC/Fa6ShyZRdfpf2BFOwBaWBQA Message-ID: <5710F82C0E73B04FA559560098BF95B124F9688D8E@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <7C01E631FF4B654FA1E783F1C0265F8C579D0F52@TK5EX14MBXC117.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4BCB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTin2cvQnXB7x9abGLF4xQyfrv9IzZCzxOHnJqlHQ@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4BCB4@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C295DDA.7040106@alcatel-lucent.com> In-Reply-To: <4C295DDA.7040106@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 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] How do we deal with unrecognized elements in requests and responses? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 30 Jun 2010 22:24:25 -0000 Igor, Discovery of the address needed for obtaining the client credentials, the e= nd-user authorization endpoint, and the token endpoint is common for many u= se cases, where a client does not have this information. I am not aware of = the use cases with the specific requirements for discovery. Zachary=20 -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of I= gor Faynberg Sent: Monday, June 28, 2010 10:44 PM To: Eran Hammer-Lahav Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] How do we deal with unrecognized elements in reques= ts and responses? I agree. I think we indeed should clearly articulate the use cases driving=20 discovery (maybe Zachary could report on those?), but I also think that=20 we will probably need to get something like "procedures," which describe=20 expected usages, within the protocol specification. For one thing, all=20 extensions whose support is essential under specific circumstances=20 should be described listing such circumstances and recommending the=20 action. (I also think that the idea of specifying pre- and post-=20 conditions in use cases will help.) Igor Eran Hammer-Lahav wrote: > > There are times when the client wants the server to fail if it doesn't=20 > support an extension. The client developer might consider the server=20 > as being less secure without the added protection of the extension and=20 > would like the server to be able to tell it was making such a request=20 > and fail. > > This clearly belongs in the use cases driving discovery, as in the=20 > core specification, the client is expected to be familiar with the=20 > details of the server. So we just need to make sure that we don't=20 > prevent such use cases. #2 doesn't prevent it, but requires the client=20 > to break something else. For example, an extension having to do with=20 > client identity should replace the client_id parameter with something=20 > else, making a server unaware of this extension fail (because the=20 > required client_id parameter will be missing). > > EHL > > *From:* David Recordon [mailto:recordond@gmail.com] > *Sent:* Monday, June 28, 2010 6:11 PM > *To:* Eran Hammer-Lahav > *Cc:* Yaron Goland; OAuth WG (oauth@ietf.org) > *Subject:* Re: [OAUTH-WG] How do we deal with unrecognized elements in=20 > requests and responses? > > For #2, if an extension defines required parameters then you're not=20 > supporting the extension if you ignore them. Or am I missing something? > > On Mon, Jun 28, 2010 at 5:59 PM, Eran Hammer-Lahav=20 > <eran@hueniverse.com <mailto:eran@hueniverse.com>> wrote: > > There are 3 general ways to deal with this: > > 1. Break on unrecognized parameters - this tends to make the use of=20 > extensions hard, and at a minimum requires an error to include the bad=20 > parameter in a machine readable way (so a library can figure out an=20 > extension is not supported). > > 2. Ignore unrecognized parameters - this is the usual way of dealing=20 > with extensible protocols. It has security implications when extension=20 > parameters must not be ignored. However, the workaround is simply to=20 > break something else (i.e. replace the client_id with something else=20 > that will cause the normal flow to break). > > 3. Same as #2 but include a directive which means 'must not ignore any=20 > parameter; return error if any parameter is unknown'. XRD used to=20 > include such a 'must-support' attribute for properties but was dropped=20 > due to lack of use cases. > > I think #2 offers a good enough balance here, but am happy to discuss=20 > #3 if people have actual use cases where ignoring an extension will=20 > cause security issues. Note that with the expectation of error codes,=20 > my upcoming extensibility proposal does not allow adding any new=20 > parameter values (only new parameters). > > EHL > > *From:* oauth-bounces@ietf.org <mailto:oauth-bounces@ietf.org>=20 > [mailto:oauth-bounces@ietf.org <mailto:oauth-bounces@ietf.org>] *On=20 > Behalf Of *Yaron Goland > *Sent:* Monday, June 28, 2010 3:02 PM > *To:* oauth@ietf.org <mailto:oauth@ietf.org> > *Subject:* [OAUTH-WG] How do we deal with unrecognized elements in=20 > requests and responses? > > In a private thread with Eran an issue came up regarding how to handle=20 > unrecognized arguments in OAuth requests and responses. > > For example, if a token endpoint receives an access token request that=20 > contains both a client_id and a client_foo_bar argument, what should=20 > it do? Should it reject the request since it doesn't recognize=20 > client_foo_bar? Should it ignore client_foo_bar and just process the=20 > request based on client_id? > > Similarly imagine that a response to an access token request contains=20 > a JSON member with some unrecognized name. What's the right behavior?=20 > Ignore the unrecognized value? Or treat the response as badly=20 > formatted and fail out? > > We need to define in the spec how to deal with unrecognized=20 > extensions. Typically the rule is 'ignore what you don't recognize'=20 > but there is a countervailing rule which applies here which is=20 > "security is different". Typically ignoring unrecognized elements in a=20 > security context can lead to security holes. > > Just looking at the history of OAuth I suspect we need to go with the=20 > ignore rule and then explore ad nauseam in the security considerations=20 > section all the ways that the ignore rule can go wrong if extensions=20 > aren't handled carefully. > > Thoughts? > > Thanks, > > Yaron > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > > ------------------------------------------------------------------------ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > =20 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From yarong@microsoft.com Wed Jun 30 17:38:56 2010 Return-Path: <yarong@microsoft.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2C603A6816 for <oauth@core3.amsl.com>; Wed, 30 Jun 2010 17:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.006 X-Spam-Level: X-Spam-Status: No, score=-10.006 tagged_above=-999 required=5 tests=[AWL=0.593, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uPVqxCsTngDk for <oauth@core3.amsl.com>; Wed, 30 Jun 2010 17:38:45 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 7E0B33A6803 for <oauth@ietf.org>; Wed, 30 Jun 2010 17:38:45 -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; Wed, 30 Jun 2010 17:38:56 -0700 Received: from TK5EX14MBXC117.redmond.corp.microsoft.com ([169.254.8.23]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.01.0160.007; Wed, 30 Jun 2010 17:38:56 -0700 From: Yaron Goland <yarong@microsoft.com> To: Torsten Lodderstedt <torsten@lodderstedt.net> Thread-Topic: [OAUTH-WG] Client credentials type Thread-Index: AcsW5Zz/FVZYBlj1T06cHdkG6yGF6wAQ7zsAAAILVAAAADaKAAAIxkVwAEFkDIAAFqxUAA== Date: Thu, 1 Jul 2010 00:38:53 +0000 Message-ID: <7C01E631FF4B654FA1E783F1C0265F8C579D7615@TK5EX14MBXC117.redmond.corp.microsoft.com> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EC84C9D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C28E814.1060102@lodderstedt.net> <AANLkTilw0noo6qyKKXDI06Y4bIiippjvjGRFia0MwXmY@mail.gmail.com> <4C28F73A.4090800@lodderstedt.net> <7C01E631FF4B654FA1E783F1C0265F8C579D107B@TK5EX14MBXC117.redmond.corp.microsoft.com> <20100630084921.12976ty3y7wuz6cc@webmail.df.eu> In-Reply-To: <20100630084921.12976ty3y7wuz6cc@webmail.df.eu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Client credentials type X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 01 Jul 2010 00:38:57 -0000 Or just a bit of XML signatures and encryption. The byte bloat is astoundin= g. Yaron > -----Original Message----- > From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > Sent: Tuesday, June 29, 2010 11:49 PM > To: Yaron Goland > Cc: Marius Scurtescu; OAuth WG (oauth@ietf.org) > Subject: RE: [OAUTH-WG] Client credentials type >=20 > that's pretty big! Can you please explain what kind of client you authent= icate > with such assertions? They must contain hundreds of attributes. >=20 > regards, > Torsten. >=20 > Zitat von Yaron Goland <yarong@microsoft.com>: >=20 > > We regularly deal with SAML assertions that easily go into the 100s of > > K. This is far more than most HTTP servers will accept. So we are > > pretty much required to use the body. > > > >> -----Original Message----- > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >> Behalf Of Torsten Lodderstedt > >> Sent: Monday, June 28, 2010 12:26 PM > >> To: Marius Scurtescu > >> Cc: OAuth WG (oauth@ietf.org) > >> Subject: Re: [OAUTH-WG] Client credentials type > >> > >> what size do you expect? SPNEGO authentication headers can be up to > >> 12392 bytes and this does not seem to be a problem. > >> > >> regards, > >> Torsten. > >> > >> Am 28.06.2010 21:19, schrieb Marius Scurtescu: > >> > Only HTTP headers may not be enough. In Yaron's proposal, the > >> > assertion could be a SAML assertion, and these could be too large > >> > for headers. > >> > > >> > I think #1 makes sense. > >> > > >> > Marius > >> > > >> > > >> > > >> > On Mon, Jun 28, 2010 at 11:21 AM, Torsten Lodderstedt > >> > <torsten@lodderstedt.net> wrote: > >> > > >> >> I would prefer (2) since authorization headers are the natural way > >> >> to handle authentication in HTTP. Different client credential > >> >> mechanisms can be represented by different authentication scheme > >> >> (even custom-defined). HTTP libraries typically have special > >> >> support for handling such headers and it keeps the authentication > >> >> mechanism orthogonal of the API. Moreover, authorization headers > >> >> very well work together with status code 401 and WWW-Authenticate > >> >> headers. Using WWW-Authenticate headers, an authz server can > >> >> easily signal what mechanisms (multiple WWW-Authenticate headers > >> >> are allowed in a single > >> HTTP response) it accepts for a particular request. > >> >> > >> >> regards, > >> >> Torsten. > >> >> > >> >> Am 28.06.2010 19:39, schrieb Eran Hammer-Lahav: > >> >> > >> >> Yaron Goland offered a proposal for an additional client > >> >> credentials mechanism based on assertion. His proposal raises the > >> >> issue of differentiating between the different kind of credentials > >> >> used. When it comes to access grant types, this group argued for > >> >> being explicit and providing a parameter declaring the grant type > >> >> being used (even though it is not technically necessary). > >> >> > >> >> > >> >> > >> >> While I don't believe a grant or credential type parameter is > >> >> needed > >> >> - the type can be deduced from the other parameters present - we > >> >> now treat the same requirement with a different solution. I think > >> >> this creates a broken environment for extensibility (which is my > >> >> current > >> focus). > >> >> > >> >> > >> >> > >> >> At the same time, introducing such a parameter can conflict with > >> >> the standard HTTP authentication mechanism. For example, a request > >> >> containing both "client_credentials_type=3Dbasic" and the HTTP > >> >> Authorization header seems odd. > >> >> > >> >> > >> >> > >> >> There are a few ways to address this: > >> >> > >> >> > >> >> > >> >> 1. Only use a type parameter when the credentials are passed using > >> >> parameters and not a header. > >> >> > >> >> 2. Only allow HTTP headers for authentication, while > >> >> "grandfathering-in" the client_secret parameter to simplify the > >> >> most > >> common current practice. > >> >> > >> >> 3. Leave is underspecified, relying on the presence of extension > >> >> parameters or authentication headers for other credentials types. > >> >> > >> >> > >> >> > >> >> Thoughts? > >> >> > >> >> > >> >> > >> >> 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 > > > > >=20 >=20 >=20 >=20 From yarong@microsoft.com Wed Jun 30 17:41:40 2010 Return-Path: <yarong@microsoft.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7397A3A684F for <oauth@core3.amsl.com>; Wed, 30 Jun 2010 17:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.041 X-Spam-Level: X-Spam-Status: No, score=-10.041 tagged_above=-999 required=5 tests=[AWL=0.558, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LNvV8uMtinjg for <oauth@core3.amsl.com>; Wed, 30 Jun 2010 17:41:39 -0700 (PDT) Received: from smtp.microsoft.com (mail1.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 336C33A6816 for <oauth@ietf.org>; Wed, 30 Jun 2010 17:41:39 -0700 (PDT) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 30 Jun 2010 17:41:43 -0700 Received: from TK5EX14MBXC117.redmond.corp.microsoft.com ([169.254.8.23]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.01.0160.007; Wed, 30 Jun 2010 17:41:45 -0700 From: Yaron Goland <yarong@microsoft.com> To: Yaron Goland <yarong@microsoft.com>, Torsten Lodderstedt <torsten@lodderstedt.net> Thread-Topic: [OAUTH-WG] Client credentials type Thread-Index: AcsW5Zz/FVZYBlj1T06cHdkG6yGF6wAQ7zsAAAILVAAAADaKAAAIxkVwAEFkDIAAFqxUAAAAF4Fw Date: Thu, 1 Jul 2010 00:41:39 +0000 Message-ID: <7C01E631FF4B654FA1E783F1C0265F8C579D765B@TK5EX14MBXC117.redmond.corp.microsoft.com> References: <90C41DD21FB7C64BB94121FBBC2E72343B3EC84C9D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C28E814.1060102@lodderstedt.net> <AANLkTilw0noo6qyKKXDI06Y4bIiippjvjGRFia0MwXmY@mail.gmail.com> <4C28F73A.4090800@lodderstedt.net> <7C01E631FF4B654FA1E783F1C0265F8C579D107B@TK5EX14MBXC117.redmond.corp.microsoft.com> <20100630084921.12976ty3y7wuz6cc@webmail.df.eu> <7C01E631FF4B654FA1E783F1C0265F8C579D7615@TK5EX14MBXC117.redmond.corp.microsoft.com> In-Reply-To: <7C01E631FF4B654FA1E783F1C0265F8C579D7615@TK5EX14MBXC117.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Client credentials type X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 01 Jul 2010 00:41:40 -0000 Oh and don't forget fun things like including the full cert chain which aft= er encoding also bloats to amazing heights. > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Yaron Goland > Sent: Wednesday, June 30, 2010 5:39 PM > To: Torsten Lodderstedt > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Client credentials type >=20 > Or just a bit of XML signatures and encryption. The byte bloat is astound= ing. >=20 > Yaron >=20 > > -----Original Message----- > > From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > > Sent: Tuesday, June 29, 2010 11:49 PM > > To: Yaron Goland > > Cc: Marius Scurtescu; OAuth WG (oauth@ietf.org) > > Subject: RE: [OAUTH-WG] Client credentials type > > > > that's pretty big! Can you please explain what kind of client you > > authenticate with such assertions? They must contain hundreds of > attributes. > > > > regards, > > Torsten. > > > > Zitat von Yaron Goland <yarong@microsoft.com>: > > > > > We regularly deal with SAML assertions that easily go into the 100s > > > of K. This is far more than most HTTP servers will accept. So we are > > > pretty much required to use the body. > > > > > >> -----Original Message----- > > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > > >> Behalf Of Torsten Lodderstedt > > >> Sent: Monday, June 28, 2010 12:26 PM > > >> To: Marius Scurtescu > > >> Cc: OAuth WG (oauth@ietf.org) > > >> Subject: Re: [OAUTH-WG] Client credentials type > > >> > > >> what size do you expect? SPNEGO authentication headers can be up to > > >> 12392 bytes and this does not seem to be a problem. > > >> > > >> regards, > > >> Torsten. > > >> > > >> Am 28.06.2010 21:19, schrieb Marius Scurtescu: > > >> > Only HTTP headers may not be enough. In Yaron's proposal, the > > >> > assertion could be a SAML assertion, and these could be too large > > >> > for headers. > > >> > > > >> > I think #1 makes sense. > > >> > > > >> > Marius > > >> > > > >> > > > >> > > > >> > On Mon, Jun 28, 2010 at 11:21 AM, Torsten Lodderstedt > > >> > <torsten@lodderstedt.net> wrote: > > >> > > > >> >> I would prefer (2) since authorization headers are the natural > > >> >> way to handle authentication in HTTP. Different client > > >> >> credential mechanisms can be represented by different > > >> >> authentication scheme (even custom-defined). HTTP libraries > > >> >> typically have special support for handling such headers and it > > >> >> keeps the authentication mechanism orthogonal of the API. > > >> >> Moreover, authorization headers very well work together with > > >> >> status code 401 and WWW-Authenticate headers. Using > > >> >> WWW-Authenticate headers, an authz server can easily signal what > > >> >> mechanisms (multiple WWW-Authenticate headers are allowed in a > > >> >> single > > >> HTTP response) it accepts for a particular request. > > >> >> > > >> >> regards, > > >> >> Torsten. > > >> >> > > >> >> Am 28.06.2010 19:39, schrieb Eran Hammer-Lahav: > > >> >> > > >> >> Yaron Goland offered a proposal for an additional client > > >> >> credentials mechanism based on assertion. His proposal raises > > >> >> the issue of differentiating between the different kind of > > >> >> credentials used. When it comes to access grant types, this > > >> >> group argued for being explicit and providing a parameter > > >> >> declaring the grant type being used (even though it is not techni= cally > necessary). > > >> >> > > >> >> > > >> >> > > >> >> While I don't believe a grant or credential type parameter is > > >> >> needed > > >> >> - the type can be deduced from the other parameters present - we > > >> >> now treat the same requirement with a different solution. I > > >> >> think this creates a broken environment for extensibility (which > > >> >> is my current > > >> focus). > > >> >> > > >> >> > > >> >> > > >> >> At the same time, introducing such a parameter can conflict with > > >> >> the standard HTTP authentication mechanism. For example, a > > >> >> request containing both "client_credentials_type=3Dbasic" and the > > >> >> HTTP Authorization header seems odd. > > >> >> > > >> >> > > >> >> > > >> >> There are a few ways to address this: > > >> >> > > >> >> > > >> >> > > >> >> 1. Only use a type parameter when the credentials are passed > > >> >> using parameters and not a header. > > >> >> > > >> >> 2. Only allow HTTP headers for authentication, while > > >> >> "grandfathering-in" the client_secret parameter to simplify the > > >> >> most > > >> common current practice. > > >> >> > > >> >> 3. Leave is underspecified, relying on the presence of extension > > >> >> parameters or authentication headers for other credentials types. > > >> >> > > >> >> > > >> >> > > >> >> Thoughts? > > >> >> > > >> >> > > >> >> > > >> >> 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 > > > > > > > > > > > > > > >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From yarong@microsoft.com Wed Jun 30 17:47:42 2010 Return-Path: <yarong@microsoft.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6C3F3A6863 for <oauth@core3.amsl.com>; Wed, 30 Jun 2010 17:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.865 X-Spam-Level: X-Spam-Status: No, score=-8.865 tagged_above=-999 required=5 tests=[AWL=-0.680, BAYES_40=-0.185, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O+BITo+q-Cof for <oauth@core3.amsl.com>; Wed, 30 Jun 2010 17:47:41 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id DC6383A6816 for <oauth@ietf.org>; Wed, 30 Jun 2010 17:47:41 -0700 (PDT) Received: from TK5EX14CASC131.redmond.corp.microsoft.com (157.54.52.38) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 30 Jun 2010 17:47:47 -0700 Received: from TK5EX14MBXC117.redmond.corp.microsoft.com ([169.254.8.23]) by TK5EX14CASC131.redmond.corp.microsoft.com ([157.54.52.38]) with mapi id 14.01.0160.007; Wed, 30 Jun 2010 17:47:46 -0700 From: Yaron Goland <yarong@microsoft.com> To: "Manger, James H" <James.H.Manger@team.telstra.com>, "oauth@ietf.org" <oauth@ietf.org> Thread-Topic: Proposal for text for section 2 Thread-Index: AcsUm7O3+LYTofkOQ6CsKuFeuynp2ACcJnPgAAxyEYAAH/FooAAMQp/wADFXrDA= Date: Thu, 1 Jul 2010 00:47:44 +0000 Message-ID: <7C01E631FF4B654FA1E783F1C0265F8C579D76A1@TK5EX14MBXC117.redmond.corp.microsoft.com> References: <7C01E631FF4B654FA1E783F1C0265F8C579CC0C3@TK5EX14MBXC117.redmond.corp.microsoft.com> <7C01E631FF4B654FA1E783F1C0265F8C579D0F31@TK5EX14MBXC117.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E11265A5FC9D@WSMSG3153V.srv.dir.telstra.com> <7C01E631FF4B654FA1E783F1C0265F8C579D20CB@TK5EX14MBXC117.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E11265B7E872@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11265B7E872@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Proposal for text for section 2 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 01 Jul 2010 00:47:43 -0000 James, how can you ding client assertions credentials for doing exactly wha= t client basic credentials do? The current spec defines that client basic credentials can go into the requ= est body and defines this behavior in section 2. I just patterned the clien= t assertion credentials text word for word from the existing basic credenti= als text. That having been said I wonder if there isn't a simple compromise here. How= about we edit the client assertion proposal to include the ability to put = assertions both in the HTTP authorization header as well as in the body? Th= en the assertion proposal will be 100% equivalent to the existing basic cre= dentials proposal. After all, if we do have an assertion that is small enough to fit in the he= ader I'd rather see it there than in the body. I personally only want the b= ody as an emergency escape hatch. I'm certainly no fan of shoving this kind= of stuff in the request body. What do you think? Yaron > -----Original Message----- > From: Manger, James H [mailto:James.H.Manger@team.telstra.com] > Sent: Tuesday, June 29, 2010 7:30 PM > To: Yaron Goland; oauth@ietf.org > Subject: RE: Proposal for text for section 2 >=20 > Yaron, >=20 > [Sorry I didn't see your response before sending my previous reply] >=20 > > SAML assertions routinely run into the 10s and even 100s of K. > > This exceeds the practical limit that most HTTP servers and proxies > > put on the size of the HTTP request headers they are willing to accept. > > So we cannot rely on the HTTP authorization header as a means of > > transporting SAML assertions. > > We are thus, as a practical matter, forced into using the request body. >=20 > So SAML assertions are impractical for authenticating/authorizing request= s to > a general HTTP API. Three options are: > 1) Swap the assertion for session credentials that work with the API; or > 2) Redefine the API to include the client assertion, which constrains the= API > to only use POSTs of form-encoded requests; or > 3) Shrink the assertions (eg with compression or an artefact-binding) so = it fits > the HTTP model. >=20 > The API in question here is the OAuth2 "token endpoint" API [section 4 of > draft-ietf-oauth-v2-09]. > You want to take option 2 -- which sort of makes sense in this case since= this > API is already about swapping credentials. >=20 > This feels like a good candidate for a separate spec: "An HTTP API for > obtaining an OAuth2 token with an assertion". >=20 > The proposal might jar a little less if it was part of the API definition= [section > 4]. It is certainly not "completely orthogonal to anything in section 4" = since it > adds constraints (POST and form-encoding) and applies only to the specifi= c > section 4 API and no others. >=20 > -- > James Manger >=20 >=20 >=20 > From: Manger, James H [mailto:James.H.Manger@team.telstra.com] > Sent: Monday, June 28, 2010 9:38 PM >=20 > ..."Assertion Client Credentials" is too much of a hack. It only works fo= r > POSTs, and only when the body is form-encoded. >=20 > It could not be used, for instance, to delete a token with an HTTP DELETE > request... >=20 >=20 > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Yaron Goland > Sent: Tuesday, 29 June 2010 7:56 AM >=20 > The following is proposed language for a new section, 2.2, in the spec. T= his is > part of the spec that deals with client authentication. This proposal is > completely orthogonal to anything in section 4 such as grant types... >=20 > 2.2 Assertion Client Credentials > ... From mscurtescu@google.com Wed Jun 30 18:28:57 2010 Return-Path: <mscurtescu@google.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F8953A68C6 for <oauth@core3.amsl.com>; Wed, 30 Jun 2010 18:28:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.521 X-Spam-Level: X-Spam-Status: No, score=-101.521 tagged_above=-999 required=5 tests=[AWL=0.456, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ek2DQ1C158On for <oauth@core3.amsl.com>; Wed, 30 Jun 2010 18:28:56 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 7851C3A6896 for <oauth@ietf.org>; Wed, 30 Jun 2010 18:28:56 -0700 (PDT) Received: from hpaq5.eem.corp.google.com (hpaq5.eem.corp.google.com [172.25.149.5]) by smtp-out.google.com with ESMTP id o611T7cX029034 for <oauth@ietf.org>; Wed, 30 Jun 2010 18:29:07 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1277947747; bh=rFchWi1t8jWBAY1EDmxgwDkQvLU=; h=MIME-Version:From:Date:Message-ID:Subject:To:Content-Type; b=kjVCU44ydY+aVMJ43yLoYk4Gv0wBdjQ2HVoXiNxUrv8fsc0WlEFjK6zlMn9gvfVJm psVLfMqOcRSgCQD7lufdQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:from:date:message-id:subject:to:content-type:x-system-of-record; b=eSdcsLVs0Hw2uJvZqCutAoFZBQtOxX7mnY+V7Sy6mohw77IZ5zY7Q+tCWEMXvzGYO 89xKJ/207usfemKyPHP6g== Received: from gwj19 (gwj19.prod.google.com [10.200.10.19]) by hpaq5.eem.corp.google.com with ESMTP id o611T5Bk024340 for <oauth@ietf.org>; Wed, 30 Jun 2010 18:29:06 -0700 Received: by gwj19 with SMTP id 19so821580gwj.30 for <oauth@ietf.org>; Wed, 30 Jun 2010 18:29:05 -0700 (PDT) Received: by 10.101.3.38 with SMTP id f38mr11610609ani.90.1277947744134; Wed, 30 Jun 2010 18:29:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.132.22 with HTTP; Wed, 30 Jun 2010 18:28:44 -0700 (PDT) From: Marius Scurtescu <mscurtescu@google.com> Date: Wed, 30 Jun 2010 18:28:44 -0700 Message-ID: <AANLkTilo2O0MYi1jMqF8vlGvjQ2mmgtxTxLnFPUPcoML@mail.gmail.com> To: OAuth WG <oauth@ietf.org> Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Subject: [OAUTH-WG] sequence diagrams X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 01 Jul 2010 01:28:57 -0000 I created sequence diagrams for the main profiles supported by draft 09: https://docs.google.com/leaf?id=0B_5REGY-7RjcMjYxMzE3YTAtZWY4My00YTM5LTgzMmMtY2QwZDc3ZmEwZjhi&hl=en Let me know if they make sense and how can they be improved. Marius From sayrer@gmail.com Wed Jun 30 20:03:26 2010 Return-Path: <sayrer@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36E3C3A6867 for <oauth@core3.amsl.com>; Wed, 30 Jun 2010 20:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.949 X-Spam-Level: X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rxI+jGB6Bm+c for <oauth@core3.amsl.com>; Wed, 30 Jun 2010 20:03:25 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 4F2C13A688D for <oauth@ietf.org>; Wed, 30 Jun 2010 20:03:25 -0700 (PDT) Received: by vws14 with SMTP id 14so174643vws.31 for <oauth@ietf.org>; Wed, 30 Jun 2010 20:03:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=MB3RDApAgVSiwJ+tXLMLJ+by3Y9chc0H9EVKz4gIUJQ=; b=qow6qrN1Bl32lkHFGDriCqaVfJT7HLOZOJxLlNzW5qEK48HwSNbnPngh5+eGrfYMv4 Q3PaVGB7EonYFpedXfwrFwNdlRGh5lbxwf2U/gvIVA9RHsFI46kDCTI7KDllsR6t/u58 53DDQwngzfTp7GsPpohNiwG2solpMTVponcJA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=VgZVuWnYEhvqh9uL3JbaBPpbNmtRDoV9OZyc0q2SCcd4PMjorfLCrxll/OMsgVLGn6 HIHPvpdq0hX75J/8F80QHlVMauJN5VkOmrbRDmPKrlxlCAcgGAwwFY6Y8dXwNjprs23u 1vt+OBswtcXP6FpDhTN8q2/9iN30+Ap6L9MsU= MIME-Version: 1.0 Received: by 10.229.224.196 with SMTP id ip4mr5633064qcb.129.1277953413667; Wed, 30 Jun 2010 20:03:33 -0700 (PDT) Received: by 10.229.102.18 with HTTP; Wed, 30 Jun 2010 20:03:33 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4BCB4@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <7C01E631FF4B654FA1E783F1C0265F8C579D0F52@TK5EX14MBXC117.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4BCB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTin2cvQnXB7x9abGLF4xQyfrv9IzZCzxOHnJqlHQ@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343B3ED4BCB4@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Wed, 30 Jun 2010 20:03:33 -0700 Message-ID: <AANLkTimid0CPqqpFM3Cg7tnS2Z3fKk04aybduYSaA_7W@mail.gmail.com> From: Robert Sayre <sayrer@gmail.com> To: Eran Hammer-Lahav <eran@hueniverse.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] How do we deal with unrecognized elements in requests and responses? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 01 Jul 2010 03:03:26 -0000 On Mon, Jun 28, 2010 at 6:17 PM, Eran Hammer-Lahav <eran@hueniverse.com> wr= ote: > There are times when the client wants the server to fail if it doesn=92t > support an extension. Implementations that have such requirements also have the option of making a new protocol that shares a lot of code with OAuth. How much feature negotiation to allow in a protocol can be a tough question, but it's probably not a goal to allow any combination of mandatory extensions to be called "OAuth". --=20 Robert Sayre "I would have written a shorter letter, but I did not have the time." From James.H.Manger@team.telstra.com Wed Jun 30 21:18:12 2010 Return-Path: <James.H.Manger@team.telstra.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 646693A6831 for <oauth@core3.amsl.com>; Wed, 30 Jun 2010 21:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.258 X-Spam-Level: * X-Spam-Status: No, score=1.258 tagged_above=-999 required=5 tests=[AWL=-0.441, BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1kqi+fLHx4Aj for <oauth@core3.amsl.com>; Wed, 30 Jun 2010 21:18:11 -0700 (PDT) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by core3.amsl.com (Postfix) with ESMTP id 5CBD03A6861 for <oauth@ietf.org>; Wed, 30 Jun 2010 21:18:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,517,1272808800"; d="scan'208";a="5233944" Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipobni.tcif.telstra.com.au with ESMTP; 01 Jul 2010 14:18:19 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6029"; a="4013734" Received: from wsmsg3754.srv.dir.telstra.com ([172.49.40.198]) by ipcbni.tcif.telstra.com.au with ESMTP; 01 Jul 2010 14:18:21 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3754.srv.dir.telstra.com ([172.49.40.198]) with mapi; Thu, 1 Jul 2010 14:18:20 +1000 From: "Manger, James H" <James.H.Manger@team.telstra.com> To: Yaron Goland <yarong@microsoft.com>, "oauth@ietf.org" <oauth@ietf.org> Date: Thu, 1 Jul 2010 14:18:19 +1000 Thread-Topic: Proposal for text for section 2 Thread-Index: AcsUm7O3+LYTofkOQ6CsKuFeuynp2ACcJnPgAAxyEYAAH/FooAAMQp/wADFXrDAAAfH0QA== Message-ID: <255B9BB34FB7D647A506DC292726F6E11265CBC110@WSMSG3153V.srv.dir.telstra.com> References: <7C01E631FF4B654FA1E783F1C0265F8C579CC0C3@TK5EX14MBXC117.redmond.corp.microsoft.com> <7C01E631FF4B654FA1E783F1C0265F8C579D0F31@TK5EX14MBXC117.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E11265A5FC9D@WSMSG3153V.srv.dir.telstra.com> <7C01E631FF4B654FA1E783F1C0265F8C579D20CB@TK5EX14MBXC117.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E11265B7E872@WSMSG3153V.srv.dir.telstra.com> <7C01E631FF4B654FA1E783F1C0265F8C579D76A1@TK5EX14MBXC117.redmond.corp.microsoft.com> In-Reply-To: <7C01E631FF4B654FA1E783F1C0265F8C579D76A1@TK5EX14MBXC117.redmond.corp.microsoft.com> 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: Re: [OAUTH-WG] Proposal for text for section 2 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 01 Jul 2010 04:18:12 -0000 Yaron, > how can you ding client assertions credentials for doing exactly what cli= ent basic credentials do? I don't like client basic credentials in request bodies either. We should d= itch that as well. I am sure I have dinged it in the past. It offers too li= ttle benefit for the cost of confusing APIs (& code) by mixing the content = and authentication. And you lose a well-established discovery method: a res= ponse with WWW-Authenticate: BASIC .... At least with basic credentials they can fit in a URI. Consequently, they d= on't prevent GET, HEAD, or DELETE requests, or even non-form PUT and POST r= equests in an API. Plus the Authorization header equivalent approach always= works as well. [You can almost consider an "endpoint with client_id and client_secret" as = a single base URI for the API -- and almost pretend that it doesn't comprom= ise the HTTP model.] > How about we edit the client assertion proposal to include the ability to= put assertions both in the HTTP authorization header as well as in the bod= y? Then the assertion proposal will be 100% equivalent to the existing basi= c credentials proposal. It is hardly 100% equivalent when the header option will fail in some cases= (large assertions), and the other option fails for GETs, HEADs, DELETEs, a= nd non-form requests. I would like OAuth2 to say: "The token API will often require client auth; = a service MAY support any auth mechanisms; BASIC is a recommended mechanism= ; BASIC MUST be supported if the service issues shared secrets to clients". Using a client assertion would fit right in if it could be defined as a sta= ndalone HTTP auth mechanism (even with a option to use form params for POST= s of forms). This would be best as its own standalone spec. If such a spec gets support (despite sometimes failing for non-POST or non-= form requests), we are done. If such a spec isn't supported it suggests we = should define a specific API that accepts client assertions, instead of an = "orthogonal" auth mechanism (still best in its own spec). P.S. When are client_assertion/client_assertion_type used, as opposed to as= sertion/assertion_type? It is not clear to me from the existing and propose= d spec text. I don't think the OAuth2 spec has enough context for the asser= tion parts. It would be better outside the OAuth2 spec, where more details = could be provided about how it hooks up with the rest of a claims-based sys= tem. -- James Manger From eran@hueniverse.com Wed Jun 30 21:50:50 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6813A3A683E for <oauth@core3.amsl.com>; Wed, 30 Jun 2010 21:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.24 X-Spam-Level: X-Spam-Status: No, score=-2.24 tagged_above=-999 required=5 tests=[AWL=0.359, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o1XOAYkv1En2 for <oauth@core3.amsl.com>; Wed, 30 Jun 2010 21:50:45 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 18B473A67FB for <oauth@ietf.org>; Wed, 30 Jun 2010 21:50:44 -0700 (PDT) Received: (qmail 10443 invoked from network); 1 Jul 2010 04:50:55 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 1 Jul 2010 04:50:55 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 30 Jun 2010 21:50:55 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: "Manger, James H" <James.H.Manger@team.telstra.com>, Yaron Goland <yarong@microsoft.com>, "oauth@ietf.org" <oauth@ietf.org> Date: Wed, 30 Jun 2010 21:51:04 -0700 Thread-Topic: Proposal for text for section 2 Thread-Index: AcsUm7O3+LYTofkOQ6CsKuFeuynp2ACcJnPgAAxyEYAAH/FooAAMQp/wADFXrDAAAfH0QAAHL9dg Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C2E6@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <7C01E631FF4B654FA1E783F1C0265F8C579CC0C3@TK5EX14MBXC117.redmond.corp.microsoft.com> <7C01E631FF4B654FA1E783F1C0265F8C579D0F31@TK5EX14MBXC117.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E11265A5FC9D@WSMSG3153V.srv.dir.telstra.com> <7C01E631FF4B654FA1E783F1C0265F8C579D20CB@TK5EX14MBXC117.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E11265B7E872@WSMSG3153V.srv.dir.telstra.com> <7C01E631FF4B654FA1E783F1C0265F8C579D76A1@TK5EX14MBXC117.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E11265CBC110@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11265CBC110@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Proposal for text for section 2 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 01 Jul 2010 04:50:50 -0000 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Manger, James H > Sent: Wednesday, June 30, 2010 9:18 PM > To: Yaron Goland; oauth@ietf.org > Subject: Re: [OAUTH-WG] Proposal for text for section 2 >=20 > Yaron, >=20 > > how can you ding client assertions credentials for doing exactly what c= lient > basic credentials do? >=20 > I don't like client basic credentials in request bodies either. We should= ditch > that as well. I am sure I have dinged it in the past. It offers too littl= e benefit > for the cost of confusing APIs (& code) by mixing the content and > authentication. And you lose a well-established discovery method: a > response with WWW-Authenticate: BASIC .... You can still do that. The client_id and client_secret parameters are nothi= ng more than a convenient tool for the most common use case. Also, if you n= oticed, Basic is not the primary method and the parameters are secondary. T= hat's as far as consensus allowed and I would like to consider this item cl= osed. EHL From eran@hueniverse.com Wed Jun 30 22:07:50 2010 Return-Path: <eran@hueniverse.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E94D3A6897 for <oauth@core3.amsl.com>; Wed, 30 Jun 2010 22:07:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.035 X-Spam-Level: X-Spam-Status: No, score=-1.035 tagged_above=-999 required=5 tests=[AWL=-0.851, BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJ37C7LImAoG for <oauth@core3.amsl.com>; Wed, 30 Jun 2010 22:07:45 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id E5CF23A6855 for <oauth@ietf.org>; Wed, 30 Jun 2010 22:07:44 -0700 (PDT) Received: (qmail 14210 invoked from network); 1 Jul 2010 05:07:52 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 1 Jul 2010 05:07:52 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 30 Jun 2010 22:07:53 -0700 From: Eran Hammer-Lahav <eran@hueniverse.com> To: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org> Date: Wed, 30 Jun 2010 22:08:02 -0700 Thread-Topic: Underscore, dash, green, blue Thread-Index: AcsY2m8s3S6JcqdzQw6k4C5eNNk6vA== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C2E7@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_90C41DD21FB7C64BB94121FBBC2E72343B3ED4C2E7P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: [OAUTH-WG] Underscore, dash, green, blue X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 01 Jul 2010 05:07:50 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3ED4C2E7P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable First, sorry about this. :) I do my best not to ask the group this kind of questions and just pick some= thing on my own, but I can't decide so I'll run a quick vote (yes, a VOTE -= I can't imagine seeking a consensus call on this). -09 uses underscores for parameter names (except for in the headers) and da= shes for parameter values. This seems like an odd selection. Before, it use= d dashes for header parameter names, and underscore everywhere else. Not gr= eat either. So... The changes my OCD can live with: 1. Use dashes throughout 2. Use underscores for all parameter names (headers included), dashes for a= ll values 3. Use underscores throughout I want to get this done with in a day because people are writing code for -= 09 and I'd like to stop making changes beyond editorial. I just think that= having different styles between the endpoint parameters and header paramet= ers is broken. EHL --_000_90C41DD21FB7C64BB94121FBBC2E72343B3ED4C2E7P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"><head><meta http-equiv=3DContent-Type content= =3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros= oft Word 14 (filtered medium)"><style><!-- /* Font Definitions */ @font-face {font-family:Wingdings; panose-1:5 0 0 0 0 0 0 0 0 0;} @font-face {font-family:Wingdings; panose-1:5 0 0 0 0 0 0 0 0 0;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {mso-style-priority:34; margin-top:0in; margin-right:0in; margin-bottom:0in; margin-left:.5in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} span.EmailStyle17 {mso-style-type:personal-compose; font-family:"Calibri","sans-serif"; color:windowtext;} .MsoChpDefault {mso-style-type:export-only; font-family:"Calibri","sans-serif";} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue vli= nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal>First, sorry abo= ut this. <span style=3D'font-family:Wingdings'>J</span><o:p></o:p></p><p cl= ass=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>I do my best not = to ask the group this kind of questions and just pick something on my own, = but I can’t decide so I’ll run a quick vote (yes, a VOTE –= ; I can’t imagine seeking a consensus call on this).<o:p></o:p></p><p= class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>-09 uses under= scores for parameter names (except for in the headers) and dashes for param= eter values. This seems like an odd selection. Before, it used dashes for h= eader parameter names, and underscore everywhere else. Not great either.<o:= p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>= So…<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p class= =3DMsoNormal>The changes my OCD can live with:<o:p></o:p></p><p class=3DMso= Normal><o:p> </o:p></p><p class=3DMsoNormal>1. Use dashes throughout<o= :p></o:p></p><p class=3DMsoNormal>2. Use underscores for all parameter name= s (headers included), dashes for all values<o:p></o:p></p><p class=3DMsoNor= mal>3. Use underscores throughout<o:p></o:p></p><p class=3DMsoNormal><o:p>&= nbsp;</o:p></p><p class=3DMsoNormal>I want to get this done with in a day b= ecause people are writing code for -09 and I’d like to stop making ch= anges beyond editorial.  I just think that having different styles bet= ween the endpoint parameters and header parameters is broken.<o:p></o:p></p= ><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>EHL<o:p></o= :p></p></div></body></html>= --_000_90C41DD21FB7C64BB94121FBBC2E72343B3ED4C2E7P3PW5EX1MB01E_-- From michael.d.adams@gmail.com Wed Jun 30 22:13:01 2010 Return-Path: <michael.d.adams@gmail.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD1433A6804 for <oauth@core3.amsl.com>; Wed, 30 Jun 2010 22:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-5TjYwGejk7 for <oauth@core3.amsl.com>; Wed, 30 Jun 2010 22:13:00 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 1A3E13A67CF for <oauth@ietf.org>; Wed, 30 Jun 2010 22:13:00 -0700 (PDT) Received: by iwn40 with SMTP id 40so1736192iwn.31 for <oauth@ietf.org>; Wed, 30 Jun 2010 22:13:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=CNTo05PntS3YwKdGISYnWwQ2AUskDBMKK21d/h6yGng=; b=aWSwXuRamXcI/U33ZaTsvbO3vJ0WkzT21ZnwzyxgU+SoKtrTpVtAMB6CNzqnUoiGun JkLwge5k0OKrQzMrpcKKHQPNMJWZn7JhRAKjB0K6fdtWypwak7UzzOnQoc5szK+qrDcL cB3dVweqT43F50FgJk0/hBjZJpQQOMuh5yEo4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=xGmO8WtUdJE4iOhKU9LbpPL6wldwep/YhgWYldYhQoUeP0UbNX53jpTYjLWql+9QJG T38xdo13tzpuBP+wCLixXugxAkLRqrNJ0zNTP+ybyOO92xIa0QVZ2nrhJuhY4UWYgZeY rGTACu8QLPcufYmJhOhl4eT/WIypndaMDaMyY= Received: by 10.231.211.134 with SMTP id go6mr9157898ibb.143.1277961191251; Wed, 30 Jun 2010 22:13:11 -0700 (PDT) MIME-Version: 1.0 Sender: michael.d.adams@gmail.com Received: by 10.231.179.143 with HTTP; Wed, 30 Jun 2010 22:12:51 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C2E7@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C2E7@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Michael D Adams <mike@automattic.com> Date: Wed, 30 Jun 2010 22:12:51 -0700 X-Google-Sender-Auth: T3ko8KaRekF3QHXSxtS9pCtk0y8 Message-ID: <AANLkTikTV7MpO4ypHnwM7ynp0VNc3a4Gmgmn1j_Gyziw@mail.gmail.com> To: Eran Hammer-Lahav <eran@hueniverse.com> Content-Type: text/plain; charset=ISO-8859-1 Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Underscore, dash, green, blue X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 01 Jul 2010 05:13:02 -0000 On Wed, Jun 30, 2010 at 10:08 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote: > 1. Use dashes throughout > 2. Use underscores for all parameter names (headers included), dashes for > all values > 3. Use underscores throughout 3 From lr@lukasrosenstock.net Wed Jun 30 23:41:34 2010 Return-Path: <lr@lukasrosenstock.net> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F14C73A6802 for <oauth@core3.amsl.com>; Wed, 30 Jun 2010 23:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.605 X-Spam-Level: X-Spam-Status: No, score=-1.605 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jAumlK+td2XR for <oauth@core3.amsl.com>; Wed, 30 Jun 2010 23:41:32 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 5F5503A67D7 for <oauth@ietf.org>; Wed, 30 Jun 2010 23:41:31 -0700 (PDT) Received: by vws14 with SMTP id 14so373471vws.31 for <oauth@ietf.org>; Wed, 30 Jun 2010 23:41:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.214.195 with SMTP id hb3mr5869553qcb.292.1277966500033; Wed, 30 Jun 2010 23:41:40 -0700 (PDT) Received: by 10.229.236.130 with HTTP; Wed, 30 Jun 2010 23:41:39 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C2E7@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3ED4C2E7@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 1 Jul 2010 08:41:39 +0200 Message-ID: <AANLkTilj97ppfsqp6ZzxLJhURLhnmSx9P39-A97OuGAw@mail.gmail.com> From: Lukas Rosenstock <lr@lukasrosenstock.net> To: Eran Hammer-Lahav <eran@hueniverse.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Underscore, dash, green, blue X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 01 Jul 2010 06:41:34 -0000 3 except headers. 2010/7/1 Eran Hammer-Lahav <eran@hueniverse.com>: > First, sorry about this. J > > > > I do my best not to ask the group this kind of questions and just pick > something on my own, but I can=92t decide so I=92ll run a quick vote (yes= , a > VOTE =96 I can=92t imagine seeking a consensus call on this). > > > > -09 uses underscores for parameter names (except for in the headers) and > dashes for parameter values. This seems like an odd selection. Before, it > used dashes for header parameter names, and underscore everywhere else. N= ot > great either. > > > > So=85 > > > > The changes my OCD can live with: > > > > 1. Use dashes throughout > > 2. Use underscores for all parameter names (headers included), dashes for > all values > > 3. Use underscores throughout > > > > I want to get this done with in a day because people are writing code for > -09 and I=92d like to stop making changes beyond editorial. =A0I just thi= nk that > having different styles between the endpoint parameters and header > parameters is broken. > > > > EHL > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --=20 http://lukasrosenstock.net/

    First, th= e spec says “SHOULD NOT issue a refresh token” which means, don= ’t do it unless you have to. But what stops the client from keeping t= he same assertion and reusing it later?

     

    As f= or using other methods for providing an assertion, you need to be more spec= ific about what you have in mind. But either way, you can extend the token = endpoint to support other ways of providing assertions.

     

    EHL

     =

    From: oauth-boun= ces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Andrew Arn= ott
    Sent: Monday, June 14, 2010 8:32 PM
    To: OAuth WG (o= auth@ietf.org)
    Subject: [OAUTH-WG] Assertion flow: please add opt= ional refresh_token in response

     

    For an application I= 'm building, the installed client app will have intermittent windows of tim= e where it can obtain a (non-OAuth) assertion for user identity.  Duri= ng this time, it seems appropriate for it to use the assertion flow to obta= in an OAuth authorization so that it can impersonate the user.  So far= this is just standard Assertion Flow stuff.  But without a refresh_to= ken, the app will break when the access token expires if the app doesn't ha= ve the ability at the moment (due to not being on the corporate network at = the moment for example) to obtain a new assertion.  Since the security= model for this app would certainly allow for a refresh_token to be issued = from the original OAuth authorization server exchange, this would solve it,= if the spec didn't specifically ban such a parameter.

    Also, the use= r identity is asserted to the authorization server not through an assertion     parameter but using Kerberos (I assume) as part of the HTTP = protocol, so perhaps the spec for the assertion flow can specifically allow= for assertions to be carried as part of the transport?

    = --
    Andrew Arnott
    "I [may] not agree with what you have to say, b= ut I'll defend to the death your right to say it." - S. G. Tallentyre<= o:p>