From beaton@google.com Thu Nov 5 17:31:26 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8604728C0F8 for ; Thu, 5 Nov 2009 17:31:26 -0800 (PST) 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 gsYeDOgmI42w for ; Thu, 5 Nov 2009 17:31:25 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 8F51928C148 for ; Thu, 5 Nov 2009 17:31:25 -0800 (PST) Received: from spaceape9.eur.corp.google.com (spaceape9.eur.corp.google.com [172.28.16.143]) by smtp-out.google.com with ESMTP id nA61Vl2b009448 for ; Fri, 6 Nov 2009 01:31:47 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1257471107; bh=aMjtt33d8/Wzo9ZeJObhutwnpAQ=; h=MIME-Version:Date:Message-ID:Subject:From:To:Content-Type; b=PUnep5aUiPtLrrkR/BhNGkkI7CpbFIsTu/ZnEDsNwKLDyIImsba/+zcqF4HvQC+lf 4BoS8WR86Oxjon7ICvNJw== 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=KnHdVfob1mIVRnHcUnYcv60J9/jpc1SfeiGjgE7BY0KGjWBYICSGAOfFyL/9AhoRL Zm4eGBrnEvBKZthTOCLpQ== Received: from pzk6 (pzk6.prod.google.com [10.243.19.134]) by spaceape9.eur.corp.google.com with ESMTP id nA61TB6T027237 for ; Thu, 5 Nov 2009 17:31:42 -0800 Received: by pzk6 with SMTP id 6so705111pzk.29 for ; Thu, 05 Nov 2009 17:31:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.29.14 with SMTP id g14mr207747rvj.192.1257471102097; Thu, 05 Nov 2009 17:31:42 -0800 (PST) Date: Thu, 5 Nov 2009 17:31:42 -0800 Message-ID: From: Brian Eaton To: oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Subject: [OAUTH-WG] RSA signing and web delegation X-BeenThere: oauth@ietf.org X-Mailman-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, 06 Nov 2009 01:31:26 -0000 I spent a bit of time today wondering how to integrate RSA signing in OAuth (which has obvious key distribution advantages) with requests that only send access tokens (which has obvious usability advantages). The only way I can think of to resolve these conflicts goes like this: 1) Initial requests for user approval (using the web delegation flow) are signed using RSA. 2) Data requests are either not signed, or are signed only with the token secret using HMAC. 3) Requests to renew access tokens (if we adopt something like the scalable OAuth extension) are again signed using RSA. Thoughts? Cheers, Brian From eran@hueniverse.com Thu Nov 5 19:35:03 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A75633A6939 for ; Thu, 5 Nov 2009 19:35:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 9IchgLLAkIaA for ; Thu, 5 Nov 2009 19:35:03 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id EE67D3A6867 for ; Thu, 5 Nov 2009 19:35:02 -0800 (PST) Received: (qmail 27669 invoked from network); 6 Nov 2009 03:35:12 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 6 Nov 2009 03:35:11 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 5 Nov 2009 20:35:10 -0700 From: Eran Hammer-Lahav To: "oauth@ietf.org" Date: Thu, 5 Nov 2009 20:35:03 -0700 Thread-Topic: [OAUTH-WG] RSA signing and web delegation Thread-Index: AcpegOs8yP6liUzUQbymQEaCSgGp0gAEQ1BQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234378507843F@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] RSA signing and web delegation X-BeenThere: oauth@ietf.org X-Mailman-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, 06 Nov 2009 03:35:03 -0000 I like this approach. It keeps the RSA signing in the delegation flow and n= ot in the generic authentication method. This keeps the token as the sole a= uthentication tool when making protected resources requests (no client cred= entials or RSA keys). EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Brian Eaton > Sent: Thursday, November 05, 2009 5:32 PM > To: oauth@ietf.org > Subject: [OAUTH-WG] RSA signing and web delegation >=20 > I spent a bit of time today wondering how to integrate RSA signing in > OAuth (which has obvious key distribution advantages) with requests > that only send access tokens (which has obvious usability advantages). >=20 > The only way I can think of to resolve these conflicts goes like this: >=20 > 1) Initial requests for user approval (using the web delegation flow) > are signed using RSA. >=20 > 2) Data requests are either not signed, or are signed only with the > token secret using HMAC. >=20 > 3) Requests to renew access tokens (if we adopt something like the > scalable OAuth extension) are again signed using RSA. >=20 > Thoughts? >=20 > Cheers, > Brian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From faynberg@alcatel-lucent.com Thu Nov 5 19:49:47 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8A7D3A692E for ; Thu, 5 Nov 2009 19:49:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 pUMGsdycc07g for ; Thu, 5 Nov 2009 19:49:47 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 3D0643A699D for ; Thu, 5 Nov 2009 19:49:35 -0800 (PST) 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 nA63nueH012788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Nov 2009 21:49:57 -0600 (CST) Received: from [135.244.36.7] (faynberg.lra.lucent.com [135.244.36.7]) by umail.lucent.com (8.13.8/TPES) with ESMTP id nA63nu9F021122; Thu, 5 Nov 2009 21:49:56 -0600 (CST) Message-ID: <4AF39CE0.2080504@alcatel-lucent.com> Date: Thu, 05 Nov 2009 22:49:52 -0500 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Eran Hammer-Lahav References: <90C41DD21FB7C64BB94121FBBC2E7234378507843F@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234378507843F@P3PW5EX1MB01.EX1.SECURESERVER.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: "oauth@ietf.org" Subject: Re: [OAUTH-WG] RSA signing and web delegation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: faynberg@alcatel-lucent.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 03:49:47 -0000 One question: Is RSA is really essential here? I think not (why not use ECC or any other PKI algorithm instead?). So, I would agree with Brian so long as RSA is replaced with PKI. Igor Eran Hammer-Lahav wrote: > I like this approach. It keeps the RSA signing in the delegation flow and not in the generic authentication method. This keeps the token as the sole authentication tool when making protected resources requests (no client credentials or RSA keys). > > EHL > > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Brian Eaton >> Sent: Thursday, November 05, 2009 5:32 PM >> To: oauth@ietf.org >> Subject: [OAUTH-WG] RSA signing and web delegation >> >> I spent a bit of time today wondering how to integrate RSA signing in >> OAuth (which has obvious key distribution advantages) with requests >> that only send access tokens (which has obvious usability advantages). >> >> The only way I can think of to resolve these conflicts goes like this: >> >> 1) Initial requests for user approval (using the web delegation flow) >> are signed using RSA. >> >> 2) Data requests are either not signed, or are signed only with the >> token secret using HMAC. >> >> 3) Requests to renew access tokens (if we adopt something like the >> scalable OAuth extension) are again signed using RSA. >> >> Thoughts? >> >> 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 James.H.Manger@team.telstra.com Thu Nov 5 20:16:12 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36F583A6A37 for ; Thu, 5 Nov 2009 20:16:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id emPcOX7ltA7B for ; Thu, 5 Nov 2009 20:16:11 -0800 (PST) Received: from mailipbo.vtcif.telstra.com.au (mailipbo.vtcif.telstra.com.au [202.12.144.29]) by core3.amsl.com (Postfix) with ESMTP id 21C3D3A6A36 for ; Thu, 5 Nov 2009 20:16:09 -0800 (PST) Received: from webi.vtcif.telstra.com.au (HELO mailbi.vtcif.telstra.com.au) ([202.12.142.19]) by mailipbi.vtcif.telstra.com.au with ESMTP; 06 Nov 2009 15:15:29 +1100 Received: from mail2.cdn.telstra.com.au (localhost [127.0.0.1]) by mailbi.vtcif.telstra.com.au (Postfix) with ESMTP id CE2841DA85 for ; Fri, 6 Nov 2009 15:15:28 +1100 (EST) Received: from WSMSG3703.srv.dir.telstra.com (wsmsg3703.srv.dir.telstra.com [172.49.40.171]) by mail2.cdn.telstra.com.au (Postfix) with ESMTP id B1F1D41DC0 for ; Fri, 6 Nov 2009 15:15:10 +1100 (EST) Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3703.srv.dir.telstra.com ([172.49.40.171]) with mapi; Fri, 6 Nov 2009 15:15:27 +1100 From: "Manger, James H" To: "oauth@ietf.org" Date: Fri, 6 Nov 2009 15:15:25 +1100 Thread-Topic: [OAUTH-WG] RSA signing and web delegation Thread-Index: AcpegOs8yP6liUzUQbymQEaCSgGp0gAEQ1BQAABIf7A= Message-ID: <255B9BB34FB7D647A506DC292726F6E11248875D2D@WSMSG3153V.srv.dir.telstra.com> References: <90C41DD21FB7C64BB94121FBBC2E7234378507843F@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234378507843F@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] RSA signing and web delegation X-BeenThere: oauth@ietf.org X-Mailman-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, 06 Nov 2009 04:16:12 -0000 QnJpYW4sDQoNCj4gMSkgSW5pdGlhbCByZXF1ZXN0cyBmb3IgdXNlciBhcHByb3ZhbCAuLiBhcmUg c2lnbmVkIHVzaW5nIFJTQS4NCj4gMikgRGF0YSByZXF1ZXN0cyAuLiBhcmUgc2lnbmVkIG9ubHkg d2l0aCB0aGUgdG9rZW4gc2VjcmV0IHVzaW5nIEhNQUMuDQo+IDMpIFJlcXVlc3RzIHRvIHJlbmV3 IGFjY2VzcyB0b2tlbnMgKGlmIHdlIGFkb3B0IHNvbWV0aGluZyBsaWtlIHRoZQ0KPiAgICAgc2Nh bGFibGUgT0F1dGggZXh0ZW5zaW9uKSBhcmUgYWdhaW4gc2lnbmVkIHVzaW5nIFJTQS4NCg0KV2h5 IGRvIHlvdSBuZWVkIHRvIHVzZSB0aGUgUlNBIGtleSBkdXJpbmcgdG9rZW4gcmVuZXdhbD8NCg0K SWYgcmVuZXdhbCBjYW4gYmUgb2NjdXIgYXQgYW55IHRpbWUgYXQgdGhlIGRpc2NyZXRpb24gb2Yg dGhlIHNlcnZlciwgdGhlbiB0aGUgY2xpZW50IHdpbGwgYWx3YXlzIG5lZWQgdGhlIFJTQSBrZXkg aGFuZHkuIEl0IHNvdW5kcyBsaWtlIGl0IHdpbGwgYmUgaGFyZCBmb3IgYSBjbGllbnQgdG8gZ2V0 IGFueSBiZW5lZml0IGZyb20gbm90IG5lZWRpbmcgdGhlIFJTQSBrZXkgZm9yIHJlc291cmNlIHJl cXVlc3RzIGlmLCBhdCBhbnkgbW9tZW50LCBpdCBuZWVkcyB0aGUgUlNBIGtleSB0byByZW5ldyB0 aGUgdG9rZW4gdG8gY29tcGxldGUgYSByZXNvdXJjZSByZXF1ZXN0LiBJdCBzZWVtcyB0byBtYWtl IGl0IHRvdWdoIHRvIGhhbmQgYSB1c2VyLXNwZWNpZmljIHRva2VuIHRvIGphdmFzY3JpcHQgcnVu bmluZyBpbiB0aGF0IHVzZXIncyBicm93c2VyLCBmb3IgaW5zdGFuY2UuDQoNCklmIEkgcmVtZW1i ZXIgY29ycmVjdGx5LCB0aGUgdGhyZWF0IHRoYXQgdGhlIFNjYWxhYmxlIE9BdXRoIGV4dGVuc2lv biBhZGRyZXNzZXMgaXMgdGhhdCBtYW55IGNvbnRlbnQgc2VydmljZXMgYWNjZXB0IHRva2VucyBp c3N1ZWQgYnkgb25lIHNlY3VyaXR5IHNlcnZlciB0aGVuIG9uZSBjb250ZW50IHNlcnZlciBpcyBj b21wcm9taXNlZC4gU2VjdXJpdHkgZm9yIHRoZSBvdGhlciBjb250ZW50IHNlcnZlcnMgc2hvdWxk IGJlIHJlc3RvcmVkIGluIHRoZSBzaG9ydCAoZWcgNSBtaW4pIHRva2VuIGxpZmV0aW1lLg0KDQpJ dCBzaG91bGQgYmUgc3VmZmljaWVudCBmb3IgdGhlIHNlY3VyaXR5IHNlcnZlciB0byBiZSBhYmxl IHRvIGRpc3Rpbmd1aXNoIHRoZSBvcmlnaW5hbCBjbGllbnQgdGhhdCBhIHRva2VuIHdhcyByZXR1 cm5lZCB0bywgZnJvbSBhIG1hbGljaW91cyBwYXJ0eSB0aGF0IGxlYXJudCB0aGUgdG9rZW4gZGV0 YWlscyBmcm9tIGEgY29tcHJvbWlzZWQgY29udGVudCBzZXJ2ZXIuIFR3byBxdWljayBpZGVhczoN Cg0KMS4gQSBjb29raWUgc2V0IGJ5IHRoZSBzZWN1cml0eSBzZXJ2ZXIgd2hlbiBpc3N1aW5nIHRo ZSB0b2tlbiB3b3VsZCBiZSBzdWZmaWNpZW50LiBUaGUgY2xpZW50IHdvdWxkIHJldHVybiB0aGUg Y29va2llIGR1cmluZyByZW5ld2FsOyB0aGUgY29tcHJvbWlzZWQgY29udGVudCBzZXJ2ZXIgbmV2 ZXIgc2VlcyB0aGlzIGNvb2tpZS4NCg0KMi4gQSBiZXR0ZXIgYWx0ZXJuYXRpdmUgbWlnaHQgYmUg Zm9yIHRoZSBzZWN1cml0eSBzZXJ2ZXIgdG8gcHJvdmlkZSBhIHJlbmV3YWwgVVJMIHdoZW4gaXNz dWluZyBhIHRva2VuLiBUaGUgcmVuZXdhbCBVUkwgY2FuIGJlIHVuaXF1ZSB0byB0aGUgdG9rZW4u IEEgY29tcHJvbWlzZWQgY29udGVudCBzZXJ2ZXIgbmV2ZXIgc2VlcyB0aGUgcmVuZXdhbCBVUkwg c28gaXQgY2Fubm90IHJlbmV3IGEgdG9rZW4uDQoNCkJvdGggdGhlc2UgaWRlYXMgdGFja2xlIHRo ZSBTY2FsYWJsZSBPQXV0aCBpc3N1ZSwgd2hpbGUga2VlcGluZyB0aGUgYmVuZWZpdHMgb2Ygbm90 IG5lZWRpbmcgdGhlIFJTQSBrZXkgYWZ0ZXIgdGhlIGluaXRpYWwgaW50ZXJhY3RpdmUgZGVsZWdh dGlvbiBpbnZvbHZpbmcgdGhlIHVzZXIuDQoNCg0KDQpKYW1lcyBNYW5nZXINCkphbWVzLkguTWFu Z2VyQHRlYW0udGVsc3RyYS5jb20NCklkZW50aXR5IGFuZCBzZWN1cml0eSB0ZWFtIOKAlCBDaGll ZiBUZWNobm9sb2d5IE9mZmljZSDigJQgVGVsc3RyYQ0K From jpanzer@google.com Thu Nov 5 21:52:22 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BC953A6ABF for ; Thu, 5 Nov 2009 21:52:22 -0800 (PST) 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 4WUrDQKV4pZ5 for ; Thu, 5 Nov 2009 21:52:21 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 6F1713A6912 for ; Thu, 5 Nov 2009 21:52:21 -0800 (PST) Received: from spaceape23.eur.corp.google.com (spaceape23.eur.corp.google.com [172.28.16.75]) by smtp-out.google.com with ESMTP id nA65qhUB009017 for ; Fri, 6 Nov 2009 05:52:43 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1257486763; bh=lbL4eeyMnR1HSRa+3gsyAQ+3L+w=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=nBYpPo/ZJcxtVUZpc3efrnbQynCzivF0rAw8bwSsrte9pVVA2ZwPIv5wKbTIn4Zqe +fnSJL4aKXRhJzjPPYm+A== 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=gQWhPAQgbGUu4y1iIRiax34AQNZLcg/kXeNAORlaJG/LEpAMHGXvdzROk2KloDidL xKU2f9JZajtOZzoI3dWPg== Received: from pwj16 (pwj16.prod.google.com [10.241.219.80]) by spaceape23.eur.corp.google.com with ESMTP id nA65qdx0031254 for ; Thu, 5 Nov 2009 21:52:40 -0800 Received: by pwj16 with SMTP id 16so471963pwj.12 for ; Thu, 05 Nov 2009 21:52:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.115.66.35 with SMTP id t35mr6110654wak.87.1257486758816; Thu, 05 Nov 2009 21:52:38 -0800 (PST) In-Reply-To: References: Date: Thu, 5 Nov 2009 21:52:38 -0800 Message-ID: From: John Panzer To: Brian Eaton Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] RSA signing and web delegation X-BeenThere: oauth@ietf.org X-Mailman-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, 06 Nov 2009 05:52:22 -0000 What about 2 legged OAuth? On Thursday, November 5, 2009, Brian Eaton wrote: > I spent a bit of time today wondering how to integrate RSA signing in > OAuth (which has obvious key distribution advantages) with requests > that only send access tokens (which has obvious usability advantages). > > The only way I can think of to resolve these conflicts goes like this: > > 1) Initial requests for user approval (using the web delegation flow) > are signed using RSA. > > 2) Data requests are either not signed, or are signed only with the > token secret using HMAC. > > 3) Requests to renew access tokens (if we adopt something like the > scalable OAuth extension) are again signed using RSA. > > Thoughts? > > Cheers, > Brian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- -- John Panzer / Google jpanzer@google.com / abstractioneer.org / @jpanzer From eran@hueniverse.com Thu Nov 5 22:22:34 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5F183A67B5 for ; Thu, 5 Nov 2009 22:22:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, 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 yJyMvd-Cu71h for ; Thu, 5 Nov 2009 22:22:33 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id D6C9B3A67B4 for ; Thu, 5 Nov 2009 22:22:33 -0800 (PST) Received: (qmail 14767 invoked from network); 6 Nov 2009 06:22:56 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 6 Nov 2009 06:22:55 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 5 Nov 2009 23:22:54 -0700 From: Eran Hammer-Lahav To: John Panzer , Brian Eaton Date: Thu, 5 Nov 2009 23:20:46 -0700 Thread-Topic: [OAUTH-WG] RSA signing and web delegation Thread-Index: AcpepV6avkTZf49pQgKJxYLJ7cfgFQAAw4XA Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234378507844E@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@ietf.org" Subject: Re: [OAUTH-WG] RSA signing and web delegation X-BeenThere: oauth@ietf.org X-Mailman-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, 06 Nov 2009 06:22:35 -0000 We need to stop using this term (2 legged) and instead describe the exact u= se case. This term can mean using OAuth without user-context but in an over= all scenario where there still is a user (for example, a server offering bo= th protected resources APIs as well as client admin APIs that are not speci= fic to any resource owner). It can also be used to mean using OAuth as a mo= re secure replacement for Basic auth in which the username and password are= sent as the client credentials (and no token). We are going to address the second case by providing a new direct authentic= ation method modeled after whatever we come up for the token-based case (or= delegation, whatever we call it) - somehow... I am not sure what to do about the first case yet, but it will need to be r= esolved as part of the delegation flow for sending authenticated requests t= o obtain a token when there is still no token present. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of John Panzer > Sent: Thursday, November 05, 2009 9:53 PM > To: Brian Eaton > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] RSA signing and web delegation >=20 > What about 2 legged OAuth? >=20 > On Thursday, November 5, 2009, Brian Eaton wrote: > > I spent a bit of time today wondering how to integrate RSA signing in > > OAuth (which has obvious key distribution advantages) with requests > > that only send access tokens (which has obvious usability > advantages). > > > > The only way I can think of to resolve these conflicts goes like > this: > > > > 1) Initial requests for user approval (using the web delegation flow) > > are signed using RSA. > > > > 2) Data requests are either not signed, or are signed only with the > > token secret using HMAC. > > > > 3) Requests to renew access tokens (if we adopt something like the > > scalable OAuth extension) are again signed using RSA. > > > > Thoughts? > > > > Cheers, > > Brian > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > >=20 > -- > -- > John Panzer / Google > jpanzer@google.com / abstractioneer.org / @jpanzer > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From jpanzer@google.com Thu Nov 5 22:30:20 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C76F53A68D5 for ; Thu, 5 Nov 2009 22:30:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 1STmoT5V9f9G for ; Thu, 5 Nov 2009 22:30:18 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id C49AD3A67E3 for ; Thu, 5 Nov 2009 22:30:17 -0800 (PST) Received: from zps18.corp.google.com (zps18.corp.google.com [172.25.146.18]) by smtp-out.google.com with ESMTP id nA66Ue1J013688 for ; Thu, 5 Nov 2009 22:30:40 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1257489040; bh=FV6rEK3WUkftN+HIVSuzjFlAmi8=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=ByrkqUCQt3AJAl/7z8v2pnY8o0u5souWf7w6AvodksoUR8eN7wBTYm5++5a9kiFpX xH5VDWI3srPvK2VpcwqWg== 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=abnRYRgJmy/DjRS3WVSEk14M+XSh7AEGDSPVJujoMPOuVLsyPcwANaY2zyOWR/2v7 xCNVZeLnw8zQaQ/deK2jQ== Received: from pxi1 (pxi1.prod.google.com [10.243.27.1]) by zps18.corp.google.com with ESMTP id nA66UaUa030546 for ; Thu, 5 Nov 2009 22:30:36 -0800 Received: by pxi1 with SMTP id 1so583093pxi.32 for ; Thu, 05 Nov 2009 22:30:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.115.81.21 with SMTP id i21mr6271845wal.125.1257489036149; Thu, 05 Nov 2009 22:30:36 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234378507844E@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234378507844E@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: John Panzer Date: Thu, 5 Nov 2009 22:30:16 -0800 Message-ID: To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=0016e64de80e4f042e0477adfb2a X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] RSA signing and web delegation X-BeenThere: oauth@ietf.org X-Mailman-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, 06 Nov 2009 06:30:20 -0000 --0016e64de80e4f042e0477adfb2a Content-Type: text/plain; charset=ISO-8859-1 My query was about case #2. These cases need better names. -- John Panzer / Google jpanzer@google.com / abstractioneer.org / @jpanzer On Thu, Nov 5, 2009 at 10:20 PM, Eran Hammer-Lahav wrote: > We need to stop using this term (2 legged) and instead describe the exact > use case. This term can mean using OAuth without user-context but in an > overall scenario where there still is a user (for example, a server offering > both protected resources APIs as well as client admin APIs that are not > specific to any resource owner). It can also be used to mean using OAuth as > a more secure replacement for Basic auth in which the username and password > are sent as the client credentials (and no token). > > We are going to address the second case by providing a new direct > authentication method modeled after whatever we come up for the token-based > case (or delegation, whatever we call it) - somehow... > > I am not sure what to do about the first case yet, but it will need to be > resolved as part of the delegation flow for sending authenticated requests > to obtain a token when there is still no token present. > > EHL > > > > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > Of John Panzer > > Sent: Thursday, November 05, 2009 9:53 PM > > To: Brian Eaton > > Cc: oauth@ietf.org > > Subject: Re: [OAUTH-WG] RSA signing and web delegation > > > > What about 2 legged OAuth? > > > > On Thursday, November 5, 2009, Brian Eaton wrote: > > > I spent a bit of time today wondering how to integrate RSA signing in > > > OAuth (which has obvious key distribution advantages) with requests > > > that only send access tokens (which has obvious usability > > advantages). > > > > > > The only way I can think of to resolve these conflicts goes like > > this: > > > > > > 1) Initial requests for user approval (using the web delegation flow) > > > are signed using RSA. > > > > > > 2) Data requests are either not signed, or are signed only with the > > > token secret using HMAC. > > > > > > 3) Requests to renew access tokens (if we adopt something like the > > > scalable OAuth extension) are again signed using RSA. > > > > > > Thoughts? > > > > > > Cheers, > > > Brian > > > _______________________________________________ > > > OAuth mailing list > > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > -- > > -- > > John Panzer / Google > > jpanzer@google.com / abstractioneer.org / @jpanzer > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > --0016e64de80e4f042e0477adfb2a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable My query was about case #2. =A0These cases need better names. =A0
--
John Panzer / Google
jpanzer@google.com / abstractio= neer.org / @jpanzer



On Thu, Nov 5, 2009 at 10:20 PM, Eran Ha= mmer-Lahav <era= n@hueniverse.com> wrote:
We need to stop using this term (2 legged) and instead describe the exact u= se case. This term can mean using OAuth without user-context but in an over= all scenario where there still is a user (for example, a server offering bo= th protected resources APIs as well as client admin APIs that are not speci= fic to any resource owner). It can also be used to mean using OAuth as a mo= re secure replacement for Basic auth in which the username and password are= sent as the client credentials (and no token).

We are going to address the second case by providing a new direct authentic= ation method modeled after whatever we come up for the token-based case (or= delegation, whatever we call it) - somehow...

I am not sure what to do about the first case yet, but it will need to be r= esolved as part of the delegation flow for sending authenticated requests t= o obtain a token when there is still no token present.

EHL



> -----Original Message-----
> From: oauth-bounces@ietf.org= [mailto:oauth-bounces@ietf.o= rg] On Behalf
> Of John Panzer
> Sent: Thursday, November 05, 2009 9:53 PM
> To: Brian Eaton
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] RSA signing and web delegation
>
> What about 2 legged OAuth?
>
> On Thursday, November 5, 2009, Brian Eaton <beaton@google.com> wrote:
> > I spent a bit of time today wondering how to integrate RSA signin= g in
> > OAuth (which has obvious key distribution advantages) with reques= ts
> > that only send access tokens (which has obvious usability
> advantages).
> >
> > The only way I can think of to resolve these conflicts goes like<= br> > this:
> >
> > 1) Initial requests for user approval (using the web delegation f= low)
> > are signed using RSA.
> >
> > 2) Data requests are either not signed, or are signed only with t= he
> > token secret using HMAC.
> >
> > 3) Requests to renew access tokens (if we adopt something like th= e
> > scalable OAuth extension) are again signed using RSA.
> >
> > Thoughts?
> >
> > Cheers,
> > Brian
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> >
>
> --
> --
> John Panzer / Google
> jpanzer@google.com / abstractioneer.org / @= jpanzer
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--0016e64de80e4f042e0477adfb2a-- From eran@hueniverse.com Thu Nov 5 22:33:13 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 405A23A685E for ; Thu, 5 Nov 2009 22:33:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.075, 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 X6rMkWhVgMqL for ; Thu, 5 Nov 2009 22:33:06 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id C53053A6942 for ; Thu, 5 Nov 2009 22:33:06 -0800 (PST) Received: (qmail 15938 invoked from network); 6 Nov 2009 06:33:30 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 6 Nov 2009 06:33:30 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 5 Nov 2009 23:33:29 -0700 From: Eran Hammer-Lahav To: John Panzer Date: Thu, 5 Nov 2009 23:33:23 -0700 Thread-Topic: [OAUTH-WG] RSA signing and web delegation Thread-Index: AcpeqqnuhybXNOSsRl2hQZZAwR06CQAAFToQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234378507844F@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234378507844E@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_90C41DD21FB7C64BB94121FBBC2E7234378507844FP3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] RSA signing and web delegation X-BeenThere: oauth@ietf.org X-Mailman-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, 06 Nov 2009 06:33:13 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E7234378507844FP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Do you need an RSA option for the "Basic Auth Alternative" case? EHL From: John Panzer [mailto:jpanzer@google.com] Sent: Thursday, November 05, 2009 10:30 PM To: Eran Hammer-Lahav Cc: Brian Eaton; oauth@ietf.org Subject: Re: [OAUTH-WG] RSA signing and web delegation My query was about case #2. These cases need better names. -- John Panzer / Google jpanzer@google.com / abstractioneer.org / @jpanzer On Thu, Nov 5, 2009 at 10:20 PM, Eran Hammer-Lahav > wrote: We need to stop using this term (2 legged) and instead describe the exact u= se case. This term can mean using OAuth without user-context but in an over= all scenario where there still is a user (for example, a server offering bo= th protected resources APIs as well as client admin APIs that are not speci= fic to any resource owner). It can also be used to mean using OAuth as a mo= re secure replacement for Basic auth in which the username and password are= sent as the client credentials (and no token). We are going to address the second case by providing a new direct authentic= ation method modeled after whatever we come up for the token-based case (or= delegation, whatever we call it) - somehow... I am not sure what to do about the first case yet, but it will need to be r= esolved as part of the delegation flow for sending authenticated requests t= o obtain a token when there is still no token present. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth= -bounces@ietf.org] On Behalf > Of John Panzer > Sent: Thursday, November 05, 2009 9:53 PM > To: Brian Eaton > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] RSA signing and web delegation > > What about 2 legged OAuth? > > On Thursday, November 5, 2009, Brian Eaton > wrote: > > I spent a bit of time today wondering how to integrate RSA signing in > > OAuth (which has obvious key distribution advantages) with requests > > that only send access tokens (which has obvious usability > advantages). > > > > The only way I can think of to resolve these conflicts goes like > this: > > > > 1) Initial requests for user approval (using the web delegation flow) > > are signed using RSA. > > > > 2) Data requests are either not signed, or are signed only with the > > token secret using HMAC. > > > > 3) Requests to renew access tokens (if we adopt something like the > > scalable OAuth extension) are again signed using RSA. > > > > Thoughts? > > > > Cheers, > > Brian > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > -- > -- > John Panzer / Google > jpanzer@google.com / abstractioneer.org / @jpanzer > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --_000_90C41DD21FB7C64BB94121FBBC2E7234378507844FP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Do you need an RSA option for the “Basic Auth Alternat= ive” case?

 

EHL

 

From: John Panzer [mailto:jpanzer@google.com]
Sent: Thursday, November 05, 2009 10:30 PM
To: Eran Hammer-Lahav
Cc: Brian Eaton; oauth@ietf.org
Subject: Re: [OAUTH-WG] RSA signing and web delegation

 

My query was about case= #2.  These cases need better names.  
--
John Panzer / Google
jpanzer@google.com / abstractioneer.org / @jpanzer


On Thu, Nov 5, 2009 at 10:20 PM, Eran Hammer-Lahav <= ;eran@hueniverse.com> wrote:=

We need to stop using this term (2 legged) and instead describe the exact use case. This term can mean using OAuth without user-context but in an overall scenario where there still is a user (for example, a server offering both protected resources APIs as well as client admin APIs that are not specific to any resource owner). It can also be use= d to mean using OAuth as a more secure replacement for Basic auth in which the username and password are sent as the client credentials (and no token).
We are going to address the second case by providing a new direct authentication method modeled after whatever we come up for the token-based case (or delegation, whatever we call it) - somehow...

I am not sure what to do about the first case yet, but it will need to be resolved as part of the delegation flow for sending authenticated requests = to obtain a token when there is still no token present.


EHL



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

> Of John Panzer
> Sent: Thursday, November 05, 2009 9:53 PM
> To: Brian Eaton
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] RSA signing and web delegation
>
> What about 2 legged OAuth?
>
> On Thursday, November 5, 2009, Brian Eaton <beaton@google.com> wrote:
> > I spent a bit of time today wondering how to integrate RSA signin= g in
> > OAuth (which has obvious key distribution advantages) with reques= ts
> > that only send access tokens (which has obvious usability
> advantages).
> >
> > The only way I can think of to resolve these conflicts goes like<= br> > this:
> >
> > 1) Initial requests for user approval (using the web delegation f= low)
> > are signed using RSA.
> >
> > 2) Data requests are either not signed, or are signed only with t= he
> > token secret using HMAC.
> >
> > 3) Requests to renew access tokens (if we adopt something like th= e
> > scalable OAuth extension) are again signed using RSA.
> >
> > Thoughts?
> >
> > Cheers,
> > Brian
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> >
>
> --
> --
> John Panzer / Google
> jpanzer@google.com / abstractioneer.org= / @jpanzer
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

 

--_000_90C41DD21FB7C64BB94121FBBC2E7234378507844FP3PW5EX1MB01E_-- From beaton@google.com Fri Nov 6 09:16:17 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E493C3A67C0 for ; Fri, 6 Nov 2009 09:16:17 -0800 (PST) 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 ncHVtDCzhM3O for ; Fri, 6 Nov 2009 09:16:17 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id 456593A6823 for ; Fri, 6 Nov 2009 09:16:16 -0800 (PST) Received: from wpaz37.hot.corp.google.com (wpaz37.hot.corp.google.com [172.24.198.101]) by smtp-out.google.com with ESMTP id nA6HGbtN028541 for ; Fri, 6 Nov 2009 09:16:38 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1257527798; bh=Sr0VmEyyMTXflsJd6bBd+fLBkWM=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=chMZV7oTrodKo5bf6mkKfbEB5WBrchM2lKAPEOwqVu/12PCuBqk/xaNwMtKv2S00q oAN8a5DIcrXyo+mVl1mpw== 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=VdYp0MCcuDDXj3sM927rMWc9gJWRNYsurpSq5SezJkrWfG9fPCDFjIAPmdo51PDqD ed3Zh2Ho23Tbd7C0bAiBw== Received: from pwj13 (pwj13.prod.google.com [10.241.219.77]) by wpaz37.hot.corp.google.com with ESMTP id nA6HGYwv000724 for ; Fri, 6 Nov 2009 09:16:35 -0800 Received: by pwj13 with SMTP id 13so181638pwj.7 for ; Fri, 06 Nov 2009 09:16:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.4.12 with SMTP id g12mr258825rvi.189.1257527794300; Fri, 06 Nov 2009 09:16:34 -0800 (PST) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11248875D2D@WSMSG3153V.srv.dir.telstra.com> References: <90C41DD21FB7C64BB94121FBBC2E7234378507843F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E11248875D2D@WSMSG3153V.srv.dir.telstra.com> Date: Fri, 6 Nov 2009 09:16:34 -0800 Message-ID: From: Brian Eaton To: "Manger, James H" 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] RSA signing and web delegation X-BeenThere: oauth@ietf.org X-Mailman-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, 06 Nov 2009 17:16:18 -0000 On Thu, Nov 5, 2009 at 8:15 PM, Manger, James H wrote: >> 1) Initial requests for user approval .. are signed using RSA. >> 2) Data requests .. are signed only with the token secret using HMAC. >> 3) Requests to renew access tokens (if we adopt something like the >> =A0 =A0 scalable OAuth extension) are again signed using RSA. > > Why do you need to use the RSA key during token renewal? Requiring the consumer secret (whether is an HMAC secret or an RSA private key) during renewal helps you recover from compromise. For example, consider this scenario: 1) Client receives permission to access data on behalf of thousands of user= s. 2) Client gets hacked. Attacker steals all of the delegation tokens. 3) How do you recover? If access token renewal does not require the consumer secret, you're screwed. You have to revoke all of the delegation tokens for all of the users, and they need to reapprove. If access token renewal *does* require the consumer secret, recovery is much simpler. You rotate the consumer secret, and the attacker loses access to user data. > If renewal can be occur at any time at the discretion of the server, then= the client will always need > the RSA key handy. It sounds like it will be hard for a client to get any= benefit from not needing > the RSA key for resource requests if, at any moment, it needs the RSA key= to renew the token > to complete a resource request. It seems to make it tough to hand a user-= specific token to > javascript running in that user's browser, for instance. This is a good point. Well behaved service providers should have predictable and usable session lifetimes. For example, the client web site can get a session token that is good for one hour, and hand it to some javascript to use for one hour. At the end of that hour, the client web site needs to refresh the token. > It should be sufficient for the security server to be able to distinguish= the original > client that a token was returned to, from a malicious party that learnt t= he token > details from a compromised content server. Two quick ideas: > > 1. A cookie set by the security server when issuing the token would be > sufficient. The client would return the cookie during renewal; the compro= mised > content server never sees this cookie. IMHO, web APIs should not use cookies. (This is mostly a matter of opinion on my part, based on problems I've had with distributed cookie jar management and general annoyance in the past. I suspect if you ask application developers they'll tell you the same thing). > 2. A better alternative might be for the security server to provide a ren= ewal > URL when issuing a token. The renewal URL can be unique to the token. > A compromised content server never sees the renewal URL so it cannot rene= w a token. I like this idea, particularly if renewal requires both the renewal secret and the consumer secret. The consumer secret is useful because of the issues I mentioned above with recovering from compromise. The renewal secret is useful because it acts as a long-lived capability to access user data. This is particularly important for installed applications, where the consumer secret isn't really a secret. Cheers, Brian From beaton@google.com Fri Nov 6 09:20:36 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92FC33A68E9 for ; Fri, 6 Nov 2009 09:20:36 -0800 (PST) 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 v41TODZtaJ6S for ; Fri, 6 Nov 2009 09:20:35 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 53BD93A68E4 for ; Fri, 6 Nov 2009 09:20:35 -0800 (PST) Received: from wpaz13.hot.corp.google.com (wpaz13.hot.corp.google.com [172.24.198.77]) by smtp-out.google.com with ESMTP id nA6HKvhg016131 for ; Fri, 6 Nov 2009 17:20:57 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1257528057; bh=4j9IUNUBOKieIh/sjXFO6ZIfAdo=; h=MIME-Version:Date:Message-ID:Subject:From:To:Cc:Content-Type: Content-Transfer-Encoding; b=fbHLFF2wpPNiFhNHoebFBev9zOIwlRqN7FD4OSv5zQsx+YO1mVtE4XkBu9vRXHtG+ 5xDpMUcT5/YBh8kSWJ30Q== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:date:message-id:subject:from:to:cc: content-type:content-transfer-encoding:x-system-of-record; b=TbdRDip5UIfjCVa4+g++USvoxm3UDb4HWTjK6luLh2D9gwjoRD/l+s+TMsyVaWHVU Vx88rCI4Aqug6UDzJxPmA== Received: from pwj4 (pwj4.prod.google.com [10.241.219.68]) by wpaz13.hot.corp.google.com with ESMTP id nA6HKrwD031272 for ; Fri, 6 Nov 2009 09:20:54 -0800 Received: by pwj4 with SMTP id 4so883492pwj.6 for ; Fri, 06 Nov 2009 09:20:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.20.10 with SMTP id x10mr249821rvi.44.1257528053681; Fri, 06 Nov 2009 09:20:53 -0800 (PST) Date: Fri, 6 Nov 2009 09:20:53 -0800 Message-ID: From: Brian Eaton To: faynberg@alcatel-lucent.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: [OAUTH-WG] RSA vs PKI? X-BeenThere: oauth@ietf.org X-Mailman-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, 06 Nov 2009 17:20:36 -0000 [switching subject line to fork discussion] Hey Igor - On Thu, Nov 5, 2009 at 7:49 PM, Igor Faynberg wrote: > One question: Is RSA is really essential here? I =A0think not (why not us= e ECC > or any other PKI algorithm instead?). So, I would agree with Brian so lon= g > as RSA is replaced with PKI. Interesting point, and I'm not sure I fully understand what you are getting= at. The choice of RSA-SHA1 vs RSA-SHA256 vs ECC vs DSA-SHA1 vs seems to be about cryptographic security. What algorithms do we want to use? How are we going to migrate from older algorithms to new algorithms as the old ones are broken? What are the efficiency vs security trade-offs? PKI, on the other hand, doesn't seem to be about security in the cryptographic sense. It's more about key discovery, and trust. How do you find the consumer's public key? Have I understood where you are headed? Cheers, Brian From beaton@google.com Fri Nov 6 09:22:47 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D96028C179 for ; Fri, 6 Nov 2009 09:22:47 -0800 (PST) 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 0YGw9xVHVPFK for ; Fri, 6 Nov 2009 09:22:46 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id 40E8828C177 for ; Fri, 6 Nov 2009 09:22:46 -0800 (PST) Received: from spaceape9.eur.corp.google.com (spaceape9.eur.corp.google.com [172.28.16.143]) by smtp-out.google.com with ESMTP id nA6HN8KG023670 for ; Fri, 6 Nov 2009 09:23:09 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1257528189; bh=d8G1SrrXkjPUvaj4gCa5vtiovJ0=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=cipyCCmWhgRGOG0O5PAi0h2uvTwMj9eCtN1mM5UtO/BqcyrhS1/hZuZwBc8RecJOj 0ANXWK5pzB02HMRiUQenw== 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=SdawG05x4JvWtcsNV8Z8CdwvD+cAMDFBqgkHH+ElKC53I0eH3icdcgxQWVuoBb2qc uKkhMVWyQsPuzA+l5gCQQ== Received: from pxi39 (pxi39.prod.google.com [10.243.27.39]) by spaceape9.eur.corp.google.com with ESMTP id nA6HKjnm007045 for ; Fri, 6 Nov 2009 09:23:06 -0800 Received: by pxi39 with SMTP id 39so1578472pxi.30 for ; Fri, 06 Nov 2009 09:23:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.226.14 with SMTP id y14mr251561rvg.8.1257528185649; Fri, 06 Nov 2009 09:23:05 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234378507844F@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234378507844E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234378507844F@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Fri, 6 Nov 2009 09:23:04 -0800 Message-ID: From: Brian Eaton To: Eran Hammer-Lahav Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] RSA signing and web delegation X-BeenThere: oauth@ietf.org X-Mailman-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, 06 Nov 2009 17:22:47 -0000 On Thu, Nov 5, 2009 at 10:33 PM, Eran Hammer-Lahav wr= ote: > Do you need an RSA option for the =93Basic Auth Alternative=94 case? Yes. I've been thinking of it as "role account authentication with OAuth", because that's the main place I see it being really useful. Here's how I would model it: - send an RSA-signed message to an authorization server - authorization server returns an access token (and possibly a secret) to the client - client uses the access token for data access Cheers, Brian From infinity@lindenlab.com Fri Nov 6 11:26:21 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4781F28C116 for ; Fri, 6 Nov 2009 11:26:21 -0800 (PST) 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.486, 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 r6op7n-i1H5z for ; Fri, 6 Nov 2009 11:26:20 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 36FD728C0D8 for ; Fri, 6 Nov 2009 11:26:20 -0800 (PST) Received: by bwz23 with SMTP id 23so1535359bwz.29 for ; Fri, 06 Nov 2009 11:26:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.239.139.204 with SMTP id u12mr513698hbu.81.1257535601233; Fri, 06 Nov 2009 11:26:41 -0800 (PST) In-Reply-To: References: From: "Infinity Linden (Meadhbh Hamrick)" Date: Fri, 6 Nov 2009 11:26:21 -0800 Message-ID: <3a880e2c0911061126t176e04ebjef1acd7fcb23efed@mail.gmail.com> To: Brian Eaton Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] RSA vs PKI? X-BeenThere: oauth@ietf.org X-Mailman-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, 06 Nov 2009 19:26:21 -0000 i think everyone here probably understands that defining a small set of required crypto algorithms is a "good thing." otherwise you get MOSS. there _are_ issues with both ECC and RSA. Certicom holds some patents on ECC, so it is not a completely unencumbered technology. On the other hand, the NSA has elected to pay for a federal government wide license for these patents rather than specify RSA in Suite B. (Suite B being a collection of algorithms the NSA has approved for securing "sensitive but not classified" government information.) This has led some people to wonder whether the NSA knows something the rest of us don't regarding the efficacy of RSA. Another check mark in the RSA column is the fact that it's quite easy to find a commercial CA that supports RSA. It's much harder to find commercial support for ECC and Rabin Williams (despite the latter being defined as part of ISO9796) Just my $0.02. In the interest of full disclosure, i am a former employee of both RSADSI and Certicom and maintain a small financial interest in Certicom. -cheers -meadhbh -- infinity linden (aka meadhbh hamrick) * it's pronounced "maeve" http://wiki.secondlife.com/wiki/User:Infinity_Linden On Fri, Nov 6, 2009 at 09:20, Brian Eaton wrote: > [switching subject line to fork discussion] > > Hey Igor - > > On Thu, Nov 5, 2009 at 7:49 PM, Igor Faynberg > wrote: >> One question: Is RSA is really essential here? I =A0think not (why not u= se ECC >> or any other PKI algorithm instead?). So, I would agree with Brian so lo= ng >> as RSA is replaced with PKI. > > Interesting point, and I'm not sure I fully understand what you are getti= ng at. > > The choice of RSA-SHA1 vs RSA-SHA256 vs ECC vs DSA-SHA1 vs comes out next week> seems to be about cryptographic security. =A0What > algorithms do we want to use? =A0How are we going to migrate from older > algorithms to new algorithms as the old ones are broken? =A0What are the > efficiency vs security trade-offs? > > PKI, on the other hand, doesn't seem to be about security in the > cryptographic sense. =A0It's more about key discovery, and trust. =A0How > do you find the consumer's public key? > > Have I understood where you are headed? > > Cheers, > Brian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From eran@hueniverse.com Fri Nov 6 12:20:26 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8988E3A680B for ; Fri, 6 Nov 2009 12:20:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.070, 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 Gf9D53Hg49JT for ; Fri, 6 Nov 2009 12:20:25 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id BEFAA3A6AA3 for ; Fri, 6 Nov 2009 12:20:25 -0800 (PST) Received: (qmail 14548 invoked from network); 6 Nov 2009 20:16:58 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 6 Nov 2009 20:16:58 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Fri, 6 Nov 2009 13:16:57 -0700 From: Eran Hammer-Lahav To: Brian Eaton Date: Fri, 6 Nov 2009 13:16:54 -0700 Thread-Topic: [OAUTH-WG] RSA signing and web delegation Thread-Index: AcpfBdAtRfoOEXfDTxybmzzeUjmAeQAGB2eQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E723437850785C2@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234378507844E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234378507844F@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@ietf.org" Subject: Re: [OAUTH-WG] RSA signing and web delegation X-BeenThere: oauth@ietf.org X-Mailman-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, 06 Nov 2009 20:20:26 -0000 The "Basic auth alternative" would be a single request flow with shared sec= ret (either symmetric or asymmetric). I am not sure how the flow below appl= ies (when compared to Basic auth). EHL > -----Original Message----- > From: Brian Eaton [mailto:beaton@google.com] > Sent: Friday, November 06, 2009 9:23 AM > To: Eran Hammer-Lahav > Cc: John Panzer; oauth@ietf.org > Subject: Re: [OAUTH-WG] RSA signing and web delegation >=20 > On Thu, Nov 5, 2009 at 10:33 PM, Eran Hammer-Lahav > wrote: > > Do you need an RSA option for the "Basic Auth Alternative" case? >=20 > Yes. I've been thinking of it as "role account authentication with > OAuth", because that's the main place I see it being really useful. >=20 > Here's how I would model it: >=20 > - send an RSA-signed message to an authorization server > - authorization server returns an access token (and possibly a secret) > to the client > - client uses the access token for data access >=20 > Cheers, > Brian From beaton@google.com Fri Nov 6 13:33:58 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 678203A67EC for ; Fri, 6 Nov 2009 13:33:58 -0800 (PST) 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 lKNhDbf9EFwm for ; Fri, 6 Nov 2009 13:33:57 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 276B93A67AC for ; Fri, 6 Nov 2009 13:33:56 -0800 (PST) Received: from zps76.corp.google.com (zps76.corp.google.com [172.25.146.76]) by smtp-out.google.com with ESMTP id nA6LYI9p014356 for ; Fri, 6 Nov 2009 21:34:19 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1257543259; bh=Y80YcJfffavU/ia8oDMnoJDQqSQ=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=Qf5NBlFR3rOkucu8muDg4v6T81deiKDp+jz83LZFcEwu2dBV9YYuIv6r97fQfQbQo M3IpvbtTqDV94l4YQizOg== 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=Dm+NghxF/VnIXQeYwTWmf/N8cYdaeTXcy4+1vjdnQoQ5RqOB5ItAQvXTxUw4Cep2N nas4nGwIhnR/kh4mTfo2A== Received: from pwj1 (pwj1.prod.google.com [10.241.219.65]) by zps76.corp.google.com with ESMTP id nA6LYGaR022918 for ; Fri, 6 Nov 2009 13:34:16 -0800 Received: by pwj1 with SMTP id 1so474406pwj.0 for ; Fri, 06 Nov 2009 13:34:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.41.21 with SMTP id t21mr242904rvj.93.1257543255931; Fri, 06 Nov 2009 13:34:15 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723437850785C2@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234378507844E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234378507844F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437850785C2@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Fri, 6 Nov 2009 13:34:15 -0800 Message-ID: From: Brian Eaton To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] RSA signing and web delegation X-BeenThere: oauth@ietf.org X-Mailman-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, 06 Nov 2009 21:33:58 -0000 On Fri, Nov 6, 2009 at 12:16 PM, Eran Hammer-Lahav wrote: > The "Basic auth alternative" would be a single request flow with shared > secret (either symmetric or asymmetric). I am not sure how the flow below > applies (when compared to Basic auth). I don't think a basic auth flow based on a single secret is all that interesting, or even possible to implement. The problem is how you bootstrap the secret. Is the secret the user's password? That doesn't work with any well-designed password authentication system (See [1]). It won't get deployed. Is the secret a session cookie? That could work, but you need an answer for bootstrapping the session cookie. Is the secret an OAuth token? That could also work, but you still need an answer for bootstrapping the token. I think RSA is one of many possible answers to the bootstrapping problem. Ideally we'll have a bunch of different ways to bootstrap a session secret, and then using the session secret will be easy. Cheers, Brian [1] http://chargen.matasano.com/chargen/2007/9/7/enough-with-the-rainbow-tables-what-you-need-to-know-about-s.html From eran@hueniverse.com Fri Nov 6 14:01:30 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F8AD3A68D6 for ; Fri, 6 Nov 2009 14:01:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, 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 1OsppGP+Hx7Y for ; Fri, 6 Nov 2009 14:01:29 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 278853A677E for ; Fri, 6 Nov 2009 14:01:29 -0800 (PST) Received: (qmail 7333 invoked from network); 6 Nov 2009 22:01:53 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 6 Nov 2009 22:01:52 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 6 Nov 2009 15:01:13 -0700 From: Eran Hammer-Lahav To: "oauth@ietf.org" Date: Fri, 6 Nov 2009 15:01:10 -0700 Thread-Topic: [OAUTH-WG] RSA signing and web delegation Thread-Index: AcpfKOe+XrukjB2cQtC+K8+WmLRI3QAAYNyQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343785078621@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234378507844E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234378507844F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437850785C2@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] RSA signing and web delegation X-BeenThere: oauth@ietf.org X-Mailman-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, 06 Nov 2009 22:01:30 -0000 What this means is that there really is just one scenario: - Client obtains a set token credentials using some shared secret (symmetri= c or otherwise). - If the resources are owned by someone other than the client, authorizatio= n must be obtained. - Client uses the token credentials (alone) to access protected resources. In case where there is sometimes a resource owner other than the client, th= e client can reuse the same shared secret for both tokens (self and resourc= e owner). In cases where there is no resource owner other than the client (= the simple client-server model), the client's shared secret (can be usernam= e/password) is used to obtain a token.=20 Either way, there is always a token present and we are not attempting to di= rectly replace the Basic auth flow. This seems reasonable (and much easier) to me. It does mean we need to define two sets of authentication methods, one for = shared-secret based (symmetric or asymmetric) and one for token-based. We w= ill be able to reuse some of the flow between the two, but it sounds to me = like one will need to support more options (RSA) than the other (just HMAC = and Plain). Comments? EHL > -----Original Message----- > From: Brian Eaton [mailto:beaton@google.com] > Sent: Friday, November 06, 2009 1:34 PM > To: Eran Hammer-Lahav > Cc: John Panzer; oauth@ietf.org > Subject: Re: [OAUTH-WG] RSA signing and web delegation >=20 > On Fri, Nov 6, 2009 at 12:16 PM, Eran Hammer-Lahav > wrote: > > The "Basic auth alternative" would be a single request flow with > shared > > secret (either symmetric or asymmetric). I am not sure how the flow > below > > applies (when compared to Basic auth). >=20 > I don't think a basic auth flow based on a single secret is all that > interesting, or even possible to implement. The problem is how you > bootstrap the secret. >=20 > Is the secret the user's password? That doesn't work with any > well-designed password authentication system (See [1]). It won't get > deployed. >=20 > Is the secret a session cookie? That could work, but you need an > answer for bootstrapping the session cookie. >=20 > Is the secret an OAuth token? That could also work, but you still > need an answer for bootstrapping the token. >=20 > I think RSA is one of many possible answers to the bootstrapping > problem. Ideally we'll have a bunch of different ways to bootstrap a > session secret, and then using the session secret will be easy. >=20 > Cheers, > Brian >=20 > [1] http://chargen.matasano.com/chargen/2007/9/7/enough-with-the- > rainbow-tables-what-you-need-to-know-about-s.html From beaton@google.com Fri Nov 6 14:37:34 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7CA83A682A for ; Fri, 6 Nov 2009 14:37:34 -0800 (PST) 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 oEYbpVhOGkMQ for ; Fri, 6 Nov 2009 14:37:34 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id C94FD3A67FA for ; Fri, 6 Nov 2009 14:37:33 -0800 (PST) Received: from wpaz37.hot.corp.google.com (wpaz37.hot.corp.google.com [172.24.198.101]) by smtp-out.google.com with ESMTP id nA6MbseB016900 for ; Fri, 6 Nov 2009 22:37:55 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1257547075; bh=mdaYka5j5Q8DspfNRcvD8lvtS/0=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=I1mkixym1VOq/bEEjc3yHnBlDRQ2sMx8bm1Ugkwl8s7v0zJNQlkIkxQ1z+a+zwf2u oTpGmiiGW6hXVwJErvjmg== 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=O6MweVTrId0mt2+RY5wCWM3zR0gPCQYb7AT2bbyEYKgTUJPJ6WI3oepzWQH0hKphI P23yYmJIkY4CjtZEWFx9g== Received: from pwj13 (pwj13.prod.google.com [10.241.219.77]) by wpaz37.hot.corp.google.com with ESMTP id nA6MboRE009436 for ; Fri, 6 Nov 2009 14:37:52 -0800 Received: by pwj13 with SMTP id 13so345648pwj.7 for ; Fri, 06 Nov 2009 14:37:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.225.9 with SMTP id x9mr296851rvg.175.1257547070448; Fri, 06 Nov 2009 14:37:50 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343785078621@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234378507844E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234378507844F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437850785C2@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785078621@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Fri, 6 Nov 2009 14:37:50 -0800 Message-ID: From: Brian Eaton 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] RSA signing and web delegation X-BeenThere: oauth@ietf.org X-Mailman-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, 06 Nov 2009 22:37:34 -0000 On Fri, Nov 6, 2009 at 2:01 PM, Eran Hammer-Lahav wro= te: > It does mean we need to define two sets of authentication methods, one fo= r shared-secret based (symmetric or asymmetric) and one for token-based. We= will be able to reuse some of the flow between the two, but it sounds to m= e like one will need to support more options (RSA) than the other (just HMA= C and Plain). > > Comments? +1. From faynberg@alcatel-lucent.com Sun Nov 8 18:16:08 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EE723A6841 for ; Sun, 8 Nov 2009 18:16:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 f56WE9bYAguj for ; Sun, 8 Nov 2009 18:16:07 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 13FA33A67A8 for ; Sun, 8 Nov 2009 18:16:06 -0800 (PST) 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 nA92GSqt013212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Nov 2009 20:16:28 -0600 (CST) Received: from [135.244.112.27] (faynberg.lra.lucent.com [135.244.112.27]) by umail.lucent.com (8.13.8/TPES) with ESMTP id nA92GOWh013898; Sun, 8 Nov 2009 20:16:26 -0600 (CST) Message-ID: <4AF77B77.40507@alcatel-lucent.com> Date: Sun, 08 Nov 2009 21:16:23 -0500 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Infinity Linden (Meadhbh Hamrick)" , Brian Eaton References: <3a880e2c0911061126t176e04ebjef1acd7fcb23efed@mail.gmail.com> In-Reply-To: <3a880e2c0911061126t176e04ebjef1acd7fcb23efed@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.37 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] RSA vs PKI? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: faynberg@alcatel-lucent.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 02:16:08 -0000 (My mail, for some strange reason, has never delivered Brian's response to me, so I first saw it in Meadhbh's quotation.) I am afraid I added to the confusion. The only point of my posting was to check if we are open to cryptographic algorithms other than RSA. (Brian, by PKI I meant the system in which signatures are obtained with private keys [and verified using the respective public keys]. So, I referred here strictly to the cryptographic side of PKI.) I am not a strong advocate of ECC. (It is only from my observations of a push for ECC in ITU-T that I started to think that it is becoming ubiquitous.) I am aware of the two advantages of ECC over RSA: 1) It is much faster and 2) it is provably secure. But I did not want to waste the OAuth bandwidth on this discussion. I only wondered if it has already been decided to lock ourselves into one specific algorithm. With thanks, Igor Infinity Linden (Meadhbh Hamrick) wrote: > i think everyone here probably understands that defining a small set > of required crypto algorithms is a "good thing." otherwise you get > MOSS. > > there _are_ issues with both ECC and RSA. > > Certicom holds some patents on ECC, so it is not a completely > unencumbered technology. > > On the other hand, the NSA has elected to pay for a federal government > wide license for these patents rather than specify RSA in Suite B. > (Suite B being a collection of algorithms the NSA has approved for > securing "sensitive but not classified" government information.) This > has led some people to wonder whether the NSA knows something the rest > of us don't regarding the efficacy of RSA. > > Another check mark in the RSA column is the fact that it's quite easy > to find a commercial CA that supports RSA. It's much harder to find > commercial support for ECC and Rabin Williams (despite the latter > being defined as part of ISO9796) > > Just my $0.02. > > In the interest of full disclosure, i am a former employee of both > RSADSI and Certicom and maintain a small financial interest in > Certicom. > > -cheers > -meadhbh > > -- > infinity linden (aka meadhbh hamrick) * it's pronounced "maeve" > http://wiki.secondlife.com/wiki/User:Infinity_Linden > > > > On Fri, Nov 6, 2009 at 09:20, Brian Eaton wrote: > >> [switching subject line to fork discussion] >> >> Hey Igor - >> >> On Thu, Nov 5, 2009 at 7:49 PM, Igor Faynberg >> wrote: >> >>> One question: Is RSA is really essential here? I think not (why not use ECC >>> or any other PKI algorithm instead?). So, I would agree with Brian so long >>> as RSA is replaced with PKI. >>> >> Interesting point, and I'm not sure I fully understand what you are getting at. >> >> The choice of RSA-SHA1 vs RSA-SHA256 vs ECC vs DSA-SHA1 vs > comes out next week> seems to be about cryptographic security. What >> algorithms do we want to use? How are we going to migrate from older >> algorithms to new algorithms as the old ones are broken? What are the >> efficiency vs security trade-offs? >> >> PKI, on the other hand, doesn't seem to be about security in the >> cryptographic sense. It's more about key discovery, and trust. How >> do you find the consumer's public key? >> >> Have I understood where you are headed? >> >> Cheers, >> Brian >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> From hallam@gmail.com Sun Nov 8 19:12:52 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E21DE3A68F9 for ; Sun, 8 Nov 2009 19:12:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[AWL=0.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 bbsSRfJCfc1o for ; Sun, 8 Nov 2009 19:12:50 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 580DF3A69FF for ; Sun, 8 Nov 2009 19:12:50 -0800 (PST) Received: by yxe30 with SMTP id 30so2883309yxe.29 for ; Sun, 08 Nov 2009 19:13:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=WEZQdyM7Sp+Siz3+5grc1Fp86JVfyqCXrzKu1qyUz3A=; b=AXf/qFiJFrKheFfnVLYrTUWTefgj/bihGN5O4vc9PI260Z8VNz+w46S6w7irfQGeBZ GjqxVgAf3+JnbZZuDwALJNKlFDMRJ5G3iF+FSGPLuBiejJh2qPw8ZSQZdBBefwMTecSP g/RyvU2KZpcqFMmhJ5C01FPaSuJxfCgzIGG68= 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=o7NH5KEcZJhjs1z7zQputebE9WngIz8aNI0HBo/cTgvnUKJ9NjJzRIrb1l2BGbm5iQ Qr0JCg/JlSUWpOZ6yzlDEmVupSXjH5arNdq29z8iqcjGjJkRQ5y15JCG+/08h+cFpQt4 A7IOHpEtYgsY/wVKDk1UnUUSiS3pt+8bAe6Ms= MIME-Version: 1.0 Received: by 10.90.61.3 with SMTP id j3mr3873780aga.40.1257736386616; Sun, 08 Nov 2009 19:13:06 -0800 (PST) In-Reply-To: <4AF77B77.40507@alcatel-lucent.com> References: <3a880e2c0911061126t176e04ebjef1acd7fcb23efed@mail.gmail.com> <4AF77B77.40507@alcatel-lucent.com> Date: Sun, 8 Nov 2009 22:13:06 -0500 Message-ID: From: Phillip Hallam-Baker To: faynberg@alcatel-lucent.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] RSA vs PKI? X-BeenThere: oauth@ietf.org X-Mailman-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, 09 Nov 2009 03:12:52 -0000 I am pretty sure ECC is no more provably secure than discrete log problems. The problem with RSA is that once you go past 2048 bits the work factor drops pretty quickly. 1048 bit RSA is roughly equivalent to an 80 bit symmetric key work factor. RSA 2048 is about 120 and RSA 4096 is 150 (these are from memory, but the drop off in effectiveness is pretty sharp). Now RSA 2048 is almost certainly enough for most things, but when you are a government agency you want the stuff you encrypt using RSA2048 on its last day of service life to be secure for another 20-30 years, possibly more. So while RSA 2048 has at least another 30 years left in it for authentication problems it is already reaching the end of its service life for certain confidentiality applications. I would suggest making RSA 2048 - SHA 256 the mandatory to implement and chose an ECC alternative from suite B. On Sun, Nov 8, 2009 at 9:16 PM, Igor Faynberg wrote: > (My mail, for some strange reason, has never delivered Brian's response t= o > me, so I first saw it in Meadhbh's quotation.) > > I am afraid I added to the confusion. The only point of my posting was to > check if we are open to cryptographic =A0algorithms other than RSA. (Bria= n, by > PKI I meant the system in which signatures are obtained with private keys > [and verified using the respective public keys]. So, I referred here > strictly to the cryptographic side of PKI.) > > I am not a strong advocate of ECC. (It is only from my observations of a > push for =A0ECC in ITU-T that I started to think that it is becoming > ubiquitous.) =A0I am aware of the two advantages of ECC over RSA: 1) It i= s > much faster and 2) it is provably secure. > > But I did not want to waste the OAuth bandwidth on this discussion. =A0I = only > wondered if =A0it has already been decided to lock ourselves into one spe= cific > algorithm. > > With thanks, > > Igor > > Infinity Linden (Meadhbh Hamrick) wrote: >> >> i think everyone here probably understands that defining a small set >> of required crypto algorithms is a "good thing." otherwise you get >> MOSS. >> >> there _are_ issues with both ECC and RSA. >> >> Certicom holds some patents on ECC, so it is not a completely >> unencumbered technology. >> >> On the other hand, the NSA has elected to pay for a federal government >> wide license for these patents rather than specify RSA in Suite B. >> (Suite B being a collection of algorithms the NSA has approved for >> securing "sensitive but not classified" government information.) This >> has led some people to wonder whether the NSA knows something the rest >> of us don't regarding the efficacy of RSA. >> >> Another check mark in the RSA column is the fact that it's quite easy >> to find a commercial CA that supports RSA. It's much harder to find >> commercial support for ECC and Rabin Williams (despite the latter >> being defined as part of ISO9796) >> >> Just my $0.02. >> >> In the interest of full disclosure, i am a former employee of both >> RSADSI and Certicom and maintain a small financial interest in >> Certicom. >> >> -cheers >> -meadhbh >> >> -- >> =A0 infinity linden (aka meadhbh hamrick) =A0* =A0it's pronounced "maeve= " >> =A0 =A0 =A0 =A0 http://wiki.secondlife.com/wiki/User:Infinity_Linden >> >> >> >> On Fri, Nov 6, 2009 at 09:20, Brian Eaton wrote: >> >>> >>> [switching subject line to fork discussion] >>> >>> Hey Igor - >>> >>> On Thu, Nov 5, 2009 at 7:49 PM, Igor Faynberg >>> wrote: >>> >>>> >>>> One question: Is RSA is really essential here? I =A0think not (why not= use >>>> ECC >>>> or any other PKI algorithm instead?). So, I would agree with Brian so >>>> long >>>> as RSA is replaced with PKI. >>>> >>> >>> Interesting point, and I'm not sure I fully understand what you are >>> getting at. >>> >>> The choice of RSA-SHA1 vs RSA-SHA256 vs ECC vs DSA-SHA1 vs >> comes out next week> seems to be about cryptographic security. =A0What >>> algorithms do we want to use? =A0How are we going to migrate from older >>> algorithms to new algorithms as the old ones are broken? =A0What are th= e >>> efficiency vs security trade-offs? >>> >>> PKI, on the other hand, doesn't seem to be about security in the >>> cryptographic sense. =A0It's more about key discovery, and trust. =A0Ho= w >>> do you find the consumer's public key? >>> >>> Have I understood where you are headed? >>> >>> 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 --=20 New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ From beaton@google.com Sun Nov 8 19:31:49 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C013A3A6A4E for ; Sun, 8 Nov 2009 19:31:49 -0800 (PST) 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 u+h6TXlXFVRA for ; Sun, 8 Nov 2009 19:31:49 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 61F783A67DB for ; Sun, 8 Nov 2009 19:31:48 -0800 (PST) Received: from wpaz29.hot.corp.google.com (wpaz29.hot.corp.google.com [172.24.198.93]) by smtp-out.google.com with ESMTP id nA93WC2W010751 for ; Mon, 9 Nov 2009 03:32:12 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1257737533; bh=cLaDg9qVDwVrr9CWNVqcr7vmqrQ=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=TEv6YPVq+u2evswSD4yue6VTbg8PB4p5OfYqIy1c0Ud/1CNN7IzmLCXrsXVOCsUOQ OBk24iegM5dqNo/ho1uew== 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=bPgAOZTlld1A/NULWaK2qJ4aGQ2IQtqeUk/ETQ/a4aNtHOxX8YctPRHc08bQFtY42 ID1Y9+aavKIUOJCg9+NaA== Received: from pwi18 (pwi18.prod.google.com [10.241.219.18]) by wpaz29.hot.corp.google.com with ESMTP id nA93W9PG006336 for ; Sun, 8 Nov 2009 19:32:10 -0800 Received: by pwi18 with SMTP id 18so1818390pwi.2 for ; Sun, 08 Nov 2009 19:32:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.226.14 with SMTP id y14mr388946rvg.8.1257737529427; Sun, 08 Nov 2009 19:32:09 -0800 (PST) In-Reply-To: References: <3a880e2c0911061126t176e04ebjef1acd7fcb23efed@mail.gmail.com> <4AF77B77.40507@alcatel-lucent.com> Date: Sun, 8 Nov 2009 19:32:09 -0800 Message-ID: From: Brian Eaton To: Phillip Hallam-Baker Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] RSA vs PKI? X-BeenThere: oauth@ietf.org X-Mailman-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, 09 Nov 2009 03:31:49 -0000 On Sun, Nov 8, 2009 at 7:13 PM, Phillip Hallam-Baker wrote: > Now RSA 2048 is almost certainly enough for most things, but when you > are a government agency you want the stuff you encrypt using RSA2048 > on its last day of service life to be secure for another 20-30 years, > possibly more. So while RSA 2048 has at least another 30 years left in > it for authentication problems it is already reaching the end of its > service life for certain confidentiality applications. > > > I would suggest making RSA 2048 - SHA 256 the mandatory to implement > and chose an ECC alternative from suite B. So the choice of RSA key length seems like something that different applications could reasonably choose on their own, no? Do we really need to include 2048 bit RSA in the spec, or is specifying RSA in general sufficient? I suspect we do need to specify acceptable hash output lengths if we're going to have decent interop. (I'm seriously pushing the bounds of my crypto knowledge here, so do let me know if any of the above is nonsense.) Cheers, Brian From hallam@gmail.com Sun Nov 8 20:01:03 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 292DF28B56A for ; Sun, 8 Nov 2009 20:01:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.463 X-Spam-Level: X-Spam-Status: No, score=-2.463 tagged_above=-999 required=5 tests=[AWL=0.136, 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 ucnp0xZ-smJm for ; Sun, 8 Nov 2009 20:01:02 -0800 (PST) Received: from mail-gx0-f212.google.com (mail-gx0-f212.google.com [209.85.217.212]) by core3.amsl.com (Postfix) with ESMTP id DF0323A67EB for ; Sun, 8 Nov 2009 20:01:00 -0800 (PST) Received: by gxk4 with SMTP id 4so2727826gxk.8 for ; Sun, 08 Nov 2009 20:01:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=8Jzh5yf2GLFOLoz6RLWcrlrHycjro9lHceUwa+F9+pY=; b=Vs191LGCt66q7UtfXvC+5O7zbd2Z1kzlNG1XicnRauAAWUOJlAanuIeKo5SUaw7XTg Yhbm8F8nIamZxrfB6FWlXzIolb7PNyjK4WEIs6ZMbsOziqID7v0oCFwA1/+VJ8oKON2q fllpP0+Ex0lqeSAjBGefFLrxN4huQu1XeWyoE= 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=lM1WGWIaB3QfowuzowZbuMrytytHt+wGPMtmw8BT9Bj08zOr3k+q9CgQoCopfEj1bW vOqf8cUlYey2YA5TuTdp5kLS8rXehBsKmuNvkzjPpKPt69Qk+SWz0xtjk5GbDYGqSp9Z BQhWonzazfmFc9dGZ9GRA8BY5RPUj/XhUdP2k= MIME-Version: 1.0 Received: by 10.90.210.11 with SMTP id i11mr13920783agg.94.1257739283226; Sun, 08 Nov 2009 20:01:23 -0800 (PST) In-Reply-To: References: <3a880e2c0911061126t176e04ebjef1acd7fcb23efed@mail.gmail.com> <4AF77B77.40507@alcatel-lucent.com> Date: Sun, 8 Nov 2009 23:01:23 -0500 Message-ID: From: Phillip Hallam-Baker To: Brian Eaton Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] RSA vs PKI? X-BeenThere: oauth@ietf.org X-Mailman-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, 09 Nov 2009 04:01:03 -0000 No, don't leave the key size to chance, there is a lot of crypto hardware out there that is quite restrictive in key sizes. The only key sizes I am aware of being widely used are 1024 and 2048. Beyond 2048 you really need to move to ECC. 1024 is considered barely sufficient and not really suitable for new applications. On Sun, Nov 8, 2009 at 10:32 PM, Brian Eaton wrote: > On Sun, Nov 8, 2009 at 7:13 PM, Phillip Hallam-Baker w= rote: >> Now RSA 2048 is almost certainly enough for most things, but when you >> are a government agency you want the stuff you encrypt using RSA2048 >> on its last day of service life to be secure for another 20-30 years, >> possibly more. So while RSA 2048 has at least another 30 years left in >> it for authentication problems it is already reaching the end of its >> service life for certain confidentiality applications. >> >> >> I would suggest making RSA 2048 - SHA 256 the mandatory to implement >> and chose an ECC alternative from suite B. > > So the choice of RSA key length seems like something that different > applications could reasonably choose on their own, no? =A0Do we really > need to include 2048 bit RSA in the spec, or is specifying RSA in > general sufficient? > > I suspect we do need to specify acceptable hash output lengths if > we're going to have decent interop. > > (I'm seriously pushing the bounds of my crypto knowledge here, so do > let me know if any of the above is nonsense.) > > Cheers, > Brian > --=20 --=20 New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ From beaton@google.com Sun Nov 8 21:02:32 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6F3B3A697F for ; Sun, 8 Nov 2009 21:02:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[AWL=0.000, 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 DbBp9HHqKP3y for ; Sun, 8 Nov 2009 21:02:32 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id DF9BB28C0D6 for ; Sun, 8 Nov 2009 21:02:31 -0800 (PST) Received: from zps35.corp.google.com (zps35.corp.google.com [172.25.146.35]) by smtp-out.google.com with ESMTP id nA952tFj014311 for ; Mon, 9 Nov 2009 05:02:56 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1257742976; bh=1UXEhT6gfxeJyHkHT4QzHofDaq4=; h=MIME-Version:Date:Message-ID:Subject:From:To:Content-Type; b=J37Muc0qAFGigRZgCWpbGFmdKSg44zbtnXXyxgjWTeuTQHyBD98JDBrHG+oYvNSsp H2X9iCY5T/tmkwL1/Q7hg== 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=ObSJeqXnmIGEhAe3S8/TAnj56C3Glpmt6cBT4MfkMaP4TV2thTtZSXoVHrXV3x9hc jRwB06qGLgPa2UA3hllXQ== Received: from pwi6 (pwi6.prod.google.com [10.241.219.6]) by zps35.corp.google.com with ESMTP id nA952YNu027572 for ; Sun, 8 Nov 2009 21:02:53 -0800 Received: by pwi6 with SMTP id 6so113824pwi.29 for ; Sun, 08 Nov 2009 21:02:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.174.1 with SMTP id w1mr443077rve.56.1257742973346; Sun, 08 Nov 2009 21:02:53 -0800 (PST) Date: Sun, 8 Nov 2009 21:02:53 -0800 Message-ID: From: Brian Eaton To: oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Subject: [OAUTH-WG] why are we signing? X-BeenThere: oauth@ietf.org X-Mailman-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, 09 Nov 2009 05:02:33 -0000 Hey folks - What are the use cases for cryptography in OAuth? Why are we signing requests? And how much of each request do we need to sign in order to be useful? As I see it, we have roughly the following menu of choices: 1) No signatures. Just use bearer tokens. Use transport layer encryption to keep those bearer tokens from leaking. 2) Signed tokens. We could just sign a timestamp, rather than entire messages. 3) Partially signed messages. We could sign just the request URL, or the request URL plus some parameters. 4) Fully signed messages. Sign as much of the HTTP request as possible, down to the bits of the HTTP entity body. My guess is we need at least two out of those four choices (one with bearer tokens, a la OAuth 1.0 plaintext) and another with cryptography. But I'm not sure whether we need to sign entire messages, or if we can get away with something simpler and still have reasonable security. Cheers, Brian From eran@hueniverse.com Sun Nov 8 23:48:05 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75C1528C1D7 for ; Sun, 8 Nov 2009 23:48:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 iS5CoJ+Et4eg for ; Sun, 8 Nov 2009 23:48:04 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id A6D3228C1C9 for ; Sun, 8 Nov 2009 23:48:04 -0800 (PST) Received: (qmail 16571 invoked from network); 9 Nov 2009 07:48:30 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 9 Nov 2009 07:48:30 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 9 Nov 2009 00:48:30 -0700 From: Eran Hammer-Lahav To: Brian Eaton , "oauth@ietf.org" Date: Mon, 9 Nov 2009 00:48:32 -0700 Thread-Topic: [OAUTH-WG] why are we signing? Thread-Index: Acpg+kQvCTQb8M3SQv6QKARAJi9ojgAFbVVg Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343785078711@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] why are we signing? X-BeenThere: oauth@ietf.org X-Mailman-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, 09 Nov 2009 07:48:05 -0000 The problem is, we are not likely to ever reach consensus on 'reasonable se= curity'. For example, I don't find most cookie-based session systems reasonably secu= re without SSL/TLS. Being able to sit at a coffee shop with free wifi and a= laptop and steal sessions cookies, then access people's email for the dura= tion the cookie is valid isn't reasonable or secure. If you would like to try this approach, I would suggest adding next to each= option the list of common attacks still possible under those terms. It wil= l allow us to evaluate the added security each level of complexity brings. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Brian Eaton > Sent: Sunday, November 08, 2009 9:03 PM > To: oauth@ietf.org > Subject: [OAUTH-WG] why are we signing? >=20 > Hey folks - >=20 > What are the use cases for cryptography in OAuth? Why are we signing > requests? And how much of each request do we need to sign in order to > be useful? >=20 > As I see it, we have roughly the following menu of choices: >=20 > 1) No signatures. > Just use bearer tokens. Use transport layer encryption to keep > those bearer tokens from leaking. >=20 > 2) Signed tokens. > We could just sign a timestamp, rather than entire messages. >=20 > 3) Partially signed messages. > We could sign just the request URL, or the request URL plus some > parameters. >=20 > 4) Fully signed messages. > Sign as much of the HTTP request as possible, down to the bits of > the HTTP entity body. >=20 > My guess is we need at least two out of those four choices (one with > bearer tokens, a la OAuth 1.0 plaintext) and another with > cryptography. But I'm not sure whether we need to sign entire > messages, or if we can get away with something simpler and still have > reasonable security. >=20 > Cheers, > Brian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From chris.messina@gmail.com Sun Nov 8 23:59:48 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A7E23A67A7 for ; Sun, 8 Nov 2009 23:59:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-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 ID7xiRiu7hH8 for ; Sun, 8 Nov 2009 23:59:46 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by core3.amsl.com (Postfix) with ESMTP id 63EDB28C104 for ; Sun, 8 Nov 2009 23:59:46 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id e12so519859fga.13 for ; Mon, 09 Nov 2009 00:00:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=D/15SKvkevd3V5cV9Q0RJKIMQO/0EG1+vZiXCQdDcqE=; b=V79F101I5PdtwYxP6hi6JwJZ0Dj0VeVO8r4crpVZFtzgftSUbp2mM454jU0eXpHRUh iprbm+aP90s9B3tkYpwYJ69mI80bPanxkfEQb23lqwUuTXYXh/U0ggf7OQxopjDv1UeR 85rXjVioD7JlfiCjJsdzvyl6Hsun6VhEgBTBM= 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=KR2OxkzkfA1lkhcdcBZ3HBfCfhaFe7kgNCMrGBL/Yz3ChYOEYl7Ok2nOaAcPL4gmw7 RMm6AudbVe1VPB7qYhBycDDa4kH+tJ0WtcY3jGG7QAbneuFhrk5o0L+Tu+sOO8nPptk6 mSwhr3Lfswz6vDciIME6FrxntA/IsL9+njiPg= MIME-Version: 1.0 Received: by 10.239.183.17 with SMTP id s17mr655207hbg.172.1257753609202; Mon, 09 Nov 2009 00:00:09 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343785078711@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343785078711@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 9 Nov 2009 00:00:09 -0800 Message-ID: <1bc4603e0911090000i6872f482pf1d003442aadd6be@mail.gmail.com> From: Chris Messina To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=001485f78b36176cf90477eb952e Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] why are we signing? X-BeenThere: oauth@ietf.org X-Mailman-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, 09 Nov 2009 07:59:48 -0000 --001485f78b36176cf90477eb952e Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Indeed, in the beginning of OAuth, that was one of the primary drivers that lead us to the decision to sign everything =97 because of the non-SSL case.= .. While it's possibly increasingly common to expect that serious developers will go and buy an SSL cert, that may not be the case for the wider array o= f hobbyist types. Now, that's not to say that they are the only audience that needs to be addressed, but the idea was to make it harder for them to screw up if they leaked their API calls... Clearly it turned out that the signing bit intended to prevent against such attacks itself was too hard to implement, and so now we're having these conversations again. At least now we have more data about what the market will bear now. Anyway, that's my recollection. But it might also not be exactly the explanation for what you're looking for. Chris On Sun, Nov 8, 2009 at 11:48 PM, Eran Hammer-Lahav wro= te: > The problem is, we are not likely to ever reach consensus on 'reasonable > security'. > > For example, I don't find most cookie-based session systems reasonably > secure without SSL/TLS. Being able to sit at a coffee shop with free wifi > and a laptop and steal sessions cookies, then access people's email for t= he > duration the cookie is valid isn't reasonable or secure. > > If you would like to try this approach, I would suggest adding next to ea= ch > option the list of common attacks still possible under those terms. It wi= ll > allow us to evaluate the added security each level of complexity brings. > > EHL > > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > Of Brian Eaton > > Sent: Sunday, November 08, 2009 9:03 PM > > To: oauth@ietf.org > > Subject: [OAUTH-WG] why are we signing? > > > > Hey folks - > > > > What are the use cases for cryptography in OAuth? Why are we signing > > requests? And how much of each request do we need to sign in order to > > be useful? > > > > As I see it, we have roughly the following menu of choices: > > > > 1) No signatures. > > Just use bearer tokens. Use transport layer encryption to keep > > those bearer tokens from leaking. > > > > 2) Signed tokens. > > We could just sign a timestamp, rather than entire messages. > > > > 3) Partially signed messages. > > We could sign just the request URL, or the request URL plus some > > parameters. > > > > 4) Fully signed messages. > > Sign as much of the HTTP request as possible, down to the bits of > > the HTTP entity body. > > > > My guess is we need at least two out of those four choices (one with > > bearer tokens, a la OAuth 1.0 plaintext) and another with > > cryptography. But I'm not sure whether we need to sign entire > > messages, or if we can get away with something simpler and still have > > reasonable security. > > > > 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 Chris Messina Open Web Advocate Personal: http://factoryjoe.com Follow me on Twitter: http://twitter.com/chrismessina Citizen Agency: http://citizenagency.com Diso Project: http://diso-project.org OpenID Foundation: http://openid.net This email is: [ ] shareable [X] ask first [ ] private --001485f78b36176cf90477eb952e Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Indeed, in the beginning of OAuth, that was one of the primary drivers that= lead us to the decision to sign everything =97 because of the non-SSL case= ...=A0

While it's possibly increasingly common to ex= pect that serious developers will go and buy an SSL cert, that may not be t= he case for the wider array of hobbyist types. Now, that's not to say t= hat they are the only audience that needs to be addressed, but the idea was= to make it harder for them to screw up if they leaked their API calls... C= learly it turned out that the signing bit intended to prevent against such = attacks itself was too hard to implement, and so now we're having these= conversations again.

At least now we have more data about what the market wi= ll bear now.

Anyway, that's my recollection. B= ut it might also not be exactly the explanation for what you're looking= for.

Chris

On Sun, Nov 8, = 2009 at 11:48 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
The problem is, we are not likely to ever reach consensus on 'reasonabl= e security'.

For example, I don't find most cookie-based session systems reasonably = secure without SSL/TLS. Being able to sit at a coffee shop with free wifi a= nd a laptop and steal sessions cookies, then access people's email for = the duration the cookie is valid isn't reasonable or secure.

If you would like to try this approach, I would suggest adding next to each= option the list of common attacks still possible under those terms. It wil= l allow us to evaluate the added security each level of complexity brings.<= br>
EHL

> -----Original Message-----
> From: oauth-bounces@ietf.org= [mailto:oauth-bounces@ietf.o= rg] On Behalf
> Of Brian Eaton
> Sent: Sunday, November 08, 2009 9:03 PM
> To: oauth@ietf.org
> Subject: [OAUTH-WG] why are we signing?
>
> Hey folks -
>
> What are the use cases for cryptography in OAuth? =A0Why are we signin= g
> requests? =A0And how much of each request do we need to sign in order = to
> be useful?
>
> As I see it, we have roughly the following menu of choices:
>
> 1) No signatures.
> =A0 =A0 Just use bearer tokens. =A0Use transport layer encryption to k= eep
> those bearer tokens from leaking.
>
> 2) Signed tokens.
> =A0 =A0 We could just sign a timestamp, rather than entire messages. >
> 3) Partially signed messages.
> =A0 =A0 We could sign just the request URL, or the request URL plus so= me
> parameters.
>
> 4) Fully signed messages.
> =A0 =A0 =A0Sign as much of the HTTP request as possible, down to the b= its of
> the HTTP entity body.
>
> My guess is we need at least two out of those four choices (one with > bearer tokens, a la OAuth 1.0 plaintext) and another with
> cryptography. =A0But I'm not sure whether we need to sign entire > messages, or if we can get away with something simpler and still have<= br> > reasonable security.
>
> Cheers,
> Brian
> _______________________________________________
> 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



--
Chris Messi= na
Open Web Advocate

Personal: = http://factoryjoe.com
Follow me on Twitter: http://twitter.com/chrismessina

Citizen Agency: http://citizenagen= cy.com
Diso Project: http://diso= -project.org
OpenID Foundation: http:/= /openid.net

This email is: =A0 [ ] shareable =A0 =A0[X] ask first =A0 [ ] private
--001485f78b36176cf90477eb952e-- From stpeter@stpeter.im Mon Nov 9 00:12:18 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CAE628C104 for ; Mon, 9 Nov 2009 00:12:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 RtBxIXHwJuCm for ; Mon, 9 Nov 2009 00:12:17 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 69EC428C1A4 for ; Mon, 9 Nov 2009 00:12:17 -0800 (PST) Received: from host-113-169.meeting.ietf.org (host-113-169.meeting.ietf.org [133.93.113.169]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id F06FA40D0B; Mon, 9 Nov 2009 01:12:42 -0700 (MST) Message-ID: <4AF7CEF8.8030009@stpeter.im> Date: Mon, 09 Nov 2009 17:12:40 +0900 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Chris Messina References: <90C41DD21FB7C64BB94121FBBC2E72343785078711@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1bc4603e0911090000i6872f482pf1d003442aadd6be@mail.gmail.com> In-Reply-To: <1bc4603e0911090000i6872f482pf1d003442aadd6be@mail.gmail.com> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] why are we signing? X-BeenThere: oauth@ietf.org X-Mailman-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, 09 Nov 2009 08:12:18 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/9/09 5:00 PM, Chris Messina wrote: > While it's possibly increasingly common to expect that serious > developers will go and buy an SSL cert, that may not be the case for the > wider array of hobbyist types. CA-issued domain certificates do not necessarily cost money, so even "hobbyist types" and others can obtain such certificates. Ping me offlist if you want examples. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkr3zvgACgkQNL8k5A2w/vzxSACg3ndq597JKGyoxzkL5gX42r8+ F1UAoKmRON0eAxS1/afVS0KJoUC8AQZe =JORx -----END PGP SIGNATURE----- From eran@hueniverse.com Mon Nov 9 00:25:47 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD0E13A67A4 for ; Mon, 9 Nov 2009 00:25:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vCNT8adh2mA8 for ; Mon, 9 Nov 2009 00:25:42 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 053523A6B03 for ; Mon, 9 Nov 2009 00:25:41 -0800 (PST) Received: (qmail 14501 invoked from network); 9 Nov 2009 08:26:07 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 9 Nov 2009 08:26:07 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Mon, 9 Nov 2009 01:26:06 -0700 From: Eran Hammer-Lahav To: "oauth@ietf.org" Date: Mon, 9 Nov 2009 01:26:09 -0700 Thread-Topic: [OAUTH-WG] why are we signing? Thread-Index: AcphEqlzuPYWbFWtQZap0lwl/eLPUQAA5vmg Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343785078716@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343785078711@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1bc4603e0911090000i6872f482pf1d003442aadd6be@mail.gmail.com> In-Reply-To: <1bc4603e0911090000i6872f482pf1d003442aadd6be@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_90C41DD21FB7C64BB94121FBBC2E72343785078716P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] why are we signing? X-BeenThere: oauth@ietf.org X-Mailman-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, 09 Nov 2009 08:25:47 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343785078716P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We are not likely to provide less security than currently offered by the 1.= 0a specification (on the authentication side). While I welcome this discuss= ion, my focus is to enable the two edge cases: "full" security (as currentl= y offered by the OAuth HMAC method) and "transport layer" security (as curr= ently offered by the PLAINTEXT method). I am confident that we can signific= antly simplify the HMAC-based solution. It is already much simpler in my wo= rking draft (which I will focus on next, right after my batch of discovery = specs is out this week). EHL From: Chris Messina [mailto:chris.messina@gmail.com] Sent: Monday, November 09, 2009 12:00 AM To: Eran Hammer-Lahav Cc: Brian Eaton; oauth@ietf.org Subject: Re: [OAUTH-WG] why are we signing? Indeed, in the beginning of OAuth, that was one of the primary drivers that= lead us to the decision to sign everything - because of the non-SSL case..= . While it's possibly increasingly common to expect that serious developers w= ill go and buy an SSL cert, that may not be the case for the wider array of= hobbyist types. Now, that's not to say that they are the only audience tha= t needs to be addressed, but the idea was to make it harder for them to scr= ew up if they leaked their API calls... Clearly it turned out that the sign= ing bit intended to prevent against such attacks itself was too hard to imp= lement, and so now we're having these conversations again. At least now we have more data about what the market will bear now. Anyway, that's my recollection. But it might also not be exactly the explan= ation for what you're looking for. Chris On Sun, Nov 8, 2009 at 11:48 PM, Eran Hammer-Lahav > wrote: The problem is, we are not likely to ever reach consensus on 'reasonable se= curity'. For example, I don't find most cookie-based session systems reasonably secu= re without SSL/TLS. Being able to sit at a coffee shop with free wifi and a= laptop and steal sessions cookies, then access people's email for the dura= tion the cookie is valid isn't reasonable or secure. If you would like to try this approach, I would suggest adding next to each= option the list of common attacks still possible under those terms. It wil= l allow us to evaluate the added security each level of complexity brings. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth= -bounces@ietf.org] On Behalf > Of Brian Eaton > Sent: Sunday, November 08, 2009 9:03 PM > To: oauth@ietf.org > Subject: [OAUTH-WG] why are we signing? > > Hey folks - > > What are the use cases for cryptography in OAuth? Why are we signing > requests? And how much of each request do we need to sign in order to > be useful? > > As I see it, we have roughly the following menu of choices: > > 1) No signatures. > Just use bearer tokens. Use transport layer encryption to keep > those bearer tokens from leaking. > > 2) Signed tokens. > We could just sign a timestamp, rather than entire messages. > > 3) Partially signed messages. > We could sign just the request URL, or the request URL plus some > parameters. > > 4) Fully signed messages. > Sign as much of the HTTP request as possible, down to the bits of > the HTTP entity body. > > My guess is we need at least two out of those four choices (one with > bearer tokens, a la OAuth 1.0 plaintext) and another with > cryptography. But I'm not sure whether we need to sign entire > messages, or if we can get away with something simpler and still have > reasonable security. > > 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 -- Chris Messina Open Web Advocate Personal: http://factoryjoe.com Follow me on Twitter: http://twitter.com/chrismessina Citizen Agency: http://citizenagency.com Diso Project: http://diso-project.org OpenID Foundation: http://openid.net This email is: [ ] shareable [X] ask first [ ] private --_000_90C41DD21FB7C64BB94121FBBC2E72343785078716P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We are not likely to provide less security than currently offered by the 1.0a specification (on the authentication side). While I wel= come this discussion, my focus is to enable the two edge cases: “full̶= 1; security (as currently offered by the OAuth HMAC method) and “transport layer̶= 1; security (as currently offered by the PLAINTEXT method). I am confident that we can significantly simplify the HMAC-based solution. It is already much simpler = in my working draft (which I will focus on next, right after my batch of disco= very specs is out this week).

 

EHL

 

 

From: Chris Messina [mailto:chris.messina@gmail.com]
Sent: Monday, November 09, 2009 12:00 AM
To: Eran Hammer-Lahav
Cc: Brian Eaton; oauth@ietf.org
Subject: Re: [OAUTH-WG] why are we signing?

 

Indeed, in the beginning of OAuth, that was one of the primary drivers that lead us to the decision to sign everything — bec= ause of the non-SSL case... 

 

While it's possibly increasingly common to expect that serious developers will go and buy an SSL cert, that may not be the case fo= r the wider array of hobbyist types. Now, that's not to say that they are the only audience that needs to be addressed, but the idea was to make it harde= r for them to screw up if they leaked their API calls... Clearly it turned ou= t that the signing bit intended to prevent against such attacks itself was to= o hard to implement, and so now we're having these conversations again.<= /o:p>

 

At least now we have more data about what the market w= ill bear now.

 

Anyway, that's my recollection. But it might also not = be exactly the explanation for what you're looking for.

 

Chris

On Sun, Nov 8, 2009 at 11:48 PM, Eran Hammer-Lahav <= ;eran@hueniverse.com> wrote:=

The problem is, we are not likely to ever reach consen= sus on 'reasonable security'.

For example, I don't find most cookie-based session systems reasonably secu= re without SSL/TLS. Being able to sit at a coffee shop with free wifi and a la= ptop and steal sessions cookies, then access people's email for the duration the cookie is valid isn't reasonable or secure.

If you would like to try this approach, I would suggest adding next to each= option the list of common attacks still possible under those terms. It will allow = us to evaluate the added security each level of complexity brings.

EHL


> -----Original Message-----
> From: oauth-bounces@ietf.org= [mailto:oauth-bounces@ietf.org] On Behalf
> Of Brian Eaton
> Sent: Sunday, November 08, 2009 9:03 PM
> To: oauth@ietf.org
> Subject: [OAUTH-WG] why are we signing?
>
> Hey folks -
>
> What are the use cases for cryptography in OAuth?  Why are we sig= ning
> requests?  And how much of each request do we need to sign in ord= er to
> be useful?
>
> As I see it, we have roughly the following menu of choices:
>
> 1) No signatures.
>     Just use bearer tokens.  Use transport layer encryp= tion to keep
> those bearer tokens from leaking.
>
> 2) Signed tokens.
>     We could just sign a timestamp, rather than entire messa= ges.
>
> 3) Partially signed messages.
>     We could sign just the request URL, or the request URL p= lus some
> parameters.
>
> 4) Fully signed messages.
>      Sign as much of the HTTP request as possible, down= to the bits of
> the HTTP entity body.
>
> My guess is we need at least two out of those four choices (one with > bearer tokens, a la OAuth 1.0 plaintext) and another with
> cryptography.  But I'm not sure whether we need to sign entire > messages, or if we can get away with something simpler and still have<= br> > reasonable security.
>
> Cheers,
> Brian
> _______________________________________________
> 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




--
Chris Messina
Open Web Advocate

Personal: http://factoryjoe.com
Follow me on Twitter: http://tw= itter.com/chrismessina

Citizen Agency: http://citizenagency.c= om
Diso Project: http://diso-project.org
OpenID Foundation: http://openid.net

This email is:   [ ] shareable    [X] ask first   [ ] private

--_000_90C41DD21FB7C64BB94121FBBC2E72343785078716P3PW5EX1MB01E_-- From Hannes.Tschofenig@gmx.net Mon Nov 9 00:57:28 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D6D73A6B13 for ; Mon, 9 Nov 2009 00:57:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[AWL=0.695, 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 T704XX02+to0 for ; Mon, 9 Nov 2009 00:57:21 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 4EFCD3A6B0A for ; Mon, 9 Nov 2009 00:57:19 -0800 (PST) Received: (qmail invoked by alias); 09 Nov 2009 08:57:44 -0000 Received: from host-18-117.meeting.ietf.org (EHLO 4FIL42860) [133.93.18.117] by mail.gmx.net (mp004) with SMTP; 09 Nov 2009 09:57:44 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19ow/FvB9Vo47DDVt4JYT1hN8mq0XjL+h+XZMW0GW bwcJxbfCA/69Zz From: "Hannes Tschofenig" To: "'Chris Messina'" , "'Eran Hammer-Lahav'" References: <90C41DD21FB7C64BB94121FBBC2E72343785078711@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1bc4603e0911090000i6872f482pf1d003442aadd6be@mail.gmail.com> Date: Mon, 9 Nov 2009 18:00:57 +0900 Message-ID: <057c01ca611b$2981e3b0$4a3e000a@nsnintra.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_057D_01CA6166.99698BB0" X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcphEqzOIb3UvrDBRQ6NfBBJY9qp6wAB5Fqg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <1bc4603e0911090000i6872f482pf1d003442aadd6be@mail.gmail.com> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5600000000000001,0.54 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] why are we signing? X-BeenThere: oauth@ietf.org X-Mailman-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, 09 Nov 2009 08:57:28 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_057D_01CA6166.99698BB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Chris, _____ From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Chris Messina Sent: 09 November, 2009 17:00 To: Eran Hammer-Lahav Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] why are we signing? Indeed, in the beginning of OAuth, that was one of the primary drivers that lead us to the decision to sign everything - because of the non-SSL case... The OAuth signing mechanism does not sign anything, only certain parts. Signing everything was consider difficult since the complete data stream may not be available. There is also a TLS-PSK variant that would not require you to use certificates if that is considered to be the problem. While it's possibly increasingly common to expect that serious developers will go and buy an SSL cert, that may not be the case for the wider array of hobbyist types. Now, that's not to say that they are the only audience that needs to be addressed, but the idea was to make it harder for them to screw up if they leaked their API calls... Clearly it turned out that the signing bit intended to prevent against such attacks itself was too hard to implement, and so now we're having these conversations again. I rather believe that the description was difficult to understand (and hence implementers got it wrong). Once libraries are available then there is no need for application designers to worry about these issues. Ciao Hannes At least now we have more data about what the market will bear now. Anyway, that's my recollection. But it might also not be exactly the explanation for what you're looking for. Chris On Sun, Nov 8, 2009 at 11:48 PM, Eran Hammer-Lahav wrote: The problem is, we are not likely to ever reach consensus on 'reasonable security'. For example, I don't find most cookie-based session systems reasonably secure without SSL/TLS. Being able to sit at a coffee shop with free wifi and a laptop and steal sessions cookies, then access people's email for the duration the cookie is valid isn't reasonable or secure. If you would like to try this approach, I would suggest adding next to each option the list of common attacks still possible under those terms. It will allow us to evaluate the added security each level of complexity brings. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Brian Eaton > Sent: Sunday, November 08, 2009 9:03 PM > To: oauth@ietf.org > Subject: [OAUTH-WG] why are we signing? > > Hey folks - > > What are the use cases for cryptography in OAuth? Why are we signing > requests? And how much of each request do we need to sign in order to > be useful? > > As I see it, we have roughly the following menu of choices: > > 1) No signatures. > Just use bearer tokens. Use transport layer encryption to keep > those bearer tokens from leaking. > > 2) Signed tokens. > We could just sign a timestamp, rather than entire messages. > > 3) Partially signed messages. > We could sign just the request URL, or the request URL plus some > parameters. > > 4) Fully signed messages. > Sign as much of the HTTP request as possible, down to the bits of > the HTTP entity body. > > My guess is we need at least two out of those four choices (one with > bearer tokens, a la OAuth 1.0 plaintext) and another with > cryptography. But I'm not sure whether we need to sign entire > messages, or if we can get away with something simpler and still have > reasonable security. > > 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 -- Chris Messina Open Web Advocate Personal: http://factoryjoe.com Follow me on Twitter: http://twitter.com/chrismessina Citizen Agency: http://citizenagency.com Diso Project: http://diso-project.org OpenID Foundation: http://openid.net This email is: [ ] shareable [X] ask first [ ] private ------=_NextPart_000_057D_01CA6166.99698BB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Chris,
From: oauth-bounces@ietf.org=20 [mailto:oauth-bounces@ietf.org] On Behalf Of Chris=20 Messina
Sent: 09 November, 2009 17:00
To: Eran=20 Hammer-Lahav
Cc: oauth@ietf.org
Subject: Re: = [OAUTH-WG]=20 why are we signing?

Indeed, in the beginning of OAuth, that was one of the = primary=20 drivers that lead us to the decision to sign everything — = because of the=20 non-SSL case... 
The OAuth signing mechanism does = not sign=20 anything, only certain parts. Signing everything was consider = difficult=20 since the complete data stream may not be available.=20  
 
There is also a TLS-PSK variant that would = not=20 require you to use certificates if that is considered to be the = problem.=20
 
While it's possibly increasingly common to expect that serious = developers=20 will go and buy an SSL cert, that may not be the case for the wider = array of=20 hobbyist types. Now, that's not to say that they are the only audience = that=20 needs to be addressed, but the idea was to make it harder for them to = screw up=20 if they leaked their API calls... Clearly it turned out that the = signing bit=20 intended to prevent against such attacks itself was too hard to = implement, and=20 so now we're having these conversations again.
 I rather believe that = the description was=20 difficult to understand (and hence implementers got it = wrong). Once=20 libraries are available then there is no need for application = designers=20 to worry about these issues. 
 
Ciao
Hannes
 
At least now we have more data about what the market will bear = now.

Anyway, that's my recollection. But it might also not be exactly = the=20 explanation for what you're looking for.

Chris

On Sun, Nov 8, 2009 at 11:48 PM, Eran = Hammer-Lahav=20 <eran@hueniverse.com> = wrote:
The=20 problem is, we are not likely to ever reach consensus on 'reasonable = security'.

For example, I don't find most cookie-based = session=20 systems reasonably secure without SSL/TLS. Being able to sit at a = coffee=20 shop with free wifi and a laptop and steal sessions cookies, then = access=20 people's email for the duration the cookie is valid isn't reasonable = or=20 secure.

If you would like to try this approach, I would = suggest=20 adding next to each option the list of common attacks still possible = under=20 those terms. It will allow us to evaluate the added security each = level of=20 complexity brings.

EHL

> -----Original Message-----
> From: oauth-bounces@ietf.org = [mailto:oauth-bounces@ietf.org] = On=20 Behalf
> Of Brian Eaton
> Sent: Sunday, November 08, = 2009 9:03=20 PM
> To: oauth@ietf.org
>=20 Subject: [OAUTH-WG] why are we signing?
>
> Hey folks=20 -
>
> What are the use cases for cryptography in OAuth?=20  Why are we signing
> requests?  And how much of = each=20 request do we need to sign in order to
> be = useful?
>
> As=20 I see it, we have roughly the following menu of = choices:
>
> 1)=20 No signatures.
>     Just use bearer tokens. =  Use=20 transport layer encryption to keep
> those bearer tokens from=20 leaking.
>
> 2) Signed tokens.
>     We = could=20 just sign a timestamp, rather than entire messages.
>
> = 3)=20 Partially signed messages.
>     We could sign just = the=20 request URL, or the request URL plus some
>=20 parameters.
>
> 4) Fully signed messages.
>   =  =20  Sign as much of the HTTP request as possible, down to the bits = of
> the HTTP entity body.
>
> My guess is we need = at=20 least two out of those four choices (one with
> bearer tokens, = a la=20 OAuth 1.0 plaintext) and another with
> cryptography. =  But I'm=20 not sure whether we need to sign entire
> messages, or if we = can get=20 away with something simpler and still have
> reasonable=20 security.
>
> Cheers,
> Brian
>=20 _______________________________________________
> OAuth = mailing=20 list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
______= _________________________________________
OAuth=20 mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
=


--
Chris Messina
Open Web = Advocate

Personal: http://factoryjoe.com
Follow me = on=20 Twitter: http://twitter.com/chrismessina<= /A>

Citizen=20 Agency: http://citizenagency.com
Diso = Project:=20 http://diso-project.org
OpenID=20 Foundation: http://openid.net

This=20 email is:   [ ] shareable    [X] ask first   [ ]=20 private
------=_NextPart_000_057D_01CA6166.99698BB0-- From hubertlvg@gmail.com Mon Nov 9 01:03:57 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B857A3A659B for ; Mon, 9 Nov 2009 01:03:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 9b6hs26xqd17 for ; Mon, 9 Nov 2009 01:03:57 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id CA8FD3A685D for ; Mon, 9 Nov 2009 01:03:56 -0800 (PST) Received: by bwz23 with SMTP id 23so3145092bwz.29 for ; Mon, 09 Nov 2009 01:04:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=bDKc/58S147e5twgE6TceJ+nH9+nMUVIgidTmvtMw8M=; b=LjD5GXUcbNLfYCmggP0AGis8uOKr9QY/K29IelmCQDbEiTJBE5p1tJ+p5MxVc7cfSF 8APwpLheQYzYY1LIFNtORefi2VolSfWE2GU1XDa0GDJ+tSOf3vWFQKAcHfU7Wg4kCOcw Q7lImMJekdrvJAB/HuUS0G7TvQkj40od3MXtU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=e2xFQaG6TtU9odhXuYiRiBI35MAbJCzqz/hSMrTtKVCBgurxLP4SpwRJsHuJjnLj7M Ea2VtQIxvASiVlLq1sFPUSJWJXCiupVsqUQOPHgs59s2dYsLQ19ja3B+kLfQLprPXgDk qZAx+EhJvyTT48rhovrfKmMr+QsNRMk+GbwqE= MIME-Version: 1.0 Received: by 10.204.152.154 with SMTP id g26mr8208753bkw.54.1257757457611; Mon, 09 Nov 2009 01:04:17 -0800 (PST) Date: Mon, 9 Nov 2009 10:04:17 +0100 Message-ID: <6c0fd2bc0911090104x7089491rd943c3b79fecd1b2@mail.gmail.com> From: Hubert Le Van Gong To: oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [OAUTH-WG] No caching? X-BeenThere: oauth@ietf.org X-Mailman-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, 09 Nov 2009 09:03:57 -0000 Section 6.6 explains there might be issues with caching but I wonder if we shouldn't go a bit further in securing the protocol messages. Shouldn't we prevent caching for at least some of the protocol messages? I find the rules in the SAML 2.0 spec fairly clear in this matter (see below). - Include Cache-Control header, set to "no-cache, no-store" - Include Pragma header, set to "no-cache" - Not include validator like Last-Modified or Etag header Even if we decide not to mandate those, would it be useful to list those as a recommendations? Hubert From Hannes.Tschofenig@gmx.net Mon Nov 9 01:16:46 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31EC43A6885 for ; Mon, 9 Nov 2009 01:16:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.594 X-Spam-Level: X-Spam-Status: No, score=-1.594 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, URIBL_RHS_DOB=1.083] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tCmK3y1W2rzr for ; Mon, 9 Nov 2009 01:16:45 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id ACD2B3A63EC for ; Mon, 9 Nov 2009 01:16:44 -0800 (PST) Received: (qmail invoked by alias); 09 Nov 2009 09:17:09 -0000 Received: from host-18-117.meeting.ietf.org (EHLO 4FIL42860) [133.93.18.117] by mail.gmx.net (mp039) with SMTP; 09 Nov 2009 10:17:09 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+coyknuJicn9+G561caEk1/umzBxRXE5oL4dCqpf ZYoGW/dfSPpynY From: "Hannes Tschofenig" To: "'Brian Eaton'" , References: Date: Mon, 9 Nov 2009 18:20:22 +0900 Message-ID: <058101ca611d$e02be780$4a3e000a@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acpg+fEBU+BwEhqXSYuENARo7UE3OwAGYHNg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: X-Y-GMX-Trusted: 0 X-FuHaFi: 0.57 Subject: Re: [OAUTH-WG] why are we signing? X-BeenThere: oauth@ietf.org X-Mailman-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, 09 Nov 2009 09:16:46 -0000 Hi Brian, There is no doubt that one can sign different parts of the message to show that you know the key and to bind the token to the request itself. You can find examples of signing different practices in other protocols. For example, DKIM allows you to vary the amount of elements being signed (see h-parameter on page 20 of http://www.ietf.org/rfc/rfc4871.txt). SIP Identity, http://www.rfc-editor.org/rfc/rfc4474.txt, signs a fixed number of fields (although more than the current Oauth spec). There is most likely no right answer since it depends a bit on the threat model and the usage scenarios. Here is an example. The signature mechanism prevents replays of the token. The HTTP case and the SIP/XMPP communication model are different since with XMPP/SIP there is also the risk that intermediaries see the token passing by and misuse it. The usage of Oauth has been suggested also for XMPP (see http://xmpp.org/extensions/xep-0235.html) and for SIP (see http://tools.ietf.org/html/draft-beck-oauth-sip-eval-00). Ciao Hannes >Hey folks - > >What are the use cases for cryptography in OAuth? Why are we >signing requests? And how much of each request do we need to >sign in order to be useful? > >As I see it, we have roughly the following menu of choices: > >1) No signatures. > Just use bearer tokens. Use transport layer encryption to >keep those bearer tokens from leaking. > >2) Signed tokens. > We could just sign a timestamp, rather than entire messages. > >3) Partially signed messages. > We could sign just the request URL, or the request URL >plus some parameters. > >4) Fully signed messages. > Sign as much of the HTTP request as possible, down to the >bits of the HTTP entity body. > >My guess is we need at least two out of those four choices >(one with bearer tokens, a la OAuth 1.0 plaintext) and another >with cryptography. But I'm not sure whether we need to sign >entire messages, or if we can get away with something simpler >and still have reasonable security. > >Cheers, >Brian >_______________________________________________ >OAuth mailing list >OAuth@ietf.org >https://www.ietf.org/mailman/listinfo/oauth > From john@jkemp.net Mon Nov 9 06:28:06 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82C4D3A693D for ; Mon, 9 Nov 2009 06:28:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 TaWnxxrfXqvz for ; Mon, 9 Nov 2009 06:28:02 -0800 (PST) Received: from outbound-mail-10.bluehost.com (outbound-mail-10.bluehost.com [69.89.17.210]) by core3.amsl.com (Postfix) with SMTP id 9D74F3A685E for ; Mon, 9 Nov 2009 06:28:02 -0800 (PST) Received: (qmail 18371 invoked by uid 0); 9 Nov 2009 14:28:28 -0000 Received: from unknown (HELO box320.bluehost.com) (69.89.31.120) by outboundproxy1.bluehost.com with SMTP; 9 Nov 2009 14:28:28 -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=N7mq7MR57mDloCLXLHHDxmUZhEFQZObckK79GnCR93uIwDVPsINuPIIGtOKY+3wiYNvPOQisvKY9jS9bWCDs164an75+LMYQG5GjCEzeVyqJYJapdAsaPiWUbyVXon7t; 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 ) id 1N7VEK-0003Pe-FH; Mon, 09 Nov 2009 07:28:28 -0700 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: John Kemp In-Reply-To: Date: Mon, 9 Nov 2009 09:28:27 -0500 Content-Transfer-Encoding: 7bit Message-Id: <35D50F5C-3982-4298-A9E0-86A528F5C5D3@jkemp.net> References: To: Brian Eaton X-Mailer: Apple Mail (2.1076) X-Identified-User: {1122:box320.bluehost.com:jkempnet:jkemp.net} {sentby:smtp auth 69.205.56.47 authed with john+jkemp.net} Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] why are we signing? X-BeenThere: oauth@ietf.org X-Mailman-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, 09 Nov 2009 14:28:06 -0000 On Nov 9, 2009, at 12:02 AM, Brian Eaton wrote: [...] > > My guess is we need at least two out of those four choices (one with > bearer tokens, a la OAuth 1.0 plaintext) and another with > cryptography. But I'm not sure whether we need to sign entire > messages, or if we can get away with something simpler and still have > reasonable security. I agree that bearer tokens are useful. As for signatures, the question is really all in the subject line. And I guess the answers I would come up with, generally-speaking would be: i) To authenticate the entity doing the signing, by means of the use and verification of that entity's key. Such authentication can be a basis for authorizing that entity via the presence of the token in the message to do whatever is asked for in the request message. ii) To bind the token and the rest of the message together to ensure that the recipient can detect whether the (important parts of the) message was tampered with by a third-party. If we are only interested in i) then signing any piece of the message might be sufficient. If we are interested in ii) (or some other security property) then we will need to identify which pieces of the message we want to provide that, or other, security properties for. - johnk From faynberg@alcatel-lucent.com Mon Nov 9 06:36:08 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 475273A67A5 for ; Mon, 9 Nov 2009 06:36:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 h33NwnqCy2ZK for ; Mon, 9 Nov 2009 06:36:07 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 4F3FF3A63C9 for ; Mon, 9 Nov 2009 06:36:07 -0800 (PST) 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 nA9EaRhf019807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Nov 2009 08:36:27 -0600 (CST) Received: from [135.244.39.234] (faynberg.lra.lucent.com [135.244.39.234]) by umail.lucent.com (8.13.8/TPES) with ESMTP id nA9EaMch025625; Mon, 9 Nov 2009 08:36:23 -0600 (CST) Message-ID: <4AF828E5.3060701@alcatel-lucent.com> Date: Mon, 09 Nov 2009 09:36:21 -0500 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Phillip Hallam-Baker References: <3a880e2c0911061126t176e04ebjef1acd7fcb23efed@mail.gmail.com> <4AF77B77.40507@alcatel-lucent.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.37 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] RSA vs PKI? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: faynberg@alcatel-lucent.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 14:36:08 -0000 I am very glad that we have key observations on the table. I do not object to making RSA mandatory; I only wanted to have other public-key algorithms considered, which is exactly what has happened. To piggy-back a note on ECC "provability," yes, its complexity indeed boils down to that of the discrete logarithm problem in a finite group. But elliptic curves define funky groups! I've heard claims from various sources--with references to Victor Shoup's results,--that in certain types of groups the average-case bound for the discrete logarithm problem equals the worst-case bound. It appears that certain elliptic curves produce just these types of fields--this is what I was told. Now, I have not read all the references--I have just started with Shoup's papers, and it may take me a couple of months or so before I fully understand both the math and the practical meaning of the claims. Once there, I will be happy to share what I learned. Igor Phillip Hallam-Baker wrote: > No, don't leave the key size to chance, there is a lot of crypto > hardware out there that is quite restrictive in key sizes. > > The only key sizes I am aware of being widely used are 1024 and 2048. > Beyond 2048 you really need to move to ECC. 1024 is considered barely > sufficient and not really suitable for new applications. > > From jonathan_moore@comcast.com Mon Nov 9 08:02:48 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36A6828C16C for ; Mon, 9 Nov 2009 08:02:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.463 X-Spam-Level: X-Spam-Status: No, score=-8.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, 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 ad4U9+A7xrVQ for ; Mon, 9 Nov 2009 08:02:47 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id CD2AC28C19B for ; Mon, 9 Nov 2009 08:02:46 -0800 (PST) Received: from ([10.195.246.152]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.60121080; Mon, 09 Nov 2009 11:03:11 -0500 Received: from PACORPEXCMB03.cable.comcast.com ([24.40.15.85]) by NJMDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 11:03:12 -0500 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, 9 Nov 2009 11:03:11 -0500 Message-ID: In-Reply-To: <6c0fd2bc0911090104x7089491rd943c3b79fecd1b2@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] No caching? Thread-Index: AcphG6TK7gWDXE0KT4qUhf1D8Fzy4QANe8vw References: <6c0fd2bc0911090104x7089491rd943c3b79fecd1b2@mail.gmail.com> From: "Moore, Jonathan (CIM)" To: X-OriginalArrivalTime: 09 Nov 2009 16:03:12.0408 (UTC) FILETIME=[237EE180:01CA6156] Subject: Re: [OAUTH-WG] No caching? X-BeenThere: oauth@ietf.org X-Mailman-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, 09 Nov 2009 16:02:48 -0000 I think there are very real use cases where I would expect (and desire) the response to an OAuth-signed request to be at least "private" cacheable, so I'm not sure I would go so far as to *recommend* (i.e. SHOULD) the full "no-cache" approach. Also, RFC2616 specifies: "In other words, the preferred behavior for an HTTP/1.1 origin server is to send both a strong entity tag and a Last-Modified value." It also goes so far as to say you SHOULD generate an ETag unless this is technically infeasible, and I don't think the OAuth case qualifies here. I'm not sure I can back not including validators in the response. In my case, I would do: Cache-Control: private, no-store, max-age=3D600 Last-Modified: Expires: Etag: Which allows for caching by HTTP/1.1 private caches but prevents caching by HTTP/1.0 caches. All that being said, however, the HTTP RFC is the source of truth as far as caching goes, and I would rather have the OAuth spec refer directly to it, much as it already does, with the "be careful what you're doing here" caveat. It might be useful, however, to call out particular portions of RFC2616 to implementors, such as Section 13 and the definitions of the individual headers in Section 14 for 'Etag', 'Last-Modified', 'Expires', 'Cache-Control', and 'Pragma'. It is also worth noting that caches may be explicitly configured to override caching directives from clients and/or servers, and hence the security of the protocol must not depend on having fully-compliant proxies and caches. Jon ........ Jon Moore Comcast Interactive Media -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Hubert Le Van Gong Sent: Monday, November 09, 2009 4:04 AM To: oauth@ietf.org Subject: [OAUTH-WG] No caching? Section 6.6 explains there might be issues with caching but I wonder if we shouldn't go a bit further in securing the protocol messages. Shouldn't we prevent caching for at least some of the protocol messages? I find the rules in the SAML 2.0 spec fairly clear in this matter (see below). - Include Cache-Control header, set to "no-cache, no-store" - Include Pragma header, set to "no-cache" - Not include validator like Last-Modified or Etag header Even if we decide not to mandate those, would it be useful to list those as a recommendations? Hubert _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From onyxraven@gmail.com Mon Nov 9 08:28:03 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A044C3A69C0 for ; Mon, 9 Nov 2009 08:28:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-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 FLWrQZ2oj0AH for ; Mon, 9 Nov 2009 08:28:02 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 6D7123A687B for ; Mon, 9 Nov 2009 08:28:02 -0800 (PST) Received: by yxe30 with SMTP id 30so3404810yxe.29 for ; Mon, 09 Nov 2009 08:28:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=2jVr0hH4DXY6Ynj2ZFv7i45myA4O3hhoOQx1kj6qz3I=; b=HRhD2diukGd3I2B/IzYENtD6jIfRxrcMsdq3/svM2na8o2DAFWn/3domeAQ9bajymT 1reLZtvC9tTwNlZqNeOFRpNDcJgJz6ZnGKbqXgMJ2/E9P0fpCHrbpSShQJvLPLkgG5ui aPrVXsngZJB7MmuxbSO23uPpJtUUuDFoZ8p2Q= 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=gNDcOkwSkd2UX1s83koh/mIOtPlJMhp4QOBYmoklo4pVjucR2iO6O8yPBC3rGQz3Et cEt6wTj9r4sObVuwyJpn7SZrtA7ljyW35WL+zolNfRBYfS1NcHrMjpZw4fMuFM2ZnIjE lH1OmeFw1b4r6ZsWxGCd2Muc91bc+yCCSSOSE= MIME-Version: 1.0 Received: by 10.150.37.40 with SMTP id k40mr1955959ybk.254.1257784103682; Mon, 09 Nov 2009 08:28:23 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343784ECD774@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343784ECD774@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 9 Nov 2009 09:28:23 -0700 Message-ID: From: Justin Hart To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=000e0cd6c984b441a50477f2aea2 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Delegation (token) 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, 09 Nov 2009 16:28:03 -0000 --000e0cd6c984b441a50477f2aea2 Content-Type: text/plain; charset=ISO-8859-1 This is a response to an older thread by Eran, but I think some of the topics brought up recently are related. On Tue, Oct 6, 2009 at 3:07 PM, Eran Hammer-Lahav wrote: > - Are there use cases where the 3-step flow (#2) is needed? > I think the complaint is that you're 'exposing' client credentials to a browser if you don't use some sort of temporary request token between the user authorization and the 'approved' usage. Essentially its between #1 and #2 above, where the user goes directly to a webpage for authorization and returns to the app with some temporary (request) token which is exchanged for the 'access' token. This takes the pre-webpage request step out. It changes the requirements on the web page request to display the client name, and associate a user with the client, that we currently get through the request token now (solved by supplying the client key). One use case I've considered is the device-without-input case. A device contacts service for a request token, and gets a short (typable) token to input on a web browser for authorization. The device then reuses that token to get an access token (which is probably longer and untypable) for subsequent authorized requests. I see the netflix device authorization as being an example of how this could look. Maybe 1.0a changes this flow though - since its essentially the reverse (go to a site and get a token to keypad into the device). Does removing the pre-web-authorization token remove the risk covered in 1.0a? (The callback verification is still nice for the above case though) > - Should we require use of HTTPS for token requests? > It'd be nice, though for independents, HTTPS can be pricey. I doubt Wordpress or Drupal would be able to promote it for independent self-hosted users because most wont buy a HTTPS hosting package on their shared hosting site. I know some sites have been slow to implement much HTTPS because of the high CPU cost of HTTPS sessions, and they're running tight on their current hardware. Probably best as a SHOULD and not a MUST. But, that means there needs to be some independently-secure way to exchange info. > - If it is ok for tokens to be sent unsecure, is it also ok to send client > secrets unsecure? > I think there was some debate on whether exposing the user credential token/secret is a risk overall? If an attacker has the client credentials, they could just direct a user through this process themselves, so what are we protecting? > - How should a PK option work? What should be signed? How should it work > over a secure channel? > I assume this PK is in context to the method OAuth works currently with the consumer_secret? What's shared secret then? I guess I dont know the distinction yet. --000e0cd6c984b441a50477f2aea2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This is a response to an older thread by Eran, but I think some of the= topics brought up recently are related.=A0

On Tue, Oct 6, 2009 at = 3:07 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
- Are there use c= ases where the 3-step flow (#2) is needed?

I think the complaint is that you're 'exposing' client credentials to a browser if you don't use som= e sort of temporary request token between the user authorization and the 'approved' usage.=A0 Essentially its between #1 and #2 above, where= the user goes directly to a webpage for authorization and returns to the app with some temporary (request) token which is exchanged for the 'access' token.=A0 This takes the pre-webpage request step out.=A0 = It changes the requirements on the web page request to display the client name, and associate a user with the client, that we currently get through the request token now (solved by supplying the client key).=A0

One use case I've considered is the device-without-input case.=A0 A device contacts service for a request token, and gets a short (typable) token to input on a web browser for authorization.=A0 The device then reuses that token to get an access token (which is probably longer and untypable) for subsequent authorized requests.=A0 I see the netflix device authorization as being an example of how this could look.=A0 Maybe 1.0a changes this flow though - since its essentially the reverse (go to a site and get a token to keypad into the device).

Does removing the pre-web-authorization token remove the risk covered in 1.0a? (The callback verification is still nice for the above case though)
=A0
- Should we require use of HTTPS for token requests?
=

It'd be nice, though for independents, HTTPS can be pricey. I doubt Wordpress or Drupal would be able to promote it for independent self-hosted users because most wont buy a HTTPS hosting package on their shared hosting site.=A0 I know some sites have been slow to implement much HTTPS because of the high CPU cost of HTTPS sessions, and they're running tight on their current hardware.=A0 Probably best a= s a SHOULD and not a MUST.=A0 But, that means there needs to be some independently-secure way to exchange info.
=A0
- If it is ok for tokens to be sent unsecure, is it also ok to send client = secrets unsecure?

I think there was some deb= ate on whether exposing the user credential token/secret is a risk overall?=A0 If an attacker has the client credentials, they could just direct a user through this process themselves, so what are we protecting?
=A0
- How should a PK option work? What should be signed? How should it work ov= er a secure channel?

I assume this PK is in context to the method OAuth works currently with the consumer_secret?=A0 What's shared secret then?=A0 I guess I dont kn= ow the distinction yet.=20 --000e0cd6c984b441a50477f2aea2-- From stpeter@stpeter.im Mon Nov 9 13:20:19 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78BF03A68EF for ; Mon, 9 Nov 2009 13:20:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 s1jJaVv4KDvD for ; Mon, 9 Nov 2009 13:20:18 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 9E1663A68E0 for ; Mon, 9 Nov 2009 13:20:18 -0800 (PST) Received: from host-113-169.meeting.ietf.org (64-104-46-217.cisco.com [64.104.46.217]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0AB7640D09 for ; Mon, 9 Nov 2009 14:20:44 -0700 (MST) Message-ID: <4AF887AA.1070904@stpeter.im> Date: Tue, 10 Nov 2009 06:20:42 +0900 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: OAuth WG X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [OAUTH-WG] informal OAuth meeting at IETF 76 X-BeenThere: oauth@ietf.org X-Mailman-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, 09 Nov 2009 21:20:19 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am working to set up an informal meeting at IETF 76. The most likely times appear to be Thursday 1510-1610 and Friday 0900-1130. I shall report back to the list when I have a room reserved. Thanks! Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkr4h6oACgkQNL8k5A2w/vzSmQCaAqOiNnR417QiSbxdL2JJRYuE Xk0AoKCm40iwA7cF6K1BYAOZQfTn0NXp =OoU0 -----END PGP SIGNATURE----- From stpeter@stpeter.im Mon Nov 9 14:14:00 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E968E3A6991 for ; Mon, 9 Nov 2009 14:14:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Es5j0O0lyXs for ; Mon, 9 Nov 2009 14:13:58 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 082DB3A6968 for ; Mon, 9 Nov 2009 14:13:58 -0800 (PST) Received: from host-113-169.meeting.ietf.org (64-104-46-217.cisco.com [64.104.46.217]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 25EF340D09 for ; Mon, 9 Nov 2009 15:14:23 -0700 (MST) Message-ID: <4AF8943E.4050802@stpeter.im> Date: Tue, 10 Nov 2009 07:14:22 +0900 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: OAuth WG X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [OAUTH-WG] comments on draft-hammer-oauth-03 X-BeenThere: oauth@ietf.org X-Mailman-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, 09 Nov 2009 22:14:02 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On the flight to Japan for IETF 76, I finally got a chance to finish reviewing draft-hammer-oauth-03, the informational documentation of what's known as "OAUth Core 1.0 Revision A" in the community. Many of my comments are purely editorial, so I will send those directly to the document editor. Here are a few slightly more substantive issues... 1. I think it would be very helpful to provide a bit more context in the Introduction. Say, two or three sentences about the provenance of this technology, the community that developed it, and a link to oauth.net (along with something like the final paragraph of the current Introduction). Something like this: The OAuth protocol was originally created by a loose group of technologists from a variety of websites and other Internet services, who wanted to solve the common problem of enabling delegated access to protected resources. The resulting OAuth protocol was stabilized at version 1.0 in October 2007 and published at the oauth.net website. This specification provides informational documentation of OAuth Core 1.0 Revision A as finalized in June 2009, incorporating several errata reported since that time as well as numerous editorial clarifications. It is not an item of the IETF's OAuth Working Group, which at the time of writing is working on an OAuth version that can be appropriate for publication on the standards track. 2. In the Terminology section, I think it might be helpful to provide pointers to the old terminology, as in: "(In the community edition, a client was called a consumer.)" We might also want to point to RFC 4949 regarding terminology and check that our usage of key terms like "authorization" is consistent with that document. 3. Before jumping right into authenticated requests in section 3, I think it would be helpful to provide a bit more context about the overall protocol flow (similar to Section 6 of the community edition). 4. In Section 3.1, we might want to say explicitly which parameters are required and which are not. For example, "Protocol parameters MUST NOT appear more than once per request. The following parameters are REQUIRED unless otherwise noted." Then say that, for example, oauth_version is RECOMMENDED instead of REQUIRED (or whatever). 5. In Section 3.2, it's not completely clear that the timestamp value must be numerical instead of, say, in ISO 8601 format. It's also not clear how the server would specify that the timestamp is something other than "the number of seconds since January 1, 1970 00:00:00 GMT". 6. In Section 3.2, let's explicitly say that methods that enable the client to sync its clock with the server's clock are out of scope for OAuth. 7. In Section 3.3, let's refer to the Security Considerations from the paragraph about not mandating a particular signature method (since that's where we talk about the properties of various methods). 8. In Section 3.3.1.1, we might want to be more explicit about which parameters are included in the "specific set of request parameters" (see recent discussion on the community list). 9. In Section 3.3.1.1 second bullet point, we say "The HTTP request entity-body, but only if..." -- does this mean that all of the three listed conditions need to be met, or any one of the conditions? 10. In Section 3.3.1.1, the sentence The "oauth_signature" parameter MUST be excluded if present. might be taken to imply that all other oauth_* parameters MUST be included (if found in the request). Let's be explicit about that. 11. In Section 3.3.4, we say that PLAINTEXT method SHOULD be used with SSL/TLS. Does that deserve to be a MUST? At least it might be worth a mention in the Security Considerations. 12. In Section 3.6, we say that "Text values are first encoded as UTF-8" but it's not fully clear to me which values this applies to or exactly where in the protocol the encoding rules are applied. 13. In Section 4, I think that a brief flow diagram would be helpful to illustrate the authorization process (e.g., this would provide context for why the client obtains a set of temporary credentials, which might not otherwise be obivous to first-time readers of Section 4.1). 14. In Section 4.2 (or in a security consideration pointed to from Section 4.2), it might be helpful to describe why oauth_callback is important and the nature of the session fixation attach that it helps to prevent. 15. In Section 6.8, I think there is a non-sequitur. Just because a client is a freely available desktop application does not mean that an attacker will be able to recover the client credentials. Perhaps one step in the chain of reasoning is not spelled out here? 16. Section 6.15 says: Clients should prevent CSRF attacks on OAuth callback URIs by verifying that the resource owner at the client site intended to complete the OAuth negotiation with the server. No guidance is provided on how the client might be able to do so. Saying that "methods for doing so are out of scope for this specification" is probably acceptable. 17. In Appendix A.1 the phrase "HTTPS POST" is used, but I think that's more accurately an HTTP POST to an SSL-protected host. Overall the spec looks very good, and IMHO is a big improvement over the community edition! Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkr4lD0ACgkQNL8k5A2w/vzkJwCfeOy6ZH1u8La20llLhgksyb4T mOYAoPrGjaVIL9w801IuguP3161i2X0/ =tN+p -----END PGP SIGNATURE----- From beaton@google.com Mon Nov 9 16:26:59 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AB133A67AF for ; Mon, 9 Nov 2009 16:26:59 -0800 (PST) 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 0DQrACN1jMMf for ; Mon, 9 Nov 2009 16:26:58 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 572653A63EB for ; Mon, 9 Nov 2009 16:26:58 -0800 (PST) Received: from zps78.corp.google.com (zps78.corp.google.com [172.25.146.78]) by smtp-out.google.com with ESMTP id nAA0RMSN019145 for ; Tue, 10 Nov 2009 00:27:23 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1257812843; bh=peRYx4Oha8hRKVZH8OkkjN11HkE=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=KyNyTf/6wq0I2h2PDP1juYrC8Dpa6kaHxO1XFkbXyAswr5xOR9Q9IiwqdQSZVm+Yi 0ItUYNLhlBuOJzMm+l6Ug== 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=Y+07ExXblVsNvhqnhx64UAg8tUmLAjN2QjiqHjbkL80/lXJqf3119BstV2Zii2tiR Ldc0hF6oHkRn+aLvUnxPg== Received: from pxi12 (pxi12.prod.google.com [10.243.27.12]) by zps78.corp.google.com with ESMTP id nAA0PTHd026278 for ; Mon, 9 Nov 2009 16:27:20 -0800 Received: by pxi12 with SMTP id 12so1350894pxi.3 for ; Mon, 09 Nov 2009 16:27:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.170.10 with SMTP id s10mr435461rve.72.1257812838938; Mon, 09 Nov 2009 16:27:18 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343785078711@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343785078711@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 9 Nov 2009 16:27:18 -0800 Message-ID: From: Brian Eaton To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] why are we signing? X-BeenThere: oauth@ietf.org X-Mailman-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, 10 Nov 2009 00:26:59 -0000 On Sun, Nov 8, 2009 at 11:48 PM, Eran Hammer-Lahav wrote: > The problem is, we are not likely to ever reach consensus on 'reasonable security'. Agreed, we are going to need a couple of options to cover even the most vanilla use cases. I fully expect other people to come up with more options for their specific use cases. My goal with this conversation is to identify the vanilla use cases that would cover most applications. > For example, I don't find most cookie-based session systems reasonably secure without SSL/TLS. > Being able to sit at a coffee shop with free wifi and a laptop and steal sessions cookies, then access > people's email for the duration the cookie is valid isn't reasonable or secure. OK, so let's consider OAuth-authenticated access to such a service... does signing requests improve security? I don't think so. The user's password is going to be sent in clear-text when they log in to the service to approve the oauth token. And whenever they view a web page on the service their session cookies are sent in clear text. The user's data (which is what really matters in this whole discussion...) is sent in clear text. AFAICT, using HMAC-SHA1 or RSA-SHA1 in such an environment doesn't protect users that much. The service really needs to support https if they are concerned about that threat model. Cheers, Brian From jpanzer@google.com Mon Nov 9 16:33:48 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6110D3A6955 for ; Mon, 9 Nov 2009 16:33:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 yTf6ibxE7mwz for ; Mon, 9 Nov 2009 16:33:47 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id 0F3403A68B0 for ; Mon, 9 Nov 2009 16:33:47 -0800 (PST) Received: from zps37.corp.google.com (zps37.corp.google.com [172.25.146.37]) by smtp-out.google.com with ESMTP id nAA0YCXW030483 for ; Mon, 9 Nov 2009 16:34:12 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1257813252; bh=YqvE1MJkQJw/2fbSUinOejVhTXM=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=jmEAtkR6AK6Oy1gpKORW65bgEKdc7r98zees2L+5eUzkMuvo00vQWq9E80zNfyk5D tYyrzwAjRnFKRmaTr2nWg== 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=iZBsYAl5BdGD/aPZEyqAwlhkZ5PoREDYQUgp/o5XgME0Daedx//Qs94bZe5O6rDcz 7DeLyFFqTUzy8J5KtbLMA== Received: from pzk4 (pzk4.prod.google.com [10.243.19.132]) by zps37.corp.google.com with ESMTP id nAA0XIS5031342 for ; Mon, 9 Nov 2009 16:34:10 -0800 Received: by pzk4 with SMTP id 4so2712405pzk.32 for ; Mon, 09 Nov 2009 16:34:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.6.25 with SMTP id 25mr15129311waf.25.1257813250190; Mon, 09 Nov 2009 16:34:10 -0800 (PST) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E72343785078711@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 9 Nov 2009 16:34:10 -0800 Message-ID: From: John Panzer To: Brian Eaton Content-Type: multipart/alternative; boundary=0016e648bcbef8ad800477f977f3 X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] why are we signing? X-BeenThere: oauth@ietf.org X-Mailman-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, 10 Nov 2009 00:33:48 -0000 --0016e648bcbef8ad800477f977f3 Content-Type: text/plain; charset=ISO-8859-1 Counter-argument: The login pages are protected with https, so their password is protected. Their session cookies are sent in clear text but are themselves encrypted and are refreshed every (say) 10 minutes to minimize exposure from leakage. The user's data certainly is sent in clear text form and an attacker can both read it and impersonate the user to send data if they grab the cookies, at least for 10 minutes. So I got nothin' there. (Would bearer token plus a way to securely rotate the token every N minutes make the OAuth session at least as secure as the above scenario?) On Mon, Nov 9, 2009 at 4:27 PM, Brian Eaton wrote: > On Sun, Nov 8, 2009 at 11:48 PM, Eran Hammer-Lahav > wrote: > > The problem is, we are not likely to ever reach consensus on 'reasonable > security'. > > Agreed, we are going to need a couple of options to cover even the > most vanilla use cases. I fully expect other people to come up with > more options for their specific use cases. > > My goal with this conversation is to identify the vanilla use cases > that would cover most applications. > > > For example, I don't find most cookie-based session systems reasonably > secure without SSL/TLS. > > Being able to sit at a coffee shop with free wifi and a laptop and steal > sessions cookies, then access > > people's email for the duration the cookie is valid isn't reasonable or > secure. > > OK, so let's consider OAuth-authenticated access to such a service... > does signing requests improve security? > > I don't think so. The user's password is going to be sent in > clear-text when they log in to the service to approve the oauth token. > And whenever they view a web page on the service their session > cookies are sent in clear text. The user's data (which is what really > matters in this whole discussion...) is sent in clear text. > > AFAICT, using HMAC-SHA1 or RSA-SHA1 in such an environment doesn't > protect users that much. The service really needs to support https if > they are concerned about that threat model. > > Cheers, > Brian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- -- John Panzer / Google jpanzer@google.com / abstractioneer.org / @jpanzer --0016e648bcbef8ad800477f977f3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Counter-argument: =A0The login pages are protected with https, so their pas= sword is protected. =A0Their session cookies are sent in clear text but are= themselves encrypted and are refreshed every (say) 10 minutes to minimize = exposure from leakage. =A0The user's data certainly is sent in clear te= xt form and an attacker can both read it and impersonate the user to send d= ata if they grab the cookies, at least for 10 minutes. =A0So I got nothin&#= 39; there. =A0

(Would bearer token plus a way to securely rotate the token = every N minutes make the OAuth session at least as secure as the above scen= ario?)

On Mon, Nov 9, 2009 at 4= :27 PM, Brian Eaton <beaton@google.com> wrote:
On Sun, Nov 8, 2009 at 11= :48 PM, Eran Hammer-Lahav <eran@h= ueniverse.com> wrote:
> The problem is, we are not likely to ever reac= h consensus on 'reasonable security'.

Agreed, we are going to need a couple of options to cover even the most vanilla use cases. =A0I fully expect other people to come up with
more options for their specific use cases.

My goal with this conversation is to identify the vanilla use cases
that would cover most applications.

> For example, I don't find most cookie-based session systems reason= ably secure without SSL/TLS.
> Being able to sit at a coffee shop with free wifi and a laptop and ste= al sessions cookies, then access
> people's email for the duration the cookie is valid isn't reas= onable or secure.

OK, so let's consider OAuth-authenticated access to such a servic= e...
does signing requests improve security?

I don't think so. =A0The user's password is going to be sent in
clear-text when they log in to the service to approve the oauth token.
=A0And whenever they view a web page on the service their session
cookies are sent in clear text. =A0The user's data (which is what reall= y
matters in this whole discussion...) is sent in clear text.

AFAICT, using HMAC-SHA1 or RSA-SHA1 in such an environment doesn't
protect users that much. =A0The service really needs to support https if they are concerned about that threat model.

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



--
--
John = Panzer / Google
jpanzer@google.com= / abstractioneer.org / @jpan= zer

--0016e648bcbef8ad800477f977f3-- From faynberg@alcatel-lucent.com Mon Nov 9 17:15:49 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35CF728C29C for ; Mon, 9 Nov 2009 17:15:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 jIVtjrDDwxnY for ; Mon, 9 Nov 2009 17:15:48 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id D6D473A69DF for ; Mon, 9 Nov 2009 17:15:47 -0800 (PST) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id nAA1G3cv016048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Nov 2009 19:16:03 -0600 (CST) Received: from [135.244.39.234] (faynberg.lra.lucent.com [135.244.39.234]) by umail.lucent.com (8.13.8/TPES) with ESMTP id nAA1Fxwb010804; Mon, 9 Nov 2009 19:16:00 -0600 (CST) Message-ID: <4AF8BECF.1080007@alcatel-lucent.com> Date: Mon, 09 Nov 2009 20:15:59 -0500 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Brian Eaton References: <90C41DD21FB7C64BB94121FBBC2E72343785078711@P3PW5EX1MB01.EX1.SECURESERVER.NET> 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.39 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] why are we signing? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: faynberg@alcatel-lucent.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 01:15:49 -0000 Brian Eaton wrote: > [...] > OK, so let's consider OAuth-authenticated access to such a service... > does signing requests improve security? > > I don't think so. The user's password is going to be sent in > clear-text when they log in to the service to approve the oauth token. > [...] Oh no! This must never happen. It MUST be that either Kerberos is employed to bypass sending of the password altogether, or the password is sent over TLS. Igor From stpeter@stpeter.im Mon Nov 9 17:28:32 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 431B228C293 for ; Mon, 9 Nov 2009 17:28:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 NdpC3M-0mP15 for ; Mon, 9 Nov 2009 17:28:31 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 628E73A6A26 for ; Mon, 9 Nov 2009 17:28:31 -0800 (PST) Received: from host-18-99.meeting.ietf.org (64-104-46-217.cisco.com [64.104.46.217]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id CD44D40D09 for ; Mon, 9 Nov 2009 18:28:57 -0700 (MST) Message-ID: <4AF8C1D7.6020200@stpeter.im> Date: Tue, 10 Nov 2009 10:28:55 +0900 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: OAuth WG References: <4AF887AA.1070904@stpeter.im> In-Reply-To: <4AF887AA.1070904@stpeter.im> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [OAUTH-WG] informal OAuth meeting at IETF 76 X-BeenThere: oauth@ietf.org X-Mailman-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, 10 Nov 2009 01:28:32 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/10/09 6:20 AM, Peter Saint-Andre wrote: > I am working to set up an informal meeting at IETF 76. The most likely > times appear to be Thursday 1510-1610 and Friday 0900-1130. I shall > report back to the list when I have a room reserved. OK, the room is reserved: Place: Camellia (4th floor) Day: Thursday, November 12 Time: 1510-1610 ("Afternoon Session II") Unfortunately this conflicts with TLS, but not with any other Apps meetings. We will have the full facilities of the room, including the ability to project slides and stream audio. If you have topics you'd like us to cover, feel free to send them to the list or poke me directly. If you would like to make a presentation, please either send your slides to me or bring them to the meeting. I can put together a brief agenda ahead of time. And we all understand that this is not an official WG meeting, right? /psa -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkr4wdcACgkQNL8k5A2w/vw+RACdF8Y/Da73CGju8EIm7td4DK/p 3BEAoMETNyBlL7m7Wi54MVreA1z+MzwB =9B/j -----END PGP SIGNATURE----- From Dick.Hardt@microsoft.com Mon Nov 9 18:09:01 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66C043A694D for ; Mon, 9 Nov 2009 18:09:01 -0800 (PST) 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 emSlGYaX1Wyw for ; Mon, 9 Nov 2009 18:09:00 -0800 (PST) Received: from smtp.microsoft.com (mail1.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 9F8DC3A690B for ; Mon, 9 Nov 2009 18:09:00 -0800 (PST) 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; Mon, 9 Nov 2009 18:09:44 -0800 Received: from TK5EX14MBXC102.redmond.corp.microsoft.com ([169.254.2.41]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi; Mon, 9 Nov 2009 18:09:26 -0800 From: Dick Hardt To: John Panzer Thread-Topic: [OAUTH-WG] why are we signing? Thread-Index: AQHKYPpiJlPvjbF+7Eug3PbIB1m6s5Et5jgAgAEXDgCAAAHrAIAAGp4A Date: Tue, 10 Nov 2009 02:09:26 +0000 Message-ID: <19B1A486-C1F9-4EAF-9DAE-FD886D829236@microsoft.com> References: <90C41DD21FB7C64BB94121FBBC2E72343785078711@P3PW5EX1MB01.EX1.SECURESERVER.NET> 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-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] why are we signing? X-BeenThere: oauth@ietf.org X-Mailman-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, 10 Nov 2009 02:09:01 -0000 On 2009-11-09, at 4:34 PM, John Panzer wrote: > Counter-argument: The login pages are protected with https, so =20 > their password is protected. One might then ask why HTTPS is not used for all the other activity if =20 it is sensitive. HTTPS is available. Crypto gets cheaper and cheaper =20 with Moore's law. > Their session cookies are sent in clear text but are themselves =20 > encrypted and are refreshed every (say) 10 minutes to minimize =20 > exposure from leakage. A lot of damage could be done in those ten minutes. > The user's data certainly is sent in clear text form and an attacker =20 > can both read it and impersonate the user to send data if they grab =20 > the cookies, at least for 10 minutes. So I got nothin' there. > > (Would bearer token plus a way to securely rotate the token every N =20 > minutes make the OAuth session at least as secure as the above =20 > scenario?) I think so. :-) -- Dick From jpanzer@google.com Mon Nov 9 18:47:24 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92AB13A68CE for ; Mon, 9 Nov 2009 18:47:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[AWL=0.000, 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 idgU+z70ojHa for ; Mon, 9 Nov 2009 18:47:23 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 78CFF3A681B for ; Mon, 9 Nov 2009 18:47:23 -0800 (PST) Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id nAA2llGg022130 for ; Tue, 10 Nov 2009 02:47:48 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1257821268; bh=q64XIX+I7uLktLvA31DT0+rfeW0=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=clCaRVhYK4F7H2ZOi/RbBuWG6Qr7EIaUh6L7qXRsnhxfrrXSNIW2tADNWfgTCOGIY gTyWvgCJogKSg0RE6x/7w== 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=FhcUqHquh9SkvKzJ4SFiNpFJV5jGLqDKUImDF7KT73S/PAABjPk7uFBxDCyGetyUl usPXZLKWoQg10lfnu7nKQ== Received: from pxi33 (pxi33.prod.google.com [10.243.27.33]) by wpaz17.hot.corp.google.com with ESMTP id nAA2lXl9001256 for ; Mon, 9 Nov 2009 18:47:45 -0800 Received: by pxi33 with SMTP id 33so23509pxi.4 for ; Mon, 09 Nov 2009 18:47:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.6.25 with SMTP id 25mr15425391waf.25.1257821265021; Mon, 09 Nov 2009 18:47:45 -0800 (PST) In-Reply-To: <19B1A486-C1F9-4EAF-9DAE-FD886D829236@microsoft.com> References: <90C41DD21FB7C64BB94121FBBC2E72343785078711@P3PW5EX1MB01.EX1.SECURESERVER.NET> <19B1A486-C1F9-4EAF-9DAE-FD886D829236@microsoft.com> From: John Panzer Date: Mon, 9 Nov 2009 18:47:23 -0800 Message-ID: To: Dick Hardt 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] why are we signing? X-BeenThere: oauth@ietf.org X-Mailman-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, 10 Nov 2009 02:47:24 -0000 On Mon, Nov 9, 2009 at 6:09 PM, Dick Hardt wrote= : > > On 2009-11-09, at 4:34 PM, John Panzer wrote: > >> Counter-argument: =A0The login pages are protected with https, so >> their password is protected. > > One might then ask why HTTPS is not used for all the other activity if > it is sensitive. HTTPS is available. Crypto gets cheaper and cheaper > with Moore's law. It would be interesting to see the price differential (for peak traffic/worst case scenario you need to provision for). Imagine that the resource is, say, a 10MB image. > > >> =A0Their session cookies are sent in clear text but are themselves >> encrypted and are refreshed every (say) 10 minutes to minimize >> exposure from leakage. > > A lot of damage could be done in those ten minutes. But much less than can be done if passwords can be collected and used later when the user is asleep, to access arbitrary services (and probably unrelated services because everyone is using the same email-based username and low-security password for everything). > >> The user's data certainly is sent in clear text form and an attacker >> can both read it and impersonate the user to send data if they grab >> the cookies, at least for 10 minutes. =A0So I got nothin' there. >> >> (Would bearer token plus a way to securely rotate the token every N >> minutes make the OAuth session at least as secure as the above >> scenario?) > > I think so. :-) Don't we want that anyway? > > -- Dick > > From Dick.Hardt@microsoft.com Mon Nov 9 19:10:51 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7ED13A686C for ; Mon, 9 Nov 2009 19:10:51 -0800 (PST) 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 qgVSCdoFu4cO for ; Mon, 9 Nov 2009 19:10:50 -0800 (PST) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 901A03A681B for ; Mon, 9 Nov 2009 19:10:50 -0800 (PST) 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; Mon, 9 Nov 2009 19:11:34 -0800 Received: from TK5EX14MBXC102.redmond.corp.microsoft.com ([169.254.2.41]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi; Mon, 9 Nov 2009 19:11:17 -0800 From: Dick Hardt To: John Panzer Thread-Topic: [OAUTH-WG] why are we signing? Thread-Index: AQHKYPpiJlPvjbF+7Eug3PbIB1m6s5Et5jgAgAEXDgCAAAHrAIAAGp4AgAAKmoCAAAargA== Date: Tue, 10 Nov 2009 03:11:15 +0000 Message-ID: <29554EF2-638B-4AE9-947E-CDB12AEAA904@microsoft.com> References: <90C41DD21FB7C64BB94121FBBC2E72343785078711@P3PW5EX1MB01.EX1.SECURESERVER.NET> <19B1A486-C1F9-4EAF-9DAE-FD886D829236@microsoft.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-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] why are we signing? X-BeenThere: oauth@ietf.org X-Mailman-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, 10 Nov 2009 03:10:52 -0000 On 2009-11-09, at 6:47 PM, John Panzer wrote: > On Mon, Nov 9, 2009 at 6:09 PM, Dick Hardt =20 > wrote: >> >> On 2009-11-09, at 4:34 PM, John Panzer wrote: >> >>> Counter-argument: The login pages are protected with https, so >>> their password is protected. >> >> One might then ask why HTTPS is not used for all the other activity =20 >> if >> it is sensitive. HTTPS is available. Crypto gets cheaper and cheaper >> with Moore's law. > > It would be interesting to see the price differential (for peak > traffic/worst case scenario you need to provision for). That would be interesting. > > Imagine that the resource is, say, a 10MB image. Setting up the connection is pretty expensive compared to moving data. > >> >> >>> Their session cookies are sent in clear text but are themselves >>> encrypted and are refreshed every (say) 10 minutes to minimize >>> exposure from leakage. >> >> A lot of damage could be done in those ten minutes. > > But much less than can be done if passwords can be collected and used > later when the user is asleep, to access arbitrary services (and > probably unrelated services because everyone is using the same > email-based username and low-security password for everything). Clearly. Point being that lots of damage can happen in ten minutes. =20 Take Twitter for an example, I can send LOTS of spam to all your =20 followers as direct messages and follow a bunch of people you don't =20 want to follow. I have gotten malware spam from other people's Twitter =20 accounts. > >> >>> The user's data certainly is sent in clear text form and an attacker >>> can both read it and impersonate the user to send data if they grab >>> the cookies, at least for 10 minutes. So I got nothin' there. >>> >>> (Would bearer token plus a way to securely rotate the token every N >>> minutes make the OAuth session at least as secure as the above >>> scenario?) >> >> I think so. :-) > > Don't we want that anyway? Yes. Refreshing the Access Token is a recommendation in WRAP. -- Dick From Dick.Hardt@microsoft.com Mon Nov 9 19:28:17 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C16703A6824 for ; Mon, 9 Nov 2009 19:28:17 -0800 (PST) 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=[AWL=-0.000, 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 XkFLte7u89yt for ; Mon, 9 Nov 2009 19:28:17 -0800 (PST) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id F16673A681B for ; Mon, 9 Nov 2009 19:28:16 -0800 (PST) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 9 Nov 2009 19:29:01 -0800 Received: from TK5EX14MBXC102.redmond.corp.microsoft.com ([169.254.2.41]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi; Mon, 9 Nov 2009 19:28:43 -0800 From: Dick Hardt To: Justin Hart Thread-Topic: [OAUTH-WG] Delegation (token) requests Thread-Index: AQHKYVm7nshVqA9g60KST8Tvjbm8UpEvLzSA Date: Tue, 10 Nov 2009 03:28:41 +0000 Message-ID: <27D25BAF-7A98-40B6-B122-6D1423AFA1F7@microsoft.com> References: <90C41DD21FB7C64BB94121FBBC2E72343784ECD774@P3PW5EX1MB01.EX1.SECURESERVER.NET> 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_27D25BAF7A9840B6B1226D1423AFA1F7microsoftcom_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Delegation (token) 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: Tue, 10 Nov 2009 03:28:17 -0000 --_000_27D25BAF7A9840B6B1226D1423AFA1F7microsoftcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On 2009-11-09, at 8:28 AM, Justin Hart wrote: - Should we require use of HTTPS for token requests? It'd be nice, though for independents, HTTPS can be pricey. I doubt Wordpre= ss or Drupal would be able to promote it for independent self-hosted users = because most wont buy a HTTPS hosting package on their shared hosting site.= I know some sites have been slow to implement much HTTPS because of the h= igh CPU cost of HTTPS sessions, and they're running tight on their current = hardware. Probably best as a SHOULD and not a MUST. I agree with the SHOULD vs MUST. But, that means there needs to be some independently-secure way to exchange= info. How secure do you mean by secure? Unless you duplicate HTTPS functionality,= you will not be as secure. Do we need to be any more secure then what sess= ion cookies in a browser provide? If so, why? -- Dick --_000_27D25BAF7A9840B6B1226D1423AFA1F7microsoftcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <14f038f1-15b9-4638-a7f9-e866a5a3c210> Content-Transfer-Encoding: quoted-printable
On 2009-11-09, at 8:28 = AM, Justin Hart wrote:
 
- Should we require use of HTTPS for token requests?
=

It'd be nice, though for independents, HTTPS can be pricey. I doubt Wordpress or Drupal would be able to promote it for independent self-hosted users because most wont buy a HTTPS hosting package on their shared hosting site.  I know some sites have been slow to implement much HTTPS because of the high CPU cost of HTTPS sessions, and they're running tight on their current hardware.  Probably best as a SHOULD and not a MUST. 

I= agree with the SHOULD vs MUST.

But, that means there needs to be some independently-secure way to exchange info.
How secure do you mean by secure? Unless you duplicate HTT= PS functionality, you will not be as secure. Do we need to be any more secu= re then what session cookies in a browser provide? If so, why?
-- Dick

= --_000_27D25BAF7A9840B6B1226D1423AFA1F7microsoftcom_-- From jpanzer@google.com Mon Nov 9 20:18:18 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 485993A6822 for ; Mon, 9 Nov 2009 20:18:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[AWL=0.000, 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 2e2slUvW0jOm for ; Mon, 9 Nov 2009 20:18:17 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 0AA753A67BD for ; Mon, 9 Nov 2009 20:18:16 -0800 (PST) Received: from spaceape11.eur.corp.google.com (spaceape11.eur.corp.google.com [172.28.16.145]) by smtp-out.google.com with ESMTP id nAA4If1G028634 for ; Tue, 10 Nov 2009 04:18:41 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1257826721; bh=vY6/rlK1Drt0WiymynTnSfAqNUM=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=YqM4Am6vKWNXaAb7cw8TgMq7szlvoYdXx+1nBFmWBG2P3LolJTbcTzeZolTNNB96u jaPYqZPdpR1xWdIez1ahQ== 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=iEHVLdkX+7hvf5j1qKe/lc5kqOurdDottdqRu+8CR1QhLB9vfvVHEJYqwyqeEiFll regBLecEHnNo0gWmj4noA== Received: from pxi15 (pxi15.prod.google.com [10.243.27.15]) by spaceape11.eur.corp.google.com with ESMTP id nAA4Ic7Z005729 for ; Mon, 9 Nov 2009 20:18:39 -0800 Received: by pxi15 with SMTP id 15so2602300pxi.23 for ; Mon, 09 Nov 2009 20:18:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.115.66.10 with SMTP id t10mr1719804wak.20.1257826713147; Mon, 09 Nov 2009 20:18:33 -0800 (PST) In-Reply-To: References: From: John Panzer Date: Mon, 9 Nov 2009 20:18:13 -0800 Message-ID: To: Brian Eaton 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] why are we signing? X-BeenThere: oauth@ietf.org X-Mailman-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, 10 Nov 2009 04:18:18 -0000 My $.02 for what it's worth: #1 is sufficient, if there is a standard mechanism to also handle access token timeout+renewal, because then OAuth is at least as secure as existing cookie based mechanisms. #1 may well be sufficient even without that proviso, assuming TLS is widely deployable, scalable, and Ben Laurie doesn't blog about more vulnerabilities next week (kidding!) (Note that nothing stops someone from doing their own encryption of user data using some other mechanism, if they really need to do so; OAuth just wouldn't standardize this.) -- John Panzer / Google jpanzer@google.com / abstractioneer.org / @jpanzer On Sun, Nov 8, 2009 at 9:02 PM, Brian Eaton wrote: > Hey folks - > > What are the use cases for cryptography in OAuth? =A0Why are we signing > requests? =A0And how much of each request do we need to sign in order to > be useful? > > As I see it, we have roughly the following menu of choices: > > 1) No signatures. > =A0 =A0Just use bearer tokens. =A0Use transport layer encryption to keep > those bearer tokens from leaking. > > 2) Signed tokens. > =A0 =A0We could just sign a timestamp, rather than entire messages. > > 3) Partially signed messages. > =A0 =A0We could sign just the request URL, or the request URL plus some p= arameters. > > 4) Fully signed messages. > =A0 =A0 Sign as much of the HTTP request as possible, down to the bits of > the HTTP entity body. > > My guess is we need at least two out of those four choices (one with > bearer tokens, a la OAuth 1.0 plaintext) and another with > cryptography. =A0But I'm not sure whether we need to sign entire > messages, or if we can get away with something simpler and still have > reasonable security. > > Cheers, > Brian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From jonathan_moore@comcast.com Mon Nov 9 20:36:26 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D2633A6820 for ; Mon, 9 Nov 2009 20:36:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.463 X-Spam-Level: X-Spam-Status: No, score=-8.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, 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 2QmBg4AXIKuO for ; Mon, 9 Nov 2009 20:36:24 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 65C173A680F for ; Mon, 9 Nov 2009 20:36:24 -0800 (PST) Received: from ([10.52.116.30]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.60218675; Mon, 09 Nov 2009 23:36:48 -0500 Received: from PACORPEXCMB03.cable.comcast.com ([24.40.15.85]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 23:36:48 -0500 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: Mon, 9 Nov 2009 23:36:48 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] comments on draft-hammer-oauth-03 Thread-Index: AcphigUd3nOpOpWCTPqrjpPzcGs23gANHuZ5 References: <4AF8943E.4050802@stpeter.im> From: "Moore, Jonathan (CIM)" To: "Peter Saint-Andre" , "OAuth WG" X-OriginalArrivalTime: 10 Nov 2009 04:36:48.0981 (UTC) FILETIME=[6AAC6050:01CA61BF] Subject: Re: [OAUTH-WG] comments on draft-hammer-oauth-03 X-BeenThere: oauth@ietf.org X-Mailman-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, 10 Nov 2009 04:36:26 -0000 Peter Saint-Andre wrote: > 11. In Section 3.3.4, we say that PLAINTEXT method SHOULD be used with > SSL/TLS. Does that deserve to be a MUST? At least it might be worth a > mention in the Security Considerations. RFC2119 says "MUST" should be reserved for cases where it is required = for interoperability (which I think isn't the case here) or where it = might cause harm (maybe this is true here?), and that an implementer may = only ignore a "SHOULD" at his/her peril (which is for sure the case = here). I agree this is worth calling out the specific risks of ignoring this if = we leave it as a SHOULD, though.=20 Maybe we can say "REALLY REALLY SHOULD (NO I MEAN IT)"? :) Jon ........ Jon Moore Comcast Interactive Media -----Original Message----- From: oauth-bounces@ietf.org on behalf of Peter Saint-Andre Sent: Mon 11/9/2009 5:14 PM To: OAuth WG Subject: [OAUTH-WG] comments on draft-hammer-oauth-03 =20 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On the flight to Japan for IETF 76, I finally got a chance to finish reviewing draft-hammer-oauth-03, the informational documentation of what's known as "OAUth Core 1.0 Revision A" in the community. Many of my comments are purely editorial, so I will send those directly to the document editor. Here are a few slightly more substantive issues... 1. I think it would be very helpful to provide a bit more context in the Introduction. Say, two or three sentences about the provenance of this technology, the community that developed it, and a link to oauth.net (along with something like the final paragraph of the current Introduction). Something like this: The OAuth protocol was originally created by a loose group of technologists from a variety of websites and other Internet services, who wanted to solve the common problem of enabling delegated access to protected resources. The resulting OAuth protocol was stabilized at version 1.0 in October 2007 and published at the oauth.net website. This specification provides informational documentation of OAuth Core 1.0 Revision A as finalized in June 2009, incorporating several errata reported since that time as well as numerous editorial clarifications. It is not an item of the IETF's OAuth Working Group, which at the time of writing is working on an OAuth version that can be appropriate for publication on the standards track. 2. In the Terminology section, I think it might be helpful to provide pointers to the old terminology, as in: "(In the community edition, a client was called a consumer.)" We might also want to point to RFC 4949 regarding terminology and check that our usage of key terms like "authorization" is consistent with that document. 3. Before jumping right into authenticated requests in section 3, I think it would be helpful to provide a bit more context about the overall protocol flow (similar to Section 6 of the community edition). 4. In Section 3.1, we might want to say explicitly which parameters are required and which are not. For example, "Protocol parameters MUST NOT appear more than once per request. The following parameters are REQUIRED unless otherwise noted." Then say that, for example, oauth_version is RECOMMENDED instead of REQUIRED (or whatever). 5. In Section 3.2, it's not completely clear that the timestamp value must be numerical instead of, say, in ISO 8601 format. It's also not clear how the server would specify that the timestamp is something other than "the number of seconds since January 1, 1970 00:00:00 GMT". 6. In Section 3.2, let's explicitly say that methods that enable the client to sync its clock with the server's clock are out of scope for = OAuth. 7. In Section 3.3, let's refer to the Security Considerations from the paragraph about not mandating a particular signature method (since that's where we talk about the properties of various methods). 8. In Section 3.3.1.1, we might want to be more explicit about which parameters are included in the "specific set of request parameters" (see recent discussion on the community list). 9. In Section 3.3.1.1 second bullet point, we say "The HTTP request entity-body, but only if..." -- does this mean that all of the three listed conditions need to be met, or any one of the conditions? 10. In Section 3.3.1.1, the sentence The "oauth_signature" parameter MUST be excluded if present. might be taken to imply that all other oauth_* parameters MUST be included (if found in the request). Let's be explicit about that. 11. In Section 3.3.4, we say that PLAINTEXT method SHOULD be used with SSL/TLS. Does that deserve to be a MUST? At least it might be worth a mention in the Security Considerations. 12. In Section 3.6, we say that "Text values are first encoded as UTF-8" but it's not fully clear to me which values this applies to or exactly where in the protocol the encoding rules are applied. 13. In Section 4, I think that a brief flow diagram would be helpful to illustrate the authorization process (e.g., this would provide context for why the client obtains a set of temporary credentials, which might not otherwise be obivous to first-time readers of Section 4.1). 14. In Section 4.2 (or in a security consideration pointed to from Section 4.2), it might be helpful to describe why oauth_callback is important and the nature of the session fixation attach that it helps to prevent. 15. In Section 6.8, I think there is a non-sequitur. Just because a client is a freely available desktop application does not mean that an attacker will be able to recover the client credentials. Perhaps one step in the chain of reasoning is not spelled out here? 16. Section 6.15 says: Clients should prevent CSRF attacks on OAuth callback URIs by verifying that the resource owner at the client site intended to complete the OAuth negotiation with the server. No guidance is provided on how the client might be able to do so. Saying that "methods for doing so are out of scope for this specification" is probably acceptable. 17. In Appendix A.1 the phrase "HTTPS POST" is used, but I think that's more accurately an HTTP POST to an SSL-protected host. Overall the spec looks very good, and IMHO is a big improvement over the community edition! Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkr4lD0ACgkQNL8k5A2w/vzkJwCfeOy6ZH1u8La20llLhgksyb4T mOYAoPrGjaVIL9w801IuguP3161i2X0/ =3DtN+p -----END PGP SIGNATURE----- _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From beaton@google.com Mon Nov 9 21:58:06 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0590C28C112 for ; Mon, 9 Nov 2009 21:58:06 -0800 (PST) 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 KpMB2zn4WNfD for ; Mon, 9 Nov 2009 21:58:05 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id 24E9728C10D for ; Mon, 9 Nov 2009 21:58:05 -0800 (PST) Received: from wpaz21.hot.corp.google.com (wpaz21.hot.corp.google.com [172.24.198.85]) by smtp-out.google.com with ESMTP id nAA5wV4m022973 for ; Mon, 9 Nov 2009 21:58:31 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1257832712; bh=qlX6/5OR6ZMLNKvSkx6I7fsqawU=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=EmqCFrrdRPTHMlI6NlBcnHlBRhETxCyKdcCLL0oI0jj9dA8pFOB7r4IYK0RPwaYly S2NNXuA/GdR7mpI4pY/eQ== 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=IA1hIdDipEdYUsO1EqpwLJ2KPDRc1HhCfB+r0CIFYYJw1QtZnsLtcXOdIAYPeqtq4 QOEz/ZVpUTCebXY9iO5ZA== Received: from pwj12 (pwj12.prod.google.com [10.241.219.76]) by wpaz21.hot.corp.google.com with ESMTP id nAA5wSd4023533 for ; Mon, 9 Nov 2009 21:58:29 -0800 Received: by pwj12 with SMTP id 12so1106748pwj.7 for ; Mon, 09 Nov 2009 21:58:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.226.14 with SMTP id y14mr473873rvg.8.1257832708431; Mon, 09 Nov 2009 21:58:28 -0800 (PST) In-Reply-To: <35D50F5C-3982-4298-A9E0-86A528F5C5D3@jkemp.net> References: <35D50F5C-3982-4298-A9E0-86A528F5C5D3@jkemp.net> Date: Mon, 9 Nov 2009 21:58:28 -0800 Message-ID: From: Brian Eaton To: John Kemp Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] why are we signing? X-BeenThere: oauth@ietf.org X-Mailman-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, 10 Nov 2009 05:58:06 -0000 On Mon, Nov 9, 2009 at 6:28 AM, John Kemp wrote: > If we are only interested in i) [authenticating the entity] then signing any piece of the message might > be sufficient. If we are interested in ii) [binding the signature to the message] (or some other security property) > then we will need to identify which pieces of the message we want to provide > that, or other, security properties for. OK, let me try to summarize what I've heard on this thread about the different use-cases for message signing: - sign the HTTP request Used to prevent MITM from replaying token to a different URL. Also limits the replay attack window to minutes instead of hours. - sign various other parts of the message DKIM: signs various message headers SIP: unspecified, just says "relevant parts of SIP request" XMPP: signs from, to, and purpose of message (roughly) OpenSocial: signs identity parameters Simple Web Tokens: signs identity parameters XMPP and OpenSocial both needed to invent their own signature base string logic in order to reuse OAuth, and I strongly suspect that the SIP folks will need to do the same. Several of those applications involve legitimate proxies that legitimately munge certain parts of the message, and are supposed to leave other parts untouched. Cheers, Brian From Dick.Hardt@microsoft.com Tue Nov 10 09:51:39 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6242A3A68C3 for ; Tue, 10 Nov 2009 09:51:39 -0800 (PST) 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=[AWL=0.000, 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 dyZRBtgw72OG for ; Tue, 10 Nov 2009 09:51:38 -0800 (PST) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id A2D883A680A for ; Tue, 10 Nov 2009 09:51:38 -0800 (PST) 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; Tue, 10 Nov 2009 09:52:05 -0800 Received: from TK5EX14MBXC102.redmond.corp.microsoft.com ([169.254.2.41]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi; Tue, 10 Nov 2009 09:52:05 -0800 From: Dick Hardt To: "oauth@ietf.org" Thread-Topic: OAuth WRAP Thread-Index: AQHKYi6Ew4AMoanf1ECw2Uf1Xwo7Hw== Date: Tue, 10 Nov 2009 17:52:04 +0000 Message-ID: References: <35D50F5C-3982-4298-A9E0-86A528F5C5D3@jkemp.net> 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-ID: <2cec8228-96af-440b-9ce6-3dc54862990d> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OAUTH-WG] OAuth WRAP X-BeenThere: oauth@ietf.org X-Mailman-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, 10 Nov 2009 17:51:39 -0000 At IIW last week, myself, Biran Eaton from Google and Allen Tom from =20 Yahoo! presented what is now called OAuth WRAP The specs and discussion specific to those documents is at: http://groups.google.com/group/oauth-wrap-wg We plan to submit the document as an I-D next week when I-D submission =20 is open again, and for further work to occur in the IETF OAuth WG. -- Dick From email@pbryan.net Tue Nov 10 10:05:40 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 195CD3A6A33 for ; Tue, 10 Nov 2009 10:05:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 OJ9RGXM4m1JS for ; Tue, 10 Nov 2009 10:05:39 -0800 (PST) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by core3.amsl.com (Postfix) with ESMTP id 590A23A6781 for ; Tue, 10 Nov 2009 10:05:39 -0800 (PST) Received: from [192.168.0.4] (S010600095baae0ff.vf.shawcable.net [174.1.50.199]) by maple.anode.ca (Postfix) with ESMTPSA id 714986154 for ; Tue, 10 Nov 2009 18:06:06 +0000 (UTC) From: "Paul C. Bryan" To: "oauth@ietf.org" In-Reply-To: References: <35D50F5C-3982-4298-A9E0-86A528F5C5D3@jkemp.net> Content-Type: text/plain Date: Tue, 10 Nov 2009 10:06:04 -0800 Message-Id: <1257876364.4540.265.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 7bit Subject: Re: [OAUTH-WG] OAuth WRAP X-BeenThere: oauth@ietf.org X-Mailman-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, 10 Nov 2009 18:05:40 -0000 Hi Dick: Given that WRAP is so different from OAuth (as I know it), other than the fact that OAuth could be used to negotiate the issuance of a WRAP refresh token, I'm curious why you chose to associate this with OAuth by giving it an "OAuth" prefix. It seems to me that it would only create confusion in this space. Paul On Tue, 2009-11-10 at 17:52 +0000, Dick Hardt wrote: > At IIW last week, myself, Biran Eaton from Google and Allen Tom from > Yahoo! presented what is now called OAuth WRAP > > The specs and discussion specific to those documents is at: > > http://groups.google.com/group/oauth-wrap-wg > > We plan to submit the document as an I-D next week when I-D submission > is open again, and for further work to occur in the IETF OAuth WG. > > -- Dick > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From infinity@lindenlab.com Tue Nov 10 11:16:23 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CA373A6983 for ; Tue, 10 Nov 2009 11:16:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.552 X-Spam-Level: X-Spam-Status: No, score=-1.552 tagged_above=-999 required=5 tests=[AWL=0.424, 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 FfLwTReLdhEQ for ; Tue, 10 Nov 2009 11:16:22 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 5C8773A692E for ; Tue, 10 Nov 2009 11:16:22 -0800 (PST) Received: by bwz23 with SMTP id 23so370274bwz.29 for ; Tue, 10 Nov 2009 11:16:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.239.184.157 with SMTP id y29mr49194hbg.54.1257880605234; Tue, 10 Nov 2009 11:16:45 -0800 (PST) In-Reply-To: <1257876364.4540.265.camel@localhost> References: <35D50F5C-3982-4298-A9E0-86A528F5C5D3@jkemp.net> <1257876364.4540.265.camel@localhost> From: "Infinity Linden (Meadhbh Hamrick)" Date: Tue, 10 Nov 2009 11:16:25 -0800 Message-ID: <3a880e2c0911101116h1f124875vac03b23d251fa4f@mail.gmail.com> To: "Paul C. Bryan" Content-Type: multipart/alternative; boundary=001485f79366a5185e047809267c Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth WRAP X-BeenThere: oauth@ietf.org X-Mailman-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, 10 Nov 2009 19:16:23 -0000 --001485f79366a5185e047809267c Content-Type: text/plain; charset=ISO-8859-1 and just to make things vaguely more confusing, some of us are working on the Virtual Worlds Region Agent Protocol (VWRAP) which makes use of OAuth. so it's possible you might see someone discussing a use case of OAuth related to VWRAP. please note it's not a typo. there really is a VWRAP. -cheers -meadhbh -- infinity linden (aka meadhbh hamrick) * it's pronounced "maeve" http://wiki.secondlife.com/wiki/User:Infinity_Linden On Tue, Nov 10, 2009 at 10:06, Paul C. Bryan wrote: > Hi Dick: > > Given that WRAP is so different from OAuth (as I know it), other than > the fact that OAuth could be used to negotiate the issuance of a WRAP > refresh token, I'm curious why you chose to associate this with OAuth by > giving it an "OAuth" prefix. It seems to me that it would only create > confusion in this space. > > Paul > > On Tue, 2009-11-10 at 17:52 +0000, Dick Hardt wrote: > > At IIW last week, myself, Biran Eaton from Google and Allen Tom from > > Yahoo! presented what is now called OAuth WRAP > > > > The specs and discussion specific to those documents is at: > > > > http://groups.google.com/group/oauth-wrap-wg > > > > We plan to submit the document as an I-D next week when I-D submission > > is open again, and for further work to occur in the IETF OAuth WG. > > > > -- 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 > --001485f79366a5185e047809267c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable and just to make things vaguely more confusing, some of us are working on t= he Virtual Worlds Region Agent Protocol (VWRAP) which makes use of OAuth. s= o it's possible you might see someone discussing a use case of OAuth re= lated to VWRAP. please note it's not a typo. there really is a VWRAP.
-cheers
-meadhbh
--
=A0 infin= ity linden (aka meadhbh hamrick) =A0* =A0it's pronounced "maeve&qu= ot;
=A0 =A0 =A0 =A0 http://wiki.secondlife.com/wiki/User:Infinity_Linden


On Tue, Nov 10, 2009 at 10:06, Paul C. B= ryan <email@pbryan= .net> wrote:
Hi Dick:

Given that WRAP is so different from OAuth (as I know it), other than
the fact that OAuth could be used to negotiate the issuance of a WRAP
refresh token, I'm curious why you chose to associate this with OAuth b= y
giving it an "OAuth" prefix. It seems to me that it would only cr= eate
confusion in this space.

Paul

On Tue, 2009-11-10 at 17:52 +0000, Dick Hardt wrote:
> At IIW last week, myself, Biran Eaton from Google and Allen Tom from > Yahoo! presented what is now called OAuth WRAP
>
> The specs and discussion specific to those documents is at:
>
> =A0 =A0 =A0 http://groups.google.com/group/oauth-wrap-wg
>
> We plan to submit the document as an I-D next week when I-D submission=
> is open again, and for further work to occur in the IETF OAuth WG.
>
> -- Dick
> _______________________________________________
> 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

--001485f79366a5185e047809267c-- From jpanzer@google.com Tue Nov 10 11:36:11 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 713B828C215 for ; Tue, 10 Nov 2009 11:36:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 Khr4WmJffhpv for ; Tue, 10 Nov 2009 11:36:10 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id 5EBB128C21B for ; Tue, 10 Nov 2009 11:36:10 -0800 (PST) Received: from wpaz21.hot.corp.google.com (wpaz21.hot.corp.google.com [172.24.198.85]) by smtp-out.google.com with ESMTP id nAAJabCw010872 for ; Tue, 10 Nov 2009 11:36:37 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1257881797; bh=DGHwkKz8W32ZGw5i3hZvheoKGds=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=L9o4lbWHm4w+nr7pjtn2m/t6V+8yKHp1Q0dwK/K3No9+OEFEEQuwrS0p88oTvxmSA RrmFuJ27s+kST46MCZAYQ== 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=kCA/LzN6ja7pEOODrNQA3MOnQYtJ62behxRTb3uBfKGYtlPAS22fVt93LJF2QCrVL QuKiNE1x8rjRLMsv/nj7Q== Received: from pzk3 (pzk3.prod.google.com [10.243.19.131]) by wpaz21.hot.corp.google.com with ESMTP id nAAJaXuX016004 for ; Tue, 10 Nov 2009 11:36:34 -0800 Received: by pzk3 with SMTP id 3so212793pzk.20 for ; Tue, 10 Nov 2009 11:36:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.252.2 with SMTP id z2mr890881wah.156.1257881793106; Tue, 10 Nov 2009 11:36:33 -0800 (PST) In-Reply-To: <1257876364.4540.265.camel@localhost> References: <35D50F5C-3982-4298-A9E0-86A528F5C5D3@jkemp.net> <1257876364.4540.265.camel@localhost> From: John Panzer Date: Tue, 10 Nov 2009 11:36:13 -0800 Message-ID: To: "Paul C. Bryan" Content-Type: multipart/alternative; boundary=0016e68786457294250478096d93 X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth WRAP X-BeenThere: oauth@ietf.org X-Mailman-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, 10 Nov 2009 19:36:11 -0000 --0016e68786457294250478096d93 Content-Type: text/plain; charset=ISO-8859-1 My personal hope is that these can be merged, as they address nearly the same use cases. WRAP is described differently from OAuth but my understanding is that it's possible do do a nearly 1:1 mapping between the two by picking appropriate options in OAuth and perhaps defining some things left undefined by the OAuth base spec. -- John Panzer / Google jpanzer@google.com / abstractioneer.org / @jpanzer On Tue, Nov 10, 2009 at 10:06 AM, Paul C. Bryan wrote: > Hi Dick: > > Given that WRAP is so different from OAuth (as I know it), other than > the fact that OAuth could be used to negotiate the issuance of a WRAP > refresh token, I'm curious why you chose to associate this with OAuth by > giving it an "OAuth" prefix. It seems to me that it would only create > confusion in this space. > > Paul > > On Tue, 2009-11-10 at 17:52 +0000, Dick Hardt wrote: > > At IIW last week, myself, Biran Eaton from Google and Allen Tom from > > Yahoo! presented what is now called OAuth WRAP > > > > The specs and discussion specific to those documents is at: > > > > http://groups.google.com/group/oauth-wrap-wg > > > > We plan to submit the document as an I-D next week when I-D submission > > is open again, and for further work to occur in the IETF OAuth WG. > > > > -- 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 > --0016e68786457294250478096d93 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable My personal hope is that these can be merged, as they address nearly the sa= me use cases. =A0WRAP is described differently from OAuth but my understand= ing is that it's possible do do a nearly 1:1 mapping between the two by= picking appropriate options in OAuth and perhaps defining some things left= undefined by the OAuth base spec.
--
John Panzer / Google
jpanzer= @google.com / abstractioneer.org<= /a> / @jpanzer



On Tue, Nov 10, 2009 at 10:06 AM, Paul C= . Bryan <email@pbr= yan.net> wrote:
Hi Dick:

Given that WRAP is so different from OAuth (as I know it), other than
the fact that OAuth could be used to negotiate the issuance of a WRAP
refresh token, I'm curious why you chose to associate this with OAuth b= y
giving it an "OAuth" prefix. It seems to me that it would only cr= eate
confusion in this space.

Paul

On Tue, 2009-11-10 at 17:52 +0000, Dick Hardt wrote:
> At IIW last week, myself, Biran Eaton from Google and Allen Tom from > Yahoo! presented what is now called OAuth WRAP
>
> The specs and discussion specific to those documents is at:
>
> =A0 =A0 =A0 http://groups.google.com/group/oauth-wrap-wg
>
> We plan to submit the document as an I-D next week when I-D submission=
> is open again, and for further work to occur in the IETF OAuth WG.
>
> -- Dick
> _______________________________________________
> 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

--0016e68786457294250478096d93-- From Dick.Hardt@microsoft.com Tue Nov 10 11:46:24 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7AFA3A6986 for ; Tue, 10 Nov 2009 11:46:24 -0800 (PST) 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=[AWL=0.000, 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 Y5NzwEuS7hU1 for ; Tue, 10 Nov 2009 11:46:23 -0800 (PST) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id A3F733A67A8 for ; Tue, 10 Nov 2009 11:46:23 -0800 (PST) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 10 Nov 2009 11:47:08 -0800 Received: from TK5EX14MBXC102.redmond.corp.microsoft.com ([169.254.2.41]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi; Tue, 10 Nov 2009 11:46:50 -0800 From: Dick Hardt To: "Paul C. Bryan" Thread-Topic: [OAUTH-WG] OAuth WRAP Thread-Index: AQHKYjCMNId7fTrAxUCo8Lgn0/Mr95EwPsoA Date: Tue, 10 Nov 2009 19:46:44 +0000 Message-ID: <498C2598-B473-4FE6-A975-A0CF87D03F5E@microsoft.com> References: <35D50F5C-3982-4298-A9E0-86A528F5C5D3@jkemp.net> <1257876364.4540.265.camel@localhost> In-Reply-To: <1257876364.4540.265.camel@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <6e37c324-009f-48ab-be12-31bb248ced51> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth WRAP X-BeenThere: oauth@ietf.org X-Mailman-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, 10 Nov 2009 19:46:24 -0000 Good question. Given the positive reception WRAP received at IIW and =20 that capabilities in WRAP are expected to come out of the work in the =20 IETF OAuth WG, there was consensus from the OAuth community to include =20 WRAP as OAuth profiles. -- Dick On 2009-11-10, at 10:06 AM, "Paul C. Bryan" wrote: > Hi Dick: > > Given that WRAP is so different from OAuth (as I know it), other than > the fact that OAuth could be used to negotiate the issuance of a WRAP > refresh token, I'm curious why you chose to associate this with =20 > OAuth by > giving it an "OAuth" prefix. It seems to me that it would only create > confusion in this space. > > Paul > > On Tue, 2009-11-10 at 17:52 +0000, Dick Hardt wrote: >> At IIW last week, myself, Biran Eaton from Google and Allen Tom from >> Yahoo! presented what is now called OAuth WRAP >> >> The specs and discussion specific to those documents is at: >> >> http://groups.google.com/group/oauth-wrap-wg >> >> We plan to submit the document as an I-D next week when I-D =20 >> submission >> is open again, and for further work to occur in the IETF OAuth WG. >> >> -- 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 email@pbryan.net Tue Nov 10 11:56:33 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B37628C110 for ; Tue, 10 Nov 2009 11:56:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 Kfa6MQTG7ymh for ; Tue, 10 Nov 2009 11:56:32 -0800 (PST) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by core3.amsl.com (Postfix) with ESMTP id 9948328C0F9 for ; Tue, 10 Nov 2009 11:56:32 -0800 (PST) Received: from [192.168.0.4] (S010600095baae0ff.vf.shawcable.net [174.1.50.199]) by maple.anode.ca (Postfix) with ESMTPSA id BBB47EA022 for ; Tue, 10 Nov 2009 19:56:59 +0000 (UTC) From: "Paul C. Bryan" To: "oauth@ietf.org" In-Reply-To: <498C2598-B473-4FE6-A975-A0CF87D03F5E@microsoft.com> References: <35D50F5C-3982-4298-A9E0-86A528F5C5D3@jkemp.net> <1257876364.4540.265.camel@localhost> <498C2598-B473-4FE6-A975-A0CF87D03F5E@microsoft.com> Content-Type: text/plain Date: Tue, 10 Nov 2009 11:56:57 -0800 Message-Id: <1257883017.10242.5.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 7bit Subject: Re: [OAUTH-WG] OAuth WRAP X-BeenThere: oauth@ietf.org X-Mailman-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, 10 Nov 2009 19:56:33 -0000 I guess I must admit I'm a bit surprised that the general consensus would be to merge with/profile WRAP as OAuth, as the deltas between the two protocols as defined seems quite substantial. Does this mean that for all intents and purposes I should consider the existing OAuth IETF drafts to date to be deprecated in favour of WRAP? Paul On Tue, 2009-11-10 at 19:46 +0000, Dick Hardt wrote: > Good question. Given the positive reception WRAP received at IIW and > that capabilities in WRAP are expected to come out of the work in the > IETF OAuth WG, there was consensus from the OAuth community to include > WRAP as OAuth profiles. > > -- Dick > > On 2009-11-10, at 10:06 AM, "Paul C. Bryan" wrote: > > > Hi Dick: > > > > Given that WRAP is so different from OAuth (as I know it), other than > > the fact that OAuth could be used to negotiate the issuance of a WRAP > > refresh token, I'm curious why you chose to associate this with > > OAuth by > > giving it an "OAuth" prefix. It seems to me that it would only create > > confusion in this space. > > > > Paul > > > > On Tue, 2009-11-10 at 17:52 +0000, Dick Hardt wrote: > >> At IIW last week, myself, Biran Eaton from Google and Allen Tom from > >> Yahoo! presented what is now called OAuth WRAP > >> > >> The specs and discussion specific to those documents is at: > >> > >> http://groups.google.com/group/oauth-wrap-wg > >> > >> We plan to submit the document as an I-D next week when I-D > >> submission > >> is open again, and for further work to occur in the IETF OAuth WG. > >> > >> -- 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 Dick.Hardt@microsoft.com Tue Nov 10 12:10:58 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25AC73A6992 for ; Tue, 10 Nov 2009 12:10:58 -0800 (PST) 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=[AWL=0.000, 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 fn8BanLHy2AV for ; Tue, 10 Nov 2009 12:10:57 -0800 (PST) Received: from smtp.microsoft.com (mail1.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id ED99C3A68FC for ; Tue, 10 Nov 2009 12:10:56 -0800 (PST) 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; Tue, 10 Nov 2009 12:11:41 -0800 Received: from TK5EX14MBXC102.redmond.corp.microsoft.com ([169.254.2.41]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi; Tue, 10 Nov 2009 12:10:52 -0800 From: Dick Hardt To: "Paul C. Bryan" Thread-Topic: [OAUTH-WG] OAuth WRAP Thread-Index: AQHKYjCMNId7fTrAxUCo8Lgn0/Mr95EwPsoAgAAC24CAAAPcAA== Date: Tue, 10 Nov 2009 20:10:46 +0000 Message-ID: <9E31CF19-93AE-4010-B846-ACE700A2798D@microsoft.com> References: <35D50F5C-3982-4298-A9E0-86A528F5C5D3@jkemp.net> <1257876364.4540.265.camel@localhost> <498C2598-B473-4FE6-A975-A0CF87D03F5E@microsoft.com> <1257883017.10242.5.camel@localhost> In-Reply-To: <1257883017.10242.5.camel@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <128e4253-33d9-4f8b-b098-f7b5e9f79a27> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth WRAP X-BeenThere: oauth@ietf.org X-Mailman-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, 10 Nov 2009 20:10:58 -0000 Eran has stated that the upcoming drafts will have the capabilities in =20 OAuth WRAP. Hopefully the Dpec provides a basis for useful dialog for =20 those attending the BoF later this week in Hiroshima. -- Dick On 2009-11-10, at 11:57 AM, "Paul C. Bryan" wrote: > I guess I must admit I'm a bit surprised that the general consensus > would be to merge with/profile WRAP as OAuth, as the deltas between =20 > the > two protocols as defined seems quite substantial. Does this mean that > for all intents and purposes I should consider the existing OAuth IETF > drafts to date to be deprecated in favour of WRAP? > > Paul > > On Tue, 2009-11-10 at 19:46 +0000, Dick Hardt wrote: >> Good question. Given the positive reception WRAP received at IIW and >> that capabilities in WRAP are expected to come out of the work in the >> IETF OAuth WG, there was consensus from the OAuth community to =20 >> include >> WRAP as OAuth profiles. >> >> -- Dick >> >> On 2009-11-10, at 10:06 AM, "Paul C. Bryan" wrote: >> >>> Hi Dick: >>> >>> Given that WRAP is so different from OAuth (as I know it), other =20 >>> than >>> the fact that OAuth could be used to negotiate the issuance of a =20 >>> WRAP >>> refresh token, I'm curious why you chose to associate this with >>> OAuth by >>> giving it an "OAuth" prefix. It seems to me that it would only =20 >>> create >>> confusion in this space. >>> >>> Paul >>> >>> On Tue, 2009-11-10 at 17:52 +0000, Dick Hardt wrote: >>>> At IIW last week, myself, Biran Eaton from Google and Allen Tom =20 >>>> from >>>> Yahoo! presented what is now called OAuth WRAP >>>> >>>> The specs and discussion specific to those documents is at: >>>> >>>> http://groups.google.com/group/oauth-wrap-wg >>>> >>>> We plan to submit the document as an I-D next week when I-D >>>> submission >>>> is open again, and for further work to occur in the IETF OAuth WG. >>>> >>>> -- 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 >>> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From eran@hueniverse.com Tue Nov 10 13:16:11 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 902E03A6832 for ; Tue, 10 Nov 2009 13:16:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.050, 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 8QIj0PXgSwE9 for ; Tue, 10 Nov 2009 13:16:04 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 7F0863A6964 for ; Tue, 10 Nov 2009 13:16:04 -0800 (PST) Received: (qmail 1494 invoked from network); 10 Nov 2009 21:16:28 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 10 Nov 2009 21:16:28 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Tue, 10 Nov 2009 14:16:24 -0700 From: Eran Hammer-Lahav To: "Paul C. Bryan" , "oauth@ietf.org" Date: Tue, 10 Nov 2009 14:16:23 -0700 Thread-Topic: [OAUTH-WG] OAuth WRAP Thread-Index: AcpiP/mtzwZ5h1wATZ2P8INHK1xq+gACxRPM Message-ID: In-Reply-To: <1257883017.10242.5.camel@localhost> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C71F182728808eranhueniversecom_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] OAuth WRAP X-BeenThere: oauth@ietf.org X-Mailman-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, 10 Nov 2009 21:16:11 -0000 --_000_C71F182728808eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable My 2c: WRAP was developed out of necessity due to limitations in OAuth and product= release schedule. Without going into too much detail about whether a whole= new protocol was really necessary, the WRAP authors felt that it was, and = that their timeline could not accommodate waiting for the OAUTH WG to accom= modate their use cases in the new version of the spec. We now have a new an= d separate spec in the space. I have encouraged the authors to submit their spec as input for the WG and = to collaborate to make the upcoming WG spec cover their use case. The goal = would be to render the separate WRAP spec unnecessary. How they or others w= ould choose to apply this to their implementation is beyond my control or (= TBH) interest. Most of the innovative ideas in WRAP are around the delegation flow (and th= ere are some good ideas in there). I plan to use some of that as the basis = for the new delegation spec. On the authentication side, WRAP uses bearer t= oken with no crypto which will be supported by the PLAIN flavor. As for how to manage community expectations, the OAuth brand, etc.: I was o= pposed to putting WRAP under the OAuth brand (the entire effort started as = "Simple OAuth"). Others felt that pretending WRAP was an OAuth profile (it = is not) and naming it as such would be less confusing or less damaging to t= he OAuth brand (if you call it the same thing, there is no competition). I = didn't care enough to (continue) that argument given my view that by the ti= me WRAP will get the wide attention OAuth has, this WG will produce stable = drafts of the new OAuth and will make this irrelevant. EHL On 11/10/09 11:56 AM, "Paul C. Bryan" wrote: I guess I must admit I'm a bit surprised that the general consensus would be to merge with/profile WRAP as OAuth, as the deltas between the two protocols as defined seems quite substantial. Does this mean that for all intents and purposes I should consider the existing OAuth IETF drafts to date to be deprecated in favour of WRAP? Paul On Tue, 2009-11-10 at 19:46 +0000, Dick Hardt wrote: > Good question. Given the positive reception WRAP received at IIW and > that capabilities in WRAP are expected to come out of the work in the > IETF OAuth WG, there was consensus from the OAuth community to include > WRAP as OAuth profiles. > > -- Dick > > On 2009-11-10, at 10:06 AM, "Paul C. Bryan" wrote: > > > Hi Dick: > > > > Given that WRAP is so different from OAuth (as I know it), other than > > the fact that OAuth could be used to negotiate the issuance of a WRAP > > refresh token, I'm curious why you chose to associate this with > > OAuth by > > giving it an "OAuth" prefix. It seems to me that it would only create > > confusion in this space. > > > > Paul > > > > On Tue, 2009-11-10 at 17:52 +0000, Dick Hardt wrote: > >> At IIW last week, myself, Biran Eaton from Google and Allen Tom from > >> Yahoo! presented what is now called OAuth WRAP > >> > >> The specs and discussion specific to those documents is at: > >> > >> http://groups.google.com/group/oauth-wrap-wg > >> > >> We plan to submit the document as an I-D next week when I-D > >> submission > >> is open again, and for further work to occur in the IETF OAuth WG. > >> > >> -- 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 > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_C71F182728808eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] OAuth WRAP My 2c:

WRAP was developed out of necessity due to limitations in OAuth and product= release schedule. Without going into too much detail about whether a whole= new protocol was really necessary, the WRAP authors felt that it was, and = that their timeline could not accommodate waiting for the OAUTH WG to accom= modate their use cases in the new version of the spec. We now have a new an= d separate spec in the space.

I have encouraged the authors to submit their spec as input for the WG and = to collaborate to make the upcoming WG spec cover their use case. The goal = would be to render the separate WRAP spec unnecessary. How they or others w= ould choose to apply this to their implementation is beyond my control or (= TBH) interest.

Most of the innovative ideas in WRAP are around the delegation flow (and th= ere are some good ideas in there). I plan to use some of that as the basis = for the new delegation spec. On the authentication side, WRAP uses bearer t= oken with no crypto which will be supported by the PLAIN flavor.

As for how to manage community expectations, the OAuth brand, etc.: I was o= pposed to putting WRAP under the OAuth brand (the entire effort started as = “Simple OAuth”). Others felt that pretending WRAP was an OAuth = profile (it is not) and naming it as such would be less confusing or less d= amaging to the OAuth brand (if you call it the same thing, there is no comp= etition). I didn’t care enough to (continue) that argument given my v= iew that by the time WRAP will get the wide attention OAuth has, this WG wi= ll produce stable drafts of the new OAuth and will make this irrelevant.
EHL




On 11/10/09 11:56 AM, "Paul C. Bryan" <email@pbryan.net> wrote:

I guess I must admit I'm a bit surprised th= at the general consensus
would be to merge with/profile WRAP as OAuth, as the deltas between the
two protocols as defined seems quite substantial. Does this mean that
for all intents and purposes I should consider the existing OAuth IETF
drafts to date to be deprecated in favour of WRAP?

Paul

On Tue, 2009-11-10 at 19:46 +0000, Dick Hardt wrote:
> Good question. Given the positive reception WRAP received at IIW and <= BR> > that capabilities in WRAP are expected to come out of the work in the =
> IETF OAuth WG, there was consensus from the OAuth community to include=
> WRAP as OAuth profiles.
>
> -- Dick
>
> On 2009-11-10, at 10:06 AM, "Paul C. Bryan" <email@pbryan.net> wrote:
>
> > Hi Dick:
> >
> > Given that WRAP is so different from OAuth (as I know it), other = than
> > the fact that OAuth could be used to negotiate the issuance of a = WRAP
> > refresh token, I'm curious why you chose to associate this with <= BR> > > OAuth by
> > giving it an "OAuth" prefix. It seems to me that it wou= ld only create
> > confusion in this space.
> >
> > Paul
> >
> > On Tue, 2009-11-10 at 17:52 +0000, Dick Hardt wrote:
> >> At IIW last week, myself, Biran Eaton from Google and Allen T= om from
> >> Yahoo! presented what is now called OAuth WRAP
> >>
> >> The specs and discussion specific to those documents is at: > >>
> >>    http://groups.google.com/group/oauth-wrap-wg
> >>
> >> We plan to submit the document as an I-D next week when I-D <= BR> > >> submission
> >> is open again, and for further work to occur in the IETF OAut= h WG.
> >>
> >> -- Dick
> >> _______________________________________________
> >> OAuth mailing list
> >> OAuth@ietf.org
> >> https= ://www.ietf.org/mailman/listinfo/oauth
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://w= ww.ietf.org/mailman/listinfo/oauth
> >

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

--_000_C71F182728808eranhueniversecom_-- From email@pbryan.net Tue Nov 10 13:40:05 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEF8B3A6B2A for ; Tue, 10 Nov 2009 13:40:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 0cotDvo6T9Yz for ; Tue, 10 Nov 2009 13:40:04 -0800 (PST) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by core3.amsl.com (Postfix) with ESMTP id C69C13A6A2A for ; Tue, 10 Nov 2009 13:40:04 -0800 (PST) Received: from [192.168.0.4] (S010600095baae0ff.vf.shawcable.net [174.1.50.199]) by maple.anode.ca (Postfix) with ESMTPSA id ED1F1EA022 for ; Tue, 10 Nov 2009 21:40:31 +0000 (UTC) From: "Paul C. Bryan" To: "oauth@ietf.org" In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Tue, 10 Nov 2009 13:40:30 -0800 Message-Id: <1257889230.10242.53.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Subject: Re: [OAUTH-WG] OAuth WRAP X-BeenThere: oauth@ietf.org X-Mailman-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, 10 Nov 2009 21:40:05 -0000 Hi Eran: Thanks for your clarification. It seems to me that without simple guidelines on what's reasonable to be called "OAuth", anyone can propose a protocol that purports to be related in some way to OAuth, at the expense of community confusion and dilution of its meaning. Is there a way to mitigate this kind of occurrence other than by simply dismissing it as noise? Paul On Tue, 2009-11-10 at 14:16 -0700, Eran Hammer-Lahav wrote: > My 2c: > > WRAP was developed out of necessity due to limitations in OAuth and > product release schedule. Without going into too much detail about > whether a whole new protocol was really necessary, the WRAP authors > felt that it was, and that their timeline could not accommodate > waiting for the OAUTH WG to accommodate their use cases in the new > version of the spec. We now have a new and separate spec in the space. > > I have encouraged the authors to submit their spec as input for the WG > and to collaborate to make the upcoming WG spec cover their use case. > The goal would be to render the separate WRAP spec unnecessary. How > they or others would choose to apply this to their implementation is > beyond my control or (TBH) interest. > > Most of the innovative ideas in WRAP are around the delegation flow > (and there are some good ideas in there). I plan to use some of that > as the basis for the new delegation spec. On the authentication side, > WRAP uses bearer token with no crypto which will be supported by the > PLAIN flavor. > > As for how to manage community expectations, the OAuth brand, etc.: I > was opposed to putting WRAP under the OAuth brand (the entire effort > started as “Simple OAuthâ€). Others felt that pretending WRAP was an > OAuth profile (it is not) and naming it as such would be less > confusing or less damaging to the OAuth brand (if you call it the same > thing, there is no competition). I didn’t care enough to (continue) > that argument given my view that by the time WRAP will get the wide > attention OAuth has, this WG will produce stable drafts of the new > OAuth and will make this irrelevant. > > EHL > > > > > On 11/10/09 11:56 AM, "Paul C. Bryan" wrote: > > I guess I must admit I'm a bit surprised that the general > consensus > would be to merge with/profile WRAP as OAuth, as the deltas > between the > two protocols as defined seems quite substantial. Does this > mean that > for all intents and purposes I should consider the existing > OAuth IETF > drafts to date to be deprecated in favour of WRAP? > > Paul > > On Tue, 2009-11-10 at 19:46 +0000, Dick Hardt wrote: > > Good question. Given the positive reception WRAP received at > IIW and > > that capabilities in WRAP are expected to come out of the > work in the > > IETF OAuth WG, there was consensus from the OAuth community > to include > > WRAP as OAuth profiles. > > > > -- Dick > > > > On 2009-11-10, at 10:06 AM, "Paul C. Bryan" > wrote: > > > > > Hi Dick: > > > > > > Given that WRAP is so different from OAuth (as I know it), > other than > > > the fact that OAuth could be used to negotiate the > issuance of a WRAP > > > refresh token, I'm curious why you chose to associate this > with > > > OAuth by > > > giving it an "OAuth" prefix. It seems to me that it would > only create > > > confusion in this space. > > > > > > Paul > > > > > > On Tue, 2009-11-10 at 17:52 +0000, Dick Hardt wrote: > > >> At IIW last week, myself, Biran Eaton from Google and > Allen Tom from > > >> Yahoo! presented what is now called OAuth WRAP > > >> > > >> The specs and discussion specific to those documents is > at: > > >> > > >> http://groups.google.com/group/oauth-wrap-wg > > >> > > >> We plan to submit the document as an I-D next week when > I-D > > >> submission > > >> is open again, and for further work to occur in the IETF > OAuth WG. > > >> > > >> -- 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 > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From eran@hueniverse.com Tue Nov 10 13:46:07 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D0B73A6B8E for ; Tue, 10 Nov 2009 13:46:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q+Tlp-yNWPZ2 for ; Tue, 10 Nov 2009 13:46:00 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id E89503A6B8B for ; Tue, 10 Nov 2009 13:45:59 -0800 (PST) Received: (qmail 30640 invoked from network); 10 Nov 2009 21:46:27 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 10 Nov 2009 21:46:27 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 10 Nov 2009 14:46:26 -0700 From: Eran Hammer-Lahav To: "Paul C. Bryan" , "oauth@ietf.org" Date: Tue, 10 Nov 2009 14:46:25 -0700 Thread-Topic: [OAUTH-WG] OAuth WRAP Thread-Index: AcpiTnA3HYJjRkbzR1yzqhSLl6hYoQAAM/U7 Message-ID: In-Reply-To: <1257889230.10242.53.camel@localhost> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C71F1F3128821eranhueniversecom_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] OAuth WRAP X-BeenThere: oauth@ietf.org X-Mailman-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, 10 Nov 2009 21:46:07 -0000 --_000_C71F1F3128821eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Not really. It is more about who you listen to than who is speaking. EHL On 11/10/09 1:40 PM, "Paul C. Bryan" wrote: Hi Eran: Thanks for your clarification. It seems to me that without simple guidelines on what's reasonable to be called "OAuth", anyone can propose a protocol that purports to be related in some way to OAuth, at the expense of community confusion and dilution of its meaning. Is there a way to mitigate this kind of occurrence other than by simply dismissing it as noise? Paul On Tue, 2009-11-10 at 14:16 -0700, Eran Hammer-Lahav wrote: > My 2c: > > WRAP was developed out of necessity due to limitations in OAuth and > product release schedule. Without going into too much detail about > whether a whole new protocol was really necessary, the WRAP authors > felt that it was, and that their timeline could not accommodate > waiting for the OAUTH WG to accommodate their use cases in the new > version of the spec. We now have a new and separate spec in the space. > > I have encouraged the authors to submit their spec as input for the WG > and to collaborate to make the upcoming WG spec cover their use case. > The goal would be to render the separate WRAP spec unnecessary. How > they or others would choose to apply this to their implementation is > beyond my control or (TBH) interest. > > Most of the innovative ideas in WRAP are around the delegation flow > (and there are some good ideas in there). I plan to use some of that > as the basis for the new delegation spec. On the authentication side, > WRAP uses bearer token with no crypto which will be supported by the > PLAIN flavor. > > As for how to manage community expectations, the OAuth brand, etc.: I > was opposed to putting WRAP under the OAuth brand (the entire effort > started as "Simple OAuth"). Others felt that pretending WRAP was an > OAuth profile (it is not) and naming it as such would be less > confusing or less damaging to the OAuth brand (if you call it the same > thing, there is no competition). I didn't care enough to (continue) > that argument given my view that by the time WRAP will get the wide > attention OAuth has, this WG will produce stable drafts of the new > OAuth and will make this irrelevant. > > EHL > > > > > On 11/10/09 11:56 AM, "Paul C. Bryan" wrote: > > I guess I must admit I'm a bit surprised that the general > consensus > would be to merge with/profile WRAP as OAuth, as the deltas > between the > two protocols as defined seems quite substantial. Does this > mean that > for all intents and purposes I should consider the existing > OAuth IETF > drafts to date to be deprecated in favour of WRAP? > > Paul > > On Tue, 2009-11-10 at 19:46 +0000, Dick Hardt wrote: > > Good question. Given the positive reception WRAP received at > IIW and > > that capabilities in WRAP are expected to come out of the > work in the > > IETF OAuth WG, there was consensus from the OAuth community > to include > > WRAP as OAuth profiles. > > > > -- Dick > > > > On 2009-11-10, at 10:06 AM, "Paul C. Bryan" > wrote: > > > > > Hi Dick: > > > > > > Given that WRAP is so different from OAuth (as I know it), > other than > > > the fact that OAuth could be used to negotiate the > issuance of a WRAP > > > refresh token, I'm curious why you chose to associate this > with > > > OAuth by > > > giving it an "OAuth" prefix. It seems to me that it would > only create > > > confusion in this space. > > > > > > Paul > > > > > > On Tue, 2009-11-10 at 17:52 +0000, Dick Hardt wrote: > > >> At IIW last week, myself, Biran Eaton from Google and > Allen Tom from > > >> Yahoo! presented what is now called OAuth WRAP > > >> > > >> The specs and discussion specific to those documents is > at: > > >> > > >> http://groups.google.com/group/oauth-wrap-wg > > >> > > >> We plan to submit the document as an I-D next week when > I-D > > >> submission > > >> is open again, and for further work to occur in the IETF > OAuth WG. > > >> > > >> -- 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 > > > > > _______________________________________________ > OAuth mailing 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_C71F1F3128821eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] OAuth WRAP Not really. It is more about who you listen to than who is speaking.<= BR>
EHL


On 11/10/09 1:40 PM, "Paul C. Bryan" <email@pbryan.net> wrote:

Hi Eran:

Thanks for your clarification.

It seems to me that without simple guidelines on what's reasonable to be called "OAuth", anyone can propose a protocol that purports to be=
related in some way to OAuth, at the expense of community confusion and
dilution of its meaning. Is there a way to mitigate this kind of
occurrence other than by simply dismissing it as noise?

Paul

On Tue, 2009-11-10 at 14:16 -0700, Eran Hammer-Lahav wrote:
> My 2c:
>
> WRAP was developed out of necessity due to limitations in OAuth and > product release schedule. Without going into too much detail about
> whether a whole new protocol was really necessary, the WRAP authors > felt that it was, and that their timeline could not accommodate
> waiting for the OAUTH WG to accommodate their use cases in the new
> version of the spec. We now have a new and separate spec in the space.=
>
> I have encouraged the authors to submit their spec as input for the WG=
> and to collaborate to make the upcoming WG spec cover their use case.<= BR> > The goal would be to render the separate WRAP spec unnecessary. How > they or others would choose to apply this to their implementation is > beyond my control or (TBH) interest.
>
> Most of the innovative ideas in WRAP are around the delegation flow > (and there are some good ideas in there). I plan to use some of that > as the basis for the new delegation spec. On the authentication side,<= BR> > WRAP uses bearer token with no crypto which will be supported by the > PLAIN flavor.
>
> As for how to manage community expectations, the OAuth brand, etc.: I<= BR> > was opposed to putting WRAP under the OAuth brand (the entire effort > started as “Simple OAuth”). Others felt that pretending WR= AP was an
> OAuth profile (it is not) and naming it as such would be less
> confusing or less damaging to the OAuth brand (if you call it the same=
> thing, there is no competition). I didn’t care enough to (contin= ue)
> that argument given my view that by the time WRAP will get the wide > attention OAuth has, this WG will produce stable drafts of the new
> OAuth and will make this irrelevant.
>
> EHL
>
>
>
>
> On 11/10/09 11:56 AM, "Paul C. Bryan" <email@pbryan.net> wrote:
>
>         I guess I must admit I= 'm a bit surprised that the general
>         consensus
>         would be to merge with= /profile WRAP as OAuth, as the deltas
>         between the
>         two protocols as defin= ed seems quite substantial. Does this
>         mean that
>         for all intents and pu= rposes I should consider the existing
>         OAuth IETF
>         drafts to date to be d= eprecated in favour of WRAP?
>        
>         Paul
>        
>         On Tue, 2009-11-10 at = 19:46 +0000, Dick Hardt wrote:
>         > Good question. Gi= ven the positive reception WRAP received at
>         IIW and
>         > that capabilities= in WRAP are expected to come out of the
>         work in the
>         > IETF OAuth WG, th= ere was consensus from the OAuth community
>         to include
>         > WRAP as OAuth pro= files.
>         >
>         > -- Dick
>         >
>         > On 2009-11-10, at= 10:06 AM, "Paul C. Bryan"
>         <email@pbryan.net> wrote:
>         >
>         > > Hi Dick:
>         > >
>         > > Given that W= RAP is so different from OAuth (as I know it),
>         other than
>         > > the fact tha= t OAuth could be used to negotiate the
>         issuance of a WRAP
>         > > refresh toke= n, I'm curious why you chose to associate this
>         with
>         > > OAuth by
>         > > giving it an= "OAuth" prefix. It seems to me that it would
>         only create
>         > > confusion in= this space.
>         > >
>         > > Paul
>         > >
>         > > On Tue, 2009= -11-10 at 17:52 +0000, Dick Hardt wrote:
>         > >> At IIW l= ast week, myself, Biran Eaton from Google and
>         Allen Tom from
>         > >> Yahoo! p= resented what is now called OAuth WRAP
>         > >>
>         > >> The spec= s and discussion specific to those documents is
>         at:
>         > >>
>         > >>  &n= bsp; http://g= roups.google.com/group/oauth-wrap-wg
>         > >>
>         > >> We plan = to submit the document as an I-D next week when
>         I-D
>         > >> submissi= on
>         > >> is open = again, and for further work to occur in the IETF
>         OAuth WG.
>         > >>
>         > >> -- Dick<= BR> >         > >> ________= _______________________________________
>         > >> OAuth ma= iling list
>         > >> OAuth@ietf.org
>         > >> https://www.ietf.org/mailm= an/listinfo/oauth
>         > >
>         > > ____________= ___________________________________
>         > > OAuth mailin= g list
>         > > OAuth@ietf.org
>         > > https://www.ietf.org/mailman/li= stinfo/oauth
>         > >
>        
>         ______________________= _________________________
>         OAuth mailing list
>         OAuth@ietf.org
>         https://www.ietf.org/mailman/listinfo/oau= th
>        

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

--_000_C71F1F3128821eranhueniversecom_-- From jpanzer@google.com Tue Nov 10 14:38:08 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90E5D28C233 for ; Tue, 10 Nov 2009 14:38:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 OhRP4vXaHRzO for ; Tue, 10 Nov 2009 14:38:07 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id 6A1143A6991 for ; Tue, 10 Nov 2009 14:38:07 -0800 (PST) Received: from wpaz5.hot.corp.google.com (wpaz5.hot.corp.google.com [172.24.198.69]) by smtp-out.google.com with ESMTP id nAAMcYLX018426 for ; Tue, 10 Nov 2009 14:38:34 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1257892714; bh=Z4mJgav0GFuW51HBz5HIVPPXG6A=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=pZrodQ4yAntkv7ASzRo3VUXujlZ4dubJArqf/h7iKdYNWgYU40yifL/5KJbH8uWU5 Bdzj08HiUf5WecW8U17rA== 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=VG/BZ+IfsVQFGrXs7KCOp5BdUY9LAVM+BuOHKjODOY14eIoIGBVysrGO4qbYdsgSE h5Erxevc65Ot2fDU8Zxyw== Received: from pwj3 (pwj3.prod.google.com [10.241.219.67]) by wpaz5.hot.corp.google.com with ESMTP id nAAMcVkl002053 for ; Tue, 10 Nov 2009 14:38:31 -0800 Received: by pwj3 with SMTP id 3so313484pwj.39 for ; Tue, 10 Nov 2009 14:38:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.186.37 with SMTP id j37mr1371673waf.36.1257892710554; Tue, 10 Nov 2009 14:38:30 -0800 (PST) In-Reply-To: References: <35D50F5C-3982-4298-A9E0-86A528F5C5D3@jkemp.net> Date: Tue, 10 Nov 2009 14:38:30 -0800 Message-ID: From: John Panzer To: Dick Hardt Content-Type: multipart/alternative; boundary=0016e64ca4d82d9eb004780bf81d X-System-Of-Record: true Cc: "oauth@ietf.org" , oauth-wrap-wg Subject: Re: [OAUTH-WG] OAuth WRAP X-BeenThere: oauth@ietf.org X-Mailman-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, 10 Nov 2009 22:38:08 -0000 --0016e64ca4d82d9eb004780bf81d Content-Type: text/plain; charset=ISO-8859-1 To clarify the distinctions between OAuth WRAP and OAuth 1.0a, the OAuth WRAP doc[1] Appendix C states the following: "OAuth WRAP requires the Authorization Server to support HTTPS, OAuth 1.0A does not." This is an important distinction, though I assume it applies only to the profile(s) supplied as part of WRAP and not to extension profile(s) that may be created. E.g., one could create a fourth profile which did not require HTTPs -- it just would not be as interoperable as the others, and servers and clients are not required to support it, but it would be otherwise compatible with WRAP if I understand correctly.) "The Access Token in OAuth WRAP is opaque to the Client. The Client does not need to perform any cryptography except for calling HTTPS." This is also important, but what is the difference between WRAP and OAuth 1.0A PLAINTEXT mode? They seem to be pretty much identical to me, if there is a difference it should be called out. "The Access Token in OAuth WRAP can contain authorization information, or claims, enabling the Protected Resource to determine the Client's authorization without querying any other resource." I don't understand this distinction; this sounds exactly like the OAuth 1.0a token. What am I missing? Best, John PS: Sorry for the munged text, that's what I get when I copy and paste from the PDF to ASCII, any chance of getting a plain text or HTML version of the spec? [1] http://oauth-wrap-wg.googlegroups.com/web/WRAP-v0.9.7.2.pdf On Tue, Nov 10, 2009 at 9:52 AM, Dick Hardt wrote: > At IIW last week, myself, Biran Eaton from Google and Allen Tom from > Yahoo! presented what is now called OAuth WRAP > > The specs and discussion specific to those documents is at: > > http://groups.google.com/group/oauth-wrap-wg > > We plan to submit the document as an I-D next week when I-D submission > is open again, and for further work to occur in the IETF OAuth WG. > > -- Dick > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- -- John Panzer / Google jpanzer@google.com / abstractioneer.org / @jpanzer --0016e64ca4d82d9eb004780bf81d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
To clarify the distinctions between OAuth WRAP and OAuth 1.0a, the OAu= th WRAP doc[1] Appendix C states the following:

&q= uot;OAuth WRAP =A0 =A0requires =A0 =A0 =A0 =A0the =A0 =A0 Authorization =A0= Server =A0to =A0 =A0 =A0support HTTPS, =A0OAuth =A0 1.0A =A0 =A0does =A0 = =A0not."

This is an important distinction, though I assume it ap= plies only to the profile(s) supplied as part of WRAP and not to extension = profile(s) that may be created. =A0E.g., one could create a fourth profile = which did not require HTTPs -- it just would not be as interoperable as the= others, and servers and clients are not required to support it, but it wou= ld be otherwise compatible with WRAP if I understand correctly.)

"The =A0 Access =A0Token =A0 in =A0 =A0 =A0OA= uth =A0 WRAP =A0 =A0is =A0 =A0 =A0opaque =A0to =A0 =A0 =A0the =A0 =A0 Clien= t. The =A0 =A0 Client =A0does =A0 =A0not =A0 =A0 need =A0 =A0to =A0 =A0 =A0= perform any =A0 =A0 cryptography =A0 =A0except =A0for =A0 =A0 calling HTTPS= ."

This is also important, but what is the difference betw= een WRAP and OAuth 1.0A PLAINTEXT mode? =A0They seem to be pretty much iden= tical to me, if there is a difference it should be called out.

"The =A0 Access =A0Token =A0 in =A0 =A0 =A0OAuth =A0 WR= AP =A0 =A0can =A0 =A0 contain authorization =A0 information, =A0 =A0or =A0 = =A0 =A0claims, enabling =A0 =A0 =A0 =A0the =A0 =A0 Protected =A0 =A0 Resour= ce =A0 =A0 =A0 =A0to =A0 =A0 =A0determine =A0 =A0 =A0 the =A0 =A0 Client= 9;s =A0 =A0 =A0 =A0authorization =A0 without querying =A0 =A0 =A0 =A0any = =A0 =A0 other =A0 resource."

I don't understand this distinction; this sounds ex= actly like the OAuth 1.0a token. =A0What am I missing?

=
Best,
John

PS:=A0=A0Sorry for= the munged text, that's what I get when I copy and paste from the PDF = to ASCII, any chance of getting a plain text or HTML version of the spec?
[1]=A0http://oauth-wrap-wg.googlegroups.com/web/WRAP-v0.9.7.2.pdf

On Tue, Nov 10, 2009 at 9:52 AM= , Dick Hardt <Dick.Hardt@microsoft.com> wrote:
At IIW last week, myself, Biran Eaton from = Google and Allen Tom from
Yahoo! presented what is now called OAuth WRAP

The specs and discussion specific to those documents is at:

=A0 =A0 =A0 =A0http://groups.google.com/group/oauth-wrap-wg

We plan to submit the document as an I-D next week when I-D submission
is open again, and for further work to occur in the IETF OAuth WG.

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



--
--
John Panzer / Goo= gle
jpanzer@google.com / abstractioneer.org / @jpanzer

--0016e64ca4d82d9eb004780bf81d-- From stpeter@stpeter.im Wed Nov 11 13:14:17 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D3823A68ED for ; Wed, 11 Nov 2009 13:14:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.805 X-Spam-Level: X-Spam-Status: No, score=-2.805 tagged_above=-999 required=5 tests=[AWL=-0.206, 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 pWkJp-bTsQVE for ; Wed, 11 Nov 2009 13:14:16 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 3A6AB3A69B8 for ; Wed, 11 Nov 2009 13:14:16 -0800 (PST) Received: from host-113-169.meeting.ietf.org (64-104-46-217.cisco.com [64.104.46.217]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id DDD7240D09; Wed, 11 Nov 2009 14:14:42 -0700 (MST) Message-ID: <4AFB2940.2030709@stpeter.im> Date: Thu, 12 Nov 2009 06:14:40 +0900 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: John Panzer References: <35D50F5C-3982-4298-A9E0-86A528F5C5D3@jkemp.net> In-Reply-To: X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010509080002010403010105" Cc: Dick Hardt , "oauth@ietf.org" , oauth-wrap-wg Subject: Re: [OAUTH-WG] OAuth WRAP X-BeenThere: oauth@ietf.org X-Mailman-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, 11 Nov 2009 21:14:17 -0000 This is a cryptographically signed message in MIME format. --------------ms010509080002010403010105 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 11/11/09 7:38 AM, John Panzer wrote: > To clarify the distinctions between OAuth WRAP and OAuth 1.0a, the OAuth > WRAP doc[1] Appendix C states the following: > > "OAuth WRAP requires the Authorization Server to > support HTTPS, OAuth 1.0A does not." It's not clear to me that this distinction would force someone to define or label a new protocol. For instance in XMPP the protocol requires support for TLS in *implementations*, but leaves the use of TLS by any one *deployment* up to local service policy. > This is an important distinction, though I assume it applies only to the > profile(s) supplied as part of WRAP and not to extension profile(s) that > may be created. E.g., one could create a fourth profile which did not > require HTTPs -- it just would not be as interoperable as the others, > and servers and clients are not required to support it, but it would be > otherwise compatible with WRAP if I understand correctly.) > > "The Access Token in OAuth WRAP is opaque to > the Client. Isn't the token always opaque to the client? What semantic information should we expect a client to clean from an access token? > The Client does not need to perform > any cryptography except for calling HTTPS." A security review would tell us if that assumption is warranted. And, again, this seems to be more of a deployment choice (the client and server require SSL/TLS and therefore feel safe in using PLAINTEXT) than a protocol change. > This is also important, but what is the difference between WRAP and > OAuth 1.0A PLAINTEXT mode? They seem to be pretty much identical to me, > if there is a difference it should be called out. Agreed. > "The Access Token in OAuth WRAP can contain > authorization information, or claims, enabling the > Protected Resource to determine the Client's > authorization without querying any other resource." > > I don't understand this distinction; this sounds exactly like the OAuth > 1.0a token. What am I missing? Yes, this sounds very similar. /psa --------------ms010509080002010403010105 Content-Type: application/x-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 hvcNAQkFMQ8XDTA5MTExMTIxMTQ0MFowIwYJKoZIhvcNAQkEMRYEFMi6qPkBl2KppWSBpn0h THfvhTbcMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEALgNaD2erHDVC9q2jmWcBsvrGjcIcIIfUkCCnMzJO AIQNh/XdRvK+9JgtYPO4A+RFQK3IzKZqHlcefwdLOwx0hEDeP9zYpr3ND5sEJ9mztNISwWeO HJ9pai2sR/5Vi3cxadat9xe85ZTCwLvbRv3mgMcJ67xj4dhcSVkXVWJDKk+GPiu8qgwkm6pR 91Me1NQHJT/T6MRab/nXxJmErmRAsJRZ0lf2HWPLsmRKY7E2ODC91s3xE6c5GCXkbkHNRAlg /fdMeV2xCSxTDixYltqLBZORMKsxyRDee7lqZ7443nX/8j/ZKuaX6bCV6dEUx+lo1tjSfEmd DjWb1UHbHE+tMwAAAAAAAA== --------------ms010509080002010403010105-- From BeckW@telekom.de Wed Nov 11 17:49:34 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 235853A6929 for ; Wed, 11 Nov 2009 17:49:34 -0800 (PST) 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 2u2Lx0VmRyjo for ; Wed, 11 Nov 2009 17:49:33 -0800 (PST) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id DE7F33A67A6 for ; Wed, 11 Nov 2009 17:49:32 -0800 (PST) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail31.telekom.de with ESMTP; 12 Nov 2009 02:49:57 +0100 Received: from S4DE8PSAAQC.mitte.t-com.de ([10.151.229.14]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Nov 2009 02:49:56 +0100 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: Thu, 12 Nov 2009 02:49:52 +0100 Message-ID: <4A956CE47D1066408D5C7EB34368A5110551FFC1@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] why are we signing? Thread-Index: AcphytkKO9GTkYlISUa3LP0WhfcPVwBbmYMA References: <35D50F5C-3982-4298-A9E0-86A528F5C5D3@jkemp.net> From: To: , X-OriginalArrivalTime: 12 Nov 2009 01:49:56.0776 (UTC) FILETIME=[6FC2A280:01CA633A] Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] why are we signing? X-BeenThere: oauth@ietf.org X-Mailman-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, 12 Nov 2009 01:49:34 -0000 On Mon, Nov 9, 2009 at 6:28 AM, John Kemp wrote: > If we are only interested in i) [authenticating the entity] then signing any piece of the message might > be sufficient. If we are interested in ii) [binding the signature to the message] (or some other security property) > then we will need to identify which pieces of the message we want to provide > that, or other, security properties for. > Brian Eaton wrote: > OK, let me try to summarize what I've heard on this thread about the > different use-cases for message signing: >=20 > - sign the HTTP request > Used to prevent MITM from replaying token to a different URL. Also > limits the replay attack window to minutes instead of hours. >=20 > - sign various other parts of the message > DKIM: signs various message headers > SIP: unspecified, just says "relevant parts of SIP request" Hannes Tschofenig suggested handle SIP messages the way described in RfC 4474 (SIP identity). It lists the parts of a SIP messsage that need to be protected. Wolfgang From beaton@google.com Wed Nov 11 17:53:36 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E07ED3A694E for ; Wed, 11 Nov 2009 17:53:36 -0800 (PST) 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 4Y6fvgb7ZjL7 for ; Wed, 11 Nov 2009 17:53:36 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id 8EC663A67F2 for ; Wed, 11 Nov 2009 17:53:35 -0800 (PST) Received: from zps78.corp.google.com (zps78.corp.google.com [172.25.146.78]) by smtp-out.google.com with ESMTP id nAC1s3tl012899 for ; Wed, 11 Nov 2009 17:54:03 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1257990844; bh=LRpMBCw6iQ/WTmvEaibK3crL7Pk=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=TR6x9nDLE7LunDVuKiyRio0aESqJADmXKDiNYH4w5QgoqHoDfNw7U5ct9wFj2GcCi Y3/KGUUejReCIkEJuvrxg== 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=H6nEVIi/6AYe+KwxdArLEgLcy5abRg2q52lzBzyd58U2LCCCnP1I14/18GPp8Grf3 5T6t9lfQdwE9dQS7dxBFw== Received: from pwi15 (pwi15.prod.google.com [10.241.219.15]) by zps78.corp.google.com with ESMTP id nAC1s1xL001472 for ; Wed, 11 Nov 2009 17:54:01 -0800 Received: by pwi15 with SMTP id 15so1081533pwi.24 for ; Wed, 11 Nov 2009 17:54:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.143.2 with SMTP id q2mr142595rvd.0.1257990841207; Wed, 11 Nov 2009 17:54:01 -0800 (PST) In-Reply-To: <4A956CE47D1066408D5C7EB34368A5110551FFC1@S4DE8PSAAQC.mitte.t-com.de> References: <35D50F5C-3982-4298-A9E0-86A528F5C5D3@jkemp.net> <4A956CE47D1066408D5C7EB34368A5110551FFC1@S4DE8PSAAQC.mitte.t-com.de> Date: Wed, 11 Nov 2009 17:54:01 -0800 Message-ID: From: Brian Eaton To: BeckW@telekom.de 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] why are we signing? X-BeenThere: oauth@ietf.org X-Mailman-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, 12 Nov 2009 01:53:37 -0000 So we've got at least five different use cases for signing requests with the oauth access token and token secret. Sweet. The downside to the use cases is that they all have incompatible signature base strings. I'd like to see us come up with something so that we don't have to reinvent the base string again for every single use case. Cheers, Brian On Wed, Nov 11, 2009 at 5:49 PM, wrote: > > On Mon, Nov 9, 2009 at 6:28 AM, John Kemp wrote: >> If we are only interested in i) [authenticating the entity] then > signing any piece of the message might >> be sufficient. If we are interested in ii) [binding the signature to > the message] (or some other security property) >> then we will need to identify which pieces of the message we want to > provide >> that, or other, security properties for. > >> Brian Eaton wrote: >> OK, let me try to summarize what I've heard on this thread about the >> different use-cases for message signing: >> >> - sign the HTTP request >> =A0 Used to prevent MITM from replaying token to a different URL. =A0Als= o >> limits the replay attack window to minutes instead of hours. >> >> - sign various other parts of the message >> =A0 DKIM: signs various message headers >> =A0 SIP: unspecified, just says "relevant parts of SIP request" > Hannes Tschofenig suggested handle SIP messages the way described in RfC > 4474 (SIP identity). It lists the parts of a SIP messsage that need to > be protected. > > Wolfgang > From rlmorgan@washington.edu Wed Nov 11 18:25:11 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DAFF28C1AA for ; Wed, 11 Nov 2009 18:25:11 -0800 (PST) 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 BP4W4BIjz842 for ; Wed, 11 Nov 2009 18:25:10 -0800 (PST) Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by core3.amsl.com (Postfix) with ESMTP id 7B65E28C13A for ; Wed, 11 Nov 2009 18:25:10 -0800 (PST) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9] (may be forged)) by mxout3.cac.washington.edu (8.14.3+UW09.06/8.14.3+UW09.09) with ESMTP id nAC2Pcmq008534 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 11 Nov 2009 18:25:38 -0800 X-Auth-Received: from host-24-167.meeting.ietf.org (host-24-167.meeting.ietf.org [133.93.24.167]) (authenticated authid=rlmorgan) by smtp.washington.edu (8.14.3+UW09.06/8.14.3+UW09.05) with ESMTP id nAC2PZBX001750 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 11 Nov 2009 18:25:38 -0800 Date: Thu, 12 Nov 2009 11:25:34 +0900 (JST) From: "RL 'Bob' Morgan" X-X-Sender: rlmorgan@perf.cac.washington.edu To: OAuth WG In-Reply-To: <4AFB2940.2030709@stpeter.im> Message-ID: References: <35D50F5C-3982-4298-A9E0-86A528F5C5D3@jkemp.net> <4AFB2940.2030709@stpeter.im> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-PMX-Version: 5.5.8.383112, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2009.11.12.21535 X-Uwash-Spam: Gauge=X, Probability=10%, Report=' TO_IN_SUBJECT 0.5, BODY_SIZE_1900_1999 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, FROM_EDU_TLD 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __TO_MALFORMED_2 0, __USER_AGENT 0' Subject: Re: [OAUTH-WG] OAuth WRAP X-BeenThere: oauth@ietf.org X-Mailman-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, 12 Nov 2009 02:25:11 -0000 Finally looking at OAuth-WRAP draft, it occurs to me that there is some context to the architecture presented there that might help. Let me say that I haven't been involved in the development of WRAP, so might be getting this wrong from the point of view of WRAP folks, I apologize if so. The concept of a "security token service" (STS) has been developed and promoted as an architecture (or pattern, perhaps) in the community that might be variously labelled as WS-Security or WS-* or SOAP-based Web Services. Searching for the phrase will reveal lots of explanatory material. At least in enterprise circles the STS concept has become pretty well accepted, even if not so widely deployed. As a concrete WS-based service the STS is accessed via the WS-Trust protocol. WS-Trust conveys security tokens but is intended to be token-neutral, that is, it can be profiled to carry many/most/all tokens associated with existing security protocols. A WS-Trust-based STS then (in theory) can translate between what a client has and what a resource server needs. This pattern is appealing in large organizations to centralize token issuance in the face of many apps with heterogenous security protocol needs. It is my impression that the discussions that led to WRAP were around the observation by some large organizations that they find the STS pattern attractive to manage access with partners of all kinds; but that the WS-* stack is hard to deploy; and OAuth does something much similar and is much easier to deploy. So they'd like a "RESTized STS" or a "OAuth with an STS in it". That's more or less what I see in this proposal, though I haven't read it in detail. So, eg, statements about "opaque tokens" in WRAP as far as I can tell aren't meant to distinguish it from OAuth 1.0 but to reflect the design inputs from WS-Trust and STS. - RL "Bob" From chris.messina@gmail.com Wed Nov 11 18:50:21 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECBE128C18E for ; Wed, 11 Nov 2009 18:50:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 Yb74r5Z82K35 for ; Wed, 11 Nov 2009 18:50:19 -0800 (PST) Received: from mail-yx0-f174.google.com (mail-yx0-f174.google.com [209.85.210.174]) by core3.amsl.com (Postfix) with ESMTP id CD01428C17B for ; Wed, 11 Nov 2009 18:50:18 -0800 (PST) Received: by yxe4 with SMTP id 4so1578429yxe.32 for ; Wed, 11 Nov 2009 18:50:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=b7sKpzlDs8suK23MEttZmRvR0Wr0gWsfVUI0arfi/NM=; b=Pxn0UKHMy8ynlXUWsf8rw+jBlwaU3U8oXVvW+ATNK8KPWOdl8IsPgqGAxnD6jTcayr uqIzrPkB+FX7776DzRsdzzXKe6yYwEPrtIaxa6vm3yKRMySh/Tex7vrPkB156xhIaCZy EowX5/Ssxx9yzjVoe8OR/dkce3n01LEQiD9jI= 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=NDfoLSUF3lJ1/vEnLj1BIuyM18JbxCqQV0iDo6XUvBiEqAsnz1K9FFGwsmegC245BQ 246qWaDCenk/h9JvPRbxqsgkb1r+mLd1azQCN88f3bTSI1mL5YKdR2xbjHM0vbCiSSIg U9Ndt6igHuRX3eX5rw8Ulk6WuUmzeLWzrYK4E= MIME-Version: 1.0 Received: by 10.150.174.9 with SMTP id w9mr4246241ybe.24.1257994241708; Wed, 11 Nov 2009 18:50:41 -0800 (PST) In-Reply-To: <1257889230.10242.53.camel@localhost> References: <1257889230.10242.53.camel@localhost> Date: Wed, 11 Nov 2009 18:50:41 -0800 Message-ID: <1bc4603e0911111850h3f8006efrd7835ca7b4d660b2@mail.gmail.com> From: Chris Messina To: "Paul C. Bryan" Content-Type: multipart/alternative; boundary=000e0cd573d2e8120a0478239bcf Cc: oauth@googlegroups.com, Dick Hardt , oauth-wrap-wg@googlegroups.com, "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth WRAP X-BeenThere: oauth@ietf.org X-Mailman-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, 12 Nov 2009 02:50:22 -0000 --000e0cd573d2e8120a0478239bcf Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, Nov 10, 2009 at 1:40 PM, Paul C. Bryan wrote: It seems to me that without simple guidelines on what's reasonable to be called "OAuth", anyone can propose a protocol that purports to be relate= d in some way to OAuth, at the expense of community confusion and dilution of its meaning. Is there a way to mitigate this kind of occurrence other than by simply dismissing it as noise? Hi Paul, This is an important point and one that drove the move to rename WRAP to OAuth WRAP. Let me explain how this decision was made, with an eye to what it means for other projects calling themselves "OAuth". Dick Hardt originally reached out to various members of the OAuth community in August and explained what he, Brian Eaton, and Allen Tom were working on (perhaps there were others, but they seem like the core group). At the time= , they called the initiative "Simple OAuth" =97 "simple" because of its relia= nce on HTTPS for handling the crypto. While moving the crypto to SSL simplified the protocol and removed the need for signing (the biggest problem for developers implementing OAuth) it created a new burden, which was obtaining a certificate. Now, the point was made to me that anyone serious about security will have to obtain an SSL cert anyway, so that wasn't such a big deal. However, from the perspective of the individual or independent developer, I felt like thi= s was a fairly serious change in OAuth, and a challenge to the promise of the OAuth protocol (namely one protocol for authorization, regardless of the size of your organization). I want people who run their own WordPress installs on a shared host to be able to use OAuth just as large providers like Google and Yahoo do. I didn't want this new effort to use the name OAuth for exactly the reasons that you specified. This seemed like a fork of the project and a dilution o= f the brand. It also seemed to conflict with Eran's work here at the IETF and I encouraged Dick to seek a more transparent process to developing the protocol. Several weeks went by and progress was made =97 including the eventual renaming of the protocol to WRAP. This seemed like a fairly satisfactory development. At IIW, Dick presented a joint session with Brian Eaton (Google) on WRAP. There was considerable interest and many suggestions and improvements were proposed. Following the session, I reconsidered my position. My original concern with WRAP (when it was called "Simple OAuth") was that it would fragment the efforts of the community. If a new protocol came out calling itself "Simple OAuth", people would gravitate to it and potentially abandon work on improving the core spec. Now with WRAP clearly taking cycles from the peopl= e at Yahoo, Google, and Microsoft who would otherwise be working on OAuth Core, we had a decision to make: refuse them the ability to use the brand o= r find a middle ground that might pave the way for similar implementation-driven projects to find a foothold in the OAuth community. On top of that, the OAuth community must confront the simplicity and elegance of Facebook Connect. Although not everyone is paying attention to Facebook, theirs is a significant enough distraction from standards-based work that we must keep in mind that OAuth does not exist in a vacuum. From = a competitive perspective, we must constantly work to improve our technology, and make it easier to adopt the "open" and "universal" solution =97 to the point where Facebook could adopt it. In that light, it's also important to remember where OAuth came from. The original contributors to OAuth were a small, tight knit group of folks solving a problem that each of them shared. They looked to the work that ha= d come before them =97 for patterns and solutions that had been established b= y the Googles, Yahoos, Flickrs, Microsofts, and AOLs of the web. What they came up with was, unexpectedly, adopted by most of the companies that were the inspiration for the universal solution. That said, looking back, OAuth itself was largely developed in semi-secrecy= , with a closed mailing list and a private spec that didn't see the light of day until months into the process. I know this because I was the one that made the decision to keep our work private. Whether we like it or not, the best work doesn't always come from completely transparent processes and so I'd be a hypocrite if I didn't evaluate WRAP in the same light that lead to the original success of OAuth. Now, when it came to deciding what to call WRAP, well... that was more of a political calculation than a technical one. Dick had done the right thing i= n coming to us early and telling us what he was working on. I wish it had happened on the public list, but that was his decision to make and the fact of the matter is: they're damned near a 1.0 spec and are now ready for feedback. This is a perfectly valid way to develop specs and standards =97 especially since they're leading with an implementation. OAuth Core 1.0 captured the best thinking around del-auth when it was produced =97 and represented the beginning of a collaborative conversation about how to move away from password confetti. In the time since OAuth was launched, we've seen a multifold increase in th= e number of sites that no longer collect user passwords and instead use some form of the OAuth pattern. From my perspective, that's a massive improvemen= t over the previous status quo. The OAuth project has raised awareness of the problem of user authentication credentials being passed to parties that shouldn't have them, and it's lead to the development of a viable and more powerful alternative. But that work isn't finished =97 and when it comes to deploying this alternative in a widespread way, it turns out that what work= s for one kind of developer or provider doesn't work for all of them. Therefore, I see WRAP as an experimental branch of OAuth =97 and one that's closer in spirit, goals, and intention to OAuth than different from it. The work that Eran is doing now on OAuth 2.0 will invariably have to consider it =97 and even he accepts that there are some good ideas built in= to it. We also know now that signing is not trivial and is one central element of OAuth that is inhibiting its adoption, probably more than any other. Therefore, there is a need to improve the usability of OAuth, and WRAP seem= s to be squarely aimed at offering a solution to that problem =97 while also offering a more deployable solution for larger, distributed providers. Given all this, it seemed to me that WRAP was more "in the family of OAuth" than a distant cousin =97 or one that should necessarily have to develop it= s own, independent community. We're all trying to solve similar and related problems, and we need cohesion and consistency in the message that we offer to the world. Forking OAuth at this stage in its development is not, in my estimation, an option, and is why I changed my mind and decided that WRAP should be renamed to OAuth WRAP. Of course it's up to the OAuth WRAP maintainers to make their case and answer the community's questions and criticisms =97 but I'd much rather hav= e them do that within the existing community infrastructure than separately. If other projects wish to call themselves "OAuth", I hope that they'll have to run through a similar gauntlet of proving how they relate to this broade= r initiative, and how they're improving the overall stack of best practices and patterns that make up the OAuth technology. Stagnant technology is dead technology, and I'm happy to see at least a vibrant conversation about what does and doesn't fit into OAuth. That was probably more than you wanted to know, but I felt it was worth explaining the WRAP -> OAuth WRAP lineage. Chris On Tue, 2009-11-10 at 14:16 -0700, Eran Hammer-Lahav wrote: > My 2c: ]]> > WRAP was developed out of necessity due to limitations in OAuth and > product release schedule. Without going into too much detail about > whether a whole new protocol was really necessary, the WRAP authors > felt that it was, and that their timeline could not accommodate > waiting for the OAUTH WG to accommodate their use cases in the new > version of the spec. We now have a new and separate spec in the space. ]]> > I have encouraged the authors to submit their spec as input for the WG > and to collaborate to make the upcoming WG spec cover their use case. > The goal would be to render the separate WRAP spec unnecessary. How > they or others would choose to apply this to their implementation is > beyond my control or (TBH) interest. ]]> > Most of the innovative ideas in WRAP are around the delegation flow > (and there are some good ideas in there). I plan to use some of that > as the basis for the new delegation spec. On the authentication side, > WRAP uses bearer token with no crypto which will be supported by the > PLAIN flavor. ]]> > As for how to manage community expectations, the OAuth brand, etc.: I > was opposed to putting WRAP under the OAuth brand (the entire effort > started as =93Simple OAuth=94). Others felt that pretending WRAP was an > OAuth profile (it is not) and naming it as such would be less > confusing or less damaging to the OAuth brand (if you call it the same > thing, there is no competition). I didn=92t care enough to (continue) > that argument given my view that by the time WRAP will get the wide > attention OAuth has, this WG will produce stable drafts of the new > OAuth and will make this irrelevant. ]]> > EHL ]]> ]]> ]]> ]]> > On 11/10/09 11:56 AM, "Paul C. Bryan" wrote: ]]> > I guess I must admit I'm a bit surprised that the general > consensus > would be to merge with/profile WRAP as OAuth, as the deltas > between the > two protocols as defined seems quite substantial. Does this > mean that > for all intents and purposes I should consider the existing > OAuth IETF > drafts to date to be deprecated in favour of WRAP? ]]> > Paul ]]> > On Tue, 2009-11-10 at 19:46 +0000, Dick Hardt wrote: > > Good question. Given the positive reception WRAP received at > IIW and > > that capabilities in WRAP are expected to come out of the > work in the > > IETF OAuth WG, there was consensus from the OAuth community > to include > > WRAP as OAuth profiles. > > > > -- Dick > > > > On 2009-11-10, at 10:06 AM, "Paul C. Bryan" > wrote: > > > > > Hi Dick: > > > > > > Given that WRAP is so different from OAuth (as I know it), > other than > > > the fact that OAuth could be used to negotiate the > issuance of a WRAP > > > refresh token, I'm curious why you chose to associate this > with > > > OAuth by > > > giving it an "OAuth" prefix. It seems to me that it would > only create > > > confusion in this space. > > > > > > Paul > > > > > > On Tue, 2009-11-10 at 17:52 +0000, Dick Hardt wrote: > > >> At IIW last week, myself, Biran Eaton from Google and > Allen Tom from > > >> Yahoo! presented what is now called OAuth WRAP > > >> > > >> The specs and discussion specific to those documents is > at: > > >> > > >> http://groups.google.com/group/oauth-wrap-wg > > >> > > >> We plan to submit the document as an I-D next week when > I-D > > >> submission > > >> is open again, and for further work to occur in the IETF > OAuth WG. > > >> > > >> -- 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 > > > ]]> > _______________________________________________ > OAuth mailing 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 Chris Messina Open Web Advocate Personal: http://factoryjoe.com Follow me on Twitter: http://twitter.com/chrismessina Citizen Agency: http://citizenagency.com Diso Project: http://diso-project.org OpenID Foundation: http://openid.net This email is: [ ] shareable [X] ask first [ ] private --000e0cd573d2e8120a0478239bcf Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, Nov 10, 2009 at 1:40 PM, Paul C. Bryan=A0= <email@pbryan.net<= /a>>=A0wrote:

It seems to me that without simple guidelines on what's= reasonable to be=A0called "OAuth", anyone can propose a protocol= that purports to be=A0related in some way to OAuth, at the expense of comm= unity confusion and=A0dilution of its meaning. Is there a way to mitigate t= his kind of=A0occurrence other than by simply dismissing it as noise?


Hi Paul,

This is an important point and one that drove the move to rename WRA= P to OAuth WRAP.

Let me explain how this decision = was made, with an eye to what it means for other projects calling themselve= s "OAuth".

Dick Hardt originally reached out to various members of= the OAuth community in August and explained what he, Brian Eaton, and Alle= n Tom were working on (perhaps there were others, but they seem like the co= re group). At the time, they called the initiative "Simple OAuth"= =97 "simple" because of its reliance on HTTPS for handling the c= rypto. While moving the crypto to SSL simplified the protocol and removed t= he need for signing (the biggest problem for developers implementing OAuth)= it created a new burden, which was obtaining a certificate.

Now, the point was made to me that anyone serious about= security will have to obtain an SSL cert anyway, so that wasn't such a= big deal. However, from the perspective of the individual or independent d= eveloper, I felt like this was a fairly serious change in OAuth, and a chal= lenge to the promise of the OAuth protocol (namely one protocol for authori= zation, regardless of the size of your organization). I want people who run= their own WordPress installs on a shared host to be able to use OAuth just= as large providers like Google and Yahoo do.

I didn't want this new effort to use the name OAuth= for exactly the reasons that you specified. This seemed like a fork of the= project and a dilution of the brand. It also seemed to conflict with Eran&= #39;s work here at the IETF and I encouraged Dick to seek a more transparen= t process to developing the protocol.

Several weeks went by and progress was made =97 includi= ng the eventual renaming of the protocol to WRAP. This seemed like a fairly= satisfactory development.

At IIW, Dick presented = a joint session with Brian Eaton (Google) on WRAP. There was considerable i= nterest and many suggestions and improvements were proposed.

Following the session, I reconsidered my position. My o= riginal concern with WRAP (when it was called "Simple OAuth") was= that it would fragment the efforts of the community. If a new protocol cam= e out calling itself "Simple OAuth", people would gravitate to it= and potentially abandon work on improving the core spec. Now with WRAP cle= arly taking cycles from the people at Yahoo, Google, and Microsoft who woul= d otherwise be working on OAuth Core, we had a decision to make: refuse the= m the ability to use the brand or find a middle ground that might pave the = way for similar implementation-driven projects to find a foothold in the OA= uth community.

On top of that, the OAuth community must confront the s= implicity and elegance of Facebook Connect. Although not everyone is paying= attention to Facebook, theirs is a significant enough distraction from sta= ndards-based work that we must keep in mind that OAuth does not exist in a = vacuum. From a competitive perspective, we must constantly work to improve = our technology, and make it easier to adopt the "open" and "= universal" solution =97 to the point where Facebook could adopt it.

In that light, it's also important to remember wher= e OAuth came from.=A0

The original contributors to= OAuth were a small, tight knit group of folks solving a problem that each = of them shared. They looked to the work that had come before them =97 for p= atterns and solutions that had been established by the Googles, Yahoos, Fli= ckrs, Microsofts, and AOLs of the web. What they came up with was, unexpect= edly, adopted by most of the companies that were the inspiration for the un= iversal solution.

That said, looking back, OAuth itself was largely devel= oped in semi-secrecy, with a closed mailing list and a private spec that di= dn't see the light of day until months into the process. I know this be= cause I was the one that made the decision to keep our work private. Whethe= r we like it or not, the best work doesn't always come from completely = transparent processes and so I'd be a hypocrite if I didn't evaluat= e WRAP in the same light that lead to the original success of OAuth.

Now, when it came to deciding what to call WRAP, well..= . that was more of a political calculation than a technical one. Dick had d= one the right thing in coming to us early and telling us what he was workin= g on. I wish it had happened on the public list, but that was his decision = to make and the fact of the matter is: they're damned near a 1.0 spec a= nd are now ready for feedback.=A0

This is a perfectly valid way to develop specs and stan= dards =97 especially since they're leading with an implementation. OAut= h Core 1.0 captured the best thinking around del-auth when it was produced = =97 and represented the beginning of a collaborative conversation about how= to move away from password confetti.=A0

In the time since OAuth was launched, we've seen a = multifold increase in the number of sites that no longer collect user passw= ords and instead use some form of the OAuth pattern. From my perspective, t= hat's a massive improvement over the previous status quo. The OAuth pro= ject has raised awareness of the problem of user authentication credentials= being passed to parties that shouldn't have them, and it's lead to= the development of a viable and more powerful alternative. But that work i= sn't finished =97 and when it comes to deploying this alternative in a = widespread way, it turns out that what works for one kind of developer or p= rovider doesn't work for all of them.

Therefore, I see WRAP as an experimental branch of OAut= h =97 and one that's closer in spirit, goals, and intention to OAuth th= an different from it.=A0

The work that Eran is doi= ng now on OAuth 2.0 will invariably have to consider it =97 and even he acc= epts that there are some good ideas built into it. We also know now that si= gning is not trivial and is one central element of OAuth that is inhibiting= its adoption, probably more than any other. Therefore, there is a need to = improve the usability of OAuth, and WRAP seems to be squarely aimed at offe= ring a solution to that problem =97 while also offering a more deployable s= olution for larger, distributed providers.

Given all this, it seemed to me that WRAP was more &quo= t;in the family of OAuth" than a distant cousin =97 or one that should= necessarily have to develop its own, independent community. We're all = trying to solve similar and related problems, and we need cohesion and cons= istency in the message that we offer to the world. Forking OAuth at this st= age in its development is not, in my estimation, an option, and is why I ch= anged my mind and decided that WRAP should be renamed to OAuth WRAP.

Of course it's up to the OAuth WRAP maintainers to = make their case and answer the community's questions and criticisms =97= but I'd much rather have them do that within the existing community in= frastructure than separately.

If other projects wish to call themselves "OAuth&q= uot;, I hope that they'll have to run through a similar gauntlet of pro= ving how they relate to this broader initiative, and how they're improv= ing the overall stack of best practices and patterns that make up the OAuth= technology. Stagnant technology is dead technology, and I'm happy to s= ee at least a vibrant conversation about what does and doesn't fit into= OAuth.

That was probably more than you wanted to know, but I f= elt it was worth explaining the WRAP -> OAuth WRAP lineage.
Chris
=A0
On Tue, 2009-11-10 a= t 14:16 -0700, Eran Hammer-Lahav wrote:
> My 2c:
]]>
> WRAP was developed out of necessity due to li= mitations in OAuth and
> product release schedule. Without going into= too much detail about
> whether a whole new protocol was really nece= ssary, the WRAP authors
> felt that it was, and that their timeline could not accommodate
>= ; waiting for the OAUTH WG to accommodate their use cases in the new
>= ; version of the spec. We now have a new and separate spec in the space. ]]>
> I have encouraged the authors to submit their spec as input = for the WG
> and to collaborate to make the upcoming WG spec cover th= eir use case.
> The goal would be to render the separate WRAP spec un= necessary. How
> they or others would choose to apply this to their implementation is> beyond my control or (TBH) interest.
]]>
> Most of the i= nnovative ideas in WRAP are around the delegation flow
> (and there a= re some good ideas in there). I plan to use some of that
> as the basis for the new delegation spec. On the authentication side,<= br>> WRAP uses bearer token with no crypto which will be supported by th= e
> PLAIN flavor.
]]>
> As for how to manage community ex= pectations, the OAuth brand, etc.: I
> was opposed to putting WRAP under the OAuth brand (the entire effort> started as =93Simple OAuth=94). Others felt that pretending WRAP was= an
> OAuth profile (it is not) and naming it as such would be less > confusing or less damaging to the OAuth brand (if you call it the same=
> thing, there is no competition). I didn=92t care enough to (contin= ue)
> that argument given my view that by the time WRAP will get the = wide
> attention OAuth has, this WG will produce stable drafts of the new
= > OAuth and will make this irrelevant.
]]>
> EHL
]]>]]>
]]>
]]>
> On 11/10/09 11:56 AM, "Paul C. Br= yan" <email@pbryan.net> wrote:
]]>
>=A0=A0=A0=A0=A0=A0=A0=A0 I guess I must admit I'm a bit s= urprised that the general
>=A0=A0=A0=A0=A0=A0=A0=A0 consensus
>= =A0=A0=A0=A0=A0=A0=A0=A0 would be to merge with/profile WRAP as OAuth, as t= he deltas
>=A0=A0=A0=A0=A0=A0=A0=A0 between the
>=A0=A0=A0=A0= =A0=A0=A0=A0 two protocols as defined seems quite substantial. Does this >=A0=A0=A0=A0=A0=A0=A0=A0 mean that
>=A0=A0=A0=A0=A0=A0=A0=A0 for = all intents and purposes I should consider the existing
>=A0=A0=A0=A0= =A0=A0=A0=A0 OAuth IETF
>=A0=A0=A0=A0=A0=A0=A0=A0 drafts to date to b= e deprecated in favour of WRAP?
]]>
>=A0=A0=A0=A0=A0=A0=A0=A0 P= aul
]]>
>=A0=A0=A0=A0=A0=A0=A0=A0 On Tue, 2009-11-10 at 19:46 +0000, D= ick Hardt wrote:
>=A0=A0=A0=A0=A0=A0=A0=A0 > Good question. Given = the positive reception WRAP received at
>=A0=A0=A0=A0=A0=A0=A0=A0 IIW= and
>=A0=A0=A0=A0=A0=A0=A0=A0 > that capabilities in WRAP are exp= ected to come out of the
>=A0=A0=A0=A0=A0=A0=A0=A0 work in the
>=A0=A0=A0=A0=A0=A0=A0=A0 &g= t; IETF OAuth WG, there was consensus from the OAuth community
>=A0= =A0=A0=A0=A0=A0=A0=A0 to include
>=A0=A0=A0=A0=A0=A0=A0=A0 > WRAP = as OAuth profiles.
>=A0=A0=A0=A0=A0=A0=A0=A0 >
>=A0=A0=A0=A0= =A0=A0=A0=A0 > -- Dick
>=A0=A0=A0=A0=A0=A0=A0=A0 >
>=A0=A0=A0=A0=A0=A0=A0=A0 > On 2= 009-11-10, at 10:06 AM, "Paul C. Bryan"
>=A0=A0=A0=A0=A0=A0= =A0=A0 <email@pbryan.net> wrote:
>=A0=A0=A0=A0=A0=A0=A0= =A0 >
>=A0=A0=A0=A0=A0=A0=A0=A0 > > Hi Dick:
>=A0=A0= =A0=A0=A0=A0=A0=A0 > >
>=A0=A0=A0=A0=A0=A0=A0=A0 > > Given that WRAP is so different from= OAuth (as I know it),
>=A0=A0=A0=A0=A0=A0=A0=A0 other than
>= =A0=A0=A0=A0=A0=A0=A0=A0 > > the fact that OAuth could be used to neg= otiate the
>=A0=A0=A0=A0=A0=A0=A0=A0 issuance of a WRAP
>=A0=A0=A0=A0=A0=A0=A0=A0 > > refresh token, I'm curious why y= ou chose to associate this
>=A0=A0=A0=A0=A0=A0=A0=A0 with
>=A0= =A0=A0=A0=A0=A0=A0=A0 > > OAuth by
>=A0=A0=A0=A0=A0=A0=A0=A0 &g= t; > giving it an "OAuth" prefix. It seems to me that it would=
>=A0=A0=A0=A0=A0=A0=A0=A0 only create
>=A0=A0=A0=A0=A0=A0=A0=A0 &g= t; > confusion in this space.
>=A0=A0=A0=A0=A0=A0=A0=A0 > ><= br>>=A0=A0=A0=A0=A0=A0=A0=A0 > > Paul
>=A0=A0=A0=A0=A0=A0=A0= =A0 > >
>=A0=A0=A0=A0=A0=A0=A0=A0 > > On Tue, 2009-11-10 = at 17:52 +0000, Dick Hardt wrote:
>=A0=A0=A0=A0=A0=A0=A0=A0 > >> At IIW last week, myself, Biran = Eaton from Google and
>=A0=A0=A0=A0=A0=A0=A0=A0 Allen Tom from
>= ;=A0=A0=A0=A0=A0=A0=A0=A0 > >> Yahoo! presented what is now called= OAuth WRAP
>=A0=A0=A0=A0=A0=A0=A0=A0 > >>
>=A0=A0=A0=A0=A0=A0=A0=A0 > >> The specs and discussion specifi= c to those documents is
>=A0=A0=A0=A0=A0=A0=A0=A0 at:
>=A0=A0= =A0=A0=A0=A0=A0=A0 > >>
>=A0=A0=A0=A0=A0=A0=A0=A0 > >&= gt;=A0=A0=A0=A0http://groups.google.com/group/oauth-wrap-wg
>=A0=A0=A0=A0=A0=A0=A0=A0 > >>
>=A0=A0=A0=A0=A0=A0=A0=A0 = > >> We plan to submit the document as an I-D next week when
&g= t;=A0=A0=A0=A0=A0=A0=A0=A0 I-D
>=A0=A0=A0=A0=A0=A0=A0=A0 > >>= ; submission
>=A0=A0=A0=A0=A0=A0=A0=A0 > >> is open again, a= nd for further work to occur in the IETF
>=A0=A0=A0=A0=A0=A0=A0=A0 OAuth WG.
>=A0=A0=A0=A0=A0=A0=A0=A0 >= >>
>=A0=A0=A0=A0=A0=A0=A0=A0 > >> -- Dick
>=A0= =A0=A0=A0=A0=A0=A0=A0 > >> _______________________________________= ________
>=A0=A0=A0=A0=A0=A0=A0=A0 > >> OAuth mailing list >=A0=A0=A0=A0=A0=A0=A0=A0 > >>=A0OAuth@ietf.org
>= =A0=A0=A0=A0=A0=A0=A0=A0 > >>=A0https://www.ietf.org/mailman/listin= fo/oauth
>=A0=A0=A0=A0=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=A0=A0=A0=A0 > >=A0OAuth@ietf.org
>=A0= =A0=A0=A0=A0=A0=A0=A0 > >=A0https://www.ietf.org/mailman/listinfo/oaut= h
>=A0=A0=A0=A0=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=A0=A0=A0=A0=A0OAuth@= ietf.org
>=A0=A0=A0=A0=A0=A0=A0=A0=A0https://www.ietf.org/mailman/= listinfo/oauth
]]>

_______________________________________________
OAuth mail= ing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/o= auth


-= -=A0
Chris Messina
Open Web Advocate

Follow me on Twitter:=A0ht= tp://twitter.com/chrismessina

Citizen Agency:= =A0http://citizenagency.com
=
Diso Project:=A0http://diso-project.or= g
OpenID Foundation:=A0http://= openid.net

This email is:=A0=A0 [ ] shareable= =A0=A0=A0=A0[X] ask first=A0=A0 [ ] private
--000e0cd573d2e8120a0478239bcf-- From eran@hueniverse.com Thu Nov 12 00:09:18 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB05C3A698E for ; Thu, 12 Nov 2009 00:09:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.403 X-Spam-Level: X-Spam-Status: No, score=-2.403 tagged_above=-999 required=5 tests=[AWL=-0.105, BAYES_00=-2.599, HTML_MESSAGE=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 iHtnLVEhmtTX for ; Thu, 12 Nov 2009 00:09:00 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 948873A69FF for ; Thu, 12 Nov 2009 00:09:00 -0800 (PST) Received: (qmail 1143 invoked from network); 12 Nov 2009 08:09:26 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 12 Nov 2009 08:09:25 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 12 Nov 2009 01:09:25 -0700 From: Eran Hammer-Lahav To: "oauth@ietf.org" Date: Thu, 12 Nov 2009 01:09:13 -0700 Thread-Topic: [WRAP] Re: [OAUTH-WG] OAuth WRAP Thread-Index: AcpjQvAN396n9PrZSk6B2wCeKl2yqwAKIDVw Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343785102B46@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <1257889230.10242.53.camel@localhost> <1bc4603e0911111850h3f8006efrd7835ca7b4d660b2@mail.gmail.com> In-Reply-To: <1bc4603e0911111850h3f8006efrd7835ca7b4d660b2@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_90C41DD21FB7C64BB94121FBBC2E72343785102B46P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] [WRAP] Re: OAuth WRAP X-BeenThere: oauth@ietf.org X-Mailman-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, 12 Nov 2009 08:09:18 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343785102B46P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I don't think it was a good idea to associate WRAP with OAuth (beyond the o= bvious technical similarities). I also don't think the decision was appropr= iately made. WRAP is in no way a profile of OAuth no matter how you look at it - it is a= completely separate protocol developed by different people. WRAP and OAuth are competing protocols and this conflict can only be resolv= ed by a new protocol replacing both. OAuth will need to change to accommoda= te the use cases driving WRAP's development. While this is certainly my int= ention, the IETF process does not guarantee that. Meanwhile, at least some = of WRAP's three corporate sponsors are going to ship running code using it,= and it is actively being promoted as a viable alternative. This is not cri= ticism (at least not in this context), just a matter of fact. The IETF WG is going to review and consider the many new (good) ideas conta= ined in WRAP as soon as it is submitted as input into the WG in the form of= an I-D. I am grateful to the authors for making it available in this manne= r. It certainly makes my life easier. I am hoping that the IETF WG can produce stable implementers drafts soon wh= ich will provide developers a better alternative than both OAuth 1.0 and WR= AP. The next few months will tell if this move has hurt the OAuth brand and= how it will impact what we end up calling the new WG protocol. All of this is nothing but the usual tension between the needs of corporati= ons to deliver products on their own timeline and the slow speed of standar= ds development, especially for something with a high profile like OAuth. Bu= t it would have moved much faster if the energy spent on WRAP was instead i= nvested here. EHL From: oauth-wrap-wg@googlegroups.com [mailto:oauth-wrap-wg@googlegroups.com= ] On Behalf Of Chris Messina Sent: Wednesday, November 11, 2009 6:51 PM To: Paul C. Bryan Cc: oauth@ietf.org; oauth@googlegroups.com; oauth-wrap-wg@googlegroups.com;= John Panzer; Dick Hardt; Brian Eaton; Eric Sachs Subject: [WRAP] Re: [OAUTH-WG] OAuth WRAP On Tue, Nov 10, 2009 at 1:40 PM, Paul C. Bryan > wrote: It seems to me that without simple guidelines on what's reasonable to be ca= lled "OAuth", anyone can propose a protocol that purports to be related in = some way to OAuth, at the expense of community confusion and dilution of it= s meaning. Is there a way to mitigate this kind of occurrence other than by= simply dismissing it as noise? Hi Paul, This is an important point and one that drove the move to rename WRAP to OA= uth WRAP. Let me explain how this decision was made, with an eye to what it means for= other projects calling themselves "OAuth". Dick Hardt originally reached out to various members of the OAuth community= in August and explained what he, Brian Eaton, and Allen Tom were working o= n (perhaps there were others, but they seem like the core group). At the ti= me, they called the initiative "Simple OAuth" - "simple" because of its rel= iance on HTTPS for handling the crypto. While moving the crypto to SSL simp= lified the protocol and removed the need for signing (the biggest problem f= or developers implementing OAuth) it created a new burden, which was obtain= ing a certificate. Now, the point was made to me that anyone serious about security will have = to obtain an SSL cert anyway, so that wasn't such a big deal. However, from= the perspective of the individual or independent developer, I felt like th= is was a fairly serious change in OAuth, and a challenge to the promise of = the OAuth protocol (namely one protocol for authorization, regardless of th= e size of your organization). I want people who run their own WordPress ins= talls on a shared host to be able to use OAuth just as large providers like= Google and Yahoo do. I didn't want this new effort to use the name OAuth for exactly the reasons= that you specified. This seemed like a fork of the project and a dilution = of the brand. It also seemed to conflict with Eran's work here at the IETF = and I encouraged Dick to seek a more transparent process to developing the = protocol. Several weeks went by and progress was made - including the eventual renami= ng of the protocol to WRAP. This seemed like a fairly satisfactory developm= ent. At IIW, Dick presented a joint session with Brian Eaton (Google) on WRAP. T= here was considerable interest and many suggestions and improvements were p= roposed. Following the session, I reconsidered my position. My original concern with= WRAP (when it was called "Simple OAuth") was that it would fragment the ef= forts of the community. If a new protocol came out calling itself "Simple O= Auth", people would gravitate to it and potentially abandon work on improvi= ng the core spec. Now with WRAP clearly taking cycles from the people at Ya= hoo, Google, and Microsoft who would otherwise be working on OAuth Core, we= had a decision to make: refuse them the ability to use the brand or find a= middle ground that might pave the way for similar implementation-driven pr= ojects to find a foothold in the OAuth community. On top of that, the OAuth community must confront the simplicity and elegan= ce of Facebook Connect. Although not everyone is paying attention to Facebo= ok, theirs is a significant enough distraction from standards-based work th= at we must keep in mind that OAuth does not exist in a vacuum. From a compe= titive perspective, we must constantly work to improve our technology, and = make it easier to adopt the "open" and "universal" solution - to the point = where Facebook could adopt it. In that light, it's also important to remember where OAuth came from. The original contributors to OAuth were a small, tight knit group of folks = solving a problem that each of them shared. They looked to the work that ha= d come before them - for patterns and solutions that had been established b= y the Googles, Yahoos, Flickrs, Microsofts, and AOLs of the web. What they = came up with was, unexpectedly, adopted by most of the companies that were = the inspiration for the universal solution. That said, looking back, OAuth itself was largely developed in semi-secrecy= , with a closed mailing list and a private spec that didn't see the light o= f day until months into the process. I know this because I was the one that= made the decision to keep our work private. Whether we like it or not, the= best work doesn't always come from completely transparent processes and so= I'd be a hypocrite if I didn't evaluate WRAP in the same light that lead t= o the original success of OAuth. Now, when it came to deciding what to call WRAP, well... that was more of a= political calculation than a technical one. Dick had done the right thing = in coming to us early and telling us what he was working on. I wish it had = happened on the public list, but that was his decision to make and the fact= of the matter is: they're damned near a 1.0 spec and are now ready for fee= dback. This is a perfectly valid way to develop specs and standards - especially s= ince they're leading with an implementation. OAuth Core 1.0 captured the be= st thinking around del-auth when it was produced - and represented the begi= nning of a collaborative conversation about how to move away from password = confetti. In the time since OAuth was launched, we've seen a multifold increase in th= e number of sites that no longer collect user passwords and instead use som= e form of the OAuth pattern. From my perspective, that's a massive improvem= ent over the previous status quo. The OAuth project has raised awareness of= the problem of user authentication credentials being passed to parties tha= t shouldn't have them, and it's lead to the development of a viable and mor= e powerful alternative. But that work isn't finished - and when it comes to= deploying this alternative in a widespread way, it turns out that what wor= ks for one kind of developer or provider doesn't work for all of them. Therefore, I see WRAP as an experimental branch of OAuth - and one that's c= loser in spirit, goals, and intention to OAuth than different from it. The work that Eran is doing now on OAuth 2.0 will invariably have to consid= er it - and even he accepts that there are some good ideas built into it. W= e also know now that signing is not trivial and is one central element of O= Auth that is inhibiting its adoption, probably more than any other. Therefo= re, there is a need to improve the usability of OAuth, and WRAP seems to be= squarely aimed at offering a solution to that problem - while also offerin= g a more deployable solution for larger, distributed providers. Given all this, it seemed to me that WRAP was more "in the family of OAuth"= than a distant cousin - or one that should necessarily have to develop its= own, independent community. We're all trying to solve similar and related = problems, and we need cohesion and consistency in the message that we offer= to the world. Forking OAuth at this stage in its development is not, in my= estimation, an option, and is why I changed my mind and decided that WRAP = should be renamed to OAuth WRAP. Of course it's up to the OAuth WRAP maintainers to make their case and answ= er the community's questions and criticisms - but I'd much rather have them= do that within the existing community infrastructure than separately. If other projects wish to call themselves "OAuth", I hope that they'll have= to run through a similar gauntlet of proving how they relate to this broad= er initiative, and how they're improving the overall stack of best practice= s and patterns that make up the OAuth technology. Stagnant technology is de= ad technology, and I'm happy to see at least a vibrant conversation about w= hat does and doesn't fit into OAuth. That was probably more than you wanted to know, but I felt it was worth exp= laining the WRAP -> OAuth WRAP lineage. Chris On Tue, 2009-11-10 at 14:16 -0700, Eran Hammer-Lahav wrote: > My 2c: ]]> > WRAP was developed out of necessity due to limitations in OAuth and > product release schedule. Without going into too much detail about > whether a whole new protocol was really necessary, the WRAP authors > felt that it was, and that their timeline could not accommodate > waiting for the OAUTH WG to accommodate their use cases in the new > version of the spec. We now have a new and separate spec in the space. ]]> > I have encouraged the authors to submit their spec as input for the WG > and to collaborate to make the upcoming WG spec cover their use case. > The goal would be to render the separate WRAP spec unnecessary. How > they or others would choose to apply this to their implementation is > beyond my control or (TBH) interest. ]]> > Most of the innovative ideas in WRAP are around the delegation flow > (and there are some good ideas in there). I plan to use some of that > as the basis for the new delegation spec. On the authentication side, > WRAP uses bearer token with no crypto which will be supported by the > PLAIN flavor. ]]> > As for how to manage community expectations, the OAuth brand, etc.: I > was opposed to putting WRAP under the OAuth brand (the entire effort > started as "Simple OAuth"). Others felt that pretending WRAP was an > OAuth profile (it is not) and naming it as such would be less > confusing or less damaging to the OAuth brand (if you call it the same > thing, there is no competition). I didn't care enough to (continue) > that argument given my view that by the time WRAP will get the wide > attention OAuth has, this WG will produce stable drafts of the new > OAuth and will make this irrelevant. ]]> > EHL ]]> ]]> ]]> ]]> > On 11/10/09 11:56 AM, "Paul C. Bryan" wrote: ]]> > I guess I must admit I'm a bit surprised that the general > consensus > would be to merge with/profile WRAP as OAuth, as the deltas > between the > two protocols as defined seems quite substantial. Does this > mean that > for all intents and purposes I should consider the existing > OAuth IETF > drafts to date to be deprecated in favour of WRAP? ]]> > Paul ]]> > On Tue, 2009-11-10 at 19:46 +0000, Dick Hardt wrote: > > Good question. Given the positive reception WRAP received at > IIW and > > that capabilities in WRAP are expected to come out of the > work in the > > IETF OAuth WG, there was consensus from the OAuth community > to include > > WRAP as OAuth profiles. > > > > -- Dick > > > > On 2009-11-10, at 10:06 AM, "Paul C. Bryan" > wrote: > > > > > Hi Dick: > > > > > > Given that WRAP is so different from OAuth (as I know it), > other than > > > the fact that OAuth could be used to negotiate the > issuance of a WRAP > > > refresh token, I'm curious why you chose to associate this > with > > > OAuth by > > > giving it an "OAuth" prefix. It seems to me that it would > only create > > > confusion in this space. > > > > > > Paul > > > > > > On Tue, 2009-11-10 at 17:52 +0000, Dick Hardt wrote: > > >> At IIW last week, myself, Biran Eaton from Google and > Allen Tom from > > >> Yahoo! presented what is now called OAuth WRAP > > >> > > >> The specs and discussion specific to those documents is > at: > > >> > > >> http://groups.google.com/group/oauth-wrap-wg > > >> > > >> We plan to submit the document as an I-D next week when > I-D > > >> submission > > >> is open again, and for further work to occur in the IETF > OAuth WG. > > >> > > >> -- 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 > > > ]]> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth ]]> _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Chris Messina Open Web Advocate Personal: http://factoryjoe.com Follow me on Twitter: http://twitter.com/chrismessina Citizen Agency: http://citizenagency.com Diso Project: http://diso-project.org OpenID Foundation: http://openid.net This email is: [ ] shareable [X] ask first [ ] private --~--~---------~--~----~------------~-------~--~----~ 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@goo= glegroups.com For more options, visit this group at http://groups.google.com/group/oauth-= wrap-wg?hl=3Den -~----------~----~----~----~------~----~------~--~--- --_000_90C41DD21FB7C64BB94121FBBC2E72343785102B46P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I don’t think it was a good idea to associate WRAP wit= h OAuth (beyond the obvious technical similarities). I also don’t think= the decision was appropriately made.

 

WRAP is in no way a profile of OAuth no matter how you look = at it – it is a completely separate protocol developed by different peop= le.

 

WRAP and OAuth are competing protocols and this conflict can only be resolved by a new protocol replacing both. OAuth will need to chang= e to accommodate the use cases driving WRAP’s development. While this is certainly my intention, the IETF process does not guarantee that. Meanwhile= , at least some of WRAP’s three corporate sponsors are going to ship runni= ng code using it, and it is actively being promoted as a viable alternative. T= his is not criticism (at least not in this context), just  a matter of fac= t.

 

The IETF WG is going to review and consider the many new (go= od) ideas contained in WRAP as soon as it is submitted as input into the WG in the fo= rm of an I-D. I am grateful to the authors for making it available in this man= ner. It certainly makes my life easier.

 

I am hoping that the IETF WG can produce stable implementers drafts soon which will provide developers a better alternative than both OA= uth 1.0 and WRAP. The next few months will tell if this move has hurt the OAuth brand and how it will impact what we end up calling the new WG protocol.

 

All of this is nothing but the usual tension between the nee= ds of corporations to deliver products on their own timeline and the slow spee= d of standards development, especially for something with a high profile like OA= uth. But it would have moved much faster if the energy spent on WRAP was instead invested here.

 

EHL

 

 

 

 

 

 

 

From: oauth-wrap-wg= @googlegroups.com [mailto:oauth-wrap-wg@googlegroups.com] On Behalf Of Chris Messina Sent: Wednesday, November 11, 2009 6:51 PM
To: Paul C. Bryan
Cc: oauth@ietf.org; oauth@googlegroups.com; oauth-wrap-wg@googlegroups.com; John Panzer; Dick Hardt; Brian Eaton; Eric Sachs
Subject: [WRAP] Re: [OAUTH-WG] OAuth WRAP

 

On Tue, Nov 10, 2009 at 1:40 PM, Paul = C. Bryan <email@pbryan.net>=  wrote:


It seems to me that without simple guidelines on what's reasonable to be called "OAuth", anyone can propose a protocol that purpor= ts to be related in some way to OAuth, at the expense of community confus= ion and dilution of its meaning. Is there a way to mitigate this kind of occurrence other than by simply dismissing it as noise?=

 

 

Hi Paul,

 

This is an important point and one that drove the move to rename WRAP to OAuth W= RAP.

 

Let me explain how this decision was made, with an eye to what it means for oth= er projects calling themselves "OAuth".

 

Dick Hardt originally reached out to various members of the OAuth community in August and explained what he, Brian Eaton, and Allen Tom were working on (perhaps there were others, but they seem like the core group). At the time= , they called the initiative "Simple OAuth" — "simple&qu= ot; because of its reliance on HTTPS for handling the crypto. While moving the crypto to SSL simplified the protocol and removed the need for signing (the biggest problem for developers implementing OAuth) it created a new burden, which was obtaining a certificate.

 

Now, the point was made to me that anyone serious about security will have to ob= tain an SSL cert anyway, so that wasn't such a big deal. However, from the perspective of the individual or independent developer, I felt like this wa= s a fairly serious change in OAuth, and a challenge to the promise of the OAuth protocol (namely one protocol for authorization, regardless of the size of = your organization). I want people who run their own WordPress installs on a shar= ed host to be able to use OAuth just as large providers like Google and Yahoo = do.

 

I didn't want this new effort to use the name OAuth for exactly the reasons t= hat you specified. This seemed like a fork of the project and a dilution of the brand. It also seemed to conflict with Eran's work here at the IETF and I encouraged Dick to seek a more transparent process to developing the protoc= ol.

 

Several weeks went by and progress was made — including the eventual renaming= of the protocol to WRAP. This seemed like a fairly satisfactory development.

 

At IIW, Dick presented a joint session with Brian Eaton (Google) on WRAP. Ther= e was considerable interest and many suggestions and improvements were propos= ed.

 

Following the session, I reconsidered my position. My original concern with WRAP (whe= n it was called "Simple OAuth") was that it would fragment the efforts= of the community. If a new protocol came out calling itself "Simple OAuth", people would gravitate to it and potentially abandon work on improving the core spec. Now with WRAP clearly taking cycles from the peopl= e at Yahoo, Google, and Microsoft who would otherwise be working on OAuth Core, = we had a decision to make: refuse them the ability to use the brand or find a middle ground that might pave the way for similar implementation-driven pro= jects to find a foothold in the OAuth community.

 

On top of that, the OAuth community must confront the simplicity and elegance = of Facebook Connect. Although not everyone is paying attention to Facebook, th= eirs is a significant enough distraction from standards-based work that we must = keep in mind that OAuth does not exist in a vacuum. From a competitive perspecti= ve, we must constantly work to improve our technology, and make it easier to ad= opt the "open" and "universal" solution — to the poin= t where Facebook could adopt it.

 

In that light, it's also important to remember where OAuth came from. 

 

The original contributors to OAuth were a small, tight knit group of folks solv= ing a problem that each of them shared. They looked to the work that had come before them — for patterns and solutions that had been established by= the Googles, Yahoos, Flickrs, Microsofts, and AOLs of the web. What they came u= p with was, unexpectedly, adopted by most of the companies that were the inspiration for the universal solution.

 

That said, looking back, OAuth itself was largely developed in semi-secrecy, wit= h a closed mailing list and a private spec that didn't see the light of day unt= il months into the process. I know this because I was the one that made the decision to keep our work private. Whether we like it or not, the best work doesn't always come from completely transparent processes and so I'd be a hypocrite if I didn't evaluate WRAP in the same light that lead to the orig= inal success of OAuth.

 

Now, when it came to deciding what to call WRAP, well... that was more of a political calculation than a technical one. Dick had done the right thing i= n coming to us early and telling us what he was working on. I wish it had happened on the public list, but that was his decision to make and the fact= of the matter is: they're damned near a 1.0 spec and are now ready for feedback. 

 

This is a perfectly valid way to develop specs and standards — especially since they're leading with an implementation. OAuth Core 1.0 captured the b= est thinking around del-auth when it was produced — and represented the beginning of a collaborative conversation about how to move away from passw= ord confetti. 

 

In the time since OAuth was launched, we've seen a multifold increase in the number of sites that no longer collect user passwords and instead use some = form of the OAuth pattern. From my perspective, that's a massive improvement ove= r the previous status quo. The OAuth project has raised awareness of the prob= lem of user authentication credentials being passed to parties that shouldn't h= ave them, and it's lead to the development of a viable and more powerful alternative. But that work isn't finished — and when it comes to deploying this alternative in a widespread way, it turns out that what work= s for one kind of developer or provider doesn't work for all of them.<= /span>

 

Therefore, I see WRAP as an experimental branch of OAuth — and one that's closer= in spirit, goals, and intention to OAuth than different from it. 

 

The work that Eran is doing now on OAuth 2.0 will invariably have to consider i= t — and even he accepts that there are some good ideas built into it. W= e also know now that signing is not trivial and is one central element of OAu= th that is inhibiting its adoption, probably more than any other. Therefore, t= here is a need to improve the usability of OAuth, and WRAP seems to be squarely aimed at offering a solution to that problem — while also offering a = more deployable solution for larger, distributed providers.

 

Given all this, it seemed to me that WRAP was more "in the family of OAuth&q= uot; than a distant cousin — or one that should necessarily have to develo= p its own, independent community. We're all trying to solve similar and relat= ed problems, and we need cohesion and consistency in the message that we offer= to the world. Forking OAuth at this stage in its development is not, in my estimation, an option, and is why I changed my mind and decided that WRAP should be renamed to OAuth WRAP.

 

Of course it's up to the OAuth WRAP maintainers to make their case and answer = the community's questions and criticisms — but I'd much rather have them = do that within the existing community infrastructure than separately.

 

If other projects wish to call themselves "OAuth", I hope that they'= ll have to run through a similar gauntlet of proving how they relate to this broader initiative, and how they're improving the overall stack of best practices and patterns that make up the OAuth technology. Stagnant technolo= gy is dead technology, and I'm happy to see at least a vibrant conversation ab= out what does and doesn't fit into OAuth.

 

That was probably more than you wanted to know, but I felt it was worth explaini= ng the WRAP -> OAuth WRAP lineage.

 

Chris

 

On Tue, 2009-11-10 at 14:16 -0700, Eran Hammer-Lahav wrote:
> My 2c:
]]>
> WRAP was developed out of necessity due to limitations in OAuth and > product release schedule. Without going into too much detail about
> whether a whole new protocol was really necessary, the WRAP authors > felt that it was, and that their timeline could not accommodate
> waiting for the OAUTH WG to accommodate their use cases in the new
> version of the spec. We now have a new and separate spec in the space.=
]]>
> I have encouraged the authors to submit their spec as input for the WG=
> and to collaborate to make the upcoming WG spec cover their use case.<= br> > The goal would be to render the separate WRAP spec unnecessary. How > they or others would choose to apply this to their implementation is > beyond my control or (TBH) interest.
]]>
> Most of the innovative ideas in WRAP are around the delegation flow > (and there are some good ideas in there). I plan to use some of that > as the basis for the new delegation spec. On the authentication side,<= br> > WRAP uses bearer token with no crypto which will be supported by the > PLAIN flavor.
]]>
> As for how to manage community expectations, the OAuth brand, etc.: I<= br> > was opposed to putting WRAP under the OAuth brand (the entire effort > started as “Simple OAuth”). Others felt that pretending WR= AP was an
> OAuth profile (it is not) and naming it as such would be less
> confusing or less damaging to the OAuth brand (if you call it the same=
> thing, there is no competition). I didn’t care enough to (contin= ue)
> that argument given my view that by the time WRAP will get the wide > attention OAuth has, this WG will produce stable drafts of the new
> OAuth and will make this irrelevant.
]]>
> EHL
]]>
]]>
]]>
]]>
> On 11/10/09 11:56 AM, "Paul C. Bryan" <email@pbryan.net&g= t; wrote:
]]>
>         I guess I must admit I= 'm a bit surprised that the general
>         consensus
>         would be to merge with/profile WRAP as OAuth, as the deltas
>         between the
>         two protocols as defin= ed seems quite substantial. Does this
>         mean that
>         for all intents and pu= rposes I should consider the existing
>         OAuth IETF
>         drafts to date to be deprecated in favour of WRAP?
]]>
>         Paul
]]>
>         On Tue, 2009-11-10 at 19:46 +0000, Dick Hardt wrote:
>         > Good question. Gi= ven the positive reception WRAP received at
>         IIW and
>         > that capabilities= in WRAP are expected to come out of the
>         work in the
>         > IETF OAuth WG, th= ere was consensus from the OAuth community
>         to include
>         > WRAP as OAuth pro= files.
>         >
>         > -- Dick
>         >
>         > On 2009-11-10, at 10:06 AM, "Paul C. Bryan"
>         <email@pbryan.net&g= t; wrote:
>         >
>         > > Hi Dick:
>         > >
>         > > Given that W= RAP is so different from OAuth (as I know it),
>         other than
>         > > the fact tha= t OAuth could be used to negotiate the
>         issuance of a WRAP
>         > > refresh toke= n, I'm curious why you chose to associate this
>         with
>         > > OAuth by
>         > > giving it an "OAuth" prefix. It seems to me that it would
>         only create
>         > > confusion in this space.
>         > >
>         > > Paul
>         > >
>         > > On Tue, 2009-11-10 at 17:52 +0000, Dick Hardt wrote:
>         > >> At IIW l= ast week, myself, Biran Eaton from Google and
>         Allen Tom from
>         > >> Yahoo! presented what is now called OAuth WRAP
>         > >>
>         > >> The spec= s and discussion specific to those documents is
>         at:
>         > >>
>         > >> &nb= sp;  htt= p://groups.google.com/group/oauth-wrap-wg
>         > >>
>         > >> We plan = to submit the document as an I-D next week when
>         I-D
>         > >> submissi= on
>         > >> is open again, and for further work to occur in the IETF
>         OAuth WG.
>         > >>
>         > >> -- Dick<= br> >         > >> _______________________________________________
>         > >> OAuth mailing list
>         > >> OAuth@ietf.org
>         > >> http= s://www.ietf.org/mailman/listinfo/oauth
>         > >
>         > > _______________________________________________
>         > > OAuth mailin= g list
>         > > OAuth@i= etf.org
>         > > http= s://www.ietf.org/mailman/listinfo/oauth
>         > >
]]>
>         _______________________________________________
>         OAuth mailing list
>         OAuth@ietf.org >         http= s://www.ietf.org/mailman/listinfo/oauth
]]>

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

 


-- 

Chris Messina

Open Web Advocate

 

Personal: http://factoryjoe.com=

Follow me on Twitter: http://twit= ter.com/chrismessina

 

Citizen Agency: http://citizenagency.com=

 

This email is:   [ ] shareable    [X] ask first   [ ] private


--~--~---------~--~----~------------~-------~--~----~
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=3Den
-~----------~----~----~----~------~----~------~--~---

--_000_90C41DD21FB7C64BB94121FBBC2E72343785102B46P3PW5EX1MB01E_-- From eran@hueniverse.com Thu Nov 12 00:16:59 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBA0D3A6935 for ; Thu, 12 Nov 2009 00:16:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gdwD+Nxh6y0R for ; Thu, 12 Nov 2009 00:16:59 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id EEAE33A6A24 for ; Thu, 12 Nov 2009 00:16:58 -0800 (PST) Received: (qmail 7720 invoked from network); 12 Nov 2009 08:17:27 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 12 Nov 2009 08:17:27 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 12 Nov 2009 01:17:27 -0700 From: Eran Hammer-Lahav To: "oauth@ietf.org" Date: Thu, 12 Nov 2009 01:17:15 -0700 Thread-Topic: [OAUTH-WG] why are we signing? Thread-Index: AcpjOxC9Jywn9WdvQaucgA3t0oWNLwANOzDQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343785102B49@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <35D50F5C-3982-4298-A9E0-86A528F5C5D3@jkemp.net> <4A956CE47D1066408D5C7EB34368A5110551FFC1@S4DE8PSAAQC.mitte.t-com.de> 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 Subject: Re: [OAUTH-WG] why are we signing? X-BeenThere: oauth@ietf.org X-Mailman-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, 12 Nov 2009 08:16:59 -0000 As a matter of process, I would suggest looking at what the 1.0 HMAC-SHA1 m= ethod signs, and discuss if it is where we should be. We are working with a= n existing draft and should structure our discussions as feedback to that p= oint of reference. This doesn't limit the conclusion in any way, and is how= this WG has been chartered. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Brian Eaton > Sent: Wednesday, November 11, 2009 5:54 PM > To: BeckW@telekom.de > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] why are we signing? >=20 > So we've got at least five different use cases for signing requests > with the oauth access token and token secret. >=20 > Sweet. >=20 > The downside to the use cases is that they all have incompatible > signature base strings. I'd like to see us come up with something so > that we don't have to reinvent the base string again for every single > use case. >=20 > Cheers, > Brian >=20 > On Wed, Nov 11, 2009 at 5:49 PM, wrote: > > > > On Mon, Nov 9, 2009 at 6:28 AM, John Kemp wrote: > >> If we are only interested in i) [authenticating the entity] then > > signing any piece of the message might > >> be sufficient. If we are interested in ii) [binding the signature to > > the message] (or some other security property) > >> then we will need to identify which pieces of the message we want to > > provide > >> that, or other, security properties for. > > > >> Brian Eaton wrote: > >> OK, let me try to summarize what I've heard on this thread about the > >> different use-cases for message signing: > >> > >> - sign the HTTP request > >> =A0 Used to prevent MITM from replaying token to a different URL. > =A0Also > >> limits the replay attack window to minutes instead of hours. > >> > >> - sign various other parts of the message > >> =A0 DKIM: signs various message headers > >> =A0 SIP: unspecified, just says "relevant parts of SIP request" > > Hannes Tschofenig suggested handle SIP messages the way described in > RfC > > 4474 (SIP identity). It lists the parts of a SIP messsage that need > to > > be protected. > > > > Wolfgang > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From jpanzer@google.com Thu Nov 12 07:45:18 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97E5E3A6A2D for ; Thu, 12 Nov 2009 07:45:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[AWL=0.000, 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 RTiBkxKfAUmD for ; Thu, 12 Nov 2009 07:45:17 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 6C7353A6A19 for ; Thu, 12 Nov 2009 07:45:17 -0800 (PST) Received: from spaceape12.eur.corp.google.com (spaceape12.eur.corp.google.com [172.28.16.146]) by smtp-out.google.com with ESMTP id nACFjjN3014637 for ; Thu, 12 Nov 2009 15:45:45 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1258040745; bh=H7m93w60xgly9MuiLN8mC9H/Cjk=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=a5G9WBdFwFMg3agfrPn2mgGe0loJI+vlO8GnVoZpmuhowieezStHk5Kkj5RnCB+kq gDqiaXAN+wxHhO4zyru2g== 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=M/yq9iFX3+BbJX+zrq5QFTv4mAdqVD++zhcQS/Y44dD7LHKyN7Yg6xZYGkw6BiOQP av+OatGBReydwkzz+NyPw== Received: from pwi15 (pwi15.prod.google.com [10.241.219.15]) by spaceape12.eur.corp.google.com with ESMTP id nACFjTnE001340 for ; Thu, 12 Nov 2009 07:45:42 -0800 Received: by pwi15 with SMTP id 15so1453730pwi.24 for ; Thu, 12 Nov 2009 07:45:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.115.102.18 with SMTP id e18mr6261611wam.174.1258040740495; Thu, 12 Nov 2009 07:45:40 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343785102B49@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <35D50F5C-3982-4298-A9E0-86A528F5C5D3@jkemp.net> <4A956CE47D1066408D5C7EB34368A5110551FFC1@S4DE8PSAAQC.mitte.t-com.de> <90C41DD21FB7C64BB94121FBBC2E72343785102B49@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 12 Nov 2009 07:45:40 -0800 Message-ID: From: John Panzer 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] why are we signing? X-BeenThere: oauth@ietf.org X-Mailman-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, 12 Nov 2009 15:45:18 -0000 I think that https plus bearer token is sufficient for 90% of use cases. I haven't heard a first principles argument otherwise. If for no other reason than the record, could the proponents of signing explain why bearer token over TLS will not meet their needs? On Thursday, November 12, 2009, Eran Hammer-Lahav wro= te: > As a matter of process, I would suggest looking at what the 1.0 HMAC-SHA1= method signs, and discuss if it is where we should be. We are working with= an existing draft and should structure our discussions as feedback to that= point of reference. This doesn't limit the conclusion in any way, and is h= ow this WG has been chartered. > > EHL > > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Brian Eaton >> Sent: Wednesday, November 11, 2009 5:54 PM >> To: BeckW@telekom.de >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] why are we signing? >> >> So we've got at least five different use cases for signing requests >> with the oauth access token and token secret. >> >> Sweet. >> >> The downside to the use cases is that they all have incompatible >> signature base strings. =A0I'd like to see us come up with something so >> that we don't have to reinvent the base string again for every single >> use case. >> >> Cheers, >> Brian >> >> On Wed, Nov 11, 2009 at 5:49 PM, =A0 wrote: >> > >> > On Mon, Nov 9, 2009 at 6:28 AM, John Kemp wrote: >> >> If we are only interested in i) [authenticating the entity] then >> > signing any piece of the message might >> >> be sufficient. If we are interested in ii) [binding the signature to >> > the message] (or some other security property) >> >> then we will need to identify which pieces of the message we want to >> > provide >> >> that, or other, security properties for. >> > >> >> Brian Eaton wrote: >> >> OK, let me try to summarize what I've heard on this thread about the >> >> different use-cases for message signing: >> >> >> >> - sign the HTTP request >> >> =A0 Used to prevent MITM from replaying token to a different URL. >> =A0Also >> >> limits the replay attack window to minutes instead of hours. >> >> >> >> - sign various other parts of the message >> >> =A0 DKIM: signs various message headers >> >> =A0 SIP: unspecified, just says "relevant parts of SIP request" >> > Hannes Tschofenig suggested handle SIP messages the way described in >> RfC >> > 4474 (SIP identity). It lists the parts of a SIP messsage that need >> to >> > be protected. >> > >> > Wolfgang >> > >> _______________________________________________ >> OAuth mailing 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 -- John Panzer / Google jpanzer@google.com / abstractioneer.org / @jpanzer From beaton@google.com Thu Nov 12 08:11:40 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 557603A6BF8 for ; Thu, 12 Nov 2009 08:11:40 -0800 (PST) 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 SlFo3I1qXv2j for ; Thu, 12 Nov 2009 08:11:39 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 92FB83A6ACC for ; Thu, 12 Nov 2009 08:11:38 -0800 (PST) Received: from wpaz37.hot.corp.google.com (wpaz37.hot.corp.google.com [172.24.198.101]) by smtp-out.google.com with ESMTP id nACGC6Oa027021 for ; Thu, 12 Nov 2009 16:12:06 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1258042326; bh=YtuZDqKYRtrYA7hoQ/jh4LKrweY=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=BOSASK01we7Vpy4zXqGKDCC+8IyJUk+Y2CDQuhzXO/hphPNQH6lFsFigTxdqNFt6r XiMteMdn5kY638xVzzRwg== 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=lhlEXbUs+rOaqBDfkwnLprfrjpp7nyxVUDP2gfSzOTUqXloCapt0Pfdl2SHB9Fm4J y+9UFrF7+ubiXDrQ8qbWg== Received: from pzk13 (pzk13.prod.google.com [10.243.19.141]) by wpaz37.hot.corp.google.com with ESMTP id nACGC3US022834 for ; Thu, 12 Nov 2009 08:12:03 -0800 Received: by pzk13 with SMTP id 13so1663688pzk.25 for ; Thu, 12 Nov 2009 08:12:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.136.19 with SMTP id j19mr174706rvd.187.1258042323261; Thu, 12 Nov 2009 08:12:03 -0800 (PST) In-Reply-To: References: <35D50F5C-3982-4298-A9E0-86A528F5C5D3@jkemp.net> <4AFB2940.2030709@stpeter.im> Date: Thu, 12 Nov 2009 08:12:03 -0800 Message-ID: From: Brian Eaton To: "RL 'Bob' Morgan" 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] OAuth WRAP X-BeenThere: oauth@ietf.org X-Mailman-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, 12 Nov 2009 16:11:40 -0000 On Wed, Nov 11, 2009 at 6:25 PM, RL 'Bob' Morgan wrote: > It is my impression that the discussions that led to WRAP were around the > observation by some large organizations that they find the STS pattern > attractive to manage access with partners of all kinds; but that the WS-* > stack is hard to deploy; and OAuth does something much similar and is muc= h > easier to deploy. =A0So they'd like a "RESTized STS" or a "OAuth with an = STS > in it". =A0That's more or less what I see in this proposal, though I have= n't > read it in detail. Pretty close. I'd add that the notion of having a highly secured credential issuing service and less trusted application servers is a pretty old one. It's baked into most trusted third-party authentication protocols, older ones like kerberos, and newer ones like SAML. Cheers, Brian From eran@hueniverse.com Thu Nov 12 23:17:50 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE21C3A694E for ; Thu, 12 Nov 2009 23:17:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2gh6sOmVbpqA for ; Thu, 12 Nov 2009 23:17:49 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 900A03A68A9 for ; Thu, 12 Nov 2009 23:17:49 -0800 (PST) Received: (qmail 17860 invoked from network); 13 Nov 2009 07:18:16 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 13 Nov 2009 07:18:16 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Fri, 13 Nov 2009 00:18:16 -0700 From: Eran Hammer-Lahav To: John Panzer Date: Fri, 13 Nov 2009 00:18:06 -0700 Thread-Topic: [OAUTH-WG] why are we signing? Thread-Index: AcpjrzLh9CPO7seuS3KLVxwxHjgfeQAgFJeA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343785102E58@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <35D50F5C-3982-4298-A9E0-86A528F5C5D3@jkemp.net> <4A956CE47D1066408D5C7EB34368A5110551FFC1@S4DE8PSAAQC.mitte.t-com.de> <90C41DD21FB7C64BB94121FBBC2E72343785102B49@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@ietf.org" Subject: Re: [OAUTH-WG] why are we signing? X-BeenThere: oauth@ietf.org X-Mailman-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, 13 Nov 2009 07:17:50 -0000 Are you suggesting using TLS for every protected resource or just for obtai= ning the token and refreshing it? OAuth today already supports this via the PLAINTEXT method (though not very= cleanly with all the other parameters still required even if useless). Also What use cases? And where is this 90% comes from? I for one have always rejected the argument that since cookies are already = so broken, there was little point in trying to make API security better. Wh= en we originally worked on OAuth we explicitly looked to prevent replay att= acks as well as intercepting and changing an authenticated request. We limi= ted our scope to protecting the request URI and (some) parameters. That pro= vided sufficient protection to the APIs people had in mind at the time whic= h were mostly GET/POST requests with just a few parameters. The body hash e= xtension then extended the usefulness of the protocol to other payloads. The delegation half of the protocol deals with exchanging passwords with to= kens. Those who find bearer token sufficient without any additional crypto = can simply focus their attention on that. On the authentication side, I wou= ld like to offer something other than "use TLS for everything" or risk atta= cks for ("only") 10 minutes. EHL > -----Original Message----- > From: John Panzer [mailto:jpanzer@google.com] > Sent: Thursday, November 12, 2009 7:46 AM > To: Eran Hammer-Lahav > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] why are we signing? >=20 > I think that https plus bearer token is sufficient for 90% of use > cases. I haven't heard a first principles argument otherwise. If for > no other reason than the record, could the proponents of signing > explain why bearer token over TLS will not meet their needs? >=20 > On Thursday, November 12, 2009, Eran Hammer-Lahav > wrote: > > As a matter of process, I would suggest looking at what the 1.0 HMAC- > SHA1 method signs, and discuss if it is where we should be. We are > working with an existing draft and should structure our discussions as > feedback to that point of reference. This doesn't limit the conclusion > in any way, and is how this WG has been chartered. > > > > EHL > > > > > >> -----Original Message----- > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > Behalf > >> Of Brian Eaton > >> Sent: Wednesday, November 11, 2009 5:54 PM > >> To: BeckW@telekom.de > >> Cc: oauth@ietf.org > >> Subject: Re: [OAUTH-WG] why are we signing? > >> > >> So we've got at least five different use cases for signing requests > >> with the oauth access token and token secret. > >> > >> Sweet. > >> > >> The downside to the use cases is that they all have incompatible > >> signature base strings. =A0I'd like to see us come up with something > so > >> that we don't have to reinvent the base string again for every > single > >> use case. > >> > >> Cheers, > >> Brian > >> > >> On Wed, Nov 11, 2009 at 5:49 PM, =A0 wrote: > >> > > >> > On Mon, Nov 9, 2009 at 6:28 AM, John Kemp wrote: > >> >> If we are only interested in i) [authenticating the entity] then > >> > signing any piece of the message might > >> >> be sufficient. If we are interested in ii) [binding the signature > to > >> > the message] (or some other security property) > >> >> then we will need to identify which pieces of the message we want > to > >> > provide > >> >> that, or other, security properties for. > >> > > >> >> Brian Eaton wrote: > >> >> OK, let me try to summarize what I've heard on this thread about > the > >> >> different use-cases for message signing: > >> >> > >> >> - sign the HTTP request > >> >> =A0 Used to prevent MITM from replaying token to a different URL. > >> =A0Also > >> >> limits the replay attack window to minutes instead of hours. > >> >> > >> >> - sign various other parts of the message > >> >> =A0 DKIM: signs various message headers > >> >> =A0 SIP: unspecified, just says "relevant parts of SIP request" > >> > Hannes Tschofenig suggested handle SIP messages the way described > in > >> RfC > >> > 4474 (SIP identity). It lists the parts of a SIP messsage that > need > >> to > >> > be protected. > >> > > >> > Wolfgang > >> > > >> _______________________________________________ > >> OAuth mailing 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 > -- > -- > John Panzer / Google > jpanzer@google.com / abstractioneer.org / @jpanzer From beaton@google.com Fri Nov 13 00:01:26 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 034913A683D for ; Fri, 13 Nov 2009 00:01:26 -0800 (PST) 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 Buzwot8W-hk2 for ; Fri, 13 Nov 2009 00:01:25 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 13B783A68DD for ; Fri, 13 Nov 2009 00:01:24 -0800 (PST) Received: from zps37.corp.google.com (zps37.corp.google.com [172.25.146.37]) by smtp-out.google.com with ESMTP id nAD81ptJ024811 for ; Fri, 13 Nov 2009 08:01:53 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1258099313; bh=lsdVzfCXxhAyEhDfrfAhGDSuO/I=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=YL/zR2Wwsefec33QPc8Vt2R5OgcpS/uKXCac9KTBwqnpr8ksJPG7YgV+bqZdlqZzA iaefF6OH13Sw5VeR6IQsA== 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=eH3RPuh/RVeP/AH13wsyDh1KZg7jcVjYC0sNmFLNa/7tCdGUXxf2CwyEc4etkN41u P6OtNBfQIxDDoNxUxjgbA== Received: from pxi29 (pxi29.prod.google.com [10.243.27.29]) by zps37.corp.google.com with ESMTP id nAD81lwS020731 for ; Fri, 13 Nov 2009 00:01:49 -0800 Received: by pxi29 with SMTP id 29so2129985pxi.1 for ; Fri, 13 Nov 2009 00:01:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.143.19 with SMTP id q19mr236797rvd.17.1258099307726; Fri, 13 Nov 2009 00:01:47 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343785102E58@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <35D50F5C-3982-4298-A9E0-86A528F5C5D3@jkemp.net> <4A956CE47D1066408D5C7EB34368A5110551FFC1@S4DE8PSAAQC.mitte.t-com.de> <90C41DD21FB7C64BB94121FBBC2E72343785102B49@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785102E58@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Fri, 13 Nov 2009 00:01:47 -0800 Message-ID: From: Brian Eaton To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] why are we signing? X-BeenThere: oauth@ietf.org X-Mailman-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, 13 Nov 2009 08:01:26 -0000 On Thu, Nov 12, 2009 at 11:18 PM, Eran Hammer-Lahav wrote: > The body hash extension then extended the usefulness of the protocol to other payloads. Careful how much faith you put in the body hash extension. =) The appendix has lots of caveats about how hard it is to deploy in practice. I don't expect most service providers to be able to do it. From eran@hueniverse.com Fri Nov 13 08:19:49 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78C083A685D for ; Fri, 13 Nov 2009 08:19:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WPNa5g3YPXWJ for ; Fri, 13 Nov 2009 08:19:48 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id B96013A67D3 for ; Fri, 13 Nov 2009 08:19:48 -0800 (PST) Received: (qmail 7064 invoked from network); 13 Nov 2009 16:20:17 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 13 Nov 2009 16:20:17 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Fri, 13 Nov 2009 09:20:16 -0700 From: Eran Hammer-Lahav To: Brian Eaton Date: Fri, 13 Nov 2009 09:20:08 -0700 Thread-Topic: [OAUTH-WG] why are we signing? Thread-Index: AcpkN4/wIK85Xtx+TvCm0tQoZ8kR3wARThdg Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343785102EE4@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <35D50F5C-3982-4298-A9E0-86A528F5C5D3@jkemp.net> <4A956CE47D1066408D5C7EB34368A5110551FFC1@S4DE8PSAAQC.mitte.t-com.de> <90C41DD21FB7C64BB94121FBBC2E72343785102B49@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785102E58@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@ietf.org" Subject: Re: [OAUTH-WG] why are we signing? X-BeenThere: oauth@ietf.org X-Mailman-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, 13 Nov 2009 16:19:49 -0000 True. But when deployed... At some point the complexity of the protocol tips over and TLS becomes a lo= t more attractive for protected resources requests. If you cannot gain easy= access to the raw entity-body then you don't really have much other option= s left other than secure the entire channel. EHL > -----Original Message----- > From: Brian Eaton [mailto:beaton@google.com] > Sent: Friday, November 13, 2009 12:02 AM > To: Eran Hammer-Lahav > Cc: John Panzer; oauth@ietf.org > Subject: Re: [OAUTH-WG] why are we signing? >=20 > On Thu, Nov 12, 2009 at 11:18 PM, Eran Hammer-Lahav > wrote: > > The body hash extension then extended the usefulness of the protocol > to other payloads. >=20 > Careful how much faith you put in the body hash extension. =3D) The > appendix has lots of caveats about how hard it is to deploy in > practice. I don't expect most service providers to be able to do it. From jpanzer@google.com Fri Nov 13 08:36:35 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF6693A6996 for ; Fri, 13 Nov 2009 08:36:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[AWL=0.000, 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 15yI4v6V-nik for ; Fri, 13 Nov 2009 08:36:34 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id 69E5E3A698E for ; Fri, 13 Nov 2009 08:36:34 -0800 (PST) Received: from wpaz13.hot.corp.google.com (wpaz13.hot.corp.google.com [172.24.198.77]) by smtp-out.google.com with ESMTP id nADGb3W7006610 for ; Fri, 13 Nov 2009 08:37:03 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1258130223; bh=koQ1ZbsDRrgd1GHlPqOU46jX2WA=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=XbQvRzmoLpGU9yadjoecQ3i3TAjLQkWNS1dIOFteuwZp68pTCbqh59eoBIC14y4ST cAKyGTK1UVQ7WK/NDbCAQ== 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=r5nHi7+BtP4GR5rvN1e3QbD0Y4R2srVJMZVuTXaOpWpq3wE3x+FgoOZeZqK7EMbdi 68vuOBgl+jHsfbM892ZUQ== Received: from pwj17 (pwj17.prod.google.com [10.241.219.81]) by wpaz13.hot.corp.google.com with ESMTP id nADGaYPP003449 for ; Fri, 13 Nov 2009 08:37:00 -0800 Received: by pwj17 with SMTP id 17so2281785pwj.5 for ; Fri, 13 Nov 2009 08:37:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.86.5 with SMTP id j5mr8222733wab.0.1258130220083; Fri, 13 Nov 2009 08:37:00 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343785102E58@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <35D50F5C-3982-4298-A9E0-86A528F5C5D3@jkemp.net> <4A956CE47D1066408D5C7EB34368A5110551FFC1@S4DE8PSAAQC.mitte.t-com.de> <90C41DD21FB7C64BB94121FBBC2E72343785102B49@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785102E58@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Fri, 13 Nov 2009 08:37:00 -0800 Message-ID: From: John Panzer 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] why are we signing? X-BeenThere: oauth@ietf.org X-Mailman-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, 13 Nov 2009 16:36:35 -0000 The 90% is just MHO. I think we should be sure that using TLS for everything is unviable in 2010 before diving into complicated signing and binding. For my use cases, non body signed requests are about equivalent to bearer token in terms of security; body signing is an interop pain point; absent a deus ex machina with a new, secure, simple, ip-free, interoperable algorithm for body signing I would personally use PLAINTEXT over TLS for resource access and move on to more important things. Note that nothing stops someone from defining a data protocol which supplies signatures and even binds to the important bits of the envelope. And if you can get XML Dsig to work interoperably for your protocol, great! But OAuth 2 could be defined to leave that to protocols and extensions. In theory this would make things less interoperable, but in practice signatures are a huge interop pain point anyway (IMHO) so I do not believe there is a practical difference in the field. On Thursday, November 12, 2009, Eran Hammer-Lahav wro= te: > Are you suggesting using TLS for every protected resource or just for obt= aining the token and refreshing it? > > OAuth today already supports this via the PLAINTEXT method (though not ve= ry cleanly with all the other parameters still required even if useless). > > Also What use cases? And where is this 90% comes from? > > I for one have always rejected the argument that since cookies are alread= y so broken, there was little point in trying to make API security better. = When we originally worked on OAuth we explicitly looked to prevent replay a= ttacks as well as intercepting and changing an authenticated request. We li= mited our scope to protecting the request URI and (some) parameters. That p= rovided sufficient protection to the APIs people had in mind at the time wh= ich were mostly GET/POST requests with just a few parameters. The body hash= extension then extended the usefulness of the protocol to other payloads. > > The delegation half of the protocol deals with exchanging passwords with = tokens. Those who find bearer token sufficient without any additional crypt= o can simply focus their attention on that. On the authentication side, I w= ould like to offer something other than "use TLS for everything" or risk at= tacks for ("only") 10 minutes. > > EHL > >> -----Original Message----- >> From: John Panzer [mailto:jpanzer@google.com] >> Sent: Thursday, November 12, 2009 7:46 AM >> To: Eran Hammer-Lahav >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] why are we signing? >> >> I think that https plus bearer token is sufficient for 90% of use >> cases. =A0I haven't heard a first principles argument otherwise. =A0If f= or >> no other reason than the record, could the proponents of signing >> explain why bearer token over TLS will not meet their needs? >> >> On Thursday, November 12, 2009, Eran Hammer-Lahav >> wrote: >> > As a matter of process, I would suggest looking at what the 1.0 HMAC- >> SHA1 method signs, and discuss if it is where we should be. We are >> working with an existing draft and should structure our discussions as >> feedback to that point of reference. This doesn't limit the conclusion >> in any way, and is how this WG has been chartered. >> > >> > EHL >> > >> > >> >> -----Original Message----- >> >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >> Behalf >> >> Of Brian Eaton >> >> Sent: Wednesday, November 11, 2009 5:54 PM >> >> To: BeckW@telekom.de >> >> Cc: oauth@ietf.org >> >> Subject: Re: [OAUTH-WG] why are we signing? >> >> >> >> So we've got at least five different use cases for signing requests >> >> with the oauth access token and token secret. >> >> >> >> Sweet. >> >> >> >> The downside to the use cases is that they all have incompatible >> >> signature base strings. =A0I'd like to see us come up with something >> so >> >> that we don't have to reinvent the base string again for every >> single >> >> use case. >> >> >> >> Cheers, >> >> Brian >> >> >> >> On Wed, Nov 11, 2009 at 5:49 PM, =A0 wrote: >> >> > >> >> > On Mon, Nov 9, 2009 at 6:28 AM, John Kemp wrote: >> >> >> If we are only interested in i) [authenticating the entity] then >> >> > signing any piece of the message might >> >> >> be sufficient. If we are interested in ii) [binding the signature >> to >> >> > the message] (or some other security property) >> >> >> then we will need to identify which pieces of the message we want >> to >> >> > provide >> >> >> that, or other, security properties for. >> >> > >> >> >> Brian Eaton wrote: >> >> >> OK, let me try to summarize what I've heard on this thread about >> the >> >> >> different use-cases for message signing: >> >> >> >> >> >> - sign the HTTP request >> >> >> =A0 Used to prevent MITM from replaying token to a different URL. >> >> =A0Also >> >> >> limits the replay attack window to minutes instead of hours. >> >> >> >> >> >> - sign various other parts of the message >> >> >> =A0 DKIM: signs various message headers >> >> >> =A0 SIP: unspecified, just says "relevant parts of SIP request" >> >> > Hannes Tschofenig suggested handle SIP messages the way described >> in >> >> RfC >> >> > 4474 (SIP identity). It lists the parts of a SIP messsage that >> need >> >> to >> >> > be protected. >> >> > >> >> > Wolfgang >> >> > >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> https://www.ietf.org/mailman/listinfo/oauth >> > _______________________________________________ >> > OAuth mailing list >> > --=20 -- John Panzer / Google jpanzer@google.com / abstractioneer.org / @jpanzer From eran@hueniverse.com Fri Nov 13 09:21:30 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FE3D3A682D for ; Fri, 13 Nov 2009 09:21:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r+Yiki+79njJ for ; Fri, 13 Nov 2009 09:21:29 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 339753A681C for ; Fri, 13 Nov 2009 09:21:29 -0800 (PST) Received: (qmail 19222 invoked from network); 13 Nov 2009 17:21:55 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 13 Nov 2009 17:21:54 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Fri, 13 Nov 2009 10:21:51 -0700 From: Eran Hammer-Lahav To: John Panzer Date: Fri, 13 Nov 2009 10:21:43 -0700 Thread-Topic: [OAUTH-WG] why are we signing? Thread-Index: Acpkf4i19C8gcEdKTPCdTKR/r6BRVgABcmvg Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343785102F1F@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <35D50F5C-3982-4298-A9E0-86A528F5C5D3@jkemp.net> <4A956CE47D1066408D5C7EB34368A5110551FFC1@S4DE8PSAAQC.mitte.t-com.de> <90C41DD21FB7C64BB94121FBBC2E72343785102B49@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785102E58@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@ietf.org" Subject: Re: [OAUTH-WG] why are we signing? X-BeenThere: oauth@ietf.org X-Mailman-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, 13 Nov 2009 17:21:30 -0000 > -----Original Message----- > From: John Panzer [mailto:jpanzer@google.com] > Sent: Friday, November 13, 2009 8:37 AM > To: Eran Hammer-Lahav > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] why are we signing? >=20 > The 90% is just MHO. >=20 > I think we should be sure that using TLS for everything is unviable in > 2010 before diving into complicated signing and binding. For my use > cases, non body signed requests are about equivalent to bearer token > in terms of security; body signing is an interop pain point; absent a > deus ex machina with a new, secure, simple, ip-free, interoperable > algorithm for body signing I would personally use PLAINTEXT over TLS > for resource access and move on to more important things. >=20 > Note that nothing stops someone from defining a data protocol which > supplies signatures and even binds to the important bits of the > envelope. And if you can get XML Dsig to work interoperably for your > protocol, great! But OAuth 2 could be defined to leave that to > protocols and extensions. In theory this would make things less > interoperable, but in practice signatures are a huge interop pain > point anyway (IMHO) so I do not believe there is a practical > difference in the field. That's half of what we are explicitly chartered to do. My point is that peo= ple should focus on the parts of the protocol they care about. I think such= a reduction in functionality and scope would require a more explicit recon= sideration of this entire WG. I for one, see great value in offering some form of crypto-based security f= or cases where TLS is not suitable. I am also not buying the argument that we should avoid crypto because it is= hard. The same argument can be made about TLS (who really writes their own= libraries for that?). EHL > On Thursday, November 12, 2009, Eran Hammer-Lahav > wrote: > > Are you suggesting using TLS for every protected resource or just for > obtaining the token and refreshing it? > > > > OAuth today already supports this via the PLAINTEXT method (though > not very cleanly with all the other parameters still required even if > useless). > > > > Also What use cases? And where is this 90% comes from? > > > > I for one have always rejected the argument that since cookies are > already so broken, there was little point in trying to make API > security better. When we originally worked on OAuth we explicitly > looked to prevent replay attacks as well as intercepting and changing > an authenticated request. We limited our scope to protecting the > request URI and (some) parameters. That provided sufficient protection > to the APIs people had in mind at the time which were mostly GET/POST > requests with just a few parameters. The body hash extension then > extended the usefulness of the protocol to other payloads. > > > > The delegation half of the protocol deals with exchanging passwords > with tokens. Those who find bearer token sufficient without any > additional crypto can simply focus their attention on that. On the > authentication side, I would like to offer something other than "use > TLS for everything" or risk attacks for ("only") 10 minutes. > > > > EHL > > > >> -----Original Message----- > >> From: John Panzer [mailto:jpanzer@google.com] > >> Sent: Thursday, November 12, 2009 7:46 AM > >> To: Eran Hammer-Lahav > >> Cc: oauth@ietf.org > >> Subject: Re: [OAUTH-WG] why are we signing? > >> > >> I think that https plus bearer token is sufficient for 90% of use > >> cases. =A0I haven't heard a first principles argument otherwise. =A0If > for > >> no other reason than the record, could the proponents of signing > >> explain why bearer token over TLS will not meet their needs? > >> > >> On Thursday, November 12, 2009, Eran Hammer-Lahav > > >> wrote: > >> > As a matter of process, I would suggest looking at what the 1.0 > HMAC- > >> SHA1 method signs, and discuss if it is where we should be. We are > >> working with an existing draft and should structure our discussions > as > >> feedback to that point of reference. This doesn't limit the > conclusion > >> in any way, and is how this WG has been chartered. > >> > > >> > EHL > >> > > >> > > >> >> -----Original Message----- > >> >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >> Behalf > >> >> Of Brian Eaton > >> >> Sent: Wednesday, November 11, 2009 5:54 PM > >> >> To: BeckW@telekom.de > >> >> Cc: oauth@ietf.org > >> >> Subject: Re: [OAUTH-WG] why are we signing? > >> >> > >> >> So we've got at least five different use cases for signing > requests > >> >> with the oauth access token and token secret. > >> >> > >> >> Sweet. > >> >> > >> >> The downside to the use cases is that they all have incompatible > >> >> signature base strings. =A0I'd like to see us come up with > something > >> so > >> >> that we don't have to reinvent the base string again for every > >> single > >> >> use case. > >> >> > >> >> Cheers, > >> >> Brian > >> >> > >> >> On Wed, Nov 11, 2009 at 5:49 PM, =A0 wrote: > >> >> > > >> >> > On Mon, Nov 9, 2009 at 6:28 AM, John Kemp > wrote: > >> >> >> If we are only interested in i) [authenticating the entity] > then > >> >> > signing any piece of the message might > >> >> >> be sufficient. If we are interested in ii) [binding the > signature > >> to > >> >> > the message] (or some other security property) > >> >> >> then we will need to identify which pieces of the message we > want > >> to > >> >> > provide > >> >> >> that, or other, security properties for. > >> >> > > >> >> >> Brian Eaton wrote: > >> >> >> OK, let me try to summarize what I've heard on this thread > about > >> the > >> >> >> different use-cases for message signing: > >> >> >> > >> >> >> - sign the HTTP request > >> >> >> =A0 Used to prevent MITM from replaying token to a different > URL. > >> >> =A0Also > >> >> >> limits the replay attack window to minutes instead of hours. > >> >> >> > >> >> >> - sign various other parts of the message > >> >> >> =A0 DKIM: signs various message headers > >> >> >> =A0 SIP: unspecified, just says "relevant parts of SIP request" > >> >> > Hannes Tschofenig suggested handle SIP messages the way > described > >> in > >> >> RfC > >> >> > 4474 (SIP identity). It lists the parts of a SIP messsage that > >> need > >> >> to > >> >> > be protected. > >> >> > > >> >> > Wolfgang > >> >> > > >> >> _______________________________________________ > >> >> OAuth mailing list > >> >> OAuth@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/oauth > >> > _______________________________________________ > >> > OAuth mailing list > >> > >=20 > -- > -- > John Panzer / Google > jpanzer@google.com / abstractioneer.org / @jpanzer From jpanzer@google.com Fri Nov 13 09:33:30 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEE023A6896 for ; Fri, 13 Nov 2009 09:33:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 aXsw6-A538Eq for ; Fri, 13 Nov 2009 09:33:29 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 3147D3A6900 for ; Fri, 13 Nov 2009 09:33:29 -0800 (PST) Received: from wpaz21.hot.corp.google.com (wpaz21.hot.corp.google.com [172.24.198.85]) by smtp-out.google.com with ESMTP id nADHXvm9012535 for ; Fri, 13 Nov 2009 17:33:57 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1258133637; bh=LGQThWYeUmhsd0dVI+CGCV2Duvk=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=YyuLZrsj6TOywrFJ5rMaSuRuKSuEzhtqOpPna5ZAz44H619/J7rP+Yyezd39neEFI 1rkUWNItTMUao3IO5t4Ig== 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=oIrFUfaEkWWrcSCthbpvRX73U+3iijulGsZHgsvH4TVYVfIRE43Z3HdO3HO0nzP3z +mDR9PlSlA2+Xu8qF4OSQ== Received: from pxi38 (pxi38.prod.google.com [10.243.27.38]) by wpaz21.hot.corp.google.com with ESMTP id nADHXsH0014583 for ; Fri, 13 Nov 2009 09:33:54 -0800 Received: by pxi38 with SMTP id 38so2383913pxi.10 for ; Fri, 13 Nov 2009 09:33:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.248.7 with SMTP id v7mr248927wah.92.1258133634147; Fri, 13 Nov 2009 09:33:54 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343785102EE4@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <35D50F5C-3982-4298-A9E0-86A528F5C5D3@jkemp.net> <4A956CE47D1066408D5C7EB34368A5110551FFC1@S4DE8PSAAQC.mitte.t-com.de> <90C41DD21FB7C64BB94121FBBC2E72343785102B49@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785102E58@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785102EE4@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: John Panzer Date: Fri, 13 Nov 2009 09:33:34 -0800 Message-ID: To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=0016e64c3d9857e5c80478441030 X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] why are we signing? X-BeenThere: oauth@ietf.org X-Mailman-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, 13 Nov 2009 17:33:30 -0000 --0016e64c3d9857e5c80478441030 Content-Type: text/plain; charset=ISO-8859-1 I agree 100% with Eran below :) To frame the discussion: There's clearly a complexity scale here. At some point along this complexity scale, you get both better security and interoperability by simply switching to TLS. I think everybody agrees there is such a tipping point somewhere along the spectrum; there's just spirited discussion about where it lies. There's another issue of course: We're trying to optimize two variables, complexity and security, at once. This means you need to map a 2d problem to a 1d scalar, which means making choices, which means spirited discussion. Here are two meta-points: 1. You can add security with additional checks, restrictions, and signatures. You can never remove complexity once it's mandated. 2. Too much complexity is insecure! Both because people don't get it right, and because it hinders adoption of our more secure approach over the much easier status quo of sharing username and password with every web app on the Internet. -- John Panzer / Google jpanzer@google.com / abstractioneer.org / @jpanzer On Fri, Nov 13, 2009 at 8:20 AM, Eran Hammer-Lahav wrote: > True. But when deployed... > > At some point the complexity of the protocol tips over and TLS becomes a > lot more attractive for protected resources requests. If you cannot gain > easy access to the raw entity-body then you don't really have much other > options left other than secure the entire channel. > > EHL > > > -----Original Message----- > > From: Brian Eaton [mailto:beaton@google.com] > > Sent: Friday, November 13, 2009 12:02 AM > > To: Eran Hammer-Lahav > > Cc: John Panzer; oauth@ietf.org > > Subject: Re: [OAUTH-WG] why are we signing? > > > > On Thu, Nov 12, 2009 at 11:18 PM, Eran Hammer-Lahav > > wrote: > > > The body hash extension then extended the usefulness of the protocol > > to other payloads. > > > > Careful how much faith you put in the body hash extension. =) The > > appendix has lots of caveats about how hard it is to deploy in > > practice. I don't expect most service providers to be able to do it. > --0016e64c3d9857e5c80478441030 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I agree 100% with Eran below :)

To frame the discussion:= =A0There's clearly a complexity scale here. =A0At some point along thi= s complexity scale, you get both better security and interoperability by si= mply switching to TLS. =A0I think everybody agrees there is such a tipping = point somewhere along the spectrum; there's just spirited discussion ab= out where it lies.

There's another issue of course: =A0We're tryin= g to optimize two variables, complexity and security, at once. =A0This mean= s you need to map a 2d problem to a 1d scalar, which means making choices, = which means spirited discussion. =A0Here are two meta-points:

1. You can add security with additional checks, restric= tions, and signatures. =A0You can never remove complexity once it's man= dated.

2. Too much complexity is insecure! =A0Both= because people don't get it right, and because it hinders adoption of = our more secure approach over the much easier status quo of sharing usernam= e and password with every web app on the Internet.

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



On Fri, Nov 13, 2009 at 8:20 AM, Eran Ha= mmer-Lahav <era= n@hueniverse.com> wrote:
True. But when deployed...

At some point the complexity of the protocol tips over and TLS becomes a lo= t more attractive for protected resources requests. If you cannot gain easy= access to the raw entity-body then you don't really have much other op= tions left other than secure the entire channel.

EHL

> -----Original Message-----
> From: Brian Eaton [mailto:beaton@= google.com]
> Sent: Friday, November 13, 2009 12:02 AM
> To: Eran Hammer-Lahav
> Cc: John Panzer; oauth@ietf.org
> Subject: Re: [OAUTH-WG] why are we signing?
>
> On Thu, Nov 12, 2009 at 11:18 = PM, Eran Hammer-Lahav
> <eran@hueniverse.com>= wrote:
> > The body hash extension then extended the usefulness of the proto= col
> to other payloads.
>
> Careful how much faith you put in the body hash extension. =3D) =A0The=
> appendix has lots of caveats about how hard it is to deploy in
> practice. =A0I don't expect most service providers to be able to d= o it.

--0016e64c3d9857e5c80478441030-- From jpanzer@google.com Fri Nov 13 09:47:32 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79B0C3A672E for ; Fri, 13 Nov 2009 09:47:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 x-d0Yo9hVC4c for ; Fri, 13 Nov 2009 09:47:30 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id F27F53A67B4 for ; Fri, 13 Nov 2009 09:47:29 -0800 (PST) Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id nADHlwLe000485 for ; Fri, 13 Nov 2009 17:47:58 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1258134478; bh=ZO+Xwhkcl4qxTzlYOxxHQf42FZU=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=qRbIrOIYp8cStQ3h/jz5UrJsBJjR1fpGmver7YIEkYWGVUvHCBYeHrW3vQYMlSU+j g/CAe8Ak4auAWlrrBqwkw== 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=QGWXikrehod/BSpEmm1h7XuU8qzi8OQUJmgIh4wCxGosV6uUP7f7Pfa9XmVOQcmUG keOIMeO28U8y34vyzDASQ== Received: from pzk32 (pzk32.prod.google.com [10.243.19.160]) by wpaz17.hot.corp.google.com with ESMTP id nADHlswr029411 for ; Fri, 13 Nov 2009 09:47:55 -0800 Received: by pzk32 with SMTP id 32so2420046pzk.21 for ; Fri, 13 Nov 2009 09:47:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.115.99.4 with SMTP id b4mr8181013wam.88.1258134474110; Fri, 13 Nov 2009 09:47:54 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343785102F1F@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <35D50F5C-3982-4298-A9E0-86A528F5C5D3@jkemp.net> <4A956CE47D1066408D5C7EB34368A5110551FFC1@S4DE8PSAAQC.mitte.t-com.de> <90C41DD21FB7C64BB94121FBBC2E72343785102B49@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785102E58@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785102F1F@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: John Panzer Date: Fri, 13 Nov 2009 09:47:34 -0800 Message-ID: To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=0016e648f0ae68b8f904784442d3 X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] why are we signing? X-BeenThere: oauth@ietf.org X-Mailman-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, 13 Nov 2009 17:47:32 -0000 --0016e648f0ae68b8f904784442d3 Content-Type: text/plain; charset=ISO-8859-1 Replies inline (sorry for async postings): On Fri, Nov 13, 2009 at 9:21 AM, Eran Hammer-Lahav wrote: > > > > -----Original Message----- > > From: John Panzer [mailto:jpanzer@google.com] > > Sent: Friday, November 13, 2009 8:37 AM > > To: Eran Hammer-Lahav > > Cc: oauth@ietf.org > > Subject: Re: [OAUTH-WG] why are we signing? > > > > The 90% is just MHO. > > > > I think we should be sure that using TLS for everything is unviable in > > 2010 before diving into complicated signing and binding. For my use > > cases, non body signed requests are about equivalent to bearer token > > in terms of security; body signing is an interop pain point; absent a > > deus ex machina with a new, secure, simple, ip-free, interoperable > > algorithm for body signing I would personally use PLAINTEXT over TLS > > for resource access and move on to more important things. > > > > Note that nothing stops someone from defining a data protocol which > > supplies signatures and even binds to the important bits of the > > envelope. And if you can get XML Dsig to work interoperably for your > > protocol, great! But OAuth 2 could be defined to leave that to > > protocols and extensions. In theory this would make things less > > interoperable, but in practice signatures are a huge interop pain > > point anyway (IMHO) so I do not believe there is a practical > > difference in the field. > > That's half of what we are explicitly chartered to do. My point is that > people should focus on the parts of the protocol they care about. I think > such a reduction in functionality and scope would require a more explicit > reconsideration of this entire WG. > If the WG needs to consider it, then I move that we do the first, PLAINTEXT, relying-on-TLS-when-necessary half (at least to the point of an I-D that people can go implement) before moving on to the far more complex world of new signature algorithms. This doesn't mean having two specs, just stabilizing the bits nobody has serious arguments about so people who need the first half can move forward. Obviously things can change in draft, etc., but we're all playing the odds here and actual running code is important to have. > I for one, see great value in offering some form of crypto-based security > for cases where TLS is not suitable. > > I am also not buying the argument that we should avoid crypto because it is > hard. The same argument can be made about TLS (who really writes their own > libraries for that?). > Nobody; we get them from Ben Laurie. But they're already available everywhere, so nobody has to write them, while the OAuth 2 libraries, whatever they will be, are available nowhere right now. So whatever OAuth comes up with has to be _significantly_ simpler and easier than using openssl. > > EHL > > > On Thursday, November 12, 2009, Eran Hammer-Lahav > > wrote: > > > Are you suggesting using TLS for every protected resource or just for > > obtaining the token and refreshing it? > > > > > > OAuth today already supports this via the PLAINTEXT method (though > > not very cleanly with all the other parameters still required even if > > useless). > > > > > > Also What use cases? And where is this 90% comes from? > > > > > > I for one have always rejected the argument that since cookies are > > already so broken, there was little point in trying to make API > > security better. When we originally worked on OAuth we explicitly > > looked to prevent replay attacks as well as intercepting and changing > > an authenticated request. We limited our scope to protecting the > > request URI and (some) parameters. That provided sufficient protection > > to the APIs people had in mind at the time which were mostly GET/POST > > requests with just a few parameters. The body hash extension then > > extended the usefulness of the protocol to other payloads. > > > > > > The delegation half of the protocol deals with exchanging passwords > > with tokens. Those who find bearer token sufficient without any > > additional crypto can simply focus their attention on that. On the > > authentication side, I would like to offer something other than "use > > TLS for everything" or risk attacks for ("only") 10 minutes. > > > > > > EHL > > > > > >> -----Original Message----- > > >> From: John Panzer [mailto:jpanzer@google.com] > > >> Sent: Thursday, November 12, 2009 7:46 AM > > >> To: Eran Hammer-Lahav > > >> Cc: oauth@ietf.org > > >> Subject: Re: [OAUTH-WG] why are we signing? > > >> > > >> I think that https plus bearer token is sufficient for 90% of use > > >> cases. I haven't heard a first principles argument otherwise. If > > for > > >> no other reason than the record, could the proponents of signing > > >> explain why bearer token over TLS will not meet their needs? > > >> > > >> On Thursday, November 12, 2009, Eran Hammer-Lahav > > > > >> wrote: > > >> > As a matter of process, I would suggest looking at what the 1.0 > > HMAC- > > >> SHA1 method signs, and discuss if it is where we should be. We are > > >> working with an existing draft and should structure our discussions > > as > > >> feedback to that point of reference. This doesn't limit the > > conclusion > > >> in any way, and is how this WG has been chartered. > > >> > > > >> > EHL > > >> > > > >> > > > >> >> -----Original Message----- > > >> >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > > >> Behalf > > >> >> Of Brian Eaton > > >> >> Sent: Wednesday, November 11, 2009 5:54 PM > > >> >> To: BeckW@telekom.de > > >> >> Cc: oauth@ietf.org > > >> >> Subject: Re: [OAUTH-WG] why are we signing? > > >> >> > > >> >> So we've got at least five different use cases for signing > > requests > > >> >> with the oauth access token and token secret. > > >> >> > > >> >> Sweet. > > >> >> > > >> >> The downside to the use cases is that they all have incompatible > > >> >> signature base strings. I'd like to see us come up with > > something > > >> so > > >> >> that we don't have to reinvent the base string again for every > > >> single > > >> >> use case. > > >> >> > > >> >> Cheers, > > >> >> Brian > > >> >> > > >> >> On Wed, Nov 11, 2009 at 5:49 PM, wrote: > > >> >> > > > >> >> > On Mon, Nov 9, 2009 at 6:28 AM, John Kemp > > wrote: > > >> >> >> If we are only interested in i) [authenticating the entity] > > then > > >> >> > signing any piece of the message might > > >> >> >> be sufficient. If we are interested in ii) [binding the > > signature > > >> to > > >> >> > the message] (or some other security property) > > >> >> >> then we will need to identify which pieces of the message we > > want > > >> to > > >> >> > provide > > >> >> >> that, or other, security properties for. > > >> >> > > > >> >> >> Brian Eaton wrote: > > >> >> >> OK, let me try to summarize what I've heard on this thread > > about > > >> the > > >> >> >> different use-cases for message signing: > > >> >> >> > > >> >> >> - sign the HTTP request > > >> >> >> Used to prevent MITM from replaying token to a different > > URL. > > >> >> Also > > >> >> >> limits the replay attack window to minutes instead of hours. > > >> >> >> > > >> >> >> - sign various other parts of the message > > >> >> >> DKIM: signs various message headers > > >> >> >> SIP: unspecified, just says "relevant parts of SIP request" > > >> >> > Hannes Tschofenig suggested handle SIP messages the way > > described > > >> in > > >> >> RfC > > >> >> > 4474 (SIP identity). It lists the parts of a SIP messsage that > > >> need > > >> >> to > > >> >> > be protected. > > >> >> > > > >> >> > Wolfgang > > >> >> > > > >> >> _______________________________________________ > > >> >> OAuth mailing list > > >> >> OAuth@ietf.org > > >> >> https://www.ietf.org/mailman/listinfo/oauth > > >> > _______________________________________________ > > >> > OAuth mailing list > > >> > > > > > -- > > -- > > John Panzer / Google > > jpanzer@google.com / abstractioneer.org / @jpanzer > --0016e648f0ae68b8f904784442d3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Replies inline (sorry for async postings):

On Fri, Nov 13, 2009 at 9:21 AM, Eran Hammer-Lahav <= eran@hueniverse.com> w= rote:


> -----Original Message-----
> From: John Panzer [mailto:jpanze= r@google.com]
> Sent: Friday, November 13, 2009 8:37 AM
> To: Eran Hammer-Lahav
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] why are we signing?
>
> The 90% is just MHO.
>
> I think we should be sure that using TLS for everything is unviable in=
> 2010 before diving into complicated signing and binding. =A0For my use=
> cases, non body signed requests are about equivalent to bearer token > in terms of security; body signing is an interop pain point; absent a<= br> > deus ex machina with a new, secure, simple, ip-free, interoperable
> algorithm for body signing I would personally use PLAINTEXT over TLS > for resource access and move on to more important things.
>
> Note that nothing stops someone from defining a data protocol which > supplies signatures and even binds to the important bits of the
> envelope. =A0And if you can get XML Dsig to work interoperably for you= r
> protocol, great! =A0But OAuth 2 could be defined to leave that to
> protocols and extensions. =A0In theory this would make things less
> interoperable, but in practice signatures are a huge interop pain
> point anyway (IMHO) so I do not believe there is a practical
> difference in the field.

That's half of what we are explicitly chartered to do. My point i= s that people should focus on the parts of the protocol they care about. I = think such a reduction in functionality and scope would require a more expl= icit reconsideration of this entire WG.

If the WG needs to consider it, then I mov= e that we do the first, PLAINTEXT, relying-on-TLS-when-necessary half (at l= east to the point of an I-D that people can go implement) before moving on = to the far more complex world of new signature algorithms. =A0

This doesn't mean having two specs, just stabilizin= g the bits nobody has serious arguments about so people who need the first = half can move forward. =A0Obviously things can change in draft, etc., but w= e're all playing the odds here and actual running code is important to = have.


I for one, see great value in offering some form of crypto-based security f= or cases where TLS is not suitable.

I am also not buying the argument that we should avoid crypto because it is= hard. The same argument can be made about TLS (who really writes their own= libraries for that?).

Nobody; we get t= hem from Ben Laurie. =A0But they're already available everywhere, so no= body has to write them, while the OAuth 2 libraries, whatever they will be,= are available nowhere right now. =A0So whatever OAuth comes up with has to= be _significantly_ simpler and easier than using openssl.

=A0

EHL

> On Thursday, November 12, 2009, Eran Hammer-Lahav <eran@hueniverse.com>
> wrote:
> > Are you suggesting using TLS for every protected resource or just= for
> obtaining the token and refreshing it?
> >
> > OAuth today already supports this via the PLAINTEXT method (thoug= h
> not very cleanly with all the other parameters still required even if<= br> > useless).
> >
> > Also What use cases? And where is this 90% comes from?
> >
> > I for one have always rejected the argument that since cookies ar= e
> already so broken, there was little point in trying to make API
> security better. When we originally worked on OAuth we explicitly
> looked to prevent replay attacks as well as intercepting and changing<= br> > an authenticated request. We limited our scope to protecting the
> request URI and (some) parameters. That provided sufficient protection=
> to the APIs people had in mind at the time which were mostly GET/POST<= br> > requests with just a few parameters. The body hash extension then
> extended the usefulness of the protocol to other payloads.
> >
> > The delegation half of the protocol deals with exchanging passwor= ds
> with tokens. Those who find bearer token sufficient without any
> additional crypto can simply focus their attention on that. On the
> authentication side, I would like to offer something other than "= use
> TLS for everything" or risk attacks for ("only") 10 min= utes.
> >
> > EHL
> >
> >> -----Original Message-----
> >> From: John Panzer [mailto:jpanzer@google.com]
> >> Sent: Thursday, November 12, 2009 7:46 AM
> >> To: Eran Hammer-Lahav
> >> Cc: oauth@ietf.org
> >> Subject: Re: [OAUTH-WG] why are we signing?
> >>
> >> I think that https plus bearer token is sufficient for 90% of= use
> >> cases. =A0I haven't heard a first principles argument oth= erwise. =A0If
> for
> >> no other reason than the record, could the proponents of sign= ing
> >> explain why bearer token over TLS will not meet their needs?<= br> > >>
> >> On Thursday, November 12, 2009, Eran Hammer-Lahav
> <eran@hueniverse.com>=
> >> wrote:
> >> > As a matter of process, I would suggest looking at what = the 1.0
> HMAC-
> >> SHA1 method signs, and discuss if it is where we should be. W= e are
> >> working with an existing draft and should structure our discu= ssions
> as
> >> feedback to that point of reference. This doesn't limit t= he
> conclusion
> >> in any way, and is how this WG has been chartered.
> >> >
> >> > EHL
> >> >
> >> >
> >> >> -----Original Message-----
> >> >> From: oaut= h-bounces@ietf.org [mailto:oa= uth-bounces@ietf.org] On
> >> Behalf
> >> >> Of Brian Eaton
> >> >> Sent: Wednesday, November 11, 2009 5:54 PM
> >> >> To: BeckW@teleko= m.de
> >> >> Cc: oauth@ietf.org=
> >> >> Subject: Re: [OAUTH-WG] why are we signing?
> >> >>
> >> >> So we've got at least five different use cases f= or signing
> requests
> >> >> with the oauth access token and token secret.
> >> >>
> >> >> Sweet.
> >> >>
> >> >> The downside to the use cases is that they all have = incompatible
> >> >> signature base strings. =A0I'd like to see us co= me up with
> something
> >> so
> >> >> that we don't have to reinvent the base string a= gain for every
> >> single
> >> >> use case.
> >> >>
> >> >> Cheers,
> >> >> Brian
> >> >>
> >> >> On Wed, Nov 11, 2009 at 5:49 PM, =A0<BeckW@telekom.de> wrote:
> >> >> >
> >> >> > On Mon, Nov 9, 2009 at 6:28 AM, John Kemp <<= a href=3D"mailto:john@jkemp.net">john@jkemp.net>
> wrote:
> >> >> >> If we are only interested in i) [authentica= ting the entity]
> then
> >> >> > signing any piece of the message might
> >> >> >> be sufficient. If we are interested in ii) = [binding the
> signature
> >> to
> >> >> > the message] (or some other security property)<= br> > >> >> >> then we will need to identify which pieces = of the message we
> want
> >> to
> >> >> > provide
> >> >> >> that, or other, security properties for. > >> >> >
> >> >> >> Brian Eaton wrote:
> >> >> >> OK, let me try to summarize what I've h= eard on this thread
> about
> >> the
> >> >> >> different use-cases for message signing: > >> >> >>
> >> >> >> - sign the HTTP request
> >> >> >> =A0 Used to prevent MITM from replaying tok= en to a different
> URL.
> >> >> =A0Also
> >> >> >> limits the replay attack window to minutes = instead of hours.
> >> >> >>
> >> >> >> - sign various other parts of the message > >> >> >> =A0 DKIM: signs various message headers
> >> >> >> =A0 SIP: unspecified, just says "relev= ant parts of SIP request"
> >> >> > Hannes Tschofenig suggested handle SIP messages= the way
> described
> >> in
> >> >> RfC
> >> >> > 4474 (SIP identity). It lists the parts of a SI= P messsage that
> >> need
> >> >> to
> >> >> > be protected.
> >> >> >
> >> >> > Wolfgang
> >> >> >
> >> >> _______________________________________________
> >> >> OAuth mailing list
> >> >> OAuth@ietf.org=
> >> >> https://www.ietf.org/mailman/listinfo/oauth
> >> > _______________________________________________
> >> > OAuth mailing list
> >> >
>
> --
> --
> John Panzer / Google
> jpanzer@google.com / abstractioneer.org / @= jpanzer

--0016e648f0ae68b8f904784442d3-- From breno.demedeiros@gmail.com Fri Nov 13 10:21:41 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9311B3A6882 for ; Fri, 13 Nov 2009 10:21:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-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 UkPjB820Rz9H for ; Fri, 13 Nov 2009 10:21:40 -0800 (PST) Received: from mail-qy0-f203.google.com (mail-qy0-f203.google.com [209.85.221.203]) by core3.amsl.com (Postfix) with ESMTP id 605193A6807 for ; Fri, 13 Nov 2009 10:21:40 -0800 (PST) Received: by qyk41 with SMTP id 41so1676197qyk.29 for ; Fri, 13 Nov 2009 10:22:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=gEDI7Zc0sT16GPprMf0+y3SP8P2aaMANbOQe339EDF8=; b=RMFZ8QXIkDH5ipursuQk+HeEGdQHSwAOqBhlo8ZNcbFREGBJKBqIG7hB3wdUkagehU xJCEpZwNVCVqSPVzJBhfFpp9qDSpG4PKBlReCSSzMKXfdLAAkav0fcZRiH9uzAD09Wul Kb4IBwMtYRGolm8SMtSQRQGVUwre40BdbINiE= 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=by2KNQ1tOl7JI3daYGBNAyEudaIW4MF3IrFPJUmh1xPo7UqwzMjQc+QomfhAAKQSWa zd8BwJm7Fni0JeVwrNa6rrvkbYIE+IsHbn2SMHddxXwHWETFVRdNpcpctBMBVJY/X/YQ 3NdQD0t/UFlM1Y/oGKogTXoMZTBcQkzFZimOk= MIME-Version: 1.0 Received: by 10.229.55.69 with SMTP id t5mr629097qcg.34.1258136527626; Fri, 13 Nov 2009 10:22:07 -0800 (PST) In-Reply-To: References: <3a880e2c0911061126t176e04ebjef1acd7fcb23efed@mail.gmail.com> <4AF77B77.40507@alcatel-lucent.com> Date: Fri, 13 Nov 2009 10:22:07 -0800 Message-ID: From: Breno To: Brian Eaton Content-Type: multipart/alternative; boundary=0015175dd8b8cee418047844bc59 Cc: Phillip Hallam-Baker , "oauth@ietf.org" Subject: Re: [OAUTH-WG] RSA vs PKI? X-BeenThere: oauth@ietf.org X-Mailman-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, 13 Nov 2009 18:21:41 -0000 --0015175dd8b8cee418047844bc59 Content-Type: text/plain; charset=ISO-8859-1 Basically, the U.S. Government currently requires 256-bit symmetric encryption keys for the highest levels of security (documents whose confidentiality over the next several decades is a matter of national security). The 256-bit security requirement in symmetric keys compares to 512-bit in ECC but only to something like RSA-15,000. It is quite clear that nobody will ever deploy RSA-15,000 because it would be incredibly inefficient compared to ECC-512. So there is no point in estipulating RSA key sizes for the highest security settings. Generally, n bits of symmetic key security map to 2n bits of ECC security (currently published cryptanalytic research). However, the reduction of RSA security to symmetric security does not follow a linear relationship. On Sun, Nov 8, 2009 at 7:32 PM, Brian Eaton wrote: > On Sun, Nov 8, 2009 at 7:13 PM, Phillip Hallam-Baker > wrote: > > Now RSA 2048 is almost certainly enough for most things, but when you > > are a government agency you want the stuff you encrypt using RSA2048 > > on its last day of service life to be secure for another 20-30 years, > > possibly more. So while RSA 2048 has at least another 30 years left in > > it for authentication problems it is already reaching the end of its > > service life for certain confidentiality applications. > > > > > > I would suggest making RSA 2048 - SHA 256 the mandatory to implement > > and chose an ECC alternative from suite B. > > So the choice of RSA key length seems like something that different > applications could reasonably choose on their own, no? Do we really > need to include 2048 bit RSA in the spec, or is specifying RSA in > general sufficient? > > I suspect we do need to specify acceptable hash output lengths if > we're going to have decent interop. > > (I'm seriously pushing the bounds of my crypto knowledge here, so do > let me know if any of the above is nonsense.) > > Cheers, > Brian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Breno de Medeiros --0015175dd8b8cee418047844bc59 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Basically, the U.S. Government currently requires 256-bit symmetric encrypt= ion keys for the highest levels of security (documents whose confidentialit= y over the next several decades is a matter of national security).

The 256-bit security requirement in symmetric keys compares to 512-bit in E= CC but only to something like RSA-15,000. It is quite clear that nobody wil= l ever deploy RSA-15,000 because it would be incredibly inefficient compare= d to ECC-512. So there is no point in estipulating RSA key sizes for the hi= ghest security settings.

Generally, n bits of symmetic key security map to 2n bits of ECC securi= ty (currently published cryptanalytic research). However, the reduction of = RSA security to symmetric security does not follow a linear relationship.
On Sun, Nov 8, 2009 at 7:32 PM, Brian Eaton = <beaton@google.co= m> wrote:
On Sun, Nov 8, 2009 at 7:13 PM, Phillip Hallam-Baker <= hallam@gmail.com> wrote:
> Now RSA 2048 is almost certainly enough for most things, but when you<= br> > are a government agency you want the stuff you encrypt using RSA2048 > on its last day of service life to be secure for another 20-30 years,<= br> > possibly more. So while RSA 2048 has at least another 30 years left in=
> it for authentication problems it is already reaching the end of its > service life for certain confidentiality applications.
>
>
> I would suggest making RSA 2048 - SHA 256 the mandatory to implement > and chose an ECC alternative from suite B.

So the choice of RSA key length seems like something that different applications could reasonably choose on their own, no? =A0Do we really
need to include 2048 bit RSA in the spec, or is specifying RSA in
general sufficient?

I suspect we do need to specify acceptable hash output lengths if
we're going to have decent interop.

(I'm seriously pushing the bounds of my crypto knowledge here, so do let me know if any of the above is nonsense.)

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



--
Breno de Me= deiros

--0015175dd8b8cee418047844bc59-- From eran@hueniverse.com Fri Nov 13 12:25:34 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 088F63A67B3 for ; Fri, 13 Nov 2009 12:25:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PGQWicyGIT1I for ; Fri, 13 Nov 2009 12:25:32 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id CDF833A6783 for ; Fri, 13 Nov 2009 12:25:31 -0800 (PST) Received: (qmail 32342 invoked from network); 13 Nov 2009 20:26:01 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 13 Nov 2009 20:26:01 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 13 Nov 2009 13:25:53 -0700 From: Eran Hammer-Lahav To: John Panzer Date: Fri, 13 Nov 2009 13:25:45 -0700 Thread-Topic: [OAUTH-WG] why are we signing? Thread-Index: AcpkiXLJ/oaEDSemRbWEj0eX3+QUBAAFVi9A Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343785102FD8@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <35D50F5C-3982-4298-A9E0-86A528F5C5D3@jkemp.net> <4A956CE47D1066408D5C7EB34368A5110551FFC1@S4DE8PSAAQC.mitte.t-com.de> <90C41DD21FB7C64BB94121FBBC2E72343785102B49@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785102E58@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785102F1F@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_90C41DD21FB7C64BB94121FBBC2E72343785102FD8P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] why are we signing? X-BeenThere: oauth@ietf.org X-Mailman-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, 13 Nov 2009 20:25:34 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343785102FD8P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable While my approach is slightly different (one of the very few benefits of be= ing the editor), it is what the plan is. The authentication spec is going t= o offer two methods: Plain (bearer token with optional shared secret), and = HMAC (a significantly simplified signature flow based on the HMAC one in 1.= 0 but with less flexibility for limited platforms). Instead of sacrificing = security I have been trying to make the case we should just raise the bar f= or what an OAuth client should be able to do. Both will accomplish simplici= ty but at different costs. The Plain method will give the bearer-token+TLS = crown everything they need out of that spec. The delegation spec is where most of the work is needed, and where I would = like to see us adopt much of the new and improved ideas from WRAP. EHL From: John Panzer [mailto:jpanzer@google.com] Sent: Friday, November 13, 2009 9:48 AM To: Eran Hammer-Lahav Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] why are we signing? Replies inline (sorry for async postings): On Fri, Nov 13, 2009 at 9:21 AM, Eran Hammer-Lahav > wrote: > -----Original Message----- > From: John Panzer [mailto:jpanzer@google.com] > Sent: Friday, November 13, 2009 8:37 AM > To: Eran Hammer-Lahav > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] why are we signing? > > The 90% is just MHO. > > I think we should be sure that using TLS for everything is unviable in > 2010 before diving into complicated signing and binding. For my use > cases, non body signed requests are about equivalent to bearer token > in terms of security; body signing is an interop pain point; absent a > deus ex machina with a new, secure, simple, ip-free, interoperable > algorithm for body signing I would personally use PLAINTEXT over TLS > for resource access and move on to more important things. > > Note that nothing stops someone from defining a data protocol which > supplies signatures and even binds to the important bits of the > envelope. And if you can get XML Dsig to work interoperably for your > protocol, great! But OAuth 2 could be defined to leave that to > protocols and extensions. In theory this would make things less > interoperable, but in practice signatures are a huge interop pain > point anyway (IMHO) so I do not believe there is a practical > difference in the field. That's half of what we are explicitly chartered to do. My point is that peo= ple should focus on the parts of the protocol they care about. I think such= a reduction in functionality and scope would require a more explicit recon= sideration of this entire WG. If the WG needs to consider it, then I move that we do the first, PLAINTEXT= , relying-on-TLS-when-necessary half (at least to the point of an I-D that = people can go implement) before moving on to the far more complex world of = new signature algorithms. This doesn't mean having two specs, just stabilizing the bits nobody has se= rious arguments about so people who need the first half can move forward. = Obviously things can change in draft, etc., but we're all playing the odds = here and actual running code is important to have. I for one, see great value in offering some form of crypto-based security f= or cases where TLS is not suitable. I am also not buying the argument that we should avoid crypto because it is= hard. The same argument can be made about TLS (who really writes their own= libraries for that?). Nobody; we get them from Ben Laurie. But they're already available everywh= ere, so nobody has to write them, while the OAuth 2 libraries, whatever the= y will be, are available nowhere right now. So whatever OAuth comes up wit= h has to be _significantly_ simpler and easier than using openssl. EHL > On Thursday, November 12, 2009, Eran Hammer-Lahav > > wrote: > > Are you suggesting using TLS for every protected resource or just for > obtaining the token and refreshing it? > > > > OAuth today already supports this via the PLAINTEXT method (though > not very cleanly with all the other parameters still required even if > useless). > > > > Also What use cases? And where is this 90% comes from? > > > > I for one have always rejected the argument that since cookies are > already so broken, there was little point in trying to make API > security better. When we originally worked on OAuth we explicitly > looked to prevent replay attacks as well as intercepting and changing > an authenticated request. We limited our scope to protecting the > request URI and (some) parameters. That provided sufficient protection > to the APIs people had in mind at the time which were mostly GET/POST > requests with just a few parameters. The body hash extension then > extended the usefulness of the protocol to other payloads. > > > > The delegation half of the protocol deals with exchanging passwords > with tokens. Those who find bearer token sufficient without any > additional crypto can simply focus their attention on that. On the > authentication side, I would like to offer something other than "use > TLS for everything" or risk attacks for ("only") 10 minutes. > > > > EHL > > > >> -----Original Message----- > >> From: John Panzer [mailto:jpanzer@google.com] > >> Sent: Thursday, November 12, 2009 7:46 AM > >> To: Eran Hammer-Lahav > >> Cc: oauth@ietf.org > >> Subject: Re: [OAUTH-WG] why are we signing? > >> > >> I think that https plus bearer token is sufficient for 90% of use > >> cases. I haven't heard a first principles argument otherwise. If > for > >> no other reason than the record, could the proponents of signing > >> explain why bearer token over TLS will not meet their needs? > >> > >> On Thursday, November 12, 2009, Eran Hammer-Lahav > > > >> wrote: > >> > As a matter of process, I would suggest looking at what the 1.0 > HMAC- > >> SHA1 method signs, and discuss if it is where we should be. We are > >> working with an existing draft and should structure our discussions > as > >> feedback to that point of reference. This doesn't limit the > conclusion > >> in any way, and is how this WG has been chartered. > >> > > >> > EHL > >> > > >> > > >> >> -----Original Message----- > >> >> From: oauth-bounces@ietf.org [mailto= :oauth-bounces@ietf.org] On > >> Behalf > >> >> Of Brian Eaton > >> >> Sent: Wednesday, November 11, 2009 5:54 PM > >> >> To: BeckW@telekom.de > >> >> Cc: oauth@ietf.org > >> >> Subject: Re: [OAUTH-WG] why are we signing? > >> >> > >> >> So we've got at least five different use cases for signing > requests > >> >> with the oauth access token and token secret. > >> >> > >> >> Sweet. > >> >> > >> >> The downside to the use cases is that they all have incompatible > >> >> signature base strings. I'd like to see us come up with > something > >> so > >> >> that we don't have to reinvent the base string again for every > >> single > >> >> use case. > >> >> > >> >> Cheers, > >> >> Brian > >> >> > >> >> On Wed, Nov 11, 2009 at 5:49 PM, > wrote: > >> >> > > >> >> > On Mon, Nov 9, 2009 at 6:28 AM, John Kemp > > wrote: > >> >> >> If we are only interested in i) [authenticating the entity] > then > >> >> > signing any piece of the message might > >> >> >> be sufficient. If we are interested in ii) [binding the > signature > >> to > >> >> > the message] (or some other security property) > >> >> >> then we will need to identify which pieces of the message we > want > >> to > >> >> > provide > >> >> >> that, or other, security properties for. > >> >> > > >> >> >> Brian Eaton wrote: > >> >> >> OK, let me try to summarize what I've heard on this thread > about > >> the > >> >> >> different use-cases for message signing: > >> >> >> > >> >> >> - sign the HTTP request > >> >> >> Used to prevent MITM from replaying token to a different > URL. > >> >> Also > >> >> >> limits the replay attack window to minutes instead of hours. > >> >> >> > >> >> >> - sign various other parts of the message > >> >> >> DKIM: signs various message headers > >> >> >> SIP: unspecified, just says "relevant parts of SIP request" > >> >> > Hannes Tschofenig suggested handle SIP messages the way > described > >> in > >> >> RfC > >> >> > 4474 (SIP identity). It lists the parts of a SIP messsage that > >> need > >> >> to > >> >> > be protected. > >> >> > > >> >> > Wolfgang > >> >> > > >> >> _______________________________________________ > >> >> OAuth mailing list > >> >> OAuth@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/oauth > >> > _______________________________________________ > >> > OAuth mailing list > >> > > > -- > -- > John Panzer / Google > jpanzer@google.com / abstractioneer.org / @jpanzer --_000_90C41DD21FB7C64BB94121FBBC2E72343785102FD8P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

While my approach is slightly different (one of the very few benefits of being the editor), it is what the plan is. The authentication s= pec is going to offer two methods: Plain (bearer token with optional shared secret), and HMAC (a significantly simplified signature flow based on the H= MAC one in 1.0 but with less flexibility for limited platforms). Instead of sac= rificing security I have been trying to make the case we should just raise the bar f= or what an OAuth client should be able to do. Both will accomplish simplicity = but at different costs. The Plain method will give the bearer-token+TLS crown everything they need out of that spec.

 

The delegation spec is where most of the work is needed, and where I would like to see us adopt much of the new and improved ideas from = WRAP.

 

EHL

 

 

 

From: John Panzer [mailto:jpanzer@google.com]
Sent: Friday, November 13, 2009 9:48 AM
To: Eran Hammer-Lahav
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] why are we signing?

 

Replies inline (sorry f= or async postings):

On Fri, Nov 13, 2009 at 9:21 AM, Eran Hammer-Lahav <= ;eran@hueniverse.com> wrote:=



> -----Original Message-----
> From: John Panzer [mailto:jpanze= r@google.com]

> Sent: Friday, November 13, 2009 8:37 AM
> To: Eran Hammer-Lahav
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] why are we signing?
>

> The 90% is just MH= O.
>
> I think we should be sure that using TLS for everything is unviable in=
> 2010 before diving into complicated signing and binding.  For my = use
> cases, non body signed requests are about equivalent to bearer token > in terms of security; body signing is an interop pain point; absent a<= br> > deus ex machina with a new, secure, simple, ip-free, interoperable
> algorithm for body signing I would personally use PLAINTEXT over TLS > for resource access and move on to more important things.
>
> Note that nothing stops someone from defining a data protocol which > supplies signatures and even binds to the important bits of the
> envelope.  And if you can get XML Dsig to work interoperably for = your
> protocol, great!  But OAuth 2 could be defined to leave that to > protocols and extensions.  In theory this would make things less<= br> > interoperable, but in practice signatures are a huge interop pain
> point anyway (IMHO) so I do not believe there is a practical
> difference in the field.

That's half of what we are explicitly chartered to do.= My point is that people should focus on the parts of the protocol they care ab= out. I think such a reduction in functionality and scope would require a more explicit reconsideration of this entire WG.

 

If the WG needs to consider it, then I move that we do= the first, PLAINTEXT, relying-on-TLS-when-necessary half (at least to the point= of an I-D that people can go implement) before moving on to the far more compl= ex world of new signature algorithms.  

 

This doesn't mean having two specs, just stabilizing t= he bits nobody has serious arguments about so people who need the first half c= an move forward.  Obviously things can change in draft, etc., but we're a= ll playing the odds here and actual running code is important to have.

 


I for one, see great value in offering some form of crypto-based security f= or cases where TLS is not suitable.

I am also not buying the argument that we should avoid crypto because it is hard. The same argument can be made about TLS (who really writes their own libraries for that?).

 

Nobody; we get them from Ben Laurie.  But they're already available everywhere, so nobody has to write them, while the OAuth = 2 libraries, whatever they will be, are available nowhere right now.  So whatever OAuth comes up with has to be _significantly_ simpler and easier t= han using openssl.

 

 


EHL


> On Thursday, November 12, 2009, Eran Hammer-Lahav <eran@hueniverse.com>
> wrote:
> > Are you suggesting using TLS for every protected resource or just= for
> obtaining the token and refreshing it?
> >
> > OAuth today already supports this via the PLAINTEXT method (thoug= h
> not very cleanly with all the other parameters still required even if<= br> > useless).
> >
> > Also What use cases? And where is this 90% comes from?
> >
> > I for one have always rejected the argument that since cookies ar= e
> already so broken, there was little point in trying to make API
> security better. When we originally worked on OAuth we explicitly
> looked to prevent replay attacks as well as intercepting and changing<= br> > an authenticated request. We limited our scope to protecting the
> request URI and (some) parameters. That provided sufficient protection=
> to the APIs people had in mind at the time which were mostly GET/POST<= br> > requests with just a few parameters. The body hash extension then
> extended the usefulness of the protocol to other payloads.
> >
> > The delegation half of the protocol deals with exchanging passwor= ds
> with tokens. Those who find bearer token sufficient without any
> additional crypto can simply focus their attention on that. On the
> authentication side, I would like to offer something other than "= use
> TLS for everything" or risk attacks for ("only") 10 minutes.
> >
> > EHL
> >
> >> -----Original Message-----
> >> From: John Panzer [mailto:jpanzer@google.com]
> >> Sent: Thursday, November 12, 2009 7:46 AM
> >> To: Eran Hammer-Lahav
> >> Cc: oauth@ietf.org
> >> Subject: Re: [OAUTH-WG] why are we signing?
> >>
> >> I think that https plus bearer token is sufficient for 90% of= use
> >> cases.  I haven't heard a first principles argument otherwise.  If
> for
> >> no other reason than the record, could the proponents of sign= ing
> >> explain why bearer token over TLS will not meet their needs?<= br> > >>
> >> On Thursday, November 12, 2009, Eran Hammer-Lahav
> <eran@hueniverse.com>=
> >> wrote:
> >> > As a matter of process, I would suggest looking at what = the 1.0
> HMAC-
> >> SHA1 method signs, and discuss if it is where we should be. W= e are
> >> working with an existing draft and should structure our discussions
> as
> >> feedback to that point of reference. This doesn't limit the > conclusion
> >> in any way, and is how this WG has been chartered.
> >> >
> >> > EHL
> >> >
> >> >
> >> >> -----Original Message-----
> >> >> From: oaut= h-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
> >> Behalf
> >> >> Of Brian Eaton
> >> >> Sent: Wednesday, November 11, 2009 5:54 PM
> >> >> To: BeckW@teleko= m.de
> >> >> Cc: oauth@ietf.org=
> >> >> Subject: Re: [OAUTH-WG] why are we signing?
> >> >>
> >> >> So we've got at least five different use cases for signing
> requests
> >> >> with the oauth access token and token secret.
> >> >>
> >> >> Sweet.
> >> >>
> >> >> The downside to the use cases is that they all have incompatible
> >> >> signature base strings.  I'd like to see us com= e up with
> something
> >> so
> >> >> that we don't have to reinvent the base string again= for every
> >> single
> >> >> use case.
> >> >>
> >> >> Cheers,
> >> >> Brian
> >> >>
> >> >> On Wed, Nov 11, 2009 at 5:49 PM,  <BeckW@telekom.de> wrote:
> >> >> >
> >> >> > On Mon, Nov 9, 2009 at 6:28 AM, John Kemp <<= a href=3D"mailto:john@jkemp.net">john@jkemp.net>
> wrote:
> >> >> >> If we are only interested in i) [authentica= ting the entity]
> then
> >> >> > signing any piece of the message might
> >> >> >> be sufficient. If we are interested in ii) [binding the
> signature
> >> to
> >> >> > the message] (or some other security property)<= br> > >> >> >> then we will need to identify which pieces = of the message we
> want
> >> to
> >> >> > provide
> >> >> >> that, or other, security properties for. > >> >> >
> >> >> >> Brian Eaton wrote:
> >> >> >> OK, let me try to summarize what I've heard= on this thread
> about
> >> the
> >> >> >> different use-cases for message signing: > >> >> >>
> >> >> >> - sign the HTTP request
> >> >> >>   Used to prevent MITM from replaying token to a different
> URL.
> >> >>  Also
> >> >> >> limits the replay attack window to minutes instead of hours.
> >> >> >>
> >> >> >> - sign various other parts of the message > >> >> >>   DKIM: signs various message headers<= br> > >> >> >>   SIP: unspecified, just says "relevant parts of SIP request"
> >> >> > Hannes Tschofenig suggested handle SIP messages= the way
> described
> >> in
> >> >> RfC
> >> >> > 4474 (SIP identity). It lists the parts of a SI= P messsage that
> >> need
> >> >> to
> >> >> > be protected.
> >> >> >
> >> >> > Wolfgang
> >> >> >
> >> >> _______________________________________________
> >> >> OAuth mailing list
> >> >> OAuth@ietf.org=
> >> >> https://www.ietf.org/mailman/listinfo/oauth
> >> > _______________________________________________
> >> > OAuth mailing list
> >> >
>
> --
> --
> John Panzer / Google
> jpanzer@google.com / abstractioneer.org= / @jpanzer

 

--_000_90C41DD21FB7C64BB94121FBBC2E72343785102FD8P3PW5EX1MB01E_-- From eran@hueniverse.com Sun Nov 15 00:25:59 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D0773A6908 for ; Sun, 15 Nov 2009 00:25:59 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, MIME error: error: illegal encoding [base64] for MIME type message/external-body X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 LcdcsHl-2TM2 for ; Sun, 15 Nov 2009 00:25:58 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 4B2DC3A6836 for ; Sun, 15 Nov 2009 00:25:58 -0800 (PST) Received: (qmail 1456 invoked from network); 15 Nov 2009 08:26:29 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 15 Nov 2009 08:26:29 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Sun, 15 Nov 2009 01:26:28 -0700 From: Eran Hammer-Lahav To: "oauth@ietf.org" , "oauth@googlegroups.com" Date: Sun, 15 Nov 2009 01:26:26 -0700 Thread-Topic: I-D Action:draft-hammer-oauth-04.txt Thread-Index: Acply+EckLJDrepTTt+NZPqL1M/DLAAACK3g Message-ID: <90C41DD21FB7C64BB94121FBBC2E723437851030EB@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/mixed; boundary="_003_90C41DD21FB7C64BB94121FBBC2E723437851030EBP3PW5EX1MB01E_" MIME-Version: 1.0 Subject: [OAUTH-WG] I-D Action:draft-hammer-oauth-04.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: Sun, 15 Nov 2009 08:25:59 -0000 --_003_90C41DD21FB7C64BB94121FBBC2E723437851030EBP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The following draft incorporates all the feedback received from the Last-Ca= ll review. Other than comments from Lisa, Peter, and the general-area revie= w, no other review has been received, which needless to say, is extremely d= isappointing. This draft is meant to replace the OAuth Core 1.0 (and Rev A) specification= as the canonical reference. It includes hundreds of hours of work to corre= ct all the known issues with the specification language and protocol errors= . It is also used as the basis for the new WG work. In other words, this has been designed to solve everything you have been co= mplaining about for 2 years. It is sad that not a single person from the or= iginal group of authors bothered to give this a thorough read and provide f= eedback. EHL -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] = On Behalf Of Internet-Drafts@ietf.org Sent: Sunday, November 15, 2009 12:15 AM To: i-d-announce@ietf.org Subject: I-D Action:draft-hammer-oauth-04.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : The OAuth Core 1.0 Protocol Author(s) : E. Hammer-Lahav, B. Cook Filename : draft-hammer-oauth-04.txt Pages : 41 Date : 2009-11-15 This document specifies the OAuth Core 1.0 protocol. OAuth provides a meth= od for clients to access server resources on behalf of another party (such = as a different client or an end user). It also provides a redirection-base= d user agent process for end users to authorize access to another party by = substituting their credentials (typically, a username and password pair) wi= th a different set of delegation- specific credentials. This document is b= ased on revision A of the community specification and includes a few clarif= ications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hammer-oauth-04.txt --_003_90C41DD21FB7C64BB94121FBBC2E723437851030EBP3PW5EX1MB01E_ Content-Type: message/external-body; name="draft-hammer-oauth-04.url" Content-Description: draft-hammer-oauth-04.url Content-Disposition: attachment; filename="draft-hammer-oauth-04.url"; size=86; creation-date="Sun, 15 Nov 2009 01:16:06 GMT"; modification-date="Sun, 15 Nov 2009 01:16:06 GMT" Content-Transfer-Encoding: base64 W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1oYW1tZXItb2F1dGgtMDQudHh0DQo= --_003_90C41DD21FB7C64BB94121FBBC2E723437851030EBP3PW5EX1MB01E_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=258; creation-date="Sun, 15 Nov 2009 01:16:06 GMT"; modification-date="Sun, 15 Nov 2009 01:16:06 GMT" Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCkludGVybmV0LURyYWZ0IGRpcmVj dG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sDQpvciBmdHA6Ly9mdHAuaWV0 Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0K --_003_90C41DD21FB7C64BB94121FBBC2E723437851030EBP3PW5EX1MB01E_-- From eran@hueniverse.com Sun Nov 15 14:29:29 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 730503A6A40 for ; Sun, 15 Nov 2009 14:29:29 -0800 (PST) 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 4d5iD3Y96S9g for ; Sun, 15 Nov 2009 14:29:28 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 9042E3A6A20 for ; Sun, 15 Nov 2009 14:29:28 -0800 (PST) Received: (qmail 15630 invoked from network); 15 Nov 2009 22:29:26 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 15 Nov 2009 22:29:25 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Sun, 15 Nov 2009 15:29:25 -0700 From: Eran Hammer-Lahav To: Avshalom Houri , "romeda@gmail.com" , General Area Review Team Date: Sun, 15 Nov 2009 15:29:25 -0700 Thread-Topic: Gen Art LC review of draft-hammer-oauth-03 Thread-Index: Acph8BjcJZBzQcIJQMS8FzZ7V1qergD0cztA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343785103100@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@ietf.org" Subject: Re: [OAUTH-WG] Gen Art LC review of draft-hammer-oauth-03 X-BeenThere: oauth@ietf.org X-Mailman-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, 15 Nov 2009 22:29:29 -0000 First, thanks! The following changes have been submitted as a -04 revision. > -----Original Message----- > From: Avshalom Houri [mailto:AVSHALOM@il.ibm.com] > Sent: Tuesday, November 10, 2009 2:25 AM > To: Eran Hammer-Lahav; romeda@gmail.com; General Area Review Team > Cc: .Lisa Dusseault > Subject: Gen Art LC review of draft-hammer-oauth-03 >=20 > I have been selected as the General Area Review Team (Gen-ART) > reviewer for this draft (for background on Gen-ART, please see > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). >=20 > Please resolve these comments along with any other Last Call comments > you may receive. >=20 > Document: draft-hammer-oauth-03 > Reviewer: Avshalom Houri > Review Date: 2009-11-10 > IETF LC End Date: 2009-11-06 > IESG Telechat date: (if known) >=20 > Summary: Draft is almost ready. Needs some more work to improve > readability and structure. >=20 > Major issues: >=20 > Section 3.3.1.1. =A0Collect Request Parameters. It is very hard to > understand this whole section. It seems that it belongs more to the > later parts of the document. Entire section reorganized and rewritten to align the narrative with the pr= otocol workflow. No changes to the normative language. > Minor issues: >=20 > Lines 421-423: > =A0 =A0nor does it include most HTTP entity-headers. =A0The importance of= the > =A0 =A0signature base string scope is that the authenticity of the exclud= ed > =A0 =A0components cannot be verified using the signature. >=20 > Could not understand the sentence starting with "The importance" Replaced with: "It is important to note that the server cannot verify the a= uthenticity of the excluded request components without using additional pro= tections such as SSL/TLS or other methods." > Lines 627-636 > =A0 =A04. =A0If the URI includes an empty path, it MUST be included as "/= ". >=20 > =A0 =A0For example: >=20 > =A0 =A0+----------------------------------+------------------------------= -+ > =A0 =A0| The request URI =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Is included= in base string as | > =A0 =A0+----------------------------------+------------------------------= -+ > =A0 =A0| HTTP://EXAMPLE.com:80/r/x?id=3D123 | http://example.com/r/x =A0 = =A0 =A0 =A0| > =A0 =A0| https://example.net:8080?q=3D1#top | https://example.net:8080/ = =A0 =A0 | > =A0 =A0+----------------------------------+------------------------------= -+ >=20 > Does it mean that the granularity here is only for whole resource? If > so it should be mentioned somewhere. No. This was a result of the way the spec was written, discussing resource = URIs instead of HTTP requests. Since HTTP requires normalizing empty paths = as '/', the spec had to mention that when discussing a URI such as http://e= xample.com. However, with the new revision, the examples have been replaced= with HTTP requests (instead of URIs), and the entire spec has been defined= in the context of HTTP 1.1. > Section 4. Redirection-Based Authorization seems to be more correctly > placed in the beginning of the document. This seems like a good idea. I am going to try it but not sure how the docu= ment will read to fresh eyes (anyone?). > Section 6. Security Considerations >=20 > I like the detailed explanations but it may be good to have some > preface that will describe the class of threats described etc. I am happy for text suggestions. Writing security text is not my area. > Appendix should be part of the document as an example. The document is full of examples. This is just a complete walkthrough. I th= ink it is fine as an appendix. > Nits/editorial comments: >=20 > Line: 360: > =A0 =A0A nonce is a random string, uniquely generated to allows the serve= r > -> =A0 =A0A nonce is a random string, uniquely generated to allow the > server >=20 > Line 378: > =A0 client needs to prove it is the rightful owner of the credentials. > -> =A0 =A0client needs to prove that it is the rightful owner of the > credentials. >=20 > Line 405: > =A0 =A0(or a sting of an equivalent value), and includes it in the > -> (or a string of an equivalent value), and includes it in the Yep. >=20 > Thanks & sorry for the late review > --Avshalom Thanks again. This was helpful. If you could review the latest revision and= confirm the major concern I would greatly appreciate it. EHL From eran@hueniverse.com Sun Nov 15 14:29:32 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA7743A68DB for ; Sun, 15 Nov 2009 14:29:32 -0800 (PST) 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 LravnqTV4gsR for ; Sun, 15 Nov 2009 14:29:31 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 5085F3A6A44 for ; Sun, 15 Nov 2009 14:29:28 -0800 (PST) Received: (qmail 12243 invoked from network); 15 Nov 2009 22:29:27 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 15 Nov 2009 22:29:27 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sun, 15 Nov 2009 15:29:27 -0700 From: Eran Hammer-Lahav To: Peter Saint-Andre , OAuth WG Date: Sun, 15 Nov 2009 15:29:27 -0700 Thread-Topic: [OAUTH-WG] comments on draft-hammer-oauth-03 Thread-Index: AcphigPJzpZC/tI2QPaSdCTLaIFYTAEOlDYg Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343785103101@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4AF8943E.4050802@stpeter.im> In-Reply-To: <4AF8943E.4050802@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] comments on draft-hammer-oauth-03 X-BeenThere: oauth@ietf.org X-Mailman-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, 15 Nov 2009 22:29:32 -0000 Thanks Peter. This is very helpful. The following changes have been submitted as a -04 revision. > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Peter Saint-Andre > Sent: Monday, November 09, 2009 2:14 PM > 1. I think it would be very helpful to provide a bit more context in > the > Introduction. Say, two or three sentences about the provenance of this > technology, the community that developed it, and a link to oauth.net > (along with something like the final paragraph of the current > Introduction). Something like this: >=20 > The OAuth protocol was originally created by a loose group of > technologists from a variety of websites and other Internet > services, who wanted to solve the common problem of enabling > delegated access to protected resources. The resulting OAuth > protocol was stabilized at version 1.0 in October 2007 and > published at the oauth.net website. This specification provides > informational documentation of OAuth Core 1.0 Revision A as > finalized in June 2009, incorporating several errata reported > since that time as well as numerous editorial clarifications. > It is not an item of the IETF's OAuth Working Group, which at > the time of writing is working on an OAuth version that can be > appropriate for publication on the standards track. Added with minor changes. > 2. In the Terminology section, I think it might be helpful to provide > pointers to the old terminology, as in: >=20 > "(In the community edition, a client was called a consumer.)" Added: "The original community specification used a somewhat different terminology= which maps to this specifications as follows: * consumer - client * service provider - server * user - resource owner * consumer key and secret - client credentials * request token and secret - temporary credentials * access token and secret - token credentials" > We might also want to point to RFC 4949 regarding terminology and check > that our usage of key terms like "authorization" is consistent with > that > document. If someone wants to give it a try, I am open to it. > 3. Before jumping right into authenticated requests in section 3, I > think it would be helpful to provide a bit more context about the > overall protocol flow (similar to Section 6 of the community edition). I flipped between section 3 and 4. This might be enough. > 4. In Section 3.1, we might want to say explicitly which parameters are > required and which are not. For example, "Protocol parameters MUST NOT > appear more than once per request. The following parameters are > REQUIRED > unless otherwise noted." Then say that, for example, oauth_version is > RECOMMENDED instead of REQUIRED (or whatever). In the new section 4.1 I added: Each of the protocol parameters listed in Section 4.3 except for "oauth_signature" is assigned a value based on its definition. All the parameters MUST be included, except for "oauth_version" which MAY be omitted, and "oauth_token" which MUST be omitted when making a temporary credentials request (Section 3.1). > 5. In Section 3.2, it's not completely clear that the timestamp value > must be numerical instead of, say, in ISO 8601 format. It's also not > clear how the server would specify that the timestamp is something > other > than "the number of seconds since January 1, 1970 00:00:00 GMT". I made a protocol change to this section, simplifying the text and remove t= he 'equal or greater' requirement (which is not really practical when used = across multiple machines): The timestamp value MUST be a positive integer. Unless otherwis= e specified by the server's documentation, the timestamp is expressed in the numbe= r of seconds since January 1, 1970 00:00:00 GMT. > 6. In Section 3.2, let's explicitly say that methods that enable the > client to sync its clock with the server's clock are out of scope for > OAuth. Done. > 7. In Section 3.3, let's refer to the Security Considerations from the > paragraph about not mandating a particular signature method (since > that's where we talk about the properties of various methods). Done. > 8. In Section 3.3.1.1, we might want to be more explicit about which > parameters are included in the "specific set of request parameters" > (see > recent discussion on the community list). Entire section rewritten. Review requested. > 9. In Section 3.3.1.1 second bullet point, we say "The HTTP request > entity-body, but only if..." -- does this mean that all of the three > listed conditions need to be met, or any one of the conditions? Done. > 10. In Section 3.3.1.1, the sentence >=20 > The "oauth_signature" parameter MUST be excluded if present. >=20 > might be taken to imply that all other oauth_* parameters MUST be > included (if found in the request). Let's be explicit about that. Please check new language. > 11. In Section 3.3.4, we say that PLAINTEXT method SHOULD be used with > SSL/TLS. Does that deserve to be a MUST? At least it might be worth a > mention in the Security Considerations. MUST is asking for too much. I added a pointer to the relevant security sec= tion. > 12. In Section 3.6, we say that "Text values are first encoded as UTF- > 8" > but it's not fully clear to me which values this applies to or exactly > where in the protocol the encoding rules are applied. I added an introduction to the section. This has always been a sore point a= nd underspecified. I am happy to consider clarifications. > 13. In Section 4, I think that a brief flow diagram would be helpful to > illustrate the authorization process (e.g., this would provide context > for why the client obtains a set of temporary credentials, which might > not otherwise be obivous to first-time readers of Section 4.1). I am going to dig Jeff's diagrams and see if I can make them work for this. > 14. In Section 4.2 (or in a security consideration pointed to from > Section 4.2), it might be helpful to describe why oauth_callback is > important and the nature of the session fixation attach that it helps > to prevent. If someone wants to offer text, I am happy to consider. I don't write secur= ity text. > 15. In Section 6.8, I think there is a non-sequitur. Just because a > client is a freely available desktop application does not mean that an > attacker will be able to recover the client credentials. Perhaps one > step in the chain of reasoning is not spelled out here? If you have access to the client bits, you can reverse engineer it to get t= he secret. See DVD encryption key... > 16. Section 6.15 says: >=20 > Clients should prevent CSRF attacks on OAuth callback URIs > by verifying that the resource owner at the client site intended to > complete the OAuth negotiation with the server. >=20 > No guidance is provided on how the client might be able to do so. > Saying > that "methods for doing so are out of scope for this specification" is > probably acceptable. Done. > 17. In Appendix A.1 the phrase "HTTPS POST" is used, but I think that's > more accurately an HTTP POST to an SSL-protected host. I think it is easier to read this way. Thanks again. Please review -04. EHL From eran@hueniverse.com Mon Nov 16 00:17:33 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3521028C0F1 for ; Mon, 16 Nov 2009 00:17:33 -0800 (PST) X-Quarantine-ID: <8SGlyZGgTFmb> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, MIME error: error: illegal encoding [base64] for MIME type message/external-body 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 8SGlyZGgTFmb for ; Mon, 16 Nov 2009 00:17:32 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 5AF0028C0E5 for ; Mon, 16 Nov 2009 00:17:32 -0800 (PST) Received: (qmail 20478 invoked from network); 16 Nov 2009 08:17:31 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 16 Nov 2009 08:17:31 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Mon, 16 Nov 2009 01:17:31 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Mon, 16 Nov 2009 01:17:31 -0700 Thread-Topic: I-D Action:draft-hammer-oauth-05.txt Thread-Index: AcpmlOfp8JINKOOgTj+BQRkgA4dfLQAABWSw Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343785103136@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/mixed; boundary="_002_90C41DD21FB7C64BB94121FBBC2E72343785103136P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: [OAUTH-WG] I-D Action:draft-hammer-oauth-05.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: Mon, 16 Nov 2009 08:17:33 -0000 --_002_90C41DD21FB7C64BB94121FBBC2E72343785103136P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : The OAuth Core 1.0 Protocol Author(s) : E. Hammer-Lahav Filename : draft-hammer-oauth-05.txt Pages : 39 Date : 2009-11-16 This document specifies the OAuth Core 1.0 protocol. OAuth provides a meth= od for clients to access server resources on behalf of another party (such = as a different client or an end user). It also provides a redirection-base= d user agent process for end users to authorize access to another party by = substituting their credentials (typically, a username and password pair) wi= th a different set of delegation- specific credentials. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hammer-oauth-05.txt -05 o Replaced the word 'lexicographical' with 'ascending' in sorting instructions. o Added note that the 'a3' parameter appears twice in the example. o Made the note about the encoding scheme being different from most common implementations more explicit. o Moved and cleaned up the example from appendix to introduction. Removed crypto details from the example. -04 o Corrected typo and other minor editorial changes. o Added warning about token sizes. o Clarified that all 'oauth_' parameters must be transmitted using the same method. o Added explicit requirement to exclude parameters not transmitted in a request in the signature base string (for example oauth_version when omitted). o Explicitly set OAuth to use HTTP 1.1. o Rearranged the signature base string section to provide a better narrative of how the HTTP request is normalized. Added the protocol parameters to the examples to better demonstrate how they are incorporated in practice. o Flipped the document order between authentication and authorization. o Removed the requirement for timestamps to be equal or greater than previous timestamps. --_002_90C41DD21FB7C64BB94121FBBC2E72343785103136P3PW5EX1MB01E_ Content-Type: message/external-body; name="draft-hammer-oauth-05.url" Content-Description: draft-hammer-oauth-05.url Content-Disposition: attachment; filename="draft-hammer-oauth-05.url"; size=86; creation-date="Mon, 16 Nov 2009 01:15:06 GMT"; modification-date="Mon, 16 Nov 2009 01:15:06 GMT" Content-Transfer-Encoding: base64 W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1oYW1tZXItb2F1dGgtMDUudHh0DQo= --_002_90C41DD21FB7C64BB94121FBBC2E72343785103136P3PW5EX1MB01E_-- From josephholsten@gmail.com Tue Nov 17 19:53:00 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57EDB3A68F5 for ; Tue, 17 Nov 2009 19:53:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 Vz8RSlOPwoOv for ; Tue, 17 Nov 2009 19:52:59 -0800 (PST) Received: from mail-gx0-f228.google.com (mail-gx0-f228.google.com [209.85.217.228]) by core3.amsl.com (Postfix) with ESMTP id D4CDB3A68EE for ; Tue, 17 Nov 2009 19:52:58 -0800 (PST) Received: by gxk28 with SMTP id 28so723807gxk.9 for ; Tue, 17 Nov 2009 19:52:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:from:to :content-type:content-transfer-encoding:mime-version:subject:date :x-mailer; bh=dv/o+daaOobVQLaZj+LoSIXRkcxS5c+X/KkFzw+3fFY=; b=rC3PgfAoKKujJmBSwrHdGT0/Yrarr3mCt6t95eeS3DfnGhoFtdcPrJRxsGzSyA0USp ziCkpmIiHYMBMG34W2MyFRp0K6msMztAURnBMftX0REpymx4DFzzzcEKMl9SJcE7WqaX e31pShF3iwHS1uYDhRS9xrIQMIM/kAUDegwjc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:from:to:content-type:content-transfer-encoding :mime-version:subject:date:x-mailer; b=bYC0IAh2QUsWMe2ZXJQ38OeEY0hGgjUk5XQFIPbO7Kcg8PGkpnmoOCoRrkhU2tJUAE YAFdfHp2UsYPePbpKHF44gP0CfZSHAyUg8gNnSfvohl6po1YaIS1/bSqNK4hviL9S2DE GRE0uivXDN89chXarMY3iWADqWnZXg/ZaBiZY= Received: by 10.91.26.31 with SMTP id d31mr1377176agj.44.1258516373879; Tue, 17 Nov 2009 19:52:53 -0800 (PST) Received: from ?192.168.1.102? (ip70-189-108-199.ok.ok.cox.net [70.189.108.199]) by mx.google.com with ESMTPS id 23sm717490yxe.18.2009.11.17.19.52.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 17 Nov 2009 19:52:52 -0800 (PST) Sender: Joseph Holsten Message-Id: <826F29F5-85AB-443B-8CAB-466EBE48AB8C@josephholsten.com> From: Joseph A Holsten To: oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 17 Nov 2009 21:52:50 -0600 X-Mailer: Apple Mail (2.936) Subject: [OAUTH-WG] Secure Client Token Storage X-BeenThere: oauth@ietf.org X-Mailman-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, 18 Nov 2009 03:53:00 -0000 If browsers start having OAuth support, they're definitely going to =20 need a secure store for those OAuth tokens, so my malicious app =20 doesn't just dig through your Firefox config for access to tokens. This doesn't seem to be mentioned in draft-hammer-oauth-05, =A74.7 is =20= server specific, and =A74.8 only recommends to hide the client =20 credentials. Should the spec add a section recommending clients store =20= access tokens in secure storage? -- Joseph Holsten http://josephholsten.com mailto:joseph@josephholsten.com tel:+1-918-948-6747 From josephholsten@gmail.com Wed Nov 18 00:33:33 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 168CD3A68B8 for ; Wed, 18 Nov 2009 00:33:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 jIV1SS51+3Wx for ; Wed, 18 Nov 2009 00:33:32 -0800 (PST) Received: from mail-yw0-f183.google.com (mail-yw0-f183.google.com [209.85.211.183]) by core3.amsl.com (Postfix) with ESMTP id 148883A67EC for ; Wed, 18 Nov 2009 00:33:31 -0800 (PST) Received: by ywh13 with SMTP id 13so1270565ywh.29 for ; Wed, 18 Nov 2009 00:33:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=1IN+OGTr6scGldxukjZ6MpWSitibUzaMzpiPO8XhKlY=; b=EdOI80bYXyUZn+udMV8GhxWgVi4cZM7H/GCEWBQjayEj2Ziqha33n/pz1WyGHGBJ6Q IS71lZ66SOgK4sf7SCqsUTsbbyc45T/IFTk9grC0/Kswxt6NRNwR47EFc+m5mAuAOf8Z 4JIGPsZM5ndgKLWnIyXaSPBsJwSEWAw+SWhnc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=O8BHIqU2E+bmtf5j0fZkig8S9EhA2alNXk+05i6aRBP+rzjdtS8AaIz7OKDnZGcNJ1 obFjVE5NI1icWT33iUfDCJ9S2piQFYchM8bO0zvTPzitxXFP/fxMsKa+kp6A+0K1Gzez YD6OdVEsBlOAQCxfQdbLN/u/0+8h61PFq1Mi8= Received: by 10.90.40.37 with SMTP id n37mr1699966agn.74.1258533207345; Wed, 18 Nov 2009 00:33:27 -0800 (PST) Received: from ?192.168.1.102? (ip70-189-108-199.ok.ok.cox.net [70.189.108.199]) by mx.google.com with ESMTPS id 39sm167381yxd.63.2009.11.18.00.33.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 18 Nov 2009 00:33:25 -0800 (PST) Sender: Joseph Holsten Message-Id: From: Joseph A Holsten To: Eran Hammer-Lahav In-Reply-To: Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 18 Nov 2009 02:33:22 -0600 References: X-Mailer: Apple Mail (2.936) Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Secure Client Token Storage X-BeenThere: oauth@ietf.org X-Mailman-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, 18 Nov 2009 08:33:33 -0000 I'm comfortable leaving it implicit if you are. It seems obvious to =20 me, I just never know if it's obvious to everyone else who might =20 implement. -- j Eran Hammer-Lahav supposedly wrote: > Would you like to propose text? > > I think this is application specific. Isn=92t calling it a token =20 > *secret* enough? :-) > > EHL > > > On 11/17/09 7:52 PM, "Joseph A Holsten" =20 > wrote: > > If browsers start having OAuth support, they're definitely going to > need a secure store for those OAuth tokens, so my malicious app > doesn't just dig through your Firefox config for access to tokens. > > This doesn't seem to be mentioned in draft-hammer-oauth-05, =A74.7 is > server specific, and =A74.8 only recommends to hide the client > credentials. Should the spec add a section recommending clients store > access tokens in secure storage? > -- > Joseph Holsten > http://josephholsten.com > mailto:joseph@josephholsten.com > tel:+1-918-948-6747 From eran@hueniverse.com Wed Nov 18 01:08:03 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6A653A68B4 for ; Wed, 18 Nov 2009 01:08:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.624 X-Spam-Level: X-Spam-Status: No, score=-1.624 tagged_above=-999 required=5 tests=[AWL=0.974, 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 xeF-ajCS1-mU for ; Wed, 18 Nov 2009 01:07:59 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id B52C83A6887 for ; Wed, 18 Nov 2009 01:07:59 -0800 (PST) Received: (qmail 11742 invoked from network); 18 Nov 2009 05:07:53 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 18 Nov 2009 05:07:53 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 17 Nov 2009 22:07:53 -0700 From: Eran Hammer-Lahav To: Joseph A Holsten , "oauth@ietf.org" Date: Tue, 17 Nov 2009 22:07:41 -0700 Thread-Topic: [OAUTH-WG] Secure Client Token Storage Thread-Index: AcpoAqDAHMthiE7eS4uXQeNCA1nHewACm0dY Message-ID: In-Reply-To: <826F29F5-85AB-443B-8CAB-466EBE48AB8C@josephholsten.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_C728C11D29773eranhueniversecom_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Secure Client Token Storage X-BeenThere: oauth@ietf.org X-Mailman-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, 18 Nov 2009 09:08:03 -0000 --_000_C728C11D29773eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Would you like to propose text? I think this is application specific. Isn't calling it a token *secret* eno= ugh? :-) EHL On 11/17/09 7:52 PM, "Joseph A Holsten" wrote: If browsers start having OAuth support, they're definitely going to need a secure store for those OAuth tokens, so my malicious app doesn't just dig through your Firefox config for access to tokens. This doesn't seem to be mentioned in draft-hammer-oauth-05, =A74.7 is server specific, and =A74.8 only recommends to hide the client credentials. Should the spec add a section recommending clients store access tokens in secure storage? -- Joseph Holsten http://josephholsten.com mailto:joseph@josephholsten.com tel:+1-918-948-6747 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_C728C11D29773eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] Secure Client Token Storage Would you like to propose text?

I think this is application specific. Isn’t calling it a token *secre= t* enough? :-)

EHL


On 11/17/09 7:52 PM, "Joseph A Holsten" <joseph@josephholsten.com> wrote:

If browsers start having OAuth support, the= y're definitely going to
need a secure store for those OAuth tokens, so my malicious app
doesn't just dig through your Firefox config for access to tokens.

This doesn't seem to be mentioned in draft-hammer-oauth-05, §4.7 is server specific, and §4.8 only recommends to hide the client
credentials. Should the spec add a section recommending clients store
access tokens in secure storage?
--
Joseph Holsten
http://josephholsten.com
mailto:joseph@josephholsten.com=
tel:+1-918-948-6747

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

--_000_C728C11D29773eranhueniversecom_-- From stpeter@stpeter.im Wed Nov 18 13:32:42 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0022A28C102 for ; Wed, 18 Nov 2009 13:32:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 lRwNfEQJYkrY for ; Wed, 18 Nov 2009 13:32:40 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 6D8A33A65A5 for ; Wed, 18 Nov 2009 13:32:40 -0800 (PST) Received: from dhcp-64-101-72-196.cisco.com (dhcp-64-101-72-196.cisco.com [64.101.72.196]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 1947940D26; Wed, 18 Nov 2009 14:32:38 -0700 (MST) Message-ID: <4B0467F4.6060702@stpeter.im> Date: Wed, 18 Nov 2009 14:32:36 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Eran Hammer-Lahav References: <4AF8943E.4050802@stpeter.im> <90C41DD21FB7C64BB94121FBBC2E72343785103101@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343785103101@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020507070703060902010908" Cc: OAuth WG Subject: Re: [OAUTH-WG] comments on draft-hammer-oauth-03 X-BeenThere: oauth@ietf.org X-Mailman-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, 18 Nov 2009 21:32:42 -0000 This is a cryptographically signed message in MIME format. --------------ms020507070703060902010908 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 11/15/09 3:29 PM, Eran Hammer-Lahav wrote: > Thanks Peter. This is very helpful. > > The following changes have been submitted as a -04 revision. Thanks for the fast turnaround! A few comments inline. >> -----Original Message----- From: oauth-bounces@ietf.org >> [mailto:oauth-bounces@ietf.org] On Behalf Of Peter Saint-Andre >> Sent: Monday, November 09, 2009 2:14 PM > >> We might also want to point to RFC 4949 regarding terminology and >> check that our usage of key terms like "authorization" is >> consistent with that document. > > If someone wants to give it a try, I am open to it. I think this is more important for OAuth 1.1 so let's fold it into that effort. In any case I don't think it's a lot of work. >> 3. Before jumping right into authenticated requests in section 3, I >> think it would be helpful to provide a bit more context about the >> overall protocol flow (similar to Section 6 of the community >> edition). > > I flipped between section 3 and 4. This might be enough. I think that does it, yes. >> 4. In Section 3.1, we might want to say explicitly which parameters >> are required and which are not. For example, "Protocol parameters >> MUST NOT appear more than once per request. The following >> parameters are REQUIRED unless otherwise noted." Then say that, for >> example, oauth_version is RECOMMENDED instead of REQUIRED (or >> whatever). > > In the new section 4.1 I added: > > Each of the protocol parameters listed in Section 4.3 except for > "oauth_signature" is assigned a value based on its definition. All > the parameters MUST be included, except for "oauth_version" which MAY > be omitted, and "oauth_token" which MUST be omitted when making a > temporary credentials request (Section 3.1). That's better, thanks. >> 5. In Section 3.2, it's not completely clear that the timestamp >> value must be numerical instead of, say, in ISO 8601 format. It's >> also not clear how the server would specify that the timestamp is >> something other than "the number of seconds since January 1, 1970 >> 00:00:00 GMT". > > I made a protocol change to this section, simplifying the text and > remove the 'equal or greater' requirement (which is not really > practical when used across multiple machines): > > The timestamp value MUST be a positive integer. Unless otherwise > specified by the server's documentation, the timestamp is expressed > in the number of seconds since January 1, 1970 00:00:00 GMT. +1 >> 8. In Section 3.3.1.1, we might want to be more explicit about >> which parameters are included in the "specific set of request >> parameters" (see recent discussion on the community list). > > Entire section rewritten. Review requested. That's clearer now. >> 10. In Section 3.3.1.1, the sentence >> >> The "oauth_signature" parameter MUST be excluded if present. >> might be taken to imply that all other oauth_* parameters MUST be >> included (if found in the request). Let's be explicit about that. > > Please check new language. Works for me. >> 11. In Section 3.3.4, we say that PLAINTEXT method SHOULD be used >> with SSL/TLS. Does that deserve to be a MUST? At least it might be >> worth a mention in the Security Considerations. > > MUST is asking for too much. I added a pointer to the relevant > security section. OK. >> 12. In Section 3.6, we say that "Text values are first encoded as >> UTF- 8" but it's not fully clear to me which values this applies to >> or exactly where in the protocol the encoding rules are applied. > > I added an introduction to the section. This has always been a sore > point and underspecified. I am happy to consider clarifications. Now it's clear that these rules apply to the signature base string. I think that it would be even clearer as follows: This specification defines the following method for percent- encoding of parameter values that are used as input to construction of the signature base string: (I say this because it's not 100% clear which strings are meant in the current text -- i.e., does the method apply only to the values in the name/value pairs?) >> 13. In Section 4, I think that a brief flow diagram would be >> helpful to illustrate the authorization process (e.g., this would >> provide context for why the client obtains a set of temporary >> credentials, which might not otherwise be obivous to first-time >> readers of Section 4.1). > > I am going to dig Jeff's diagrams and see if I can make them work for > this. OK. >> 14. In Section 4.2 (or in a security consideration pointed to from >> Section 4.2), it might be helpful to describe why oauth_callback is >> important and the nature of the session fixation attach that it >> helps to prevent. > > If someone wants to offer text, I am happy to consider. I don't write > security text. Perhaps we could borrow and adjust some text from your blog post at http://hueniverse.com/2009/04/explaining-the-oauth-session-fixation-attack/ :) >> 15. In Section 6.8, I think there is a non-sequitur. Just because a >> client is a freely available desktop application does not mean >> that an attacker will be able to recover the client credentials. >> Perhaps one step in the chain of reasoning is not spelled out here? >> > > If you have access to the client bits, you can reverse engineer it to > get the secret. See DVD encryption key... Again, I must be missing something. Just because I use Thunderbird or Pidgin or some other free software doesn't mean you can hack into my email or IM password. How is the case any different here? >> 17. In Appendix A.1 the phrase "HTTPS POST" is used, but I think >> that's more accurately an HTTP POST to an SSL-protected host. > > I think it is easier to read this way. OK. Not a big deal either way. > Thanks again. Please review -04. Done. Peter -- Peter Saint-Andre https://stpeter.im/ --------------ms020507070703060902010908 Content-Type: application/x-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 hvcNAQkFMQ8XDTA5MTExODIxMzIzNlowIwYJKoZIhvcNAQkEMRYEFPFue2mMIokjP6+PUJPG ++lwu5k/MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEANRFVMqyNO4ivotX+NP9yqjhKq5hrHXBC9ah5Ga1+ Sl80V2e8ICroqeEISrrp6WAIfd43zSPLWvlnae3qVXlPuVAj3MJoJE+GbWMoxQtrYu4q59X0 /TLG7mbnj/NR0EVnGdVn2iwOrjaPbR6F+wDeAfQXfr1VXQKh+tTatWJmu+Gpj3fe9B3wWJCw yUoVJXa/y0F0fhYt6GE2GbabNc3onefb756TXA7xppuW+fSr8H+3Mg/D6NVZmx5VyGR27NYc l/P8b5t2vL+iKPDQMGZteXV0GiFpJqWsVo2KjSV9BT1UAFTTf5mvqyUjvN7xMXndWBdHl8Bo SpV7PmpAYZbwrQAAAAAAAA== --------------ms020507070703060902010908-- From esjewett@gmail.com Wed Nov 18 14:11:27 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75D643A68C2 for ; Wed, 18 Nov 2009 14:11:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 tn0fR3UOyuHb for ; Wed, 18 Nov 2009 14:11:25 -0800 (PST) Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by core3.amsl.com (Postfix) with ESMTP id C86233A6989 for ; Wed, 18 Nov 2009 14:11:24 -0800 (PST) Received: by pzk6 with SMTP id 6so1057470pzk.29 for ; Wed, 18 Nov 2009 14:11:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=rQZ5Oq2VJiBw+VDXYw9UEYRKBtSkof1utqskTTGxkP4=; b=aM2qXuzx3ljUYbwfx/wbzSdBHT9hiA2VZPiy+273Jb7+Dgx1pa6NeLT1L+l6V3g75s LEnLu6o/5tp9icTaSjmTZYOT/i3bdH2yIfLqbNk3KiXW75H++mLB569pEWWpwlf8jXH+ QbWtWqSX9ijMSDZ5Vt03o5mLmNuddQ3XUcl7I= 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=HsLWfXgVRXRuUtAoL3CwieKt+9hvuRXbVKkDakmzZy+JkK4Y5NRh55QS/2f8x0Lcob f8s4shilmWa6zj5DE6deNVfd5F5/V/c4rDFTh4xsr2BNEesQaznwBpkN08Nw16IUIoJL StEyLkKwlnB/+Yz8ZfqC+0yKN2EQ47bYN7gx0= MIME-Version: 1.0 Received: by 10.140.207.20 with SMTP id e20mr693125rvg.135.1258582279779; Wed, 18 Nov 2009 14:11:19 -0800 (PST) In-Reply-To: <4B0467F4.6060702@stpeter.im> References: <4AF8943E.4050802@stpeter.im> <90C41DD21FB7C64BB94121FBBC2E72343785103101@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B0467F4.6060702@stpeter.im> Date: Wed, 18 Nov 2009 17:11:19 -0500 Message-ID: <68f4a0e80911181411w364b902cg37f8c011dabebdd9@mail.gmail.com> From: Ethan Jewett To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Cc: OAuth WG Subject: Re: [OAUTH-WG] comments on draft-hammer-oauth-03 X-BeenThere: oauth@ietf.org X-Mailman-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, 18 Nov 2009 22:11:27 -0000 On Wed, Nov 18, 2009 at 4:32 PM, Peter Saint-Andre > > Again, I must be missing something. Just because I use Thunderbird or > Pidgin or some other free software doesn't mean you can hack into my > email or IM password. How is the case any different here? I think in the original email "freely" was not meant in terms of free as in beer *or* free as in speech, but rather any software distributed in such a way that an attacker can get his/her hands on a copy of the executable. OAuth in normal installed software must embed the client secret into the executable, and in this case the secret is only as secret as the executable file. This is why OAuth providers that allow installed applications to authenticate against them may want to just forget about the client secret entirely. Ethan From stpeter@stpeter.im Wed Nov 18 14:38:22 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B92153A6810 for ; Wed, 18 Nov 2009 14:38:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 5gqM6pKECR0V for ; Wed, 18 Nov 2009 14:38:21 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id C88563A6A3D for ; Wed, 18 Nov 2009 14:38:21 -0800 (PST) Received: from dhcp-64-101-72-196.cisco.com (dhcp-64-101-72-196.cisco.com [64.101.72.196]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E0FDB40D26; Wed, 18 Nov 2009 15:38:18 -0700 (MST) Message-ID: <4B047759.4060208@stpeter.im> Date: Wed, 18 Nov 2009 15:38:17 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Ethan Jewett References: <4AF8943E.4050802@stpeter.im> <90C41DD21FB7C64BB94121FBBC2E72343785103101@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B0467F4.6060702@stpeter.im> <68f4a0e80911181411w364b902cg37f8c011dabebdd9@mail.gmail.com> In-Reply-To: <68f4a0e80911181411w364b902cg37f8c011dabebdd9@mail.gmail.com> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060605030607070607080407" Cc: OAuth WG Subject: Re: [OAUTH-WG] comments on draft-hammer-oauth-03 X-BeenThere: oauth@ietf.org X-Mailman-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, 18 Nov 2009 22:38:22 -0000 This is a cryptographically signed message in MIME format. --------------ms060605030607070607080407 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 11/18/09 3:11 PM, Ethan Jewett wrote: > On Wed, Nov 18, 2009 at 4:32 PM, Peter Saint-Andre >> Again, I must be missing something. Just because I use Thunderbird or >> Pidgin or some other free software doesn't mean you can hack into my >> email or IM password. How is the case any different here? > > I think in the original email "freely" was not meant in terms of free > as in beer *or* free as in speech, but rather any software distributed > in such a way that an attacker can get his/her hands on a copy of the > executable. OAuth in normal installed software must embed the client > secret into the executable, and in this case the secret is only as > secret as the executable file. > > This is why OAuth providers that allow installed applications to > authenticate against them may want to just forget about the client > secret entirely. Aha, I see. I misunderstood the meaning of "freely downloadable application". Peter -- Peter Saint-Andre https://stpeter.im/ --------------ms060605030607070607080407 Content-Type: application/x-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 hvcNAQkFMQ8XDTA5MTExODIyMzgxN1owIwYJKoZIhvcNAQkEMRYEFLnBVb7SPXTpEtzsCzPP K8jh+JtYMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEASCObmZyytkY/Z2dSv/nVxh8Ve1OumRCC+8pVAEQI 0JRiQ7fk8vmjs4Ue/vz3pIh+Jy9EmBaSaBPBKkjSWcrkfn5IzYsR64bYTczZf9aOe8d2Arom MUyJD420l1OXEvoJPYe4n7++heJiSHZ+rvqk2Mz4yrup8TE+Tj/D/9DXC/u0PFCBqzhwxFl4 d53XNrd17YOPqY7kVXSgmsvnM25R/wXZGls9TSWjlhE1ujI8i7/7LwdnPXYPcJ9np4bGp+fN mO2jLfUYyk4L3rUmXMw85ew3TL7Zj5bi9bjH6DIdd9Mp5VWjKP22AzhcT1d7txQsWkQq60rX r2raW39wu07ykAAAAAAAAA== --------------ms060605030607070607080407-- From eran@hueniverse.com Wed Nov 18 15:03:25 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0DA73A685D for ; Wed, 18 Nov 2009 15:03:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.819 X-Spam-Level: X-Spam-Status: No, score=-1.819 tagged_above=-999 required=5 tests=[AWL=0.780, 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 697E99Lw4qnV for ; Wed, 18 Nov 2009 15:03:24 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id A8FCB3A688D for ; Wed, 18 Nov 2009 15:03:24 -0800 (PST) Received: (qmail 32727 invoked from network); 18 Nov 2009 23:03:23 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 18 Nov 2009 23:03:22 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 18 Nov 2009 16:03:19 -0700 From: Eran Hammer-Lahav To: Peter Saint-Andre Date: Wed, 18 Nov 2009 16:03:29 -0700 Thread-Topic: [OAUTH-WG] comments on draft-hammer-oauth-03 Thread-Index: Acpolqg9y0D8kVJIS/eSRCDrRdnDPgADA7EA Message-ID: <90C41DD21FB7C64BB94121FBBC2E723437851824C8@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4AF8943E.4050802@stpeter.im> <90C41DD21FB7C64BB94121FBBC2E72343785103101@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B0467F4.6060702@stpeter.im> In-Reply-To: <4B0467F4.6060702@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 Cc: OAuth WG Subject: Re: [OAUTH-WG] comments on draft-hammer-oauth-03 X-BeenThere: oauth@ietf.org X-Mailman-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, 18 Nov 2009 23:03:26 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUGV0ZXIgU2FpbnQtQW5k cmUgW21haWx0bzpzdHBldGVyQHN0cGV0ZXIuaW1dDQo+IFNlbnQ6IFdlZG5lc2RheSwgTm92ZW1i ZXIgMTgsIDIwMDkgMTozMyBQTQ0KDQo+ID4+IDEyLiBJbiBTZWN0aW9uIDMuNiwgd2Ugc2F5IHRo YXQgIlRleHQgdmFsdWVzIGFyZSBmaXJzdCBlbmNvZGVkIGFzDQo+ID4+IFVURi0gOCIgYnV0IGl0 J3Mgbm90IGZ1bGx5IGNsZWFyIHRvIG1lIHdoaWNoIHZhbHVlcyB0aGlzIGFwcGxpZXMgdG8NCj4g Pj4gb3IgZXhhY3RseSB3aGVyZSBpbiB0aGUgcHJvdG9jb2wgdGhlIGVuY29kaW5nIHJ1bGVzIGFy ZSBhcHBsaWVkLg0KPiA+DQo+ID4gSSBhZGRlZCBhbiBpbnRyb2R1Y3Rpb24gdG8gdGhlIHNlY3Rp b24uIFRoaXMgaGFzIGFsd2F5cyBiZWVuIGEgc29yZQ0KPiA+IHBvaW50IGFuZCB1bmRlcnNwZWNp ZmllZC4gSSBhbSBoYXBweSB0byBjb25zaWRlciBjbGFyaWZpY2F0aW9ucy4NCj4gDQo+IE5vdyBp dCdzIGNsZWFyIHRoYXQgdGhlc2UgcnVsZXMgYXBwbHkgdG8gdGhlIHNpZ25hdHVyZSBiYXNlIHN0 cmluZy4gSQ0KPiB0aGluayB0aGF0IGl0IHdvdWxkIGJlIGV2ZW4gY2xlYXJlciBhcyBmb2xsb3dz Og0KPiANCj4gICAgVGhpcyBzcGVjaWZpY2F0aW9uIGRlZmluZXMgdGhlIGZvbGxvd2luZyBtZXRo b2QgZm9yIHBlcmNlbnQtDQo+ICAgIGVuY29kaW5nIG9mIHBhcmFtZXRlciB2YWx1ZXMgdGhhdCBh cmUgdXNlZCBhcyBpbnB1dCB0byBjb25zdHJ1Y3Rpb24NCj4gICAgb2YgdGhlIHNpZ25hdHVyZSBi YXNlIHN0cmluZzoNCj4gDQo+IChJIHNheSB0aGlzIGJlY2F1c2UgaXQncyBub3QgMTAwJSBjbGVh ciB3aGljaCBzdHJpbmdzIGFyZSBtZWFudCBpbiB0aGUNCj4gY3VycmVudCB0ZXh0IC0tIGkuZS4s IGRvZXMgdGhlIG1ldGhvZCBhcHBseSBvbmx5IHRvIHRoZSB2YWx1ZXMgaW4gdGhlDQo+IG5hbWUv dmFsdWUgcGFpcnM/KQ0KDQpJJ2xsIHRha2UgYSBsb29rLiBUaGUgcHJvYmxlbSBpcyB3ZSAiYWNj aWRlbnRseSIgYXBwbGllZCB0aGUgZW5jb2RpbmcgbWV0aG9kIHRvIHRoZSBhdXRob3JpemF0aW9u IGhlYWRlci4uLiBUaGlzIG1lYW5zIHRoaXMgc3BlY2lmaWMgd2F5IG9mIGVuY29kaW5nIGxlYWtl ZCBvdXQgb2YgdGhlIHNpZ25hdHVyZSBiYXNlIHN0cmluZyBzY29wZS4gVGhpcyBtYWtlcyBpdCBh IGJpdCBoYXJkIHRvIGJlIHNvIHNwZWNpZmljIGFib3V0IGl0cyBjb250ZXh0LiBJIGNhbiB0cnkg dG8gYmUgbW9yZSBzcGVjaWZpYyBieSBzYXlpbmcgaXQgaXMgZm9yIHRoZSBTQlMgYW5kIGhlYWRl ciwgYnV0IGRvZXMgbm90IGFwcGx5IHRvIHBhcmFtZXRlciBlbmNvZGluZyBpbiB0aGUgcXVlcnkg b3IgYm9keS4uLiBOb3Qgc3VyZSBob3cgbXVjaCB0aGF0IHdpbGwgaGVscCB0aG91Z2guDQoNCj4g Pj4gMTMuIEluIFNlY3Rpb24gNCwgSSB0aGluayB0aGF0IGEgYnJpZWYgZmxvdyBkaWFncmFtIHdv dWxkIGJlDQo+ID4+IGhlbHBmdWwgdG8gaWxsdXN0cmF0ZSB0aGUgYXV0aG9yaXphdGlvbiBwcm9j ZXNzIChlLmcuLCB0aGlzIHdvdWxkDQo+ID4+IHByb3ZpZGUgY29udGV4dCBmb3Igd2h5IHRoZSBj bGllbnQgb2J0YWlucyBhIHNldCBvZiB0ZW1wb3JhcnkNCj4gPj4gY3JlZGVudGlhbHMsIHdoaWNo IG1pZ2h0IG5vdCBvdGhlcndpc2UgYmUgb2Jpdm91cyB0byBmaXJzdC10aW1lDQo+ID4+IHJlYWRl cnMgb2YgU2VjdGlvbiA0LjEpLg0KPiA+DQo+ID4gSSBhbSBnb2luZyB0byBkaWcgSmVmZidzIGRp YWdyYW1zIGFuZCBzZWUgaWYgSSBjYW4gbWFrZSB0aGVtIHdvcmsgZm9yDQo+ID4gdGhpcy4NCj4g DQo+IE9LLg0KDQpTdGlsbCBvbiBteSBsaXN0IHBlbmRpbmcgbW9yZSBpdGVtcy4NCg0KPiA+PiAx NC4gSW4gU2VjdGlvbiA0LjIgKG9yIGluIGEgc2VjdXJpdHkgY29uc2lkZXJhdGlvbiBwb2ludGVk IHRvIGZyb20NCj4gPj4gU2VjdGlvbiA0LjIpLCBpdCBtaWdodCBiZSBoZWxwZnVsIHRvIGRlc2Ny aWJlIHdoeSBvYXV0aF9jYWxsYmFjayBpcw0KPiA+PiAgaW1wb3J0YW50IGFuZCB0aGUgbmF0dXJl IG9mIHRoZSBzZXNzaW9uIGZpeGF0aW9uIGF0dGFjaCB0aGF0IGl0DQo+ID4+IGhlbHBzIHRvIHBy ZXZlbnQuDQo+ID4NCj4gPiBJZiBzb21lb25lIHdhbnRzIHRvIG9mZmVyIHRleHQsIEkgYW0gaGFw cHkgdG8gY29uc2lkZXIuIEkgZG9uJ3Qgd3JpdGUNCj4gPiBzZWN1cml0eSB0ZXh0Lg0KPiANCj4g UGVyaGFwcyB3ZSBjb3VsZCBib3Jyb3cgYW5kIGFkanVzdCBzb21lIHRleHQgZnJvbSB5b3VyIGJs b2cgcG9zdCBhdA0KPiBodHRwOi8vaHVlbml2ZXJzZS5jb20vMjAwOS8wNC9leHBsYWluaW5nLXRo ZS1vYXV0aC1zZXNzaW9uLWZpeGF0aW9uLQ0KPiBhdHRhY2svDQo+IDopDQoNCkdvIGZvciBpdC4u LiA6LSkgSXQgaXMgb25lIHRoaW5nIGZvciBtZSB0byB3cml0ZSBibG9nIHBvc3RzICh3aXRoIHRo ZSByZXZpZXcgb2YgQnJpYW4gYW5kIERpcmspLCBidXQgYW5vdGhlciB0byB3cml0ZSBpdCBmb3Ig dGhlIHNwZWMuDQoNCj4gPj4gMTUuIEluIFNlY3Rpb24gNi44LCBJIHRoaW5rIHRoZXJlIGlzIGEg bm9uLXNlcXVpdHVyLiBKdXN0IGJlY2F1c2UgYQ0KPiA+PiAgY2xpZW50IGlzIGEgZnJlZWx5IGF2 YWlsYWJsZSBkZXNrdG9wIGFwcGxpY2F0aW9uIGRvZXMgbm90IG1lYW4NCj4gPj4gdGhhdCBhbiBh dHRhY2tlciB3aWxsIGJlIGFibGUgdG8gcmVjb3ZlciB0aGUgY2xpZW50IGNyZWRlbnRpYWxzLg0K PiA+PiBQZXJoYXBzIG9uZSBzdGVwIGluIHRoZSBjaGFpbiBvZiByZWFzb25pbmcgaXMgbm90IHNw ZWxsZWQgb3V0IGhlcmU/DQo+ID4+DQo+ID4NCj4gPiBJZiB5b3UgaGF2ZSBhY2Nlc3MgdG8gdGhl IGNsaWVudCBiaXRzLCB5b3UgY2FuIHJldmVyc2UgZW5naW5lZXIgaXQgdG8NCj4gPiBnZXQgdGhl IHNlY3JldC4gU2VlIERWRCBlbmNyeXB0aW9uIGtleS4uLg0KPiANCj4gQWdhaW4sIEkgbXVzdCBi ZSBtaXNzaW5nIHNvbWV0aGluZy4gSnVzdCBiZWNhdXNlIEkgdXNlIFRodW5kZXJiaXJkIG9yDQo+ IFBpZGdpbiBvciBzb21lIG90aGVyIGZyZWUgc29mdHdhcmUgZG9lc24ndCBtZWFuIHlvdSBjYW4g aGFjayBpbnRvIG15DQo+IGVtYWlsIG9yIElNIHBhc3N3b3JkLiBIb3cgaXMgdGhlIGNhc2UgYW55 IGRpZmZlcmVudCBoZXJlPw0KDQpObyBuby4gKllvdSogY2FuIGhhY2sgdGhvc2UgYXBwbGljYXRp b25zIGFuZCBmaW5kIHRoZWlyIGNsaWVudCBjcmVkZW50aWFscyAobm90IHRva2VuIGNyZWRlbnRp YWxzKS4NCg0KVGhhbmtzLA0KDQpFSEwNCg0KDQo= From stpeter@stpeter.im Thu Nov 19 15:49:03 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C02928C0DB for ; Thu, 19 Nov 2009 15:49:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lwq5pDnBYNYU for ; Thu, 19 Nov 2009 15:49:02 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 2407328C0D7 for ; Thu, 19 Nov 2009 15:49:02 -0800 (PST) Received: from squire.local (ip-216-17-182-30.rev.frii.com [216.17.182.30]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id EC41740D13; Thu, 19 Nov 2009 16:48:58 -0700 (MST) Message-ID: <4B05D52F.1070303@stpeter.im> Date: Thu, 19 Nov 2009 16:30:55 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Eran Hammer-Lahav References: <4AF8943E.4050802@stpeter.im> <90C41DD21FB7C64BB94121FBBC2E72343785103101@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B0467F4.6060702@stpeter.im> <90C41DD21FB7C64BB94121FBBC2E723437851824C8@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723437851824C8@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010409040304050004080609" Cc: OAuth WG Subject: Re: [OAUTH-WG] comments on draft-hammer-oauth-03 X-BeenThere: oauth@ietf.org X-Mailman-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, 19 Nov 2009 23:49:03 -0000 This is a cryptographically signed message in MIME format. --------------ms010409040304050004080609 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 11/18/09 4:03 PM, Eran Hammer-Lahav wrote: > >> -----Original Message----- From: Peter Saint-Andre >> [mailto:stpeter@stpeter.im] Sent: Wednesday, November 18, 2009 1:33 >> PM > >>>> 12. In Section 3.6, we say that "Text values are first encoded >>>> as UTF- 8" but it's not fully clear to me which values this >>>> applies to or exactly where in the protocol the encoding rules >>>> are applied. >>> I added an introduction to the section. This has always been a >>> sore point and underspecified. I am happy to consider >>> clarifications. >> Now it's clear that these rules apply to the signature base string. >> I think that it would be even clearer as follows: >> >> This specification defines the following method for percent- >> encoding of parameter values that are used as input to construction >> of the signature base string: >> >> (I say this because it's not 100% clear which strings are meant in >> the current text -- i.e., does the method apply only to the values >> in the name/value pairs?) > > I'll take a look. The problem is we "accidently" applied the encoding > method to the authorization header... This means this specific way of > encoding leaked out of the signature base string scope. This makes it > a bit hard to be so specific about its context. I can try to be more > specific by saying it is for the SBS and header, but does not apply > to parameter encoding in the query or body... Not sure how much that > will help though. That's not a disaster, I just thought it would be good to clarify the context to forestall confusion. But I don't know if this is a source of confusion at present. >>>> 13. In Section 4, I think that a brief flow diagram would be >>>> helpful to illustrate the authorization process (e.g., this >>>> would provide context for why the client obtains a set of >>>> temporary credentials, which might not otherwise be obivous to >>>> first-time readers of Section 4.1). >>> I am going to dig Jeff's diagrams and see if I can make them work >>> for this. >> OK. > > Still on my list pending more items. IMHO this is nice but not necessary. Perhaps it's an item for the WG items and not the informational spec. >>>> 14. In Section 4.2 (or in a security consideration pointed to >>>> from Section 4.2), it might be helpful to describe why >>>> oauth_callback is important and the nature of the session >>>> fixation attach that it helps to prevent. >>> If someone wants to offer text, I am happy to consider. I don't >>> write security text. >> Perhaps we could borrow and adjust some text from your blog post at >> >> http://hueniverse.com/2009/04/explaining-the-oauth-session-fixation- >> attack/ :) > > Go for it... :-) It is one thing for me to write blog posts (with the > review of Brian and Dirk), but another to write it for the spec. I'll see what I can come up with. >>>> 15. In Section 6.8, I think there is a non-sequitur. Just >>>> because a client is a freely available desktop application does >>>> not mean that an attacker will be able to recover the client >>>> credentials. Perhaps one step in the chain of reasoning is not >>>> spelled out here? >>>> >>> If you have access to the client bits, you can reverse engineer >>> it to get the secret. See DVD encryption key... >> Again, I must be missing something. Just because I use Thunderbird >> or Pidgin or some other free software doesn't mean you can hack >> into my email or IM password. How is the case any different here? > > No no. *You* can hack those applications and find their client > credentials (not token credentials). Yes, I figured that out now. :) Peter -- Peter Saint-Andre https://stpeter.im/ --------------ms010409040304050004080609 Content-Type: application/x-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 hvcNAQkFMQ8XDTA5MTExOTIzMzA1NVowIwYJKoZIhvcNAQkEMRYEFIBa1JmDS/Rp3ZdE1CYa 0w8/7BmnMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAc0X5bcWI+xgJuUZKkMXbCBy772GxZeLjxFxrDedx t+KobPe5RdzrQQq1rIe2JWWqmRdm7xIrOZm7/9wkKLSawBzxPwtAGLGsaGEqQfBdU+tt9wR+ LXmVVSkNfsToIHAWR91CaDh5+G11i9x1kKqWAW47CHRxTz2IlmcHtkgwFdAFKrJ2tc3ZJI45 71k/Fu1jzsBkd3DufVaNmQWaaO9aZJtskQpHEoXT4TOQsRqtSICLo+OGAa03CHIzWF2dQ+FG Phi/KaP21SY9ATcbQpAvRKUT4vsMOB4sejGI6WkkboTEatQGjgMqz1gzDRuOZQu4YVwUCkdq aVLKscIDNnBlFQAAAAAAAA== --------------ms010409040304050004080609-- From eran@hueniverse.com Fri Nov 20 19:37:56 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EF7F3A6867 for ; Fri, 20 Nov 2009 19:37:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.042 X-Spam-Level: X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[AWL=0.557, 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 swMd0R0OgOSD for ; Fri, 20 Nov 2009 19:37:55 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 65D2F3A6809 for ; Fri, 20 Nov 2009 19:37:55 -0800 (PST) Received: (qmail 5316 invoked from network); 21 Nov 2009 03:37:52 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 21 Nov 2009 03:37:51 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Fri, 20 Nov 2009 20:37:51 -0700 From: Eran Hammer-Lahav To: "OAuth WG (oauth@ietf.org)" Date: Fri, 20 Nov 2009 20:37:33 -0700 Thread-Topic: New Version Notification - draft-hammer-oauth-06.txt Thread-Index: AcpqWugpSGDOYas8TgiCpXwqNojxVwAAJ1uw Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343785182B60@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] FW: New Version Notification - draft-hammer-oauth-06.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: Sat, 21 Nov 2009 03:37:56 -0000 TGFzdCBjaGFuY2UgdG8gcHJvdmlkZSBmZWVkYmFjayBieSBNb24gMTEvMjMuDQoNCiAgIC0wNg0K DQogICBvICBNb3ZlZCBwYXJhbWV0ZXIgc2VjdGlvbiBpbnRvIGNsaWVudCBpbnN0cnVjdGlvbnMu DQoNCiAgIG8gIEFkZGVkIG1vcmUgZXhhbXBsZXMgaW4gdGhlIGRlbGVnYXRpb24gc2VjdGlvbiwg aW5jbHVkaW5nIG1vcmUNCiAgICAgIGNvbXBsZXRlIEhUVFAgcmVzcG9uc2VzLg0KDQogICBvICBS ZW1vdmVkIGxhbmd1YWdlIGFib3V0IHJlc3RyaWN0aW5nIHRoZSB1c2Ugb2YgdGhlICdvYXV0aF8n IHByZWZpeC4NCg0KICAgbyAgQ2hhbmdlZCB0aGUgbm9uY2UgYW5kIHRpbWVzdGFtcCBwYXJhbWV0 ZXJzIHRvIG9wdGlvbmFsIHdoZW4gdXNpbmcNCiAgICAgIFBMQUlOVEVYVCAgKFBST1RPQ09MIENI QU5HRSkuDQoNCiAgIG8gIEFsbG93ZWQgZW1wdHkgdG9rZW4gaW4gdGVtcG9yYXJ5IGNyZWRlbnRp YWxzIHJlcXVlc3RzIChQUk9UT0NPTCBDSEFOR0UpLg0KDQpFSEwNCg0KLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCkZyb206IEludGVybmV0LURyYWZ0QGlldGYub3JnIFttYWlsdG86SW50ZXJu ZXQtRHJhZnRAaWV0Zi5vcmddIA0KU2VudDogRnJpZGF5LCBOb3ZlbWJlciAyMCwgMjAwOSA3OjMw IFBNDQpUbzogRXJhbiBIYW1tZXItTGFoYXY7IHJvbWVkYUBnbWFpbC5jb207IGRyYWZ0LWhhbW1l ci1vYXV0aEB0b29scy5pZXRmLm9yZzsgbGlzYS5kdXNzZWF1bHRAZ21haWwuY29tDQpTdWJqZWN0 OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gLSBkcmFmdC1oYW1tZXItb2F1dGgtMDYudHh0IA0K DQpOZXcgdmVyc2lvbiAoLTA2KSBoYXMgYmVlbiBzdWJtaXR0ZWQgZm9yIGRyYWZ0LWhhbW1lci1v YXV0aC0wNi50eHQuDQpodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1o YW1tZXItb2F1dGgtMDYudHh0DQoNCg0KRGlmZiBmcm9tIHByZXZpb3VzIHZlcnNpb246DQpodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWhhbW1lci1vYXV0aC0wNg0KDQpJ RVRGIFNlY3JldGFyaWF0Lg0K From eran@hueniverse.com Mon Nov 23 12:10:59 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05DA23A69F8 for ; Mon, 23 Nov 2009 12:10:59 -0800 (PST) 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 ChM5zBpYmhUg for ; Mon, 23 Nov 2009 12:10:58 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 0183F3A68C3 for ; Mon, 23 Nov 2009 12:10:57 -0800 (PST) Received: (qmail 15048 invoked from network); 23 Nov 2009 20:10:52 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 23 Nov 2009 20:10:52 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 23 Nov 2009 13:10:51 -0700 From: Eran Hammer-Lahav To: "OAuth WG (oauth@ietf.org)" Date: Mon, 23 Nov 2009 13:10:55 -0700 Thread-Topic: New Version Notification - draft-hammer-oauth-07.txt Thread-Index: Acpsc1iVd1RbzoMSQw6VU4TBZh4vBgABU27w Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343785182DEC@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] FW: New Version Notification - draft-hammer-oauth-07.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: Mon, 23 Nov 2009 20:10:59 -0000 VGhpcyBoYXMgYmVlbiBzZW50IHRvIHRoZSBJRVNUIGZvciBmaW5hbCBhcHByb3ZhbC4gTWFueSB0 aGFua3MgdG8gdGhvc2Ugd2hvIHRvb2sgdGhlIHRpbWUgdG8gcmV2aWV3IGFuZCBwcm92aWRlZCBm ZWVkYmFjay4NCg0KRUhMDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBJbnRl cm5ldC1EcmFmdEBpZXRmLm9yZyBbbWFpbHRvOkludGVybmV0LURyYWZ0QGlldGYub3JnXSANClNl bnQ6IE1vbmRheSwgTm92ZW1iZXIgMjMsIDIwMDkgMTE6MzAgQU0NClRvOiBFcmFuIEhhbW1lci1M YWhhdjsgcm9tZWRhQGdtYWlsLmNvbTsgZHJhZnQtaGFtbWVyLW9hdXRoQHRvb2xzLmlldGYub3Jn OyBsaXNhLmR1c3NlYXVsdEBnbWFpbC5jb20NClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNh dGlvbiAtIGRyYWZ0LWhhbW1lci1vYXV0aC0wNy50eHQgDQoNCk5ldyB2ZXJzaW9uICgtMDcpIGhh cyBiZWVuIHN1Ym1pdHRlZCBmb3IgZHJhZnQtaGFtbWVyLW9hdXRoLTA3LnR4dC4NCmh0dHA6Ly93 d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWhhbW1lci1vYXV0aC0wNy50eHQNCg0K DQpEaWZmIGZyb20gcHJldmlvdXMgdmVyc2lvbjoNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9yZmNk aWZmP3VybDI9ZHJhZnQtaGFtbWVyLW9hdXRoLTA3DQoNCklFVEYgU2VjcmV0YXJpYXQuDQo= From eve@xmlgrrl.com Mon Nov 23 18:05:10 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBABD3A688B for ; Mon, 23 Nov 2009 18:05:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.122 X-Spam-Level: **** X-Spam-Status: No, score=4.122 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FH_HOST_EQ_D_D_D_D=0.765, FROM_DOMAIN_NOVOWEL=0.5, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, HOST_MISMATCH_NET=0.311, 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 LVh6CBOzXfWw for ; Mon, 23 Nov 2009 18:05:10 -0800 (PST) Received: from mail.promanage-inc.com (static-98-111-84-13.sttlwa.fios.verizon.net [98.111.84.13]) by core3.amsl.com (Postfix) with ESMTP id 00E233A6860 for ; Mon, 23 Nov 2009 18:05:09 -0800 (PST) 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 nAO24hWg015939 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 23 Nov 2009 18:05:05 -0800 From: Eve Maler Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 23 Nov 2009 18:04:43 -0800 To: oauth@ietf.org, oauth@googlegroups.com Message-Id: Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Subject: [OAUTH-WG] Seeking feedback on UMA's use of OAuth and discovery mechanisms X-BeenThere: oauth@ietf.org X-Mailman-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, 24 Nov 2009 02:05:11 -0000 The User-Managed Access effort[1], previously mentioned on this list as = "ProtectServe", intends to solve user-driven permissioning = (authorization) problems at Internet scale. It is designed to be = modular, and to reuse and profile existing technology as much as = possible. Therefore, we have attempted to "stay out of the business of = authentication", profiling OAuth lightly in order to do so. The UMA group would be grateful for your feedback on our intended usage = of OAuth and its emerging discovery methods. Details can be found in the = worked example in our spec[2]; various explanatory materials about UMA = in general are available as well.[3] Briefly, the UMA protocol has four distinct parties vs. OAuth's three: = there's an authorizing user, a consumer/client (which we call = a"requester"), an SP/server (which we call a "host"), and an = authorization manager. We compose three instances of OAuth to introduce = all these parties appropriately to each other: there's user/host/AM = (three-legged), requester/host (two-legged), and requester/AM (another = two-legged). Because of our goals to allow most of these parties to meet = fairly dynamically, we are leaning quite heavily on XRD and LRDD for = discovery; various simplifying assumptions could probably be made to = simplify this picture, however. (If you find UMA's use cases and design center interesting, you'd be = very welcome at the table.[4]) Thanks, Eve UMA group chair [1] http://kantarainitiative.org/confluence/display/uma/Home [2] = http://kantarainitiative.org/confluence/display/uma/UMA+1.0+Core+Protocol [3] http://kantarainitiative.org/confluence/display/uma/UMA+Explained [4] http://signup.kantarainitiative.org/?selectedGroup=3D11 Eve Maler eve@xmlgrrl.com http://www.xmlgrrl.com/blog= From jpanzer@google.com Mon Nov 23 18:53:53 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52DA728C1E2 for ; Mon, 23 Nov 2009 18:53:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.17 X-Spam-Level: X-Spam-Status: No, score=-105.17 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5, 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 i1KTCkVbDmVN for ; Mon, 23 Nov 2009 18:53:52 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id DE8B028C1D5 for ; Mon, 23 Nov 2009 18:53:51 -0800 (PST) Received: from zps77.corp.google.com (zps77.corp.google.com [172.25.146.77]) by smtp-out.google.com with ESMTP id nAO2rkE1013616 for ; Mon, 23 Nov 2009 18:53:47 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1259031227; bh=emQ/YavKWfaBSD6TsAmuXbcdNHg=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=bm5T8AkS0uhe01XQhAaouEpOI3XyzEP03VBVu/BzHi4Yjk2KE6uZM2asuWKyRsg42 iEoaPqhAaXjwxXDrchycA== 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=OBhvXWLTQYUvpux6ilLAW+UHsp/hF+9A77ND0L/5grIEcd3JezFxkXaGS83ddG05P xD2+kBNm/OoaQLT281rSQ== Received: from pwi15 (pwi15.prod.google.com [10.241.219.15]) by zps77.corp.google.com with ESMTP id nAO2riBT025325 for ; Mon, 23 Nov 2009 18:53:44 -0800 Received: by pwi15 with SMTP id 15so4036652pwi.24 for ; Mon, 23 Nov 2009 18:53:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.9.6 with SMTP id 6mr10909382wai.35.1259031224089; Mon, 23 Nov 2009 18:53:44 -0800 (PST) In-Reply-To: References: From: John Panzer Date: Mon, 23 Nov 2009 18:53:24 -0800 Message-ID: To: Eve Maler Content-Type: multipart/alternative; boundary=00504502e165df7be00479150cc6 X-System-Of-Record: true Cc: oauth@googlegroups.com, oauth@ietf.org Subject: Re: [OAUTH-WG] Seeking feedback on UMA's use of OAuth and discovery mechanisms X-BeenThere: oauth@ietf.org X-Mailman-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, 24 Nov 2009 02:53:53 -0000 --00504502e165df7be00479150cc6 Content-Type: text/plain; charset=ISO-8859-1 It sounds very interesting. In OAuth terms, I think it adds, to the basic OAuth 3 legged flow, the ability to delegate the authorization decisions 'normally' made out of band of the OAuth protocol to a completely separate service. Aftet 60 seconds looking at it, my first silly question is how the AM service is determined -- it looks like everything is based on LRDD starting from the resource being accessed? -- John Panzer / Google jpanzer@google.com / abstractioneer.org / @jpanzer On Mon, Nov 23, 2009 at 6:04 PM, Eve Maler wrote: > The User-Managed Access effort[1], previously mentioned on this list as > "ProtectServe", intends to solve user-driven permissioning (authorization) > problems at Internet scale. It is designed to be modular, and to reuse and > profile existing technology as much as possible. Therefore, we have > attempted to "stay out of the business of authentication", profiling OAuth > lightly in order to do so. > > The UMA group would be grateful for your feedback on our intended usage of > OAuth and its emerging discovery methods. Details can be found in the worked > example in our spec[2]; various explanatory materials about UMA in general > are available as well.[3] > > Briefly, the UMA protocol has four distinct parties vs. OAuth's three: > there's an authorizing user, a consumer/client (which we call a"requester"), > an SP/server (which we call a "host"), and an authorization manager. We > compose three instances of OAuth to introduce all these parties > appropriately to each other: there's user/host/AM (three-legged), > requester/host (two-legged), and requester/AM (another two-legged). Because > of our goals to allow most of these parties to meet fairly dynamically, we > are leaning quite heavily on XRD and LRDD for discovery; various simplifying > assumptions could probably be made to simplify this picture, however. > > (If you find UMA's use cases and design center interesting, you'd be very > welcome at the table.[4]) > > Thanks, > > Eve > UMA group chair > > [1] http://kantarainitiative.org/confluence/display/uma/Home > [2] > http://kantarainitiative.org/confluence/display/uma/UMA+1.0+Core+Protocol > [3] http://kantarainitiative.org/confluence/display/uma/UMA+Explained > [4] http://signup.kantarainitiative.org/?selectedGroup=11 > > > Eve Maler > eve@xmlgrrl.com > http://www.xmlgrrl.com/blog > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --00504502e165df7be00479150cc6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It sounds very interesting. In OAuth terms, I think it adds, to the basic O= Auth 3 legged flow, the ability to delegate the authorization decisions = 9;normally' made out of band of the OAuth protocol to a completely sepa= rate service. =A0Aftet 60 seconds looking at it, my first silly question is= how the AM service is determined -- it looks like everything is based on L= RDD starting from the resource being accessed?

--
John Panzer / Google
jpanzer@google.com / a= bstractioneer.org / @jpanzer



On Mon, Nov 23, 2009 at 6:04 PM, Eve Mal= er <eve@xmlgrrl.com= > wrote:
The User-Managed Access effort[1], previously mentioned on this list as &qu= ot;ProtectServe", intends to solve user-driven permissioning (authoriz= ation) problems at Internet scale. It is designed to be modular, and to reu= se and profile existing technology as much as possible. Therefore, we have = attempted to "stay out of the business of authentication", profil= ing OAuth lightly in order to do so.

The UMA group would be grateful for your feedback on our intended usage of = OAuth and its emerging discovery methods. Details can be found in the worke= d example in our spec[2]; various explanatory materials about UMA in genera= l are available as well.[3]

Briefly, the UMA protocol has four distinct parties vs. OAuth's three: = there's an authorizing user, a consumer/client (which we call a"re= quester"), an SP/server (which we call a "host"), and an aut= horization manager. We compose three instances of OAuth to introduce all th= ese parties appropriately to each other: there's user/host/AM (three-le= gged), requester/host (two-legged), and requester/AM (another two-legged). = Because of our goals to allow most of these parties to meet fairly dynamica= lly, we are leaning quite heavily on XRD and LRDD for discovery; various si= mplifying assumptions could probably be made to simplify this picture, howe= ver.

(If you find UMA's use cases and design center interesting, you'd b= e very welcome at the table.[4])

Thanks,

=A0 =A0 =A0 =A0Eve
=A0 =A0 =A0 =A0UMA group chair

[1] http://kantarainitiative.org/confluence/display/uma/Home
[2] http://kantarainitiative.org/confluence/di= splay/uma/UMA+1.0+Core+Protocol
[3] http://kantarainitiative.org/confluence/display/um= a/UMA+Explained
[4] http://signup.kantarainitiative.org/?selectedGroup=3D11<= br>

Eve Maler
eve@xmlgrrl.com
http://www.xmlgrr= l.com/blog
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--00504502e165df7be00479150cc6-- From eve@xmlgrrl.com Mon Nov 23 19:52:17 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F019528C1DF for ; Mon, 23 Nov 2009 19:52:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.915 X-Spam-Level: ** X-Spam-Status: No, score=2.915 tagged_above=-999 required=5 tests=[AWL=1.206, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FROM_DOMAIN_NOVOWEL=0.5, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, HOST_MISMATCH_NET=0.311, 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 UiaY0WURJDP7 for ; Mon, 23 Nov 2009 19:52:16 -0800 (PST) Received: from mail.promanage-inc.com (static-98-111-84-13.sttlwa.fios.verizon.net [98.111.84.13]) by core3.amsl.com (Postfix) with ESMTP id 9714D3A67FB for ; Mon, 23 Nov 2009 19:52:16 -0800 (PST) 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 nAO3poK7017249 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 23 Nov 2009 19:52:08 -0800 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/alternative; boundary=Apple-Mail-339--592847235 From: Eve Maler In-Reply-To: Date: Mon, 23 Nov 2009 19:51:50 -0800 Message-Id: <47282989-64BB-4673-B94B-7BBBB6B488E1@xmlgrrl.com> References: To: John Panzer X-Mailer: Apple Mail (2.1077) Cc: oauth@googlegroups.com, oauth@ietf.org Subject: Re: [OAUTH-WG] Seeking feedback on UMA's use of OAuth and discovery mechanisms X-BeenThere: oauth@ietf.org X-Mailman-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, 24 Nov 2009 03:52:18 -0000 --Apple-Mail-339--592847235 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks for taking a look, and I'd say your gloss of it is exactly right. = The idea is that externalizing the authorization function from many = hosts to a clever enough AM service (there are plenty of UX implications = here in addition to protocol stuff) could let you keep better track of = your digital footprint, apply consistent policy across various = categories (per host, per requester, per resource class...), and even = help you extract promises (or payments) from the requester before = granting access. The one sub-relationship among the four parties that is the *least* = dynamic is the user's introduction of the host to the AM. It's the one = prerequisite step before the actual authorization flow. LRDD/XRD comes = into play in that first step too, though, enabling the host to learn how = to begin authenticating to the AM and subsequently how to send = (OAuth-enabled) UMA access requests to it. Swimlane diagrams of the steps are linked off here: > http://kantarainitiative.org/confluence/display/uma/UMA+Explained ...as is a flowchart of the post-step-1 authorization flow. Eve On 23 Nov 2009, at 6:53 PM, John Panzer wrote: > It sounds very interesting. In OAuth terms, I think it adds, to the = basic OAuth 3 legged flow, the ability to delegate the authorization = decisions 'normally' made out of band of the OAuth protocol to a = completely separate service. Aftet 60 seconds looking at it, my first = silly question is how the AM service is determined -- it looks like = everything is based on LRDD starting from the resource being accessed? >=20 > -- > John Panzer / Google > jpanzer@google.com / abstractioneer.org / @jpanzer >=20 >=20 >=20 > On Mon, Nov 23, 2009 at 6:04 PM, Eve Maler wrote: > The User-Managed Access effort[1], previously mentioned on this list = as "ProtectServe", intends to solve user-driven permissioning = (authorization) problems at Internet scale. It is designed to be = modular, and to reuse and profile existing technology as much as = possible. Therefore, we have attempted to "stay out of the business of = authentication", profiling OAuth lightly in order to do so. >=20 > The UMA group would be grateful for your feedback on our intended = usage of OAuth and its emerging discovery methods. Details can be found = in the worked example in our spec[2]; various explanatory materials = about UMA in general are available as well.[3] >=20 > Briefly, the UMA protocol has four distinct parties vs. OAuth's three: = there's an authorizing user, a consumer/client (which we call = a"requester"), an SP/server (which we call a "host"), and an = authorization manager. We compose three instances of OAuth to introduce = all these parties appropriately to each other: there's user/host/AM = (three-legged), requester/host (two-legged), and requester/AM (another = two-legged). Because of our goals to allow most of these parties to meet = fairly dynamically, we are leaning quite heavily on XRD and LRDD for = discovery; various simplifying assumptions could probably be made to = simplify this picture, however. >=20 > (If you find UMA's use cases and design center interesting, you'd be = very welcome at the table.[4]) >=20 > Thanks, >=20 > Eve > UMA group chair >=20 > [1] http://kantarainitiative.org/confluence/display/uma/Home > [2] = http://kantarainitiative.org/confluence/display/uma/UMA+1.0+Core+Protocol > [3] http://kantarainitiative.org/confluence/display/uma/UMA+Explained > [4] http://signup.kantarainitiative.org/?selectedGroup=3D11 >=20 >=20 > Eve Maler > eve@xmlgrrl.com > http://www.xmlgrrl.com/blog > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 Eve Maler eve@xmlgrrl.com http://www.xmlgrrl.com/blog --Apple-Mail-339--592847235 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
...as = is a flowchart of the post-step-1 authorization = flow.

Eve

On 23 Nov = 2009, at 6:53 PM, John Panzer wrote:

It sounds = very interesting. In OAuth terms, I think it adds, to the basic OAuth 3 = legged flow, the ability to delegate the authorization decisions = 'normally' made out of band of the OAuth protocol to a completely = separate service.  Aftet 60 seconds looking at it, my first silly = question is how the AM service is determined -- it looks like everything = is based on LRDD starting from the resource being accessed?

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



On Mon, Nov 23, 2009 at 6:04 PM, Eve = Maler <eve@xmlgrrl.com> = wrote:
The User-Managed Access effort[1], previously mentioned on this list as = "ProtectServe", intends to solve user-driven permissioning = (authorization) problems at Internet scale. It is designed to be = modular, and to reuse and profile existing technology as much as = possible. Therefore, we have attempted to "stay out of the business of = authentication", profiling OAuth lightly in order to do so.

The UMA group would be grateful for your feedback on our intended usage = of OAuth and its emerging discovery methods. Details can be found in the = worked example in our spec[2]; various explanatory materials about UMA = in general are available as well.[3]

Briefly, the UMA protocol has four distinct parties vs. OAuth's three: = there's an authorizing user, a consumer/client (which we call = a"requester"), an SP/server (which we call a "host"), and an = authorization manager. We compose three instances of OAuth to introduce = all these parties appropriately to each other: there's user/host/AM = (three-legged), requester/host (two-legged), and requester/AM (another = two-legged). Because of our goals to allow most of these parties to meet = fairly dynamically, we are leaning quite heavily on XRD and LRDD for = discovery; various simplifying assumptions could probably be made to = simplify this picture, however.

(If you find UMA's use cases and design center interesting, you'd be = very welcome at the table.[4])

Thanks,

       Eve
       UMA group chair

[1] http://kantarainitiative.org/confluence/display/uma/Home=
[2] http://kantarainitiative.org/confluence/display/uma/UMA+= 1.0+Core+Protocol
[3] http://kantarainitiative.org/confluence/display/uma/UMA+= Explained
[4] http://signup.kantarainitiative.org/?selectedGroup=3D11<= /a>


Eve Maler
eve@xmlgrrl.com
http://www.xmlgrrl.com/blog
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



= --Apple-Mail-339--592847235-- From eran@hueniverse.com Mon Nov 23 21:45:42 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2883E3A6B4E for ; Mon, 23 Nov 2009 21:45:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 Rm1ZntoSltk9 for ; Mon, 23 Nov 2009 21:45:41 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 674B23A6B4B for ; Mon, 23 Nov 2009 21:45:40 -0800 (PST) Received: (qmail 1372 invoked from network); 24 Nov 2009 05:45:36 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 24 Nov 2009 05:45:36 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 23 Nov 2009 22:45:36 -0700 From: Eran Hammer-Lahav To: "OAuth WG (oauth@ietf.org)" Date: Mon, 23 Nov 2009 22:45:40 -0700 Thread-Topic: Separate names for authentication and authorization Thread-Index: AcpsyVrEhLl1lT3eSx65Trbzz+rwlw== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343785182F4F@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: AVca AYVT A0rC BArd BQba B0Xz C1+z DKU/ D4A1 EmVT FDs/ Gee4 HF3N II8+ JF23 Jp8r; 1; bwBhAHUAdABoAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {F45B7584-0011-425B-9473-21598023EC01}; ZQByAGEAbgBAAGgAdQBlAG4AaQB2AGUAcgBzAGUALgBjAG8AbQA=; Tue, 24 Nov 2009 05:45:40 GMT; UwBlAHAAYQByAGEAdABlACAAbgBhAG0AZQBzACAAZgBvAHIAIABhAHUAdABoAGUAbgB0AGkAYwBhAHQAaQBvAG4AIABhAG4AZAAgAGEAdQB0AGgAbwByAGkAegBhAHQAaQBvAG4A x-cr-puzzleid: {F45B7584-0011-425B-9473-21598023EC01} acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OAUTH-WG] Separate names for authentication and authorization X-BeenThere: oauth@ietf.org X-Mailman-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, 24 Nov 2009 05:45:42 -0000 How do people feel about using OAuth as the name for the different flows to= obtain a token, including the new flows defined in WRAP, and calling the a= uthentication part simply the Token Authentication scheme, in line with Bas= ic and Digest? I think this would be much more in-line with people's expectations of the O= Auth "brand". EHL From email@pbryan.net Mon Nov 23 21:47:27 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8399B3A67A7 for ; Mon, 23 Nov 2009 21:47:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 40Ad-0oH+qGQ for ; Mon, 23 Nov 2009 21:47:26 -0800 (PST) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by core3.amsl.com (Postfix) with ESMTP id CED513A677E for ; Mon, 23 Nov 2009 21:47:26 -0800 (PST) Received: from [192.168.0.4] (S010600095baae0ff.vf.shawcable.net [174.1.50.199]) by maple.anode.ca (Postfix) with ESMTPSA id 1DA3F614E for ; Tue, 24 Nov 2009 05:47:22 +0000 (UTC) From: "Paul C. Bryan" To: "OAuth WG (oauth@ietf.org)" In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343785182F4F@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343785182F4F@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset="UTF-8" Date: Mon, 23 Nov 2009 21:47:11 -0800 Message-ID: <1259041631.12400.13.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit Subject: Re: [OAUTH-WG] Separate names for authentication and authorization X-BeenThere: oauth@ietf.org X-Mailman-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, 24 Nov 2009 05:47:27 -0000 +1 On Mon, 2009-11-23 at 22:45 -0700, Eran Hammer-Lahav wrote: > How do people feel about using OAuth as the name for the different flows to obtain a token, including the new flows defined in WRAP, and calling the authentication part simply the Token Authentication scheme, in line with Basic and Digest? > > I think this would be much more in-line with people's expectations of the OAuth "brand". > > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From jpanzer@google.com Mon Nov 23 22:42:03 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7BB23A6B36 for ; Mon, 23 Nov 2009 22:42:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.573 X-Spam-Level: X-Spam-Status: No, score=-105.573 tagged_above=-999 required=5 tests=[AWL=0.403, 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 6dXMXVkQLXuw for ; Mon, 23 Nov 2009 22:42:02 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id EE02A3A681A for ; Mon, 23 Nov 2009 22:42:01 -0800 (PST) Received: from zps18.corp.google.com (zps18.corp.google.com [172.25.146.18]) by smtp-out.google.com with ESMTP id nAO6fu63024252 for ; Mon, 23 Nov 2009 22:41:56 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1259044916; bh=Ap9M7TSqG+mIv88VHfhCY3+KTfc=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=JOfnW9TKLHLfx8DNo+3SUVHkueTFlzvqPcbgWUP+OAxzRsC0V9cja8W5fNJuLMU93 7k33i5o52FRaMgmfg2VOw== 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=MkdibpSoPtQEtE7ecL4FbHi9U09fohL0vXao8lIa9zpZGYZVaqvz4w0oFu7dvgWpG i1bUWS1lGSKSp7mEmFv3g== Received: from yxe40 (yxe40.prod.google.com [10.190.2.40]) by zps18.corp.google.com with ESMTP id nAO6frKs029124 for ; Mon, 23 Nov 2009 22:41:54 -0800 Received: by yxe40 with SMTP id 40so5987440yxe.28 for ; Mon, 23 Nov 2009 22:41:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.3.14 with SMTP id 14mr5697471ybc.228.1259044913095; Mon, 23 Nov 2009 22:41:53 -0800 (PST) In-Reply-To: <1259041631.12400.13.camel@localhost> References: <90C41DD21FB7C64BB94121FBBC2E72343785182F4F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1259041631.12400.13.camel@localhost> From: John Panzer Date: Mon, 23 Nov 2009 22:41:33 -0800 Message-ID: To: "Paul C. Bryan" Content-Type: multipart/alternative; boundary=000e0cd6ac44cd25d80479183c75 X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Separate names for authentication and authorization X-BeenThere: oauth@ietf.org X-Mailman-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, 24 Nov 2009 06:42:04 -0000 --000e0cd6ac44cd25d80479183c75 Content-Type: text/plain; charset=ISO-8859-1 Sounds good ("Token Auth")? -- John Panzer / Google jpanzer@google.com / abstractioneer.org / @jpanzer On Mon, Nov 23, 2009 at 9:47 PM, Paul C. Bryan wrote: > +1 > > On Mon, 2009-11-23 at 22:45 -0700, Eran Hammer-Lahav wrote: > > How do people feel about using OAuth as the name for the different flows > to obtain a token, including the new flows defined in WRAP, and calling the > authentication part simply the Token Authentication scheme, in line with > Basic and Digest? > > > > I think this would be much more in-line with people's expectations of the > OAuth "brand". > > > > 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 > --000e0cd6ac44cd25d80479183c75 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sounds good ("Token Auth")?
--
John Panzer / = Google
jpanzer@google.com / abstractioneer.org / @jpanzer


On Mon, Nov 23, 2009 at 9:47 PM, Paul C.= Bryan <email@pbry= an.net> wrote:
+1

On Mon, 2009-11-23 at 22:45 -0700, Eran Hammer-Lahav wrote:
> How do people feel about using OAuth as the name for the different flo= ws to obtain a token, including the new flows defined in WRAP, and calling = the authentication part simply the Token Authentication scheme, in line wit= h Basic and Digest?
>
> I think this would be much more in-line with people's expectations= of the OAuth "brand".
>
> 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

--000e0cd6ac44cd25d80479183c75-- From rbarnes@bbn.com Tue Nov 24 05:55:07 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C92D3A6A3E for ; Tue, 24 Nov 2009 05:55:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 vwDBXY-h8C0o for ; Tue, 24 Nov 2009 05:55:06 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 4BB923A6784 for ; Tue, 24 Nov 2009 05:55:06 -0800 (PST) Received: from [192.1.255.180] (helo=col-dhcp-192-1-255-180.bbn.com) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1NCvrA-0005SV-C3; Tue, 24 Nov 2009 08:55:00 -0500 Message-Id: <8A1C3A73-FE3C-4DFB-9F6B-3D3761B9B824@bbn.com> From: Richard Barnes To: Eran Hammer-Lahav In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343785182F4F@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 24 Nov 2009 08:54:58 -0500 References: <90C41DD21FB7C64BB94121FBBC2E72343785182F4F@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-Mailer: Apple Mail (2.936) Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Separate names for authentication and authorization X-BeenThere: oauth@ietf.org X-Mailman-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, 24 Nov 2009 13:55:07 -0000 The high-level separation makes sense; I'm fine with reserving OAuth for the delegation flow and calling the authentication method something else. (Digression: Could this be helpful in allowing other authentication mechanisms into OAuth?) That said, I'm not sure "Token Auth" is quite accurate (you could just as well pass a token over Basic). The important thing about the authentication scheme that OAuth defines is that it provides some of the benefit of Digest (e.g., it doesn't reveal secrets) but without requiring two RTTs. Maybe something like "Direct Auth" ("One-Shot"? "Simple-Digest"?). On the other hand, it is just a name. That which we call OAuth, by any other name.. --Richard On Nov 24, 2009, at 12:45 AM, Eran Hammer-Lahav wrote: > How do people feel about using OAuth as the name for the different > flows to obtain a token, including the new flows defined in WRAP, > and calling the authentication part simply the Token Authentication > scheme, in line with Basic and Digest? > > I think this would be much more in-line with people's expectations > of the OAuth "brand". > > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From email@pbryan.net Tue Nov 24 06:55:34 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47D6F3A682E for ; Tue, 24 Nov 2009 06:55:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 uAv7Wv2HnFZL for ; Tue, 24 Nov 2009 06:55:33 -0800 (PST) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by core3.amsl.com (Postfix) with ESMTP id 8D2313A67F4 for ; Tue, 24 Nov 2009 06:55:33 -0800 (PST) Received: from [192.168.0.4] (S010600095baae0ff.vf.shawcable.net [174.1.50.199]) by maple.anode.ca (Postfix) with ESMTPSA id DD0E66154; Tue, 24 Nov 2009 14:55:28 +0000 (UTC) From: "Paul C. Bryan" To: Richard Barnes In-Reply-To: <8A1C3A73-FE3C-4DFB-9F6B-3D3761B9B824@bbn.com> References: <90C41DD21FB7C64BB94121FBBC2E72343785182F4F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <8A1C3A73-FE3C-4DFB-9F6B-3D3761B9B824@bbn.com> Content-Type: text/plain; charset="UTF-8" Date: Tue, 24 Nov 2009 06:55:17 -0800 Message-ID: <1259074517.12400.16.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Separate names for authentication and authorization X-BeenThere: oauth@ietf.org X-Mailman-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, 24 Nov 2009 14:55:34 -0000 People generally refer to RFC 2617 as (HTTP) "Basic" and "Digest" authentication methods. Since OAuth is going toward "Token" as the method type in the Authorization header, it seems to be consistent to refer to it in similar fashion. On Tue, 2009-11-24 at 08:54 -0500, Richard Barnes wrote: > The high-level separation makes sense; I'm fine with reserving OAuth > for the delegation flow and calling the authentication method > something else. (Digression: Could this be helpful in allowing other > authentication mechanisms into OAuth?) > > That said, I'm not sure "Token Auth" is quite accurate (you could just > as well pass a token over Basic). The important thing about the > authentication scheme that OAuth defines is that it provides some of > the benefit of Digest (e.g., it doesn't reveal secrets) but without > requiring two RTTs. Maybe something like "Direct Auth" ("One-Shot"? > "Simple-Digest"?). > > On the other hand, it is just a name. That which we call OAuth, by > any other name.. > > --Richard > > > > On Nov 24, 2009, at 12:45 AM, Eran Hammer-Lahav wrote: > > > How do people feel about using OAuth as the name for the different > > flows to obtain a token, including the new flows defined in WRAP, > > and calling the authentication part simply the Token Authentication > > scheme, in line with Basic and Digest? > > > > I think this would be much more in-line with people's expectations > > of the OAuth "brand". > > > > 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 stpeter@stpeter.im Tue Nov 24 07:56:14 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B067128C117 for ; Tue, 24 Nov 2009 07:56:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 bW6-Uzr4ZJXK for ; Tue, 24 Nov 2009 07:56:14 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id D8FAB28C106 for ; Tue, 24 Nov 2009 07:56:13 -0800 (PST) Received: from dhcp-64-101-72-196.cisco.com (dhcp-64-101-72-196.cisco.com [64.101.72.196]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A2CB440472; Tue, 24 Nov 2009 08:56:08 -0700 (MST) Message-ID: <4B0C0218.704@stpeter.im> Date: Tue, 24 Nov 2009 08:56:08 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Eran Hammer-Lahav References: <90C41DD21FB7C64BB94121FBBC2E72343785182F4F@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343785182F4F@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020100090400000302060605" Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Separate names for authentication and authorization X-BeenThere: oauth@ietf.org X-Mailman-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, 24 Nov 2009 15:56:14 -0000 This is a cryptographically signed message in MIME format. --------------ms020100090400000302060605 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 11/23/09 10:45 PM, Eran Hammer-Lahav wrote: > How do people feel about using OAuth as the name for the different > flows to obtain a token, including the new flows defined in WRAP, and > calling the authentication part simply the Token Authentication > scheme, in line with Basic and Digest? +1 > I think this would be much more in-line with people's expectations of > the OAuth "brand". Agreed. /psa --------------ms020100090400000302060605 Content-Type: application/x-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 hvcNAQkFMQ8XDTA5MTEyNDE1NTYwOFowIwYJKoZIhvcNAQkEMRYEFIqxux2TFCmm+pTS/BtY eMzuywEXMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAjmNwdAhlfy3yjMHnunxxLWTQ8qrBX4EpbJukSMsP 0ukBl1udgb5yVVdUTee/qlGZ7cUHzSbXs7Da1IAkcvsv/ZQxKNFCWd+Jr9b0MyNxVwdbw4ID l69NQCTZKrUM10tSbDHwr7t5epLhFFRlrO31i3Plx5uYqln7qbt+tzT0ql3zSXLOSbVKaZJ2 kIClyC7TGJ+4993cWb06DTEUGE1KT2hejz8CQ4jlG/9XE7fvN9bRuWC/8ottGaItflQncqwT UwdmsNPvDTDwXDotmUXS3ipdRKAaivO+nzvPukmQgNEPU0YGKGto4Gfa8Ck6S+kqL+OH4nk2 EIb5SEsSJExNsgAAAAAAAA== --------------ms020100090400000302060605-- From rbarnes@bbn.com Tue Nov 24 07:58:53 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AC103A68D0 for ; Tue, 24 Nov 2009 07:58:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 8fmT+M2jZy6y for ; Tue, 24 Nov 2009 07:58:52 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 459653A6893 for ; Tue, 24 Nov 2009 07:58:52 -0800 (PST) Received: from [192.1.255.180] (helo=col-dhcp-192-1-255-180.bbn.com) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1NCxmw-0000Ct-C7; Tue, 24 Nov 2009 10:58:46 -0500 Message-Id: <7B353C7D-BED1-4AC9-BE86-BCD636142F39@bbn.com> From: Richard Barnes To: "Paul C. Bryan" In-Reply-To: <1259074517.12400.16.camel@localhost> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 24 Nov 2009 10:58:46 -0500 References: <90C41DD21FB7C64BB94121FBBC2E72343785182F4F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <8A1C3A73-FE3C-4DFB-9F6B-3D3761B9B824@bbn.com> <1259074517.12400.16.camel@localhost> X-Mailer: Apple Mail (2.936) Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Separate names for authentication and authorization X-BeenThere: oauth@ietf.org X-Mailman-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, 24 Nov 2009 15:58:53 -0000 Actually, the token that draft-hammer-oauth-07 has for the WWW- Authenticate and Authorization headers is "OAuth". (Were you thinking of something else?) I certainly agree that whatever the token is should match our name for the technique, but it's not called "Token" right now. --Richard On Nov 24, 2009, at 9:55 AM, Paul C. Bryan wrote: > People generally refer to RFC 2617 as (HTTP) "Basic" and "Digest" > authentication methods. Since OAuth is going toward "Token" as the > method type in the Authorization header, it seems to be consistent to > refer to it in similar fashion. > > On Tue, 2009-11-24 at 08:54 -0500, Richard Barnes wrote: >> The high-level separation makes sense; I'm fine with reserving OAuth >> for the delegation flow and calling the authentication method >> something else. (Digression: Could this be helpful in allowing other >> authentication mechanisms into OAuth?) >> >> That said, I'm not sure "Token Auth" is quite accurate (you could >> just >> as well pass a token over Basic). The important thing about the >> authentication scheme that OAuth defines is that it provides some of >> the benefit of Digest (e.g., it doesn't reveal secrets) but without >> requiring two RTTs. Maybe something like "Direct Auth" ("One-Shot"? >> "Simple-Digest"?). >> >> On the other hand, it is just a name. That which we call OAuth, by >> any other name.. >> >> --Richard >> >> >> >> On Nov 24, 2009, at 12:45 AM, Eran Hammer-Lahav wrote: >> >>> How do people feel about using OAuth as the name for the different >>> flows to obtain a token, including the new flows defined in WRAP, >>> and calling the authentication part simply the Token Authentication >>> scheme, in line with Basic and Digest? >>> >>> I think this would be much more in-line with people's expectations >>> of the OAuth "brand". >>> >>> 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 Nov 24 08:53:45 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB5BB3A6AB6 for ; Tue, 24 Nov 2009 08:53:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.209 X-Spam-Level: X-Spam-Status: No, score=-2.209 tagged_above=-999 required=5 tests=[AWL=0.390, 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 S-qiVtDkaGOV for ; Tue, 24 Nov 2009 08:53:45 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 0B20B3A6843 for ; Tue, 24 Nov 2009 08:53:45 -0800 (PST) Received: (qmail 14585 invoked from network); 24 Nov 2009 16:53:40 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 24 Nov 2009 16:53:39 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 24 Nov 2009 09:53:39 -0700 From: Eran Hammer-Lahav To: Richard Barnes , "Paul C. Bryan" Date: Tue, 24 Nov 2009 09:53:45 -0700 Thread-Topic: [OAUTH-WG] Separate names for authentication and authorization Thread-Index: AcptHwNoRsmJsQqBScmZvFx/RNKn8wAByLUQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343785183006@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343785182F4F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <8A1C3A73-FE3C-4DFB-9F6B-3D3761B9B824@bbn.com> <1259074517.12400.16.camel@localhost> <7B353C7D-BED1-4AC9-BE86-BCD636142F39@bbn.com> In-Reply-To: <7B353C7D-BED1-4AC9-BE86-BCD636142F39@bbn.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] Separate names for authentication and authorization X-BeenThere: oauth@ietf.org X-Mailman-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, 24 Nov 2009 16:53:46 -0000 The proposal (from a couple months back) was to pick a new scheme name. I h= ave to go back to my notes to see if we reached consensus, but I like Token= . It is short, simple, and reflect the idea that you are using a token with= specific scope and lifetime instead of regular credentials. How you get th= at token is left for the other spec (or extensions). And yes, by having OAuth scoped to the authorization part, it will be easie= r to bind it with other token transport methods than the HTTP/header. EHL > -----Original Message----- > From: Richard Barnes [mailto:rbarnes@bbn.com] > Sent: Tuesday, November 24, 2009 7:59 AM > To: Paul C. Bryan > Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Separate names for authentication and > authorization >=20 > Actually, the token that draft-hammer-oauth-07 has for the WWW- > Authenticate and Authorization headers is "OAuth". (Were you thinking of > something else?) I certainly agree that whatever the token is should mat= ch > our name for the technique, but it's not called "Token" > right now. >=20 > --Richard >=20 >=20 >=20 >=20 > On Nov 24, 2009, at 9:55 AM, Paul C. Bryan wrote: >=20 > > People generally refer to RFC 2617 as (HTTP) "Basic" and "Digest" > > authentication methods. Since OAuth is going toward "Token" as the > > method type in the Authorization header, it seems to be consistent to > > refer to it in similar fashion. > > > > On Tue, 2009-11-24 at 08:54 -0500, Richard Barnes wrote: > >> The high-level separation makes sense; I'm fine with reserving OAuth > >> for the delegation flow and calling the authentication method > >> something else. (Digression: Could this be helpful in allowing other > >> authentication mechanisms into OAuth?) > >> > >> That said, I'm not sure "Token Auth" is quite accurate (you could > >> just as well pass a token over Basic). The important thing about the > >> authentication scheme that OAuth defines is that it provides some of > >> the benefit of Digest (e.g., it doesn't reveal secrets) but without > >> requiring two RTTs. Maybe something like "Direct Auth" ("One-Shot"? > >> "Simple-Digest"?). > >> > >> On the other hand, it is just a name. That which we call OAuth, by > >> any other name.. > >> > >> --Richard > >> > >> > >> > >> On Nov 24, 2009, at 12:45 AM, Eran Hammer-Lahav wrote: > >> > >>> How do people feel about using OAuth as the name for the different > >>> flows to obtain a token, including the new flows defined in WRAP, > >>> and calling the authentication part simply the Token Authentication > >>> scheme, in line with Basic and Digest? > >>> > >>> I think this would be much more in-line with people's expectations > >>> of the OAuth "brand". > >>> > >>> 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 Nov 24 08:56:41 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 493C93A6B4B for ; Tue, 24 Nov 2009 08:56:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.244 X-Spam-Level: X-Spam-Status: No, score=-2.244 tagged_above=-999 required=5 tests=[AWL=0.355, 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 dkWMe9eoE0Cz for ; Tue, 24 Nov 2009 08:56:40 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id C213A3A67E9 for ; Tue, 24 Nov 2009 08:56:38 -0800 (PST) Received: (qmail 22349 invoked from network); 24 Nov 2009 16:56:33 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 24 Nov 2009 16:56:33 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 24 Nov 2009 09:56:33 -0700 From: Eran Hammer-Lahav To: "OAuth WG (oauth@ietf.org)" Date: Tue, 24 Nov 2009 09:56:38 -0700 Thread-Topic: Signature crypto Thread-Index: AcptJxbCg4OTTyo5R7W/lAVRgCT0Xg== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343785183009@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: ZV0= BJ52 Baw1 CwAj FdXJ Ftmn GDan Gbqq Gf7U HwLB K7ud K9NT MNS+ MXTh MaN6 Msyy; 1; bwBhAHUAdABoAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {B6454E9A-3B13-4A7A-9B01-D38A46B7E15D}; ZQByAGEAbgBAAGgAdQBlAG4AaQB2AGUAcgBzAGUALgBjAG8AbQA=; Tue, 24 Nov 2009 16:56:38 GMT;UwBpAGcAbgBhAHQAdQByAGUAIABjAHIAeQBwAHQAbwA= x-cr-puzzleid: {B6454E9A-3B13-4A7A-9B01-D38A46B7E15D} acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OAUTH-WG] Signature crypto X-BeenThere: oauth@ietf.org X-Mailman-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, 24 Nov 2009 16:56:41 -0000 I think we have consensus that the spec should not mandate a particular has= h algorithm. This still leave the issue of assigning algorithms short names= for the purpose of negotiation and declaration. Is there a registry availa= ble for such algorithms we can use or do we need to create a new one? EHL From davidrecordon@facebook.com Tue Nov 24 10:57:43 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF5903A6816 for ; Tue, 24 Nov 2009 10:57:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.965 X-Spam-Level: X-Spam-Status: No, score=-5.965 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4, 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 jBM5yrdVgmXz for ; Tue, 24 Nov 2009 10:57:43 -0800 (PST) Received: from mailout-sf2p.facebook.com (mailout-snc1.facebook.com [69.63.179.25]) by core3.amsl.com (Postfix) with ESMTP id 03C713A688E for ; Tue, 24 Nov 2009 10:57:42 -0800 (PST) Received: from mail.thefacebook.com (intlb01.snat.snc1.facebook.com [10.128.203.15] (may be forged)) by pp02.snc1.tfbnw.net (8.14.1/8.14.1) with ESMTP id nAOIvHOH020307 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 24 Nov 2009 10:57:17 -0800 Received: from SC-MBXC1.TheFacebook.com ([192.168.18.102]) by sc-hub02.TheFacebook.com ([192.168.18.105]) with mapi; Tue, 24 Nov 2009 10:57:36 -0800 From: David Recordon To: "oauth@ietf.org" Date: Tue, 24 Nov 2009 10:57:33 -0800 Thread-Topic: Facebook, OAuth, and WRAP Thread-Index: AcptN/sGLUJPJF8VTBWs8YsEibJh6w== Message-ID: <148C596691F29F4EA6968577BE2CDFAE06A1B9FE@SC-MBXC1.TheFacebook.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=2009-11-24_09:2009-11-16, 2009-11-24, 2009-11-24 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-0911240180 Cc: Naitik Shah , Brent Goldman , Luke Shepard Subject: [OAUTH-WG] Facebook, OAuth, and WRAP X-BeenThere: oauth@ietf.org X-Mailman-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, 24 Nov 2009 18:58:17 -0000 Hey all, This was originally a comment on Eran's post about WRAP (http://hueniverse.= com/2009/11/wrap-and-the-demise-of-the-oauth-community/). Beyond Luke and = I talking at the Internet Identity Workshop a few weeks ago, I don't think = we've actually articulated where Facebook is thinking in regards to OAuth. = In order to help get OAuth 2.0 done, I wanted to make sure we've shared wh= ere we see OAuth 1.0 falling short, why we're interested in WRAP, and the f= our main use cases our current proprietary authentication mechanism solves.= We've also signed Open Web Foundation agreements for OAuth Core 1.0a and = the WRAP specs (http://developers.facebook.com/news.php?blog=3D1&story=3D33= 5). The largest issue in Facebook moving to OAuth 1.0 (and yes, Eran's new RFC = is awesome) is the increase in the number of HTTP requests that developers = will need to make in comparison to our current authentication mechanism. W= e want to move to using OAuth, but for this reason and hearing strongly fro= m other major implementors that OAuth has not been widely adopted by their = developer communities because it is too difficult to correctly implement ha= s us concerned. The most interesting part of WRAP are the various profiles. They currently= map well to our existing authentication mechanisms and the username/passwo= rd profile is an API we offer to whitelisted partners such as the XBox and = Playstation 3. It would be great if OAuth 2.0 had a similar profile mechan= ism where each profile is optimized in terms of the number of steps (HTTP r= equests) required versus being combined together like OAuth 1.0. I'm not convinced that signatures are "too hard" for developers especially = when libraries hide them away. That said, OAuth 1.0 implementations still = requires that developers understand the different types of tokens in additi= on to when and how they're generated. WRAP is intriguing in terms of really simplifying what developers need to u= nderstand. The first step being trading some set of credentials or asking = the user to go somewhere results in an access token. The second step then = being including that access token via HTTP headers, a GET arg, or a POST ar= g over SSL without needing to calculate any sort of signatures. The downsi= de is that now all APIs need to be served over SSL, but that seems doable. These are the four main use cases which were focused on. While there is qu= ite a bit of overlap between them, we think that it is important to have sp= ecifically optimized flows for each so that individually they are as simple= as possible to implement. 1) "OAuth" web flow of redirecting a user to Facebook, them authorizing pre= -registered application, and then being redirected back to the web app with= in their browser. 2) A mobile/desktop flow where the user is redirected back to Facebook, aut= horizes the app, and then is sent back to the application. We both have a = version of this use case where the application separately opens a browser a= nd one where the application is able to embed a browser directly. 3) A mobile/desktop/device flow where the user enters their Facebook userna= me/password which the application then trades for a token. This is for whi= telisted partners. 4) A fully JavaScript environment where the JavaScript sets a cookie contai= ning the credentials needed for the web application to get API access while= the user has an active session. We think that WRAP currently solves #3, probably solves #2, and mostly solv= es #1. #4 hasn't been tackled within WRAP yet, but we hope to develop a pr= ofile for it as well. I'm happy to participate in the IETF to help develop OAuth 2.0 and to encou= rage others from Facebook to do the same, but also want to be really pragma= tic around having something we can ship (either WRAP or 2.0) sooner rather = than later. Cheers, --David From stpeter@stpeter.im Tue Nov 24 15:10:40 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D12103A6876 for ; Tue, 24 Nov 2009 15:10:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 U9YgY6ssw0l5 for ; Tue, 24 Nov 2009 15:10:39 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 043763A67E3 for ; Tue, 24 Nov 2009 15:10:39 -0800 (PST) Received: from dhcp-64-101-72-196.cisco.com (dhcp-64-101-72-196.cisco.com [64.101.72.196]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0612740D12; Tue, 24 Nov 2009 16:10:33 -0700 (MST) Message-ID: <4B0C67E8.3070709@stpeter.im> Date: Tue, 24 Nov 2009 16:10:32 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Eran Hammer-Lahav References: <90C41DD21FB7C64BB94121FBBC2E72343785183009@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343785183009@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080607070800090507080203" Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Signature crypto X-BeenThere: oauth@ietf.org X-Mailman-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, 24 Nov 2009 23:10:41 -0000 This is a cryptographically signed message in MIME format. --------------ms080607070800090507080203 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 11/24/09 9:56 AM, Eran Hammer-Lahav wrote: > I think we have consensus that the spec should not mandate a > particular hash algorithm. This still leave the issue of assigning > algorithms short names for the purpose of negotiation and > declaration. Is there a registry available for such algorithms we can > use or do we need to create a new one? The IANA maintains a registry here: http://www.iana.org/assignments/hash-function-text-names Peter -- Peter Saint-Andre https://stpeter.im/ --------------ms080607070800090507080203 Content-Type: application/x-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 hvcNAQkFMQ8XDTA5MTEyNDIzMTAzMlowIwYJKoZIhvcNAQkEMRYEFIMiU/wcfSpC6QJmyE0a mU2Hil0fMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAFoT+3JtZah+gbSCUURc/Op8yWRqkv0OgJUKhqV+h kDOk0kcWAzpupFIfE/dJRhmx/lSHBJjB+bX2whzjoMB6B3paxi0x4KBbhdHIIjkrgyq2dqV7 FSManrnfA57qx2RqwrWOeyD/s1mjLbPRMlFrtr78P0i6b8ObWoziflXefVXU/6EdcfVdFJ8s hgVhgJy04cNqFHLmt1XabCphMK7UKjypA3PE+WOv8imFPVCZRACRT23ZQXjW7SsfviQArldy a19ZLBLPz/kSRs0ehejYfz8fq8JgBLHeiX7CPNRoUAAJYpO2nl2ZFGts+2uaHAqfCSf7i2jy 4W7aTmY+RAhsbgAAAAAAAA== --------------ms080607070800090507080203-- From mjmalone@gmail.com Tue Nov 24 16:36:11 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CF963A6857 for ; Tue, 24 Nov 2009 16:36:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 8uAHHZ-NdVzr for ; Tue, 24 Nov 2009 16:36:10 -0800 (PST) Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by core3.amsl.com (Postfix) with ESMTP id 9EFFA3A67BD for ; Tue, 24 Nov 2009 16:36:10 -0800 (PST) Received: by pzk6 with SMTP id 6so4943138pzk.29 for ; Tue, 24 Nov 2009 16:36:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=3ytydq3v1xOH42oypR0jZsDgFlwlKpMbUfZ4V4hpiL0=; b=qtSualVQ5rPxnZ1QqIk8R+l+kPc6M70pXnXeGauCAgny+sShqZFDhQ8AbJZnQWaVJs ugwSOpmv9IMCL1U6MlJq5pxj1Yd16HSf13oEzfnGvSXPSZTaLz7fY5lzuHX57csVJELn dSsTdPMucTZEjX3xPbwcWpFHpWbkSafvR5BVU= 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=JJH6cvNgbGYIK5T4pNRmlp+/KU8LgJ5CyuUl9fugBzon/TZwu03nht6TX++0AF2BWn y+p0iYngsFYZdIg6fRADMU+ZJ+S4WILCN3BIASnDAeND+py3hJ6WFvk6vndOjMFCJchB XnNCkDAmlcxo6gx9LcFOlMyDM2Edyp660Y4j0= MIME-Version: 1.0 Received: by 10.142.118.27 with SMTP id q27mr746964wfc.313.1259109354727; Tue, 24 Nov 2009 16:35:54 -0800 (PST) In-Reply-To: <148C596691F29F4EA6968577BE2CDFAE06A1B9FE@SC-MBXC1.TheFacebook.com> References: <148C596691F29F4EA6968577BE2CDFAE06A1B9FE@SC-MBXC1.TheFacebook.com> Date: Tue, 24 Nov 2009 16:35:54 -0800 Message-ID: From: Mike Malone To: David Recordon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Naitik Shah , "oauth@ietf.org" , Brent Goldman , Luke Shepard Subject: Re: [OAUTH-WG] Facebook, OAuth, and WRAP X-BeenThere: oauth@ietf.org X-Mailman-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, 25 Nov 2009 00:36:11 -0000 On Tue, Nov 24, 2009 at 10:57 AM, David Recordon wrote: > > The largest issue in Facebook moving to OAuth 1.0 (and yes, Eran's new RF= C is awesome) is the increase in the number of HTTP requests that developer= s will need to make in comparison to our current authentication mechanism. The OAuth _flow_ (in a browser) requires a couple additional requests compared to Facebook Connect (in a browser). But Facebook Connect is really a different beast since it relies on the Browser and Javascript to magically set cookies cross domain and whatnot. I agree that it's non-trivial to extend OAuth to cover this use case (we've sort of done it at Six Apart and the flow is clunky and complicated). And even if you figure out how to make the flow work you can't really make requests purely on the client side without compromising your consumer secret. That said, as far as I can tell, using OAuth for delegated communication via an intermediary (a web app or iPhone app, for example) should be doable for Facebook. The only real differences I see between OAuth and WRAP for this use case are: * WRAP requires SSL instead of signing URLs * WRAP renamed request token to refresh token and lets you use them to exchange for temporary access tokens multiple times * WRAP has a defined flow for accepting username/password & exchanging for an access token I'm guessing that the big win you see is the third point, but the auth flow is really a small part of OAuth. If the flow defined in OAuth 1.0 doesn't work for you why not create a new flow and keep the rest of the spec? > The most interesting part of WRAP are the various profiles. =A0They curre= ntly map well to our existing authentication mechanisms and the username/pa= ssword profile is an API we offer to whitelisted partners such as the XBox = and Playstation 3. =A0It would be great if OAuth 2.0 had a similar profile = mechanism where each profile is optimized in terms of the number of steps (= HTTP requests) required versus being combined together like OAuth 1.0. Again, the flow is really just half of OAuth. Maybe it'd make sense to split the OAuth flow and OAuth request signing into separate specs? > I'm not convinced that signatures are "too hard" for developers especiall= y when libraries hide them away. =A0That said, OAuth 1.0 implementations st= ill requires that developers understand the different types of tokens in ad= dition to when and how they're generated. WRAP seems to have a bunch of different tokens too, they just don't call them all tokens (there's the refresh token, the client id & secret, the access token, the verification code... everything seems to be there). Re: signatures, I think the SSL requirement would be a much larger burden on developers. It's hard enough to debug OAuth problems when you can sniff the flow using ngrep. Although I guess removing signing would help here a bit. > WRAP is intriguing in terms of really simplifying what developers need to= understand. =A0The first step being trading some set of credentials or ask= ing the user to go somewhere results in an access token. =A0The second step= then being including that access token via HTTP headers, a GET arg, or a P= OST arg over SSL without needing to calculate any sort of signatures. =A0Th= e downside is that now all APIs need to be served over SSL, but that seems = doable. I don't think you'd be able to use GET params with WRAP since stuff isn't signed. Other than that, I guess the terminology is simpler..? I'm used to the OAuth terminology by now so it's hard for me to say. The flow doesn't seem all that different to me. Maybe it's a communication problem? > These are the four main use cases which were focused on. =A0While there i= s quite a bit of overlap between them, we think that it is important to hav= e specifically optimized flows for each so that individually they are as si= mple as possible to implement. > > 1) "OAuth" web flow of redirecting a user to Facebook, them authorizing p= re-registered application, and then being redirected back to the web app wi= thin their browser. > 2) A mobile/desktop flow where the user is redirected back to Facebook, a= uthorizes the app, and then is sent back to the application. =A0We both hav= e a version of this use case where the application separately opens a brows= er and one where the application is able to embed a browser directly. > 3) A mobile/desktop/device flow where the user enters their Facebook user= name/password which the application then trades for a token. =A0This is for= whitelisted partners. > 4) A fully JavaScript environment where the JavaScript sets a cookie cont= aining the credentials needed for the web application to get API access whi= le the user has an active session. > > We think that WRAP currently solves #3, probably solves #2, and mostly so= lves #1. =A0#4 hasn't been tackled within WRAP yet, but we hope to develop = a profile for it as well. Again, I think the only use case that would be truly difficult to solve with OAuth is #4. I think #4 is an interesting problem though, and I'd be happy to see OAuth support for a pure Javascript environment. One final note - unless I'm missing something WRAP is vulnerable to the same session fixation attack that OAuth 1.0 had... unless it's requiring callback registration, which is a really lame solution to that problem. Mike From beaton@google.com Tue Nov 24 17:28:52 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C088B3A6828 for ; Tue, 24 Nov 2009 17:28:52 -0800 (PST) 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 YIJWzO7HI2h6 for ; Tue, 24 Nov 2009 17:28:52 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id E819F3A63D3 for ; Tue, 24 Nov 2009 17:28:51 -0800 (PST) Received: from wpaz33.hot.corp.google.com (wpaz33.hot.corp.google.com [172.24.198.97]) by smtp-out.google.com with ESMTP id nAP1SkoU029534 for ; Tue, 24 Nov 2009 17:28:47 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1259112527; bh=xTJ1cgZHqCmQ6jxekMXmoNAA6TE=; h=MIME-Version:Date:Message-ID:Subject:From:To:Cc:Content-Type; b=jKR+xKCpekxMQhdL8x88vlcyEpLgqZ8rFuyxRBlOxNiBxedMVF/HSedNKy36iBpk2 9tf8gAcSXHlrOp4k3ryrA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:date:message-id:subject:from:to:cc: content-type:x-system-of-record; b=ER4AVHyEC4lzVXlDaaBwmhZ+uTSKO8ImzSzee8bi1GQn8Lbt15vT0ow40r1J5LDlE VD4Zx1/Gabgu2/4kwiaQA== Received: from pxi8 (pxi8.prod.google.com [10.243.27.8]) by wpaz33.hot.corp.google.com with ESMTP id nAP1SfLi006278 for ; Tue, 24 Nov 2009 17:28:41 -0800 Received: by pxi8 with SMTP id 8so5597712pxi.27 for ; Tue, 24 Nov 2009 17:28:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.199.16 with SMTP id w16mr449400rvf.252.1259112521365; Tue, 24 Nov 2009 17:28:41 -0800 (PST) Date: Tue, 24 Nov 2009 17:28:41 -0800 Message-ID: From: Brian Eaton To: Mike Malone Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: Naitik Shah , Luke Shepard , Brent Goldman , "oauth@ietf.org" Subject: [OAUTH-WG] WRAP session fixation? X-BeenThere: oauth@ietf.org X-Mailman-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, 25 Nov 2009 01:28:52 -0000 On Tue, Nov 24, 2009 at 4:35 PM, Mike Malone wrote: > One final note - unless I'm missing something WRAP is vulnerable to > the same session fixation attack that OAuth 1.0 had... unless it's > requiring callback registration, which is a really lame solution to > that problem. Callback registration is not required to prevent session fixation. Check out the requirements in section 5.4.6 "Successful Access Token Response From Authorization Server." They are (supposed to) be sufficient to prevent the attack. Cheers, Brian From mjmalone@gmail.com Tue Nov 24 17:45:28 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A578A28C159 for ; Tue, 24 Nov 2009 17:45:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 kRBBtdKdrh4X for ; Tue, 24 Nov 2009 17:45:27 -0800 (PST) Received: from mail-pz0-f174.google.com (mail-pz0-f174.google.com [209.85.222.174]) by core3.amsl.com (Postfix) with ESMTP id DD73128C158 for ; Tue, 24 Nov 2009 17:45:27 -0800 (PST) Received: by pzk4 with SMTP id 4so4872807pzk.32 for ; Tue, 24 Nov 2009 17:45:17 -0800 (PST) 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=NHMaCTy+/AxEqMWLX2ylGLFYlMIsEwI+OrJ8M6XcKxM=; b=ZpOm4PNhc8s09JE2NZEGEyIh0d11HcawfN/BQDGYKYV5JSX7KTnIlG7nCJc65KZEa9 1E8zJcT5VibY0L/nCXDStTYTI9ZK2QLI/epQ2Wtf5fSnJcs9Q6706dYUotQT1C2khler ylsSmBJ/YTWHTlYwZyUI5iXQTtMdoGg19/J9Y= 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=BQMJD7o519ZAR//ItRKNXPaDn+a99y0LH49KM5yStoAQQkJa2U5nnjCUlYUmX8sWc5 jmtpAcM9wWxr3/ImoTT6Ons3/b8bb1V1JXsT4SaO6tLhXNSMkZc7IFY/FtPyHcW4bHU+ 5zwfU4Yfd4x4w2iscALw62NsuyXDHaoOb+zEw= Received: by 10.115.135.6 with SMTP id m6mr14102393wan.22.1259113517633; Tue, 24 Nov 2009 17:45:17 -0800 (PST) Received: from ?10.97.158.79? ([166.205.136.41]) by mx.google.com with ESMTPS id 23sm1547412pzk.8.2009.11.24.17.45.13 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 24 Nov 2009 17:45:16 -0800 (PST) References: Message-Id: <059DCB41-BC68-43B9-8E50-B774AD71FB24@gmail.com> From: Michael Malone 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 (7C144) Mime-Version: 1.0 (iPhone Mail 7C144) Date: Tue, 24 Nov 2009 17:45:01 -0800 Cc: Naitik Shah , Luke Shepard , Brent Goldman , "oauth@ietf.org" Subject: Re: [OAUTH-WG] WRAP session fixation? X-BeenThere: oauth@ietf.org X-Mailman-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, 25 Nov 2009 01:45:28 -0000 On Nov 24, 2009, at 5:28 PM, Brian Eaton wrote: > On Tue, Nov 24, 2009 at 4:35 PM, Mike Malone > wrote: >> One final note - unless I'm missing something WRAP is vulnerable to >> the same session fixation attack that OAuth 1.0 had... unless it's >> requiring callback registration, which is a really lame solution to >> that problem. > > Callback registration is not required to prevent session fixation. > Check out the requirements in section 5.4.6 "Successful Access Token > Response From Authorization Server." They are (supposed to) be > sufficient to prevent the attack. Ah interesting, so you pass the callback URL to the authorization server again to get an access token? How does that work if you _do_ have a registered callback URL? I'll have to take another look at the spec. Thanks, Mike From beaton@google.com Tue Nov 24 17:58:52 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F28383A6952 for ; Tue, 24 Nov 2009 17:58:51 -0800 (PST) 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 7TUyESRMtWsD for ; Tue, 24 Nov 2009 17:58:51 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id ED86F3A693A for ; Tue, 24 Nov 2009 17:58:50 -0800 (PST) Received: from spaceape14.eur.corp.google.com (spaceape14.eur.corp.google.com [172.28.16.148]) by smtp-out.google.com with ESMTP id nAP1wirj007655 for ; Wed, 25 Nov 2009 01:58:44 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1259114324; bh=LN5w8W9S3Y+p9xSW8WMV4F3zdYc=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=KQnZ7Qt7MqV/r2YrlDFhXlksudRlQEbdVxlHpD9AGAok6EAJTckHBJwtLGl/ydtoV OVwmb7A6nBKKzVasTC/+A== 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=BCUwI84EuxTr3Sg2zZhE6imga+OAPj3DCjTmUEtn3nZDcaJ+yrW2mpXihbMtWPeBt VSuLXLV7NvLWr1gsjO6rw== Received: from pxi34 (pxi34.prod.google.com [10.243.27.34]) by spaceape14.eur.corp.google.com with ESMTP id nAP1wZZP016686 for ; Tue, 24 Nov 2009 17:58:39 -0800 Received: by pxi34 with SMTP id 34so5325135pxi.8 for ; Tue, 24 Nov 2009 17:58:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.133.4 with SMTP id g4mr463922rvd.145.1259114315371; Tue, 24 Nov 2009 17:58:35 -0800 (PST) In-Reply-To: <059DCB41-BC68-43B9-8E50-B774AD71FB24@gmail.com> References: <059DCB41-BC68-43B9-8E50-B774AD71FB24@gmail.com> Date: Tue, 24 Nov 2009 17:58:35 -0800 Message-ID: From: Brian Eaton To: Michael Malone Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: Naitik Shah , Luke Shepard , Brent Goldman , "oauth@ietf.org" Subject: Re: [OAUTH-WG] WRAP session fixation? X-BeenThere: oauth@ietf.org X-Mailman-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, 25 Nov 2009 01:58:52 -0000 On Tue, Nov 24, 2009 at 5:45 PM, Michael Malone wrote: > Ah interesting, so you pass the callback URL to the authorization server > again to get an access token? How does that work if you _do_ have a > registered callback URL? It depends on the authorization server, but my guess is that if the authorization server required callback URL registration in the first place they will be checking callback URLs when users hit the approval page. If an unknown callback URL hits the approval page, the authorization server will probably refuse to return the user to the callback. Cheers, Brian From beaton@google.com Tue Nov 24 18:18:07 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E799928C173 for ; Tue, 24 Nov 2009 18:18:06 -0800 (PST) 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 RUMaJrY2nlYT for ; Tue, 24 Nov 2009 18:18:06 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id EFF4A28C172 for ; Tue, 24 Nov 2009 18:18:05 -0800 (PST) Received: from spaceape10.eur.corp.google.com (spaceape10.eur.corp.google.com [172.28.16.144]) by smtp-out.google.com with ESMTP id nAP2Hx3T026793 for ; Tue, 24 Nov 2009 18:18:00 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1259115480; bh=7NZM8QZ4S8K/73X5/EyrJYDC3/M=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=ppvxwuTnzV7wv0TKwe6ouTht4yb5H4FYN7Pdat7uR4to9iiM94RMB0X3sIjTU6Scu axOu5YW9p5QHhgUjpwbIg== 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=IFs+DrJRY3lc5tSB73IL9HQLA71I9Yga45fZpC/iRca8Z7rtxbaa0w/qvdW3UXhe4 o9pmQOFx/odcaqe9ESxaw== Received: from pxi38 (pxi38.prod.google.com [10.243.27.38]) by spaceape10.eur.corp.google.com with ESMTP id nAP2HtoA028446 for ; Tue, 24 Nov 2009 18:17:56 -0800 Received: by pxi38 with SMTP id 38so5122014pxi.10 for ; Tue, 24 Nov 2009 18:17:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.128.9 with SMTP id a9mr438010rvd.146.1259115475188; Tue, 24 Nov 2009 18:17:55 -0800 (PST) In-Reply-To: References: Date: Tue, 24 Nov 2009 18:17:54 -0800 Message-ID: From: Brian Eaton To: Luke Shepard Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: Brent Goldman , Naitik Shah , "oauth@ietf.org" Subject: Re: [OAUTH-WG] WRAP session fixation? X-BeenThere: oauth@ietf.org X-Mailman-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, 25 Nov 2009 02:18:07 -0000 On Tue, Nov 24, 2009 at 6:14 PM, Luke Shepard wrote= : > Yup, that=92s basically what we do today- throw an error and don=92t retu= rn. But > this is less than ideal. > > We have discussed that we=92d probably like to return, but with an error > message. This would be in section 5.4.4 of the spec (=93Authorization ser= ver > directs user back to the client=94) we would like to pass additional > parameters for the error message- something other than user_denied, but > which indicates that the application was just misconfigured. I guess it depends on the business requirements that led to callback URL preregistration. Some sites require callback URL registration so they don't need to redirect to unknown third-party sites... in which case redirecting with an error message doesn't really fix the issue. Other sites require callback URL registration for security reasons, in which case an error message is just fine. Cheers, Brian From jpanzer@google.com Tue Nov 24 22:16:01 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A41AB3A6A02 for ; Tue, 24 Nov 2009 22:16:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.775 X-Spam-Level: X-Spam-Status: No, score=-105.775 tagged_above=-999 required=5 tests=[AWL=0.201, 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 8i9eLReesNAB for ; Tue, 24 Nov 2009 22:16:00 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 58E1B3A69F8 for ; Tue, 24 Nov 2009 22:16:00 -0800 (PST) Received: from wpaz1.hot.corp.google.com (wpaz1.hot.corp.google.com [172.24.198.65]) by smtp-out.google.com with ESMTP id nAP6FrXv018390 for ; Wed, 25 Nov 2009 06:15:54 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1259129754; bh=8eHuOaD7XF6r1fhExbmhc63kcGk=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=jS+iSqJ4ySKt8ggPlmNbFrICvFsqlWnVooCl7sYO9CAYEPLE+/whs7Uop7oL+2zPg 2soOy61aQvI5jhsgwqobg== 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=yTdIhOea0w05Y4IfHZWAkuhuoxRLoLGYxxYI80uqu51YhyKNzEfB+bc1FZ7Znb2rd pCLLI4KgrQCElLwVcaSSg== Received: from pwj1 (pwj1.prod.google.com [10.241.219.65]) by wpaz1.hot.corp.google.com with ESMTP id nAP6FoDU009396 for ; Tue, 24 Nov 2009 22:15:51 -0800 Received: by pwj1 with SMTP id 1so4703182pwj.0 for ; Tue, 24 Nov 2009 22:15:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.187.20 with SMTP id k20mr14569218waf.213.1259129750172; Tue, 24 Nov 2009 22:15:50 -0800 (PST) In-Reply-To: References: <148C596691F29F4EA6968577BE2CDFAE06A1B9FE@SC-MBXC1.TheFacebook.com> From: John Panzer Date: Tue, 24 Nov 2009 22:15:30 -0800 Message-ID: To: Mike Malone Content-Type: multipart/alternative; boundary=0016e64b1e047c364b04792bfd95 X-System-Of-Record: true Cc: Naitik Shah , Luke Shepard , Brent Goldman , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Facebook, OAuth, and WRAP X-BeenThere: oauth@ietf.org X-Mailman-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, 25 Nov 2009 06:16:01 -0000 --0016e64b1e047c364b04792bfd95 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Nov 24, 2009 at 4:35 PM, Mike Malone wrote: > On Tue, Nov 24, 2009 at 10:57 AM, David Recordon > wrote: > > > > The largest issue in Facebook moving to OAuth 1.0 (and yes, Eran's new > RFC is awesome) is the increase in the number of HTTP requests that > developers will need to make in comparison to our current authentication > mechanism. > > The OAuth _flow_ (in a browser) requires a couple additional requests > compared to Facebook Connect (in a browser). But Facebook Connect is > really a different beast since it relies on the Browser and Javascript > to magically set cookies cross domain and whatnot. I agree that it's > non-trivial to extend OAuth to cover this use case (we've sort of done > it at Six Apart and the flow is clunky and complicated). And even if > you figure out how to make the flow work you can't really make > requests purely on the client side without compromising your consumer > secret. > > That said, as far as I can tell, using OAuth for delegated > communication via an intermediary (a web app or iPhone app, for > example) should be doable for Facebook. The only real differences I > see between OAuth and WRAP for this use case are: > * WRAP requires SSL instead of signing URLs > Aside: If an SP specified OAuth PLAINTEXT signature mode, and used https: URLs for its API, would there be any effective difference between OAuth and WRAP for that SP? (Best as I can tell the only difference would be a mandated %26 character in the OAuth blob you pass in to get access, but I may be missing something.) --0016e64b1e047c364b04792bfd95 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Nov 24, 2009 at 4:35 PM, Mike Malone <mjmalone@gmail.com= > wrote:
On Tue, Nov 24, 2009 at 10:57 AM, David Recordon
<davidrecordon@facebook.co= m> wrote:
>
> The largest issue in Facebook moving to OAuth 1.0 (and yes, Eran's= new RFC is awesome) is the increase in the number of HTTP requests that de= velopers will need to make in comparison to our current authentication mech= anism.

The OAuth _flow_ (in a browser) requires a couple additional requests=
compared to Facebook Connect (in a browser). But Facebook Connect is
really a different beast since it relies on the Browser and Javascript
to magically set cookies cross domain and whatnot. I agree that it's non-trivial to extend OAuth to cover this use case (we've sort of done<= br> it at Six Apart and the flow is clunky and complicated). And even if
you figure out how to make the flow work you can't really make
requests purely on the client side without compromising your consumer
secret.

That said, as far as I can tell, using OAuth for delegated
communication via an intermediary (a web app or iPhone app, for
example) should be doable for Facebook. The only real differences I
see between OAuth and WRAP for this use case are:
=A0* WRAP requires SSL instead of signing URLs

Aside: If an SP specified OAuth PLAINTEXT signature mode, and used= https: URLs for its API, would there be any effective difference between O= Auth and WRAP for that SP? =A0(Best as I can tell the only difference would= be a mandated %26 character in the OAuth blob you pass in to get access, b= ut I may be missing something.)

--0016e64b1e047c364b04792bfd95-- From mjmalone@gmail.com Tue Nov 24 22:40:27 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A6FE28C1E2 for ; Tue, 24 Nov 2009 22:40:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 tvMS6N82GH1Y for ; Tue, 24 Nov 2009 22:40:25 -0800 (PST) Received: from mail-qy0-f203.google.com (mail-qy0-f203.google.com [209.85.221.203]) by core3.amsl.com (Postfix) with ESMTP id 3844328C1E1 for ; Tue, 24 Nov 2009 22:40:25 -0800 (PST) Received: by qyk41 with SMTP id 41so3777938qyk.29 for ; Tue, 24 Nov 2009 22:40:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=EkxD2mjXou+KtrZ8eN0wbUMwtmbetnQ4RLJkltpzlt4=; b=b+99cIN4wZzMLIQMn9nVzh+sLbmsB6F9GEN2sCE7tISq+bKhlTWMY8xn6cRs9tPTQ8 KCqVj0wuJILLvcw2IT+EodwXrqxIWDmWRcLBNORoSWg0kavzpgA4dWFawdp9x8wqvyUq zrIcj1NLhj993RHUI9iJ7icRDR8v/4FfzlwCo= 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=H0m/9oyxXtFZ4ZgCnP4X76LtP6dqVt4efTbF3r8873MwgJV8ZTy9qARIoJgFPaLQiJ 5d4OzuoD5TWcpsKgY5wsnxAt1+d62zWILOMJdMbmHjubrCk+hcaLLR0Twbq/mHqoiOmp tuRXYXjZMj9usWzS+aEK787n6DQq2CoaWZf+8= MIME-Version: 1.0 Received: by 10.229.115.15 with SMTP id g15mr77373qcq.14.1259131217830; Tue, 24 Nov 2009 22:40:17 -0800 (PST) In-Reply-To: References: <148C596691F29F4EA6968577BE2CDFAE06A1B9FE@SC-MBXC1.TheFacebook.com> Date: Tue, 24 Nov 2009 22:40:17 -0800 Message-ID: From: Mike Malone To: John Panzer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Naitik Shah , Luke Shepard , Brent Goldman , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Facebook, OAuth, and WRAP X-BeenThere: oauth@ietf.org X-Mailman-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, 25 Nov 2009 06:40:27 -0000 On Tue, Nov 24, 2009 at 10:15 PM, John Panzer wrote: > On Tue, Nov 24, 2009 at 4:35 PM, Mike Malone wrote: >> >> On Tue, Nov 24, 2009 at 10:57 AM, David Recordon >> wrote: >> > >> > The largest issue in Facebook moving to OAuth 1.0 (and yes, Eran's new >> > RFC is awesome) is the increase in the number of HTTP requests that >> > developers will need to make in comparison to our current authenticati= on >> > mechanism. >> >> The OAuth _flow_ (in a browser) requires a couple additional requests >> compared to Facebook Connect (in a browser). But Facebook Connect is >> really a different beast since it relies on the Browser and Javascript >> to magically set cookies cross domain and whatnot. I agree that it's >> non-trivial to extend OAuth to cover this use case (we've sort of done >> it at Six Apart and the flow is clunky and complicated). And even if >> you figure out how to make the flow work you can't really make >> requests purely on the client side without compromising your consumer >> secret. >> >> That said, as far as I can tell, using OAuth for delegated >> communication via an intermediary (a web app or iPhone app, for >> example) should be doable for Facebook. The only real differences I >> see between OAuth and WRAP for this use case are: >> =A0* WRAP requires SSL instead of signing URLs > > Aside: If an SP specified OAuth PLAINTEXT signature mode, and used https: > URLs for its API, would there be any effective difference between OAuth a= nd > WRAP for that SP? =A0(Best as I can tell the only difference would be a > mandated %26 character in the OAuth blob you pass in to get access, but I > may be missing something.) Yea, they're more or less the same. That's one use case for PLAINTEXT OAuth. You still have a "signature" though, it's just the base64'd signature base string. From stephen.farrell@cs.tcd.ie Wed Nov 25 05:52:33 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1424B3A67A8 for ; Wed, 25 Nov 2009 05:52:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7kXvJmsaEMK for ; Wed, 25 Nov 2009 05:52:32 -0800 (PST) Received: from VA3EHSOBE002.bigfish.com (va3ehsobe002.messaging.microsoft.com [216.32.180.12]) by core3.amsl.com (Postfix) with ESMTP id 2E95B28C10C for ; Wed, 25 Nov 2009 05:52:32 -0800 (PST) Received: from mail18-va3-R.bigfish.com (10.7.14.247) by VA3EHSOBE002.bigfish.com (10.7.40.22) with Microsoft SMTP Server id 8.1.240.5; Wed, 25 Nov 2009 13:52:26 +0000 Received: from mail18-va3 (localhost.localdomain [127.0.0.1]) by mail18-va3-R.bigfish.com (Postfix) with ESMTP id 7126310D82AE; Wed, 25 Nov 2009 13:52:26 +0000 (UTC) X-SpamScore: -8 X-BigFish: VPS-8(zz98dN168aJzz1202hzzz2dh6bh87h61h) X-Spam-TCS-SCL: 0:0 X-FB-DOMAIN-IP-MATCH: fail Received: from mail18-va3 (localhost.localdomain [127.0.0.1]) by mail18-va3 (MessageSwitch) id 1259157143191790_6224; Wed, 25 Nov 2009 13:52:23 +0000 (UTC) Received: from VA3EHSMHS022.bigfish.com (unknown [10.7.14.244]) by mail18-va3.bigfish.com (Postfix) with ESMTP id D76E119C80A6; Wed, 25 Nov 2009 13:52:22 +0000 (UTC) Received: from imx2.tcd.ie (134.226.1.156) by VA3EHSMHS022.bigfish.com (10.7.99.32) with Microsoft SMTP Server id 14.0.482.32; Wed, 25 Nov 2009 13:52:20 +0000 Received: from Vams.imx2 (imx2.tcd.ie [134.226.1.156]) by imx2.tcd.ie (Postfix) with SMTP id 6FD8168006; Wed, 25 Nov 2009 13:52:19 +0000 (GMT) Received: from imx2.tcd.ie ([134.226.1.156]) by imx2.tcd.ie ([134.226.1.156]) with SMTP (gateway) id A046A66C085; Wed, 25 Nov 2009 13:52:19 +0000 Received: from [134.226.36.180] (sfarrell.dsg.cs.tcd.ie [134.226.36.180]) by imx2.tcd.ie (Postfix) with ESMTP id 60E4768006; Wed, 25 Nov 2009 13:52:19 +0000 (GMT) Message-ID: <4B0D3698.8070706@cs.tcd.ie> Date: Wed, 25 Nov 2009 13:52:24 +0000 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.23 (X11/20090812) MIME-Version: 1.0 To: Eran Hammer-Lahav References: <90C41DD21FB7C64BB94121FBBC2E72343785183009@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343785183009@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-AntiVirus-Status: MessageID = A146A66C085 X-AntiVirus-Status: Host: imx2.tcd.ie X-AntiVirus-Status: Action Taken: X-AntiVirus-Status: NONE X-AntiVirus-Status: Checked by TCD Vexira. (version=1.60.2 VDF=10.113.28) X-Reverse-DNS: imx2.tcd.ie Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Signature crypto X-BeenThere: oauth@ietf.org X-Mailman-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, 25 Nov 2009 13:52:33 -0000 Eran Hammer-Lahav wrote: > I think we have consensus that the spec should not mandate a particular hash algorithm. This still leave the issue of assigning algorithms short names for the purpose of negotiation and declaration. Is there a registry available for such algorithms we can use or do we need to create a new one? Sorry to have missed out on the thread where that was discussed, but it'd be odd for an IETF security spec to not mandate some algorithms and quite likely to generate comments later in the process if there's no well-defined way to ensure interop. Do we have that? Ta, S. From infinity@lindenlab.com Wed Nov 25 06:19:14 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 856C728C22C for ; Wed, 25 Nov 2009 06:19:14 -0800 (PST) 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 lU8e96+TKTDq for ; Wed, 25 Nov 2009 06:19:13 -0800 (PST) Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id 161773A68AB for ; Wed, 25 Nov 2009 06:19:12 -0800 (PST) Received: by fxm5 with SMTP id 5so7004507fxm.28 for ; Wed, 25 Nov 2009 06:19:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.239.181.11 with SMTP id k11mr769346hbg.203.1259158743539; Wed, 25 Nov 2009 06:19:03 -0800 (PST) In-Reply-To: <4B0D3698.8070706@cs.tcd.ie> References: <90C41DD21FB7C64BB94121FBBC2E72343785183009@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B0D3698.8070706@cs.tcd.ie> From: "Infinity Linden (Meadhbh Hamrick)" Date: Wed, 25 Nov 2009 06:18:43 -0800 Message-ID: <3a880e2c0911250618w358579d9o38b5ad90cb9242af@mail.gmail.com> To: Stephen Farrell Content-Type: multipart/alternative; boundary=001485f87fb49fe000047932bddf Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Signature crypto X-BeenThere: oauth@ietf.org X-Mailman-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, 25 Nov 2009 14:19:14 -0000 --001485f87fb49fe000047932bddf Content-Type: text/plain; charset=ISO-8859-1 +1 to stephen's comment. when it comes to algorithm support and selection, i think the consensus that's emerged is we should require an algorithm that "looks good" at the moment the spec is being drafted, but allow the use of other optional algorithms. ("looks good" here means that there are no known successful attacks against the math of the algorithm and there's a general consensus amongst cryptographers that there won't be one in the next 20 years.) the rationale behind this may have to do with the experience some implementers had with MOSS / MIME Object Security Services (aka RFC1848.) MOSS was specified to address issues people had raised with PEM (Privacy Enhanced Mail). The problem with MOSS is that it was near infinitely flexible and you could create an implementation that strictly adhered to the specification, but was non-interoperable if you chose to support a different set of optional encipherment algorithms. so the concern here is that if you allow all hash algorithms to be optional, you'll find some outlier who wants to use HAVAL with Rabin Williams to generate signatures and will sell this solution into the marketplace, then go out of business. people who bought the solution won't think anything's wrong 'til they try to hook it up to someone else who's using a more traditional SHA256+RSA or ECDSA solution. a great wailing and gnashing of teeth will follow. but if we REQUIRE that everyone use SHA256 but allow other hash algorithms, then we won't have this problem. -cheers -meadhbh -- infinity linden (aka meadhbh hamrick) * it's pronounced "maeve" http://wiki.secondlife.com/wiki/User:Infinity_Linden On Wed, Nov 25, 2009 at 05:52, Stephen Farrell wrote: > > > Eran Hammer-Lahav wrote: > > I think we have consensus that the spec should not mandate a particular > hash algorithm. This still leave the issue of assigning algorithms short > names for the purpose of negotiation and declaration. Is there a registry > available for such algorithms we can use or do we need to create a new one? > > Sorry to have missed out on the thread where that was discussed, but > it'd be odd for an IETF security spec to not mandate some algorithms > and quite likely to generate comments later in the process if there's > no well-defined way to ensure interop. Do we have that? > > Ta, > S. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001485f87fb49fe000047932bddf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1 to stephen's comment.

when it comes to algorithm = support and selection, i think the consensus that's emerged is we shoul= d require an algorithm that "looks good" at the moment the spec i= s being drafted, but allow the use of other optional algorithms. ("loo= ks good" here means that there are no known successful attacks against= the math of the algorithm and there's a general consensus amongst cryp= tographers that there won't be one in the next 20 years.)

the rationale behind this may have to do with the exper= ience some implementers had with MOSS / MIME Object Security Services (aka = RFC1848.) MOSS was specified to address issues people had raised with PEM (= Privacy Enhanced Mail). The problem with MOSS is that it was near infinitel= y flexible and you could create an implementation that strictly adhered to = the specification, but was non-interoperable if you chose to support a diff= erent set of optional encipherment algorithms.

so the concern here is that if you allow all hash algor= ithms to be optional, you'll find some outlier who wants to use HAVAL w= ith Rabin Williams to generate signatures and will sell this solution into = the marketplace, then go out of business. people who bought the solution wo= n't think anything's wrong 'til they try to hook it up to someo= ne else who's using a more traditional SHA256+RSA or ECDSA solution.=A0= a great wailing and gnashing of teeth will follow.

but if we REQUIRE that everyone use SHA256 but allow ot= her hash algorithms, then we won't have this problem.

-cheers
-meadhbh

--
=A0 i= nfinity linden (aka meadhbh hamrick) =A0* =A0it's pronounced "maev= e"
=A0 =A0 =A0 =A0 http://wiki.secondlife.com/wiki/User:Infinity_Linden


On Wed, Nov 25, 2009 at 05:52, Stephen F= arrell <s= tephen.farrell@cs.tcd.ie> wrote:


Eran Hammer-Lahav wrote:
> I think we have consensus that the spec should not mandate a particula= r hash algorithm. This still leave the issue of assigning algorithms short = names for the purpose of negotiation and declaration. Is there a registry a= vailable for such algorithms we can use or do we need to create a new one?<= br>
Sorry to have missed out on the thread where that was discussed, but<= br> it'd be odd for an IETF security spec to not mandate some algorithms and quite likely to generate comments later in the process if there's no well-defined way to ensure interop. Do we have that?

Ta,
S.

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

--001485f87fb49fe000047932bddf-- From hubertlvg@gmail.com Wed Nov 25 06:28:56 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97B6F3A68D4 for ; Wed, 25 Nov 2009 06:28:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 YniPjzfaOP7y for ; Wed, 25 Nov 2009 06:28:55 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 3B0B63A689B for ; Wed, 25 Nov 2009 06:28:55 -0800 (PST) Received: by bwz23 with SMTP id 23so7311376bwz.29 for ; Wed, 25 Nov 2009 06:28:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ksEmk5D/sY8JNgR4uahWrkuJ8Zgk9jjAGKaBbRqhvz0=; b=brPmJZdoohHO5XIf7/IOR186Qz7dqchE305apPpDvGzLIWLiyj/iBk71qLToZ1ywbJ ZdeDTNzmoYdquqx2DHiJtyfM+jM1PUAeVS9YGhJQpPpMYwoh1ZDHtvnH669Y7iLmIWzG yQ2/0NMyEaCaR6MbWMp2WhU4cni8jtdQPkBYQ= 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=cr2VZs4wI4lbaOTtEWF1I/cZq5PuVo//9K7BesBBc0EUnEjh/1GHOIYOBxIW7cHK71 IC9U78NNU7pGwnMEK44BD0VSydep74bBJ35/zkKBbiy9h6q0UoxeQyECbI1Sjj4defZC eEqgqVzuvc+jOZO5IcdpeANFX4Yz5Vr9VWpvk= MIME-Version: 1.0 Received: by 10.204.48.131 with SMTP id r3mr1229992bkf.195.1259159326691; Wed, 25 Nov 2009 06:28:46 -0800 (PST) In-Reply-To: <3a880e2c0911250618w358579d9o38b5ad90cb9242af@mail.gmail.com> References: <90C41DD21FB7C64BB94121FBBC2E72343785183009@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B0D3698.8070706@cs.tcd.ie> <3a880e2c0911250618w358579d9o38b5ad90cb9242af@mail.gmail.com> Date: Wed, 25 Nov 2009 15:28:46 +0100 Message-ID: <6c0fd2bc0911250628l7a9bc86gdfe15154c2566210@mail.gmail.com> From: Hubert Le Van Gong To: "Infinity Linden (Meadhbh Hamrick)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Signature crypto X-BeenThere: oauth@ietf.org X-Mailman-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, 25 Nov 2009 14:28:56 -0000 +1 A mandatory support will surely help interoperability. If we also have the negotiation piece of protocol we had discussed before then we should be fine on that end of things. Hubert On Wed, Nov 25, 2009 at 3:18 PM, Infinity Linden (Meadhbh Hamrick) wrote: > +1 to stephen's comment. > when it comes to algorithm support and selection, i think the consensus > that's emerged is we should require an algorithm that "looks good" at the > moment the spec is being drafted, but allow the use of other optional > algorithms. ("looks good" here means that there are no known successful > attacks against the math of the algorithm and there's a general consensus > amongst cryptographers that there won't be one in the next 20 years.) > the rationale behind this may have to do with the experience some > implementers had with MOSS / MIME Object Security Services (aka RFC1848.) > MOSS was specified to address issues people had raised with PEM (Privacy > Enhanced Mail). The problem with MOSS is that it was near infinitely > flexible and you could create an implementation that strictly adhered to = the > specification, but was non-interoperable if you chose to support a differ= ent > set of optional encipherment algorithms. > so the concern here is that if you allow all hash algorithms to be option= al, > you'll find some outlier who wants to use HAVAL with Rabin Williams to > generate signatures and will sell this solution into the marketplace, the= n > go out of business. people who bought the solution won't think anything's > wrong 'til they try to hook it up to someone else who's using a more > traditional SHA256+RSA or ECDSA solution.=A0a great wailing and gnashing = of > teeth will follow. > but if we REQUIRE that everyone use SHA256 but allow other hash algorithm= s, > then we won't have this problem. > -cheers > -meadhbh > -- > =A0 infinity linden (aka meadhbh hamrick) =A0* =A0it's pronounced "maeve" > =A0 =A0 =A0 =A0 http://wiki.secondlife.com/wiki/User:Infinity_Linden > > > On Wed, Nov 25, 2009 at 05:52, Stephen Farrell > wrote: >> >> >> Eran Hammer-Lahav wrote: >> > I think we have consensus that the spec should not mandate a particula= r >> > hash algorithm. This still leave the issue of assigning algorithms sho= rt >> > names for the purpose of negotiation and declaration. Is there a regis= try >> > available for such algorithms we can use or do we need to create a new= one? >> >> Sorry to have missed out on the thread where that was discussed, but >> it'd be odd for an IETF security spec to not mandate some algorithms >> and quite likely to generate comments later in the process if there's >> no well-defined way to ensure interop. Do we have that? >> >> Ta, >> S. >> >> _______________________________________________ >> OAuth mailing 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 lshepard@facebook.com Tue Nov 24 18:15:23 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E674228C170 for ; Tue, 24 Nov 2009 18:15:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.264 X-Spam-Level: X-Spam-Status: No, score=-6.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, 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 CdgRpJyDARse for ; Tue, 24 Nov 2009 18:15:19 -0800 (PST) Received: from mailout-sf2p.facebook.com (mailout-snc1.facebook.com [69.63.179.25]) by core3.amsl.com (Postfix) with ESMTP id DEBF528C16A for ; Tue, 24 Nov 2009 18:15:19 -0800 (PST) Received: from mail.thefacebook.com (intlb01.snat.snc1.facebook.com [10.128.203.17] (may be forged)) by pp02.snc1.tfbnw.net (8.14.1/8.14.1) with ESMTP id nAP2EqYs024446 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 24 Nov 2009 18:14:52 -0800 Received: from SC-MBXC1.TheFacebook.com ([192.168.18.102]) by sc-hub01.TheFacebook.com ([192.168.18.104]) with mapi; Tue, 24 Nov 2009 18:15:11 -0800 From: Luke Shepard To: Brian Eaton , Michael Malone Date: Tue, 24 Nov 2009 18:14:45 -0800 Thread-Topic: WRAP session fixation? Thread-Index: AcptctGXjPHxXuHUS5KLHVkGM/7xFgAAjyU4 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_C731D31518C2Clshepardfacebookcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2009-11-24_12:2009-11-16, 2009-11-24, 2009-11-24 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-0911240282 X-Mailman-Approved-At: Wed, 25 Nov 2009 07:43:43 -0800 Cc: Naitik Shah , Brent Goldman , "oauth@ietf.org" Subject: Re: [OAUTH-WG] WRAP session fixation? X-BeenThere: oauth@ietf.org X-Mailman-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, 25 Nov 2009 07:37:14 -0000 --_000_C731D31518C2Clshepardfacebookcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yup, that's basically what we do today- throw an error and don't return. Bu= t this is less than ideal. We have discussed that we'd probably like to return, but with an error mess= age. This would be in section 5.4.4 of the spec ("Authorization server dire= cts user back to the client") we would like to pass additional parameters f= or the error message- something other than user_denied, but which indicates= that the application was just misconfigured. On 11/24/09 5:58 PM, "Brian Eaton" wrote: On Tue, Nov 24, 2009 at 5:45 PM, Michael Malone wrote: > Ah interesting, so you pass the callback URL to the authorization server > again to get an access token? How does that work if you _do_ have a > registered callback URL? It depends on the authorization server, but my guess is that if the authorization server required callback URL registration in the first place they will be checking callback URLs when users hit the approval page. If an unknown callback URL hits the approval page, the authorization server will probably refuse to return the user to the callback. Cheers, Brian --_000_C731D31518C2Clshepardfacebookcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: WRAP session fixation? Yup, that’s basically what we do today- throw an error and don&= #8217;t return. But this is less than ideal.

We have discussed that we’d probably like to return, but with an erro= r message. This would be in section 5.4.4 of the spec (“Authorization= server directs user back to the client”) we would like to pass addit= ional parameters for the error message- something other than user_denied, b= ut which indicates that the application was just misconfigured.


On 11/24/09 5:58 PM, "Brian Eaton" <beaton@google.com> wrote:

On Tue, Nov 24, 2009 at 5:45 PM, Michael Ma= lone <mjmalone@gmail.com> wrote: > Ah interesting, so you pass the callback URL to the authorization serv= er
> again to get an access token? How does that work if you _do_ have a > registered callback URL?

It depends on the authorization server, but my guess is that if the
authorization server required callback URL registration in the first
place they will be checking callback URLs when users hit the approval
page.  If an unknown callback URL hits the approval page, the
authorization server will probably refuse to return the user to the
callback.

Cheers,
Brian

--_000_C731D31518C2Clshepardfacebookcom_-- From brent@facebook.com Wed Nov 25 06:03:35 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA98E3A69C3 for ; Wed, 25 Nov 2009 06:03:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.964 X-Spam-Level: X-Spam-Status: No, score=-5.964 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4, 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 2Qwq7B-+9eyA for ; Wed, 25 Nov 2009 06:03:33 -0800 (PST) Received: from mailout-snc1.facebook.com (mailout-snc1.facebook.com [69.63.179.25]) by core3.amsl.com (Postfix) with ESMTP id C15333A6AC0 for ; Wed, 25 Nov 2009 06:03:33 -0800 (PST) Received: from mail.thefacebook.com (intlb01.snat.snc1.facebook.com [10.128.203.15] (may be forged)) by pp01.snc1.tfbnw.net (8.14.1/8.14.1) with ESMTP id nAPE3HHI028683 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 25 Nov 2009 06:03:17 -0800 Received: from SC-MBXC1.TheFacebook.com ([192.168.18.102]) by sc-hub01.TheFacebook.com ([192.168.18.104]) with mapi; Wed, 25 Nov 2009 06:03:26 -0800 From: Brent Goldman To: Mike Malone Date: Wed, 25 Nov 2009 06:03:23 -0800 Thread-Topic: [OAUTH-WG] Facebook, OAuth, and WRAP Thread-Index: Acpt2A6RpCBQZoxRTBq7PY9v2AIxPA== Message-ID: References: <148C596691F29F4EA6968577BE2CDFAE06A1B9FE@SC-MBXC1.TheFacebook.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_C6B20C22ED3A4714943FFEA0A2347045facebookcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2009-11-25_10:2009-11-16, 2009-11-25, 2009-11-25 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-0911250105 X-Mailman-Approved-At: Wed, 25 Nov 2009 07:43:43 -0800 Cc: Naitik Shah , Luke Shepard , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Facebook, OAuth, and WRAP X-BeenThere: oauth@ietf.org X-Mailman-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, 25 Nov 2009 14:05:06 -0000 --_000_C6B20C22ED3A4714943FFEA0A2347045facebookcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Nov 24, 2009, at 4:35 PM, Mike Malone wrote: On Tue, Nov 24, 2009 at 10:57 AM, David Recordon > wrote: The largest issue in Facebook moving to OAuth 1.0 (and yes, Eran's new RFC = is awesome) is the increase in the number of HTTP requests that developers = will need to make in comparison to our current authentication mechanism. The OAuth _flow_ (in a browser) requires a couple additional requests compared to Facebook Connect (in a browser). But Facebook Connect is really a different beast since it relies on the Browser and Javascript to magically set cookies cross domain and whatnot. I agree that it's non-trivial to extend OAuth to cover this use case (we've sort of done it at Six Apart and the flow is clunky and complicated). And even if you figure out how to make the flow work you can't really make requests purely on the client side without compromising your consumer secret. Facebook Connect can work without cookies (e.g., in a Safari iframe, or if = the developer manually turns this off via a configuration option) -- the co= okies are just used as a simple cache, and are not magic or a defining feat= ure of Connect. Additionally, by default, Connect does not work across doma= ins unless the developer configures a base domain with us. To top it all of= f, Connect also works in a non-JS environment, or in an environment where t= he developers don't want to use the Facebook JS. Therefore, I think we can fairly compare OAuth and Facebook Connect apples = to apples, and we should just consider cookies, multiple domains, and JS sn= azziness as extra features that would be nice to add to OAuth via extension= s. As David stated, the largest issue with Facebook moving to OAuth truly i= s the number of requests. That said, as far as I can tell, using OAuth for delegated communication via an intermediary (a web app or iPhone app, for example) should be doable for Facebook. The only real differences I see between OAuth and WRAP for this use case are: * WRAP requires SSL instead of signing URLs * WRAP renamed request token to refresh token and lets you use them to exchange for temporary access tokens multiple times * WRAP has a defined flow for accepting username/password & exchanging for an access token I'm guessing that the big win you see is the third point, but the auth flow is really a small part of OAuth. If the flow defined in OAuth 1.0 doesn't work for you why not create a new flow and keep the rest of the spec? The third point is pretty cool, but Facebook actually discourages exchangin= g usernames/passwords for access tokens. Only a handful of whitelisted part= ners have access to this. In the vast majority of cases, usernames and pas= swords are given directly to Facebook.com instead of t= o the app. The most interesting part of WRAP are the various profiles. They currently= map well to our existing authentication mechanisms and the username/passwo= rd profile is an API we offer to whitelisted partners such as the XBox and = Playstation 3. It would be great if OAuth 2.0 had a similar profile mechan= ism where each profile is optimized in terms of the number of steps (HTTP r= equests) required versus being combined together like OAuth 1.0. Again, the flow is really just half of OAuth. Maybe it'd make sense to split the OAuth flow and OAuth request signing into separate specs? This is a really interesting idea that I think makes a lot of sense. I don'= t see why the various WRAP profiles couldn't work almost identically in OAu= th 2.0, with the main differences being that OAuth 2.0 would have an extra = step to exchange a secret (or perhaps even reuse a step if it makes sense, = and then API calls would have a signature instead of being called over SSL. I'm not convinced that signatures are "too hard" for developers especially = when libraries hide them away. That said, OAuth 1.0 implementations still = requires that developers understand the different types of tokens in additi= on to when and how they're generated. WRAP seems to have a bunch of different tokens too, they just don't call them all tokens (there's the refresh token, the client id & secret, the access token, the verification code... everything seems to be there). Re: signatures, I think the SSL requirement would be a much larger burden on developers. It's hard enough to debug OAuth problems when you can sniff the flow using ngrep. Although I guess removing signing would help here a bit. Good point about the tokens. One of us should make a list of all the terms = in each spec, and then set up a mapping between the sets, to see if the num= ber of concepts is really all that different. WRAP is intriguing in terms of really simplifying what developers need to u= nderstand. The first step being trading some set of credentials or asking = the user to go somewhere results in an access token. The second step then = being including that access token via HTTP headers, a GET arg, or a POST ar= g over SSL without needing to calculate any sort of signatures. The downsi= de is that now all APIs need to be served over SSL, but that seems doable. I don't think you'd be able to use GET params with WRAP since stuff isn't signed. Other than that, I guess the terminology is simpler..? I'm used to the OAuth terminology by now so it's hard for me to say. The flow doesn't seem all that different to me. Maybe it's a communication problem? Why does the lack of signatures mean we can't use GET params? We can still = trust everything because it's happening over SSL. These are the four main use cases which were focused on. While there is qu= ite a bit of overlap between them, we think that it is important to have sp= ecifically optimized flows for each so that individually they are as simple= as possible to implement. 1) "OAuth" web flow of redirecting a user to Facebook, them authorizing pre= -registered application, and then being redirected back to the web app with= in their browser. 2) A mobile/desktop flow where the user is redirected back to Facebook, aut= horizes the app, and then is sent back to the application. We both have a = version of this use case where the application separately opens a browser a= nd one where the application is able to embed a browser directly. 3) A mobile/desktop/device flow where the user enters their Facebook userna= me/password which the application then trades for a token. This is for whi= telisted partners. 4) A fully JavaScript environment where the JavaScript sets a cookie contai= ning the credentials needed for the web application to get API access while= the user has an active session. We think that WRAP currently solves #3, probably solves #2, and mostly solv= es #1. #4 hasn't been tackled within WRAP yet, but we hope to develop a pr= ofile for it as well. Again, I think the only use case that would be truly difficult to solve with OAuth is #4. I think #4 is an interesting problem though, and I'd be happy to see OAuth support for a pure Javascript environment. One final note - unless I'm missing something WRAP is vulnerable to the same session fixation attack that OAuth 1.0 had... unless it's requiring callback registration, which is a really lame solution to that problem. Mike --_000_C6B20C22ED3A4714943FFEA0A2347045facebookcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
On Nov 24, 2= 009, at 4:35 PM, Mike Malone wrote:

On Tue, Nov 24, 2009 at 10:57 AM, Davi= d Recordon
<davidrecord= on@facebook.com> wrote:

The largest issue in Facebook moving to OAuth 1= .0 (and yes, Eran's new RFC is awesome) is the increase in the number of HT= TP requests that developers will need to make in comparison to our current = authentication mechanism.

The OAuth _flow_ (in a browse= r) requires a couple additional requests
compared to Facebook Connect (i= n a browser). But Facebook Connect is
really a different beast since it = relies on the Browser and Javascript
to magically set cookies cross doma= in and whatnot. I agree that it's
non-trivial to extend OAuth to cover t= his use case (we've sort of done
it at Six Apart and the flow is clunky = and complicated). And even if
you figure out how to make the flow work y= ou can't really make
requests purely on the client side without compromi= sing your consumer
secret.

Fac= ebook Connect can work without cookies (e.g., in a Safari iframe, or if the= developer manually turns this off via a configuration option) -- the cooki= es are just used as a simple cache, and are not magic or a defining feature= of Connect. Additionally, by default, Connect does not work across do= mains unless the developer configures a base domain with us. To top it all = off, Connect also works in a non-JS environment, or in an environment where= the developers don't want to use the Facebook JS.

Therefore, I think we can fairly compare OAuth and Facebook Connect apples= to apples, and we should just consider cookies, multiple domains, and JS s= nazziness as extra features that would be nice to add to OAuth via extensio= ns. As David stated, the largest issue with Facebook moving to OAuth truly = is the number of requests.


That said, as far as I can tell, using OAuth for delegated
commun= ication via an intermediary (a web app or iPhone app, for
example) shoul= d be doable for Facebook. The only real differences I
see between OAuth = and WRAP for this use case are:
 * WRAP requires SSL instead of si= gning URLs
 * WRAP renamed request token to refresh token and lets= you use them
to exchange for temporary access tokens multiple times
=  * WRAP has a defined flow for accepting username/password &
e= xchanging for an access token

I'm guessing that the big win you see = is the third point, but the auth
flow is really a small part of OAuth. I= f the flow defined in OAuth 1.0
doesn't work for you why not create a ne= w flow and keep the rest of
the spec?

The third point is pretty cool, but Facebook actually discoura= ges exchanging usernames/passwords for access tokens. Only a handful o= f whitelisted partners have access to this.  In the vast majority= of cases, usernames and passwords are given directly to Facebook.com instead of to the app.


The most interesting part = of WRAP are the various profiles.  They currently map well to our exis= ting authentication mechanisms and the username/password profile is an API = we offer to whitelisted partners such as the XBox and Playstation 3.  = It would be great if OAuth 2.0 had a similar profile mechanism where each p= rofile is optimized in terms of the number of steps (HTTP requests) require= d versus being combined together like OAuth 1.0.

Again,= the flow is really just half of OAuth. Maybe it'd make sense to
split t= he OAuth flow and OAuth request signing into separate specs?

This is a really interesting idea that I think = makes a lot of sense. I don't see why the various WRAP profiles couldn't wo= rk almost identically in OAuth 2.0, with the main differences being that&nb= sp;OAuth 2.0 would have an extra step to exchange a secret (or perhaps even= reuse a step if it makes sense, and then API calls would have a signature = instead of being called over SSL.


I'm not convinced that signatures are "too hard" for= developers especially when libraries hide them away.  That said, OAut= h 1.0 implementations still requires that developers understand the differe= nt types of tokens in addition to when and how they're generated.

WRAP seems to have a bunch of different tokens too, they just do= n't
call them all tokens (there's the refresh token, the client id &=
secret, the access token, the verification code... everything seems to<= br>be there).

Re: signatures, I think the SSL requirement would be a= much larger
burden on developers. It's hard enough to debug OAuth probl= ems when
you can sniff the flow using ngrep. Although I guess removing s= igning
would help here a bit.

= Good point about the tokens. One of us should make a list of all the terms = in each spec, and then set up a mapping between the sets, to see if the num= ber of concepts is really all that different.


WRAP is intriguing in terms of rea= lly simplifying what developers need to understand.  The first step be= ing trading some set of credentials or asking the user to go somewhere resu= lts in an access token.  The second step then being including that acc= ess token via HTTP headers, a GET arg, or a POST arg over SSL without needi= ng to calculate any sort of signatures.  The downside is that now all = APIs need to be served over SSL, but that seems doable.
I don't think you'd be able to use GET params with WRAP since stuff
isn= 't signed. Other than that, I guess the terminology is simpler..?
I'm us= ed to the OAuth terminology by now so it's hard for me to say.
The flow = doesn't seem all that different to me. Maybe it's a
communication proble= m?

Why does the lack of signature= s mean we can't use GET params? We can still trust everything because it's = happening over SSL.


These are the four main use cases which were focused on. &nb= sp;While there is quite a bit of overlap between them, we think that it is = important to have specifically optimized flows for each so that individuall= y they are as simple as possible to implement.

1) "OAuth" web flo= w of redirecting a user to Facebook, them authorizing pre-registered applic= ation, and then being redirected back to the web app within their browser.<= br>
2) A mobile/desktop flow where th= e user is redirected back to Facebook, authorizes the app, and then is sent= back to the application.  We both have a version of this use case whe= re the application separately opens a browser and one where the application= is able to embed a browser directly.
3) A mobile/desktop/device flow where the user enters their Facebook u= sername/password which the application then trades for a token.  This = is for whitelisted partners.
4) A= fully JavaScript environment where the JavaScript sets a cookie containing= the credentials needed for the web application to get API access while the= user has an active session.

=
We think that WRAP currently solves = #3, probably solves #2, and mostly solves #1.  #4 hasn't been tackled = within WRAP yet, but we hope to develop a profile for it as well.

Again, I think the only use case that would be truly difficult t= o
solve with OAuth is #4. I think #4 is an interesting problem though,and I'd be happy to see OAuth support for a pure Javascript
environmen= t.

One final note - unless I'm missing something WRAP is vulnerable = to
the same session fixation attack that OAuth 1.0 had... unless it'srequiring callback registration, which is a really lame solution to
tha= t problem.

Mike

= --_000_C6B20C22ED3A4714943FFEA0A2347045facebookcom_-- From brent@facebook.com Wed Nov 25 06:10:23 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C514328C226 for ; Wed, 25 Nov 2009 06:10:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.156 X-Spam-Level: X-Spam-Status: No, score=-6.156 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 DUFYZ28hGdhT for ; Wed, 25 Nov 2009 06:10:20 -0800 (PST) Received: from mailout-sf2p.facebook.com (mailout-snc1.facebook.com [69.63.179.25]) by core3.amsl.com (Postfix) with ESMTP id 8F5F528C11A for ; Wed, 25 Nov 2009 06:10:20 -0800 (PST) Received: from mail.thefacebook.com (intlb01.snat.snc1.facebook.com [10.128.203.18] (may be forged)) by pp02.snc1.tfbnw.net (8.14.1/8.14.1) with ESMTP id nAPE9oKZ006905 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 25 Nov 2009 06:09:51 -0800 Received: from SC-MBXC1.TheFacebook.com ([192.168.18.102]) by sc-hub01.TheFacebook.com ([192.168.18.104]) with mapi; Wed, 25 Nov 2009 06:10:10 -0800 From: Brent Goldman To: Mike Malone Date: Wed, 25 Nov 2009 06:10:07 -0800 Thread-Topic: [OAUTH-WG] Facebook, OAuth, and WRAP Thread-Index: Acpt2P7iKbd3qlrwQbikIj65NvDVrA== Message-ID: References: <148C596691F29F4EA6968577BE2CDFAE06A1B9FE@SC-MBXC1.TheFacebook.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=2009-11-25_10:2009-11-16, 2009-11-25, 2009-11-25 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-0911250106 X-Mailman-Approved-At: Wed, 25 Nov 2009 07:43:43 -0800 Cc: Naitik Shah , Luke Shepard , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Facebook, OAuth, and WRAP X-BeenThere: oauth@ietf.org X-Mailman-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, 25 Nov 2009 14:10:23 -0000 On Nov 24, 2009, at 10:40 PM, Mike Malone wrote: > On Tue, Nov 24, 2009 at 10:15 PM, John Panzer =20 > wrote: >> On Tue, Nov 24, 2009 at 4:35 PM, Mike Malone =20 >> wrote: >>> >>> On Tue, Nov 24, 2009 at 10:57 AM, David Recordon >>> wrote: >>>> >>>> The largest issue in Facebook moving to OAuth 1.0 (and yes, =20 >>>> Eran's new >>>> RFC is awesome) is the increase in the number of HTTP requests that >>>> developers will need to make in comparison to our current =20 >>>> authentication >>>> mechanism. >>> >>> The OAuth _flow_ (in a browser) requires a couple additional =20 >>> requests >>> compared to Facebook Connect (in a browser). But Facebook Connect is >>> really a different beast since it relies on the Browser and =20 >>> Javascript >>> to magically set cookies cross domain and whatnot. I agree that it's >>> non-trivial to extend OAuth to cover this use case (we've sort of =20 >>> done >>> it at Six Apart and the flow is clunky and complicated). And even if >>> you figure out how to make the flow work you can't really make >>> requests purely on the client side without compromising your =20 >>> consumer >>> secret. >>> >>> That said, as far as I can tell, using OAuth for delegated >>> communication via an intermediary (a web app or iPhone app, for >>> example) should be doable for Facebook. The only real differences I >>> see between OAuth and WRAP for this use case are: >>> * WRAP requires SSL instead of signing URLs >> >> Aside: If an SP specified OAuth PLAINTEXT signature mode, and used =20 >> https: >> URLs for its API, would there be any effective difference between =20 >> OAuth and >> WRAP for that SP? (Best as I can tell the only difference would be a >> mandated %26 character in the OAuth blob you pass in to get access, =20 >> but I >> may be missing something.) > > Yea, they're more or less the same. That's one use case for PLAINTEXT > OAuth. You still have a "signature" though, it's just the base64'd > signature base string. If they're more or less the same (besides the difference you =20 mentioned), then why not also create an SSL signature mode which =20 leaves out the oauth_signature param? If SSL mode is this essentially =20 the same as WRAP, why not actually make this the bridge between the =20 two specs? From brent@facebook.com Wed Nov 25 06:57:37 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 937983A68B4 for ; Wed, 25 Nov 2009 06:57:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.21 X-Spam-Level: X-Spam-Status: No, score=-6.21 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, 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 llGhhCszJwNi for ; Wed, 25 Nov 2009 06:57:36 -0800 (PST) Received: from mailout-sf2p.facebook.com (mailout-snc1.facebook.com [69.63.179.25]) by core3.amsl.com (Postfix) with ESMTP id 3CE153A63C9 for ; Wed, 25 Nov 2009 06:57:36 -0800 (PST) Received: from mail.thefacebook.com (intlb01.snat.snc1.facebook.com [10.128.203.15] (may be forged)) by pp02.snc1.tfbnw.net (8.14.1/8.14.1) with ESMTP id nAPEv3jj017534 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 25 Nov 2009 06:57:03 -0800 Received: from SC-MBXC1.TheFacebook.com ([192.168.18.102]) by sc-hub01.TheFacebook.com ([192.168.18.104]) with mapi; Wed, 25 Nov 2009 06:57:19 -0800 From: Brent Goldman To: Brian Eaton Date: Wed, 25 Nov 2009 06:57:17 -0800 Thread-Topic: WRAP session fixation? Thread-Index: Acpt35XNH7BhjOe4Q6asZ1tapscVag== 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_ED81D84D0FB2497688078724954C826Afacebookcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2009-11-25_10:2009-11-16, 2009-11-25, 2009-11-25 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-0911250119 X-Mailman-Approved-At: Wed, 25 Nov 2009 07:43:43 -0800 Cc: Naitik Shah , "oauth@ietf.org" , Luke Shepard Subject: Re: [OAUTH-WG] WRAP session fixation? X-BeenThere: oauth@ietf.org X-Mailman-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, 25 Nov 2009 14:57:37 -0000 --_000_ED81D84D0FB2497688078724954C826Afacebookcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Facebook Platform/Connect has some pretty interesting logic involving regis= tered callback URLs in our proprietary auth flows. Much of this is because = we hate showing error messages. Maybe OAuth could borrow some of these idea= s? Here's some more info. I'm using the terminology "specified callback URL" to refer to the callback= URL specified in the request, and "registered callback URL" to refer to th= e callback URL configured with us in advance. There are two types of callba= ck URLs that can be specified in a request: absolute and relative. Case 1. Specified callback URL is absolute. If the specified callback URL is "safe", we redirect to it. Otherwise, inst= ead of throwing an error, we redirect to the registered callback URL, with = the specified callback URL in a GET param called "next". It's up to the dev= eloper of the registered callback URL to use the "next" param, or they can = just ignore it. To determine if the specified callback URL is safe: if the registered callb= ack URL is a directory, then the specified callback URL has to be within th= at subdirectory. Otherwise, the specified callback URL has to point to the = same file as the registered callback URL, and any query params on the regis= tered callback URL have to also be present in the specified callback URL For example, if the registered callback URL is http://www.foobar.com/callba= ck/, and the specified callback URL is http://www.foobar.com/callback/metho= d2, we know the specified callback URL is safe and thus redirect directly t= here. But if the specified callback URL is http://www.facebook.com/logged-i= nto-foobar, which is unsafe, we redirect to http://www.foobar.com/callback?= next=3D{urlencode(http://www.facebook.com/logged-into-foobar)} Note: we also support the concept of a "base domain", which essentially whi= telists every page on that domain, and every page on all subdomains of that= domain, as safe. Case 2. Specified callback URL is relative. In this case, there's no issue of safety, since we'll always redirect to a = URL constructed based on the registered callback URL, which is by definitio= n safe. More information about constructing the URL to redirect to: 2.1. If the registered callback URL doesn't have a question mark anywhere i= n it, we can just append the specified callback URL to it and redirect. For= example, with a registered callback of http://www.foobar.com/callback/ and= a specified callback URL of "loggedin.php?done=3Dtrue", we redirect to htt= p://www.foobar.com/callback/loggedin.php?done=3Dtrue. 2.2 If the registered callback URL has a question mark, we append the speci= fied callback URL directly, but do some munging to the params to get everyt= hing on the same level. For example, with a registered callback of "http://= www.foobar.com/callback?page=3D" and a specified callback URL of "loggedin.= php?done=3Dtrue", we redirect to http://www.foobar.com/callback?page=3Dlogg= edin.php&done=3Dtrue (notice how the second ? changed to a &). Case 3. Unspecified callback URL. I lied, there's actually a third case. We support auth flows with unspecifi= ed callback URLs in the request. If there's a registered callback URL, we j= ust redirect there. Otherwise, we show an error message. So basically the o= nly way to get an error message is if there is no specified callback URL or= registered callback URL. -Brent On Nov 24, 2009, at 6:17 PM, Brian Eaton wrote: On Tue, Nov 24, 2009 at 6:14 PM, Luke Shepard > wrote: Yup, that=92s basically what we do today- throw an error and don=92t return= . But this is less than ideal. We have discussed that we=92d probably like to return, but with an error message. This would be in section 5.4.4 of the spec (=93Authorization serve= r directs user back to the client=94) we would like to pass additional parameters for the error message- something other than user_denied, but which indicates that the application was just misconfigured. I guess it depends on the business requirements that led to callback URL preregistration. Some sites require callback URL registration so they don't need to redirect to unknown third-party sites... in which case redirecting with an error message doesn't really fix the issue. Other sites require callback URL registration for security reasons, in which case an error message is just fine. Cheers, Brian --_000_ED81D84D0FB2497688078724954C826Afacebookcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Facebook Platform/Connect = has some pretty interesting logic involving registered callback URLs in our= proprietary auth flows. Much of this is because we hate showing error mess= ages. Maybe OAuth could borrow some of these ideas? Here's some more i= nfo.

I'm using the terminology "specified= callback URL" to refer to the callback URL specified in the request, and "= registered callback URL" to refer to the callback URL configured with us in= advance. There are two types of callback URLs that can be specified in a r= equest: absolute and relative. 

Case 1. Sp= ecified callback URL is absolute.
If the specified callback U= RL is "safe", we redirect to it. Otherwise, instead of throwing an error,&n= bsp;we redirect to the registered callback URL, with the specified callback= URL in a GET param called "next". It's up to the developer of the register= ed callback URL to use the "next" param, or they can just ignore it.
<= div>
To determine if the specified callback URL is safe: if t= he registered callback URL is a directory, then the specified callback URL = has to be within that subdirectory. Otherwise, the specified callback URL h= as to point to the same file as the registered callback URL, and any query = params on the registered callback URL have to also be present in the specif= ied callback URL

For example, if the registered ca= llback URL is http://www.foobar= .com/callback/, and the specified callback URL is http://www.foobar.com/callback/method2, w= e know the specified callback URL is safe and thus redirect directly there.= But if the specified callback URL is http://www.facebook.com/logged-into-foobar, which is = unsafe, we redirect to http://www.foobar.= com/callback?next=3D{urlencode(http://www.facebook.com/logged-into-foobar)}
<= br>
Note: we also support the concept of a "base domain", which e= ssentially whitelists every page on that domain, and every page on all subd= omains of that domain, as safe.

Case 2. Specifi= ed callback URL is relative.
In this case, there's no issue o= f safety, since we'll always redirect to a URL constructed based on the reg= istered callback URL, which is by definition safe.

More information about constructing the URL to redirect to:
2.1.= If the registered callback URL doesn't have a question mark anywhere in it= , we can just append the specified callback URL to it and redirect. For exa= mple, with a registered callback of http://www.foobar.com/callback/ and a specified callback URL of "l= oggedin.php?done=3Dtrue", we redirect to http://www.foobar.com/callback/loggedin.p= hp?done=3Dtrue.
2.2 If the registered callback URL has a ques= tion mark, we append the specified callback URL directly, but do some mungi= ng to the params to get everything on the same level. For example, with a r= egistered callback of "h= ttp://www.foobar.com/callback?page=3D" and a specified callback URL of = "loggedin.php?done=3Dtrue", we redirect to http://www.foobar.com/callba= ck?page=3Dloggedin.php&done=3Dtrue (notice how the second ? changed= to a &).

Case 3. Unspecified callback URL.=
I lied, there's actually a third case. We support auth flows= with unspecified callback URLs in the request. If there's a registered cal= lback URL, we just redirect there. Otherwise, we show an error message. So = basically the only way to get an error message is if there is no specified = callback URL or registered callback URL.

-Brent


On Nov 24, 2009, at 6:= 17 PM, Brian Eaton wrote:

On Tue, Nov 24, 2009 at 6:14 PM, Luke Shepard &l= t;lshepard@facebook.com> wr= ote:
Yup, that=92s basically what we do today-= throw an error and don=92t return. But
this is less than ideal.
<= br>
We have discussed that we=92d pro= bably like to return, but with an error
message. This would be in section 5.4.4 of the spec (=93Authorizatio= n server
directs user back to the= client=94) we would like to pass additional
parameters for the error message- something other than user_den= ied, but
which indicates that the= application was just misconfigured.

I guess it depends= on the business requirements that led to callback
URL preregistration. =  Some sites require callback URL registration so
they don't need to= redirect to unknown third-party sites... in which
case redirecting with= an error message doesn't really fix the issue.

Other sites require = callback URL registration for security reasons, in
which case an error m= essage is just fine.

Cheers,
Brian
= --_000_ED81D84D0FB2497688078724954C826Afacebookcom_-- From Bart.bv.Vrancken@alcatel-lucent.be Wed Nov 25 07:49:42 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 245303A684D for ; Wed, 25 Nov 2009 07:49:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bF+d7hYmoJdC for ; Wed, 25 Nov 2009 07:49:41 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id BF3073A6861 for ; Wed, 25 Nov 2009 07:49:40 -0800 (PST) Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.dc-m.alcatel-lucent.com [155.132.6.78]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id nAPFm44x008712 for ; Wed, 25 Nov 2009 16:49:34 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.52]) by FRVELSBHS06.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Nov 2009 16:49:25 +0100 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: Wed, 25 Nov 2009 16:49:25 +0100 Message-ID: <7A6D4815C5E8F74988784FEBD50F2F1E044CFE8B@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <6c0fd2bc0911250628l7a9bc86gdfe15154c2566210@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] Signature crypto Thread-Index: Acpt264rvoc2V/dqRauAu2lrI/NlbQACvd9Q References: <90C41DD21FB7C64BB94121FBBC2E72343785183009@P3PW5EX1MB01.EX1.SECURESERVER.NET><4B0D3698.8070706@cs.tcd.ie><3a880e2c0911250618w358579d9o38b5ad90cb9242af@mail.gmail.com> <6c0fd2bc0911250628l7a9bc86gdfe15154c2566210@mail.gmail.com> From: "Vrancken Bart bv" To: X-OriginalArrivalTime: 25 Nov 2009 15:49:25.0639 (UTC) FILETIME=[DD4FF170:01CA6DE6] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Subject: Re: [OAUTH-WG] Signature crypto X-BeenThere: oauth@ietf.org X-Mailman-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, 25 Nov 2009 15:49:42 -0000 +1 Interoperability is the most important part for a spec like this. = Require that everyone uses 1 specific algorithm and allow other = algorithms. Bart -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf = Of Hubert Le Van Gong Sent: woensdag 25 november 2009 15:29 To: Infinity Linden (Meadhbh Hamrick) Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Signature crypto +1 A mandatory support will surely help interoperability. If we also have the negotiation piece of protocol we had discussed before then we should be fine on that end of things. Hubert On Wed, Nov 25, 2009 at 3:18 PM, Infinity Linden (Meadhbh Hamrick) wrote: > +1 to stephen's comment. > when it comes to algorithm support and selection, i think the = consensus > that's emerged is we should require an algorithm that "looks good" at = the > moment the spec is being drafted, but allow the use of other optional > algorithms. ("looks good" here means that there are no known = successful > attacks against the math of the algorithm and there's a general = consensus > amongst cryptographers that there won't be one in the next 20 years.) > the rationale behind this may have to do with the experience some > implementers had with MOSS / MIME Object Security Services (aka = RFC1848.) > MOSS was specified to address issues people had raised with PEM = (Privacy > Enhanced Mail). The problem with MOSS is that it was near infinitely > flexible and you could create an implementation that strictly adhered = to the > specification, but was non-interoperable if you chose to support a = different > set of optional encipherment algorithms. > so the concern here is that if you allow all hash algorithms to be = optional, > you'll find some outlier who wants to use HAVAL with Rabin Williams to > generate signatures and will sell this solution into the marketplace, = then > go out of business. people who bought the solution won't think = anything's > wrong 'til they try to hook it up to someone else who's using a more > traditional SHA256+RSA or ECDSA solution.=A0a great wailing and = gnashing of > teeth will follow. > but if we REQUIRE that everyone use SHA256 but allow other hash = algorithms, > then we won't have this problem. > -cheers > -meadhbh > -- > =A0 infinity linden (aka meadhbh hamrick) =A0* =A0it's pronounced = "maeve" > =A0 =A0 =A0 =A0 http://wiki.secondlife.com/wiki/User:Infinity_Linden > > > On Wed, Nov 25, 2009 at 05:52, Stephen Farrell = > wrote: >> >> >> Eran Hammer-Lahav wrote: >> > I think we have consensus that the spec should not mandate a = particular >> > hash algorithm. This still leave the issue of assigning algorithms = short >> > names for the purpose of negotiation and declaration. Is there a = registry >> > available for such algorithms we can use or do we need to create a = new one? >> >> Sorry to have missed out on the thread where that was discussed, but >> it'd be odd for an IETF security spec to not mandate some algorithms >> and quite likely to generate comments later in the process if there's >> no well-defined way to ensure interop. Do we have that? >> >> Ta, >> S. >> >> _______________________________________________ >> OAuth mailing 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 leah.culver@gmail.com Wed Nov 25 08:15:56 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 849AC3A6AAA for ; Wed, 25 Nov 2009 08:15:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-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 th4bk0pir2yt for ; Wed, 25 Nov 2009 08:15:55 -0800 (PST) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id 5C05B3A6AA0 for ; Wed, 25 Nov 2009 08:15:55 -0800 (PST) Received: by pwi6 with SMTP id 6so5400319pwi.29 for ; Wed, 25 Nov 2009 08:15:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type; bh=1vEx5VpA+TOWnocqtN6DIfuKL06I6RA5pn8ABbKs9Eo=; b=otXzUyIBb20tdnAL5yvaZRh12Ma/aMF5gkUgLAwmVTmlg2RRUddTumu2w5WK9yE8Ih 90nxMjHmwaSjWZGvjPiuHHNTp6Fn8JdOuzUJ0aPnXIxGKLB8G51AoztCTnZkgh69H1fL eAhjaDh3P7WV2zsDwCRMvD+hW4MnyBFyn18rc= 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; b=uruIY3uROZj3gGWF3EPaBAn2bkDimnRJk7a5Rdx6tAHgZx5IYGBApIpq6Q4XXqPMvx +El7W963mT8FwC/roa3K+kZyehCgS6hvvrMymdWO02F4y2XIaems6jFDJpHqpU5yHL3l Wqk0DcQHGHIQHVbuTXceVx7ltTwmUW4trKZUo= MIME-Version: 1.0 Received: by 10.140.136.19 with SMTP id j19mr427652rvd.187.1259165748095; Wed, 25 Nov 2009 08:15:48 -0800 (PST) In-Reply-To: References: <148C596691F29F4EA6968577BE2CDFAE06A1B9FE@SC-MBXC1.TheFacebook.com> From: Leah Culver Date: Wed, 25 Nov 2009 08:15:28 -0800 Message-ID: <9184e2a80911250815i411a0780kf5a51399cc3b64d7@mail.gmail.com> To: Brent Goldman Content-Type: multipart/alternative; boundary=000e0cd2531a20eccc0479345f3e Cc: Naitik Shah , "oauth@ietf.org" , Luke Shepard Subject: Re: [OAUTH-WG] Facebook, OAuth, and WRAP X-BeenThere: oauth@ietf.org X-Mailman-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, 25 Nov 2009 16:15:56 -0000 --000e0cd2531a20eccc0479345f3e Content-Type: text/plain; charset=ISO-8859-1 On Wed, Nov 25, 2009 at 6:10 AM, Brent Goldman wrote: > > On Nov 24, 2009, at 10:40 PM, Mike Malone wrote: > > > On Tue, Nov 24, 2009 at 10:15 PM, John Panzer > > wrote: > >> On Tue, Nov 24, 2009 at 4:35 PM, Mike Malone > >> wrote: > >>> > >>> On Tue, Nov 24, 2009 at 10:57 AM, David Recordon > >>> wrote: > >>>> > >>>> The largest issue in Facebook moving to OAuth 1.0 (and yes, > >>>> Eran's new > >>>> RFC is awesome) is the increase in the number of HTTP requests that > >>>> developers will need to make in comparison to our current > >>>> authentication > >>>> mechanism. > >>> > >>> The OAuth _flow_ (in a browser) requires a couple additional > >>> requests > >>> compared to Facebook Connect (in a browser). But Facebook Connect is > >>> really a different beast since it relies on the Browser and > >>> Javascript > >>> to magically set cookies cross domain and whatnot. I agree that it's > >>> non-trivial to extend OAuth to cover this use case (we've sort of > >>> done > >>> it at Six Apart and the flow is clunky and complicated). And even if > >>> you figure out how to make the flow work you can't really make > >>> requests purely on the client side without compromising your > >>> consumer > >>> secret. > >>> > >>> That said, as far as I can tell, using OAuth for delegated > >>> communication via an intermediary (a web app or iPhone app, for > >>> example) should be doable for Facebook. The only real differences I > >>> see between OAuth and WRAP for this use case are: > >>> * WRAP requires SSL instead of signing URLs > >> > >> Aside: If an SP specified OAuth PLAINTEXT signature mode, and used > >> https: > >> URLs for its API, would there be any effective difference between > >> OAuth and > >> WRAP for that SP? (Best as I can tell the only difference would be a > >> mandated %26 character in the OAuth blob you pass in to get access, > >> but I > >> may be missing something.) > > > > Yea, they're more or less the same. That's one use case for PLAINTEXT > > OAuth. You still have a "signature" though, it's just the base64'd > > signature base string. > > If they're more or less the same (besides the difference you > mentioned), then why not also create an SSL signature mode which > leaves out the oauth_signature param? If SSL mode is this essentially > the same as WRAP, why not actually make this the bridge between the > two specs? > > +1 since this is easy enough to add to most OAuth libraries. I know (at least) the PHP and Python ones break out the signature step into separate methods so we could just add another one for SSL with no oauth_signature. Hmm... the only thing that might have to change is some of the error messages. Leah --000e0cd2531a20eccc0479345f3e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Nov 25, 2009 at 6:10 AM, Brent G= oldman <brent@fa= cebook.com> wrote:

On Nov 24, 2009, at 10:40 PM, Mike Malone wrote:

> On Tue, Nov 24, 2009 at 10:15 PM, John Panzer <jpanzer@google.com>
> wrote:
>> On Tue, Nov 24, 2009 at 4:35 PM, Mike Malone <mjmalone@gmail.com>
>> wrote:
>>>
>>> On Tue, Nov 24, 2009 at 10:57 AM, David Recordon
>>> <davidrecordo= n@facebook.com> wrote:
>>>>
>>>> The largest issue in Facebook moving to OAuth 1.0 (and yes= ,
>>>> Eran's new
>>>> RFC is awesome) is the increase in the number of HTTP requ= ests that
>>>> developers will need to make in comparison to our current<= br> >>>> authentication
>>>> mechanism.
>>>
>>> The OAuth _flow_ (in a browser) requires a couple additional >>> requests
>>> compared to Facebook Connect (in a browser). But Facebook Conn= ect is
>>> really a different beast since it relies on the Browser and >>> Javascript
>>> to magically set cookies cross domain and whatnot. I agree tha= t it's
>>> non-trivial to extend OAuth to cover this use case (we've = sort of
>>> done
>>> it at Six Apart and the flow is clunky and complicated). And e= ven if
>>> you figure out how to make the flow work you can't really = make
>>> requests purely on the client side without compromising your >>> consumer
>>> secret.
>>>
>>> That said, as far as I can tell, using OAuth for delegated
>>> communication via an intermediary (a web app or iPhone app, fo= r
>>> example) should be doable for Facebook. The only real differen= ces I
>>> see between OAuth and WRAP for this use case are:
>>> =A0* WRAP requires SSL instead of signing URLs
>>
>> Aside: If an SP specified OAuth PLAINTEXT signature mode, and used=
>> https:
>> URLs for its API, would there be any effective difference between<= br> >> OAuth and
>> WRAP for that SP? =A0(Best as I can tell the only difference would= be a
>> mandated %26 character in the OAuth blob you pass in to get access= ,
>> but I
>> may be missing something.)
>
> Yea, they're more or less the same. That's one use case for PL= AINTEXT
> OAuth. You still have a "signature" though, it's just th= e base64'd
> signature base string.

If they're more or less the same (besides the difference yo= u
mentioned), then why not also create an SSL signature mode which
leaves out the oauth_signature param? If SSL mode is this essentially
the same as WRAP, why not actually make this the bridge between the
two specs?


+1 since this is easy enough to add to most OAuth= libraries. I know (at least) the PHP and Python ones break out the signatu= re step into separate methods so we could just add another one for SSL with= no oauth_signature. Hmm... the only thing that might have to change is som= e of the error messages.

Leah
--000e0cd2531a20eccc0479345f3e-- From hannes.tschofenig@nsn.com Wed Nov 25 08:16:29 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42D5828C270 for ; Wed, 25 Nov 2009 08:16:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 AOrJDPohpdQF for ; Wed, 25 Nov 2009 08:16:28 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 858773A6AAA for ; Wed, 25 Nov 2009 08:16:27 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id nAPGGHNk013061 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 25 Nov 2009 17:16:17 +0100 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id nAPGGHnJ002491; Wed, 25 Nov 2009 17:16:17 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Nov 2009 17:16:17 +0100 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, 25 Nov 2009 18:19:45 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4501EE54E2@FIESEXC015.nsn-intra.net> In-Reply-To: <3a880e2c0911250618w358579d9o38b5ad90cb9242af@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] Signature crypto Thread-Index: Acpt2kdUTG1tt6wWTq6qbaiQ5IVy0wADocaQ References: <90C41DD21FB7C64BB94121FBBC2E72343785183009@P3PW5EX1MB01.EX1.SECURESERVER.NET><4B0D3698.8070706@cs.tcd.ie> <3a880e2c0911250618w358579d9o38b5ad90cb9242af@mail.gmail.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Infinity Linden (Meadhbh Hamrick)" , "Stephen Farrell" X-OriginalArrivalTime: 25 Nov 2009 16:16:17.0185 (UTC) FILETIME=[9DDE5910:01CA6DEA] Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Signature crypto X-BeenThere: oauth@ietf.org X-Mailman-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, 25 Nov 2009 16:16:29 -0000 This case is interesting.=20 =20 Until recently I have also thought that one has to specify a mandatory-to-implement algorithm in a security protocol since otherwise interoperability would really suffer. When working in KEYPROV I learned through Russ Housley that this is actually not true.=20 He said: " Some specifications in the security area do not pick a mandatory to implement algorithm. RFC 5280 is one example. Instead the companion specifications tell what algorithm is appropriate for a particular environment.=20 " =20 There are a few reasons why you often cannot agree on a specific algorithm. Examples are different usage scenarios that demand a certain algorithm, certain software packages that may or may not support certain algorithms at a specific point in time, different performance/hardware requirements, IPR concerns, etc. =20 In any case it is likely that the chosen algorithm will get replaced in a few years from now and one does not want to update the specification every time. Hence, having some form of crypto-agility is generally a good idea since you might want to negotiate a set of algorithms anyway and it is quite likely that an algorithm is found that both parties support.=20 =20 Ciao Hannes ________________________________ From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of ext Infinity Linden (Meadhbh Hamrick) Sent: 25 November, 2009 16:19 To: Stephen Farrell Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Signature crypto =09 =09 +1 to stephen's comment.=20 when it comes to algorithm support and selection, i think the consensus that's emerged is we should require an algorithm that "looks good" at the moment the spec is being drafted, but allow the use of other optional algorithms. ("looks good" here means that there are no known successful attacks against the math of the algorithm and there's a general consensus amongst cryptographers that there won't be one in the next 20 years.) the rationale behind this may have to do with the experience some implementers had with MOSS / MIME Object Security Services (aka RFC1848.) MOSS was specified to address issues people had raised with PEM (Privacy Enhanced Mail). The problem with MOSS is that it was near infinitely flexible and you could create an implementation that strictly adhered to the specification, but was non-interoperable if you chose to support a different set of optional encipherment algorithms. so the concern here is that if you allow all hash algorithms to be optional, you'll find some outlier who wants to use HAVAL with Rabin Williams to generate signatures and will sell this solution into the marketplace, then go out of business. people who bought the solution won't think anything's wrong 'til they try to hook it up to someone else who's using a more traditional SHA256+RSA or ECDSA solution. a great wailing and gnashing of teeth will follow. but if we REQUIRE that everyone use SHA256 but allow other hash algorithms, then we won't have this problem. -cheers -meadhbh -- infinity linden (aka meadhbh hamrick) * it's pronounced "maeve" http://wiki.secondlife.com/wiki/User:Infinity_Linden =09 =09 =09 On Wed, Nov 25, 2009 at 05:52, Stephen Farrell wrote: =09 Eran Hammer-Lahav wrote: > I think we have consensus that the spec should not mandate a particular hash algorithm. This still leave the issue of assigning algorithms short names for the purpose of negotiation and declaration. Is there a registry available for such algorithms we can use or do we need to create a new one? =09 =09 Sorry to have missed out on the thread where that was discussed, but it'd be odd for an IETF security spec to not mandate some algorithms and quite likely to generate comments later in the process if there's no well-defined way to ensure interop. Do we have that? =09 Ta, S. =09 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =09 From eran@hueniverse.com Wed Nov 25 08:19:37 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 325F63A6947 for ; Wed, 25 Nov 2009 08:19:37 -0800 (PST) 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 0iBM9vNVB0dM for ; Wed, 25 Nov 2009 08:19:36 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 491A43A6833 for ; Wed, 25 Nov 2009 08:19:36 -0800 (PST) Received: (qmail 6340 invoked from network); 25 Nov 2009 16:19:30 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 25 Nov 2009 16:19:30 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 25 Nov 2009 09:19:30 -0700 From: Eran Hammer-Lahav To: Stephen Farrell Date: Wed, 25 Nov 2009 09:19:40 -0700 Thread-Topic: [OAUTH-WG] Signature crypto Thread-Index: Acpt1oe5OPbwOs5tQVq0LToARcjhHgAFGQhQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343785209782@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343785183009@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B0D3698.8070706@cs.tcd.ie> In-Reply-To: <4B0D3698.8070706@cs.tcd.ie> 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] Signature crypto X-BeenThere: oauth@ietf.org X-Mailman-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, 25 Nov 2009 16:19:37 -0000 Mandating a baseline is still something we don't have consensus on. What I = meant is that we agreed to allow crypto negotiation and therefore need a wa= y to manage the algorithm names somehow. Looks like the IANA registry menti= oned is the way to go. EHL > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Wednesday, November 25, 2009 5:52 AM > To: Eran Hammer-Lahav > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Signature crypto >=20 >=20 >=20 > Eran Hammer-Lahav wrote: > > I think we have consensus that the spec should not mandate a particular > hash algorithm. This still leave the issue of assigning algorithms short = names > for the purpose of negotiation and declaration. Is there a registry avail= able > for such algorithms we can use or do we need to create a new one? >=20 > Sorry to have missed out on the thread where that was discussed, but it'd= be > odd for an IETF security spec to not mandate some algorithms and quite li= kely > to generate comments later in the process if there's no well-defined way = to > ensure interop. Do we have that? >=20 > Ta, > S. From stephen.farrell@cs.tcd.ie Wed Nov 25 08:44:39 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1CE93A6AB5 for ; Wed, 25 Nov 2009 08:44:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AGa3tQf3ydnn for ; Wed, 25 Nov 2009 08:44:39 -0800 (PST) Received: from TX2EHSOBE010.bigfish.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by core3.amsl.com (Postfix) with ESMTP id E73DF3A68F9 for ; Wed, 25 Nov 2009 08:44:38 -0800 (PST) Received: from mail136-tx2-R.bigfish.com (10.9.14.246) by TX2EHSOBE010.bigfish.com (10.9.40.30) with Microsoft SMTP Server id 8.1.240.5; Wed, 25 Nov 2009 16:44:34 +0000 Received: from mail136-tx2 (localhost.localdomain [127.0.0.1]) by mail136-tx2-R.bigfish.com (Postfix) with ESMTP id 08EB43A0607; Wed, 25 Nov 2009 16:44:34 +0000 (UTC) X-SpamScore: -52 X-BigFish: VPS-52(zz542N1432R98dN168aJ9371Pzz1202hzz1033ILz2dh87h6bh61h) X-Spam-TCS-SCL: 0:0 X-FB-DOMAIN-IP-MATCH: fail Received: from mail136-tx2 (localhost.localdomain [127.0.0.1]) by mail136-tx2 (MessageSwitch) id 1259167457164635_26641; Wed, 25 Nov 2009 16:44:17 +0000 (UTC) Received: from TX2EHSMHS024.bigfish.com (unknown [10.9.14.236]) by mail136-tx2.bigfish.com (Postfix) with ESMTP id 4675410E0096; Wed, 25 Nov 2009 16:44:15 +0000 (UTC) Received: from imx2.tcd.ie (134.226.1.156) by TX2EHSMHS024.bigfish.com (10.9.99.124) with Microsoft SMTP Server id 14.0.482.32; Wed, 25 Nov 2009 16:44:13 +0000 Received: from Vams.imx2 (imx2.tcd.ie [134.226.1.156]) by imx2.tcd.ie (Postfix) with SMTP id CAD2A68003; Wed, 25 Nov 2009 16:44:12 +0000 (GMT) Received: from imx2.tcd.ie ([134.226.1.156]) by imx2.tcd.ie ([134.226.1.156]) with SMTP (gateway) id A017B1C7267; Wed, 25 Nov 2009 16:44:12 +0000 Received: from [134.226.36.180] (sfarrell.dsg.cs.tcd.ie [134.226.36.180]) by imx2.tcd.ie (Postfix) with ESMTP id ACE6768003; Wed, 25 Nov 2009 16:44:12 +0000 (GMT) Message-ID: <4B0D5EE1.9000309@cs.tcd.ie> Date: Wed, 25 Nov 2009 16:44:17 +0000 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.23 (X11/20090812) MIME-Version: 1.0 To: Eran Hammer-Lahav References: <90C41DD21FB7C64BB94121FBBC2E72343785183009@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B0D3698.8070706@cs.tcd.ie> <90C41DD21FB7C64BB94121FBBC2E72343785209782@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343785209782@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-AntiVirus-Status: MessageID = A117B1C7267 X-AntiVirus-Status: Host: imx2.tcd.ie X-AntiVirus-Status: Action Taken: X-AntiVirus-Status: NONE X-AntiVirus-Status: Checked by TCD Vexira. (version=1.60.2 VDF=10.113.28) X-Reverse-DNS: imx2.tcd.ie Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Signature crypto X-BeenThere: oauth@ietf.org X-Mailman-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, 25 Nov 2009 16:44:39 -0000 Eran Hammer-Lahav wrote: > Mandating a baseline is still something we don't have consensus on. Personally I reckon that that'll be required in the end. > What I meant is that we agreed to allow crypto negotiation and therefore need a way to manage the algorithm names somehow. Looks like the IANA registry mentioned is the way to go. Sounds reasonable if all you need to negotiate are hash algorithm names. Is that the case? I also note that the update rule for that registry is fairly strict - it requires a standards track RFC that UPDATEs or OBSOLETEs RFC3279 so if folks want to use algorithms other than those already listed, it might make more sense to start a new registry with a different update rule. I would hope though that there's no need for hash functions other than those listed (until the NIST competition is done at least and I expect that 3279 will be UPDATEd after that). S. > > EHL > >> -----Original Message----- >> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] >> Sent: Wednesday, November 25, 2009 5:52 AM >> To: Eran Hammer-Lahav >> Cc: OAuth WG (oauth@ietf.org) >> Subject: Re: [OAUTH-WG] Signature crypto >> >> >> >> Eran Hammer-Lahav wrote: >>> I think we have consensus that the spec should not mandate a particular >> hash algorithm. This still leave the issue of assigning algorithms short names >> for the purpose of negotiation and declaration. Is there a registry available >> for such algorithms we can use or do we need to create a new one? >> >> Sorry to have missed out on the thread where that was discussed, but it'd be >> odd for an IETF security spec to not mandate some algorithms and quite likely >> to generate comments later in the process if there's no well-defined way to >> ensure interop. Do we have that? >> >> Ta, >> S. > > From stephen.farrell@cs.tcd.ie Wed Nov 25 08:57:31 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 818D528C14E for ; Wed, 25 Nov 2009 08:57:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OAQ8RpNHAyp5 for ; Wed, 25 Nov 2009 08:57:30 -0800 (PST) Received: from TX2EHSOBE010.bigfish.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by core3.amsl.com (Postfix) with ESMTP id 7286428C140 for ; Wed, 25 Nov 2009 08:57:30 -0800 (PST) Received: from mail17-tx2-R.bigfish.com (10.9.14.249) by TX2EHSOBE010.bigfish.com (10.9.40.30) with Microsoft SMTP Server id 8.1.240.5; Wed, 25 Nov 2009 16:57:25 +0000 Received: from mail17-tx2 (localhost.localdomain [127.0.0.1]) by mail17-tx2-R.bigfish.com (Postfix) with ESMTP id 5414BA68606; Wed, 25 Nov 2009 16:57:25 +0000 (UTC) X-SpamScore: -48 X-BigFish: VPS-48(zz14e0P1432R9370J98dN168aJzz1202hzz1033ILz2dh87h6bh61h) X-Spam-TCS-SCL: 0:0 X-FB-DOMAIN-IP-MATCH: fail Received: from mail17-tx2 (localhost.localdomain [127.0.0.1]) by mail17-tx2 (MessageSwitch) id 1259168198838984_31347; Wed, 25 Nov 2009 16:56:38 +0000 (UTC) Received: from TX2EHSMHS045.bigfish.com (unknown [10.9.14.249]) by mail17-tx2.bigfish.com (Postfix) with ESMTP id 96C4415D8084; Wed, 25 Nov 2009 16:56:37 +0000 (UTC) Received: from imx2.tcd.ie (134.226.1.156) by TX2EHSMHS045.bigfish.com (10.9.99.145) with Microsoft SMTP Server id 14.0.482.32; Wed, 25 Nov 2009 16:56:35 +0000 Received: from Vams.imx2 (imx2.tcd.ie [134.226.1.156]) by imx2.tcd.ie (Postfix) with SMTP id 156C668006; Wed, 25 Nov 2009 16:56:35 +0000 (GMT) Received: from imx2.tcd.ie ([134.226.1.156]) by imx2.tcd.ie ([134.226.1.156]) with SMTP (gateway) id A01CC605D8C; Wed, 25 Nov 2009 16:56:35 +0000 Received: from [134.226.36.180] (sfarrell.dsg.cs.tcd.ie [134.226.36.180]) by imx2.tcd.ie (Postfix) with ESMTP id E6C0A68003; Wed, 25 Nov 2009 16:56:34 +0000 (GMT) Message-ID: <4B0D61C8.6070408@cs.tcd.ie> Date: Wed, 25 Nov 2009 16:56:40 +0000 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.23 (X11/20090812) MIME-Version: 1.0 To: "Tschofenig, Hannes (NSN - FI/Espoo)" References: <90C41DD21FB7C64BB94121FBBC2E72343785183009@P3PW5EX1MB01.EX1.SECURESERVER.NET><4B0D3698.8070706@cs.tcd.ie> <3a880e2c0911250618w358579d9o38b5ad90cb9242af@mail.gmail.com> <3D3C75174CB95F42AD6BCC56E5555B4501EE54E2@FIESEXC015.nsn-intra.net> In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B4501EE54E2@FIESEXC015.nsn-intra.net> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-AntiVirus-Status: MessageID = A11CC605D8C X-AntiVirus-Status: Host: imx2.tcd.ie X-AntiVirus-Status: Action Taken: X-AntiVirus-Status: NONE X-AntiVirus-Status: Checked by TCD Vexira. (version=1.60.2 VDF=10.113.28) X-Reverse-DNS: imx2.tcd.ie Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Signature crypto X-BeenThere: oauth@ietf.org X-Mailman-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, 25 Nov 2009 16:57:31 -0000 5280 is a special case since its a profile that gets referenced by other RFCs so there's always a 2nd RFC involved there. While one could imagine OAuth having a separate RFC that just specifies a current algorithm set, I'm not sure that'd be best...it might, but I'd suspect not. My reason for that is that I'd expect that we'd rev. something else in the protocol about as often as (or more often than) we'd change the mandatory to implement algorithm. But I guess we'll see. S. Tschofenig, Hannes (NSN - FI/Espoo) wrote: > This case is interesting. > > Until recently I have also thought that one has to specify a > mandatory-to-implement algorithm in a security protocol since otherwise > interoperability would really suffer. When working in KEYPROV I learned > through Russ Housley that this is actually not true. > > He said: > " > Some specifications in the security area do not pick a mandatory to > implement algorithm. RFC 5280 is one example. Instead the companion > specifications tell what algorithm is appropriate for a particular > environment. > " > > There are a few reasons why you often cannot agree on a specific > algorithm. Examples are different usage scenarios that demand a certain > algorithm, certain software packages that may or may not support certain > algorithms at a specific point in time, different performance/hardware > requirements, IPR concerns, etc. > > In any case it is likely that the chosen algorithm will get replaced in > a few years from now and one does not want to update the specification > every time. Hence, having some form of crypto-agility is generally a > good idea since you might want to negotiate a set of algorithms anyway > and it is quite likely that an algorithm is found that both parties > support. > > Ciao > Hannes > > > > ________________________________ > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > Behalf Of ext Infinity Linden (Meadhbh Hamrick) > Sent: 25 November, 2009 16:19 > To: Stephen Farrell > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Signature crypto > > > +1 to stephen's comment. > > when it comes to algorithm support and selection, i think the > consensus that's emerged is we should require an algorithm that "looks > good" at the moment the spec is being drafted, but allow the use of > other optional algorithms. ("looks good" here means that there are no > known successful attacks against the math of the algorithm and there's a > general consensus amongst cryptographers that there won't be one in the > next 20 years.) > > the rationale behind this may have to do with the experience > some implementers had with MOSS / MIME Object Security Services (aka > RFC1848.) MOSS was specified to address issues people had raised with > PEM (Privacy Enhanced Mail). The problem with MOSS is that it was near > infinitely flexible and you could create an implementation that strictly > adhered to the specification, but was non-interoperable if you chose to > support a different set of optional encipherment algorithms. > > so the concern here is that if you allow all hash algorithms to > be optional, you'll find some outlier who wants to use HAVAL with Rabin > Williams to generate signatures and will sell this solution into the > marketplace, then go out of business. people who bought the solution > won't think anything's wrong 'til they try to hook it up to someone else > who's using a more traditional SHA256+RSA or ECDSA solution. a great > wailing and gnashing of teeth will follow. > > but if we REQUIRE that everyone use SHA256 but allow other hash > algorithms, then we won't have this problem. > > -cheers > -meadhbh > > -- > infinity linden (aka meadhbh hamrick) * it's pronounced > "maeve" > http://wiki.secondlife.com/wiki/User:Infinity_Linden > > > > On Wed, Nov 25, 2009 at 05:52, Stephen Farrell > wrote: > > > > > Eran Hammer-Lahav wrote: > > I think we have consensus that the spec should not > mandate a particular hash algorithm. This still leave the issue of > assigning algorithms short names for the purpose of negotiation and > declaration. Is there a registry available for such algorithms we can > use or do we need to create a new one? > > > Sorry to have missed out on the thread where that was > discussed, but > it'd be odd for an IETF security spec to not mandate > some algorithms > and quite likely to generate comments later in the > process if there's > no well-defined way to ensure interop. Do we have that? > > Ta, > S. > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > From eran@hueniverse.com Wed Nov 25 09:52:26 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCB8D3A6AFB for ; Wed, 25 Nov 2009 09:52:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.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 I0YrOFZyDpTA for ; Wed, 25 Nov 2009 09:52:26 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id EF9873A6AE7 for ; Wed, 25 Nov 2009 09:52:25 -0800 (PST) Received: (qmail 17223 invoked from network); 25 Nov 2009 17:52:21 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 25 Nov 2009 17:52:21 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 25 Nov 2009 10:52:12 -0700 From: Eran Hammer-Lahav To: Stephen Farrell Date: Wed, 25 Nov 2009 10:52:22 -0700 Thread-Topic: [OAUTH-WG] Signature crypto Thread-Index: Acpt7pSuYnX/bLa8QDafocxOnS4STwACWuuw Message-ID: <90C41DD21FB7C64BB94121FBBC2E723437852097FC@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343785183009@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B0D3698.8070706@cs.tcd.ie> <90C41DD21FB7C64BB94121FBBC2E72343785209782@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B0D5EE1.9000309@cs.tcd.ie> In-Reply-To: <4B0D5EE1.9000309@cs.tcd.ie> 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] Signature crypto X-BeenThere: oauth@ietf.org X-Mailman-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, 25 Nov 2009 17:52:26 -0000 > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Wednesday, November 25, 2009 8:44 AM > To: Eran Hammer-Lahav > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Signature crypto >=20 >=20 >=20 > Eran Hammer-Lahav wrote: > > Mandating a baseline is still something we don't have consensus on. >=20 > Personally I reckon that that'll be required in the end. >=20 > > What I meant is that we agreed to allow crypto negotiation and > therefore need a way to manage the algorithm names somehow. Looks like > the IANA registry mentioned is the way to go. >=20 > Sounds reasonable if all you need to negotiate are hash algorithm names. = Is > that the case? Yes. > I also note that the update rule for that registry is fairly strict - it = requires a > standards track RFC that UPDATEs or OBSOLETEs RFC3279 so if folks want to > use algorithms other than those already listed, it might make more sense = to > start a new registry with a different update rule. I would hope though th= at > there's no need for hash functions other than those listed (until the NIS= T > competition is done at least and I expect that 3279 will be UPDATEd after > that). >=20 > S. >=20 >=20 >=20 > > > > EHL > > > >> -----Original Message----- > >> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > >> Sent: Wednesday, November 25, 2009 5:52 AM > >> To: Eran Hammer-Lahav > >> Cc: OAuth WG (oauth@ietf.org) > >> Subject: Re: [OAUTH-WG] Signature crypto > >> > >> > >> > >> Eran Hammer-Lahav wrote: > >>> I think we have consensus that the spec should not mandate a > >>> particular > >> hash algorithm. This still leave the issue of assigning algorithms > >> short names for the purpose of negotiation and declaration. Is there > >> a registry available for such algorithms we can use or do we need to > create a new one? > >> > >> Sorry to have missed out on the thread where that was discussed, but > >> it'd be odd for an IETF security spec to not mandate some algorithms > >> and quite likely to generate comments later in the process if there's > >> no well-defined way to ensure interop. Do we have that? > >> > >> Ta, > >> S. > > > > From infinity@lindenlab.com Wed Nov 25 10:24:37 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE0243A6914 for ; Wed, 25 Nov 2009 10:24:37 -0800 (PST) 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 KLfrYqBrLktU for ; Wed, 25 Nov 2009 10:24:36 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by core3.amsl.com (Postfix) with ESMTP id 5BBAE3A68BD for ; Wed, 25 Nov 2009 10:24:35 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id e12so1789846fga.13 for ; Wed, 25 Nov 2009 10:24:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.239.139.84 with SMTP id s20mr851016hbs.110.1259173466331; Wed, 25 Nov 2009 10:24:26 -0800 (PST) In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B4501EE54E2@FIESEXC015.nsn-intra.net> References: <90C41DD21FB7C64BB94121FBBC2E72343785183009@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B0D3698.8070706@cs.tcd.ie> <3a880e2c0911250618w358579d9o38b5ad90cb9242af@mail.gmail.com> <3D3C75174CB95F42AD6BCC56E5555B4501EE54E2@FIESEXC015.nsn-intra.net> From: "Infinity Linden (Meadhbh Hamrick)" Date: Wed, 25 Nov 2009 10:24:05 -0800 Message-ID: <3a880e2c0911251024g1310d64fld7adf54951433d30@mail.gmail.com> To: "Tschofenig, Hannes (NSN - FI/Espoo)" Content-Type: multipart/alternative; boundary=001485f6c7c22bda180479362b28 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Signature crypto X-BeenThere: oauth@ietf.org X-Mailman-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, 25 Nov 2009 18:24:38 -0000 --001485f6c7c22bda180479362b28 Content-Type: text/plain; charset=ISO-8859-1 selecting a required to implement algorithm is independent of extensibility. it is always possible to get both. and yes, you can separate required algorithms from core functionality. so if RFC XXX0 described OAuth mechanisms, and then RFCXXX1 described SHA1+RSA as being required while RFCXXX2 described ECDSA as being required, you could get people talking about supporting "RFCXXX1" or "RFCXXX2" instead of talking about supporting RFCXXX0. RTP did a pretty good job of describing core concepts and features in RFC3550, then added a/v in RFC3551. Secure RTP (or SRTP) was defined in RFC3771, and mandated a particular set of algorithms. unfortunately, some of these algorithms were difficult to implement on some handsets. AES, for instance seemed to eat up a lot of CPU time on some lower end devices. there was a second scheme that used a lighter-weight algorithm, but i don't think it ever saw the light of day. so the moral of the story is that if you don't mandate a required algorithm, you'll get MOSS. you _can_ separate the mechanism from the required algorithm, and put the two in different RFCs. but it doesn't eliminate all risk of non-interoperability, because as soon as you define your first "profile" RFC, you're going to find that someone want's to use a second set of algorithms. experience tends to show that only one of these will be predominant. at that point, people lose interest in the non-predominant profile and back the one which is perceived to have more external support. so at this point the only thing that separating the algorithms out buys you is you get to defer selection of the "required" algorithm spec. RFC5280 is probably okay with not specifying a required algorithm because SHA1+RSA is a de facto standard in this community because Verisign dominated the industry for so long and only supported SHA1+RSA and *shudder* MD5+RSA. this doesn't affect organizations that do like using commercial CA's (like the federal bridge CA) because they already have large organizations (like NIST, AMX, etc.) describing a collection of acceptable algorithms. in those communities, vendors generally don't talk about RFC5280 compatibility, but rather "suitability for use with the federal bridge" or "suitability for use with the automotive information exchange." OAuth does _not_ have a pre-existing group which mandates algorithms. thus, i think that NOT requiring an algorithm somewhere will lead to a bit of confusion amongst people wishing to implement the spec. still, it's not like the sky's falling. but i would offer the predictions: a. if we don't have a required algorithm somewhere, you will find that OAuth users will select whatever algorithm set they like. many times, they will choose algorithms that other people don't use. when they start to want to interoperate with these people, there will be a mild gnashing of teeth as the two parties make a pairwise agreement over which algorithm they'll use. it's not the end of the world, but this sort of pairwise algorithm negotiation will occur all over the place. b. if you put required algorithms in a second RFC, distinct from the draft defining OAuth mechanisms, you will quickly see someone write an additional draft with a new set of required algorithms. you'll then have a mild amount of confusion over which one should be supported, possibly ending when everyone decides to support both. in this case, you might as well have defined both as being REQUIRED. c. if chaos looms for longer than it takes for a FLOSS developer to reasonably apply support to PHP, Python/WSGI and Java, then you'll see whatever algorithm choice that developer makes become the de facto standard (because it's available everywhere.) if we're unlucky, that developer will make their algorithm choice based on the 1996 edition of Applied Crypto which does not have suitable exhortations for developers to eschew MD5. so... it's probably less about it being absolutely necessary to select a required algorithm for the spec, and more about what kind of chaos can we live with? -cheers -meadhbh -- infinity linden (aka meadhbh hamrick) * it's pronounced "maeve" http://wiki.secondlife.com/wiki/User:Infinity_Linden On Wed, Nov 25, 2009 at 08:19, Tschofenig, Hannes (NSN - FI/Espoo) < hannes.tschofenig@nsn.com> wrote: > This case is interesting. > > Until recently I have also thought that one has to specify a > mandatory-to-implement algorithm in a security protocol since otherwise > interoperability would really suffer. When working in KEYPROV I learned > through Russ Housley that this is actually not true. > > He said: > " > Some specifications in the security area do not pick a mandatory to > implement algorithm. RFC 5280 is one example. Instead the companion > specifications tell what algorithm is appropriate for a particular > environment. > " > > There are a few reasons why you often cannot agree on a specific > algorithm. Examples are different usage scenarios that demand a certain > algorithm, certain software packages that may or may not support certain > algorithms at a specific point in time, different performance/hardware > requirements, IPR concerns, etc. > > In any case it is likely that the chosen algorithm will get replaced in > a few years from now and one does not want to update the specification > every time. Hence, having some form of crypto-agility is generally a > good idea since you might want to negotiate a set of algorithms anyway > and it is quite likely that an algorithm is found that both parties > support. > > Ciao > Hannes > > > > ________________________________ > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > Behalf Of ext Infinity Linden (Meadhbh Hamrick) > Sent: 25 November, 2009 16:19 > To: Stephen Farrell > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Signature crypto > > > +1 to stephen's comment. > > when it comes to algorithm support and selection, i think the > consensus that's emerged is we should require an algorithm that "looks > good" at the moment the spec is being drafted, but allow the use of > other optional algorithms. ("looks good" here means that there are no > known successful attacks against the math of the algorithm and there's a > general consensus amongst cryptographers that there won't be one in the > next 20 years.) > > the rationale behind this may have to do with the experience > some implementers had with MOSS / MIME Object Security Services (aka > RFC1848.) MOSS was specified to address issues people had raised with > PEM (Privacy Enhanced Mail). The problem with MOSS is that it was near > infinitely flexible and you could create an implementation that strictly > adhered to the specification, but was non-interoperable if you chose to > support a different set of optional encipherment algorithms. > > so the concern here is that if you allow all hash algorithms to > be optional, you'll find some outlier who wants to use HAVAL with Rabin > Williams to generate signatures and will sell this solution into the > marketplace, then go out of business. people who bought the solution > won't think anything's wrong 'til they try to hook it up to someone else > who's using a more traditional SHA256+RSA or ECDSA solution. a great > wailing and gnashing of teeth will follow. > > but if we REQUIRE that everyone use SHA256 but allow other hash > algorithms, then we won't have this problem. > > -cheers > -meadhbh > > -- > infinity linden (aka meadhbh hamrick) * it's pronounced > "maeve" > http://wiki.secondlife.com/wiki/User:Infinity_Linden > > > > On Wed, Nov 25, 2009 at 05:52, Stephen Farrell > wrote: > > > > > Eran Hammer-Lahav wrote: > > I think we have consensus that the spec should not > mandate a particular hash algorithm. This still leave the issue of > assigning algorithms short names for the purpose of negotiation and > declaration. Is there a registry available for such algorithms we can > use or do we need to create a new one? > > > Sorry to have missed out on the thread where that was > discussed, but > it'd be odd for an IETF security spec to not mandate > some algorithms > and quite likely to generate comments later in the > process if there's > no well-defined way to ensure interop. Do we have that? > > Ta, > S. > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > --001485f6c7c22bda180479362b28 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable selecting a required to implement algorithm is independent of extensibility= . it is always possible to get both.

and yes, you can se= parate required algorithms from core functionality. so if RFC XXX0 describe= d OAuth mechanisms, and then RFCXXX1 described SHA1+RSA as being required w= hile RFCXXX2 described ECDSA as being required, you could get people talkin= g about supporting "RFCXXX1" or "RFCXXX2" instead of ta= lking about supporting RFCXXX0.

RTP did a pretty good job of describing core concepts a= nd features in RFC3550, then added a/v in RFC3551. Secure RTP (or SRTP) was= defined in RFC3771, and mandated a particular set of algorithms. unfortuna= tely, some of these algorithms were difficult to implement on some handsets= . AES, for instance seemed to eat up a lot of CPU time on some lower end de= vices. there was a second scheme that used a lighter-weight algorithm, but = i don't think it ever saw the light of day.

so the moral of the story is that if you don't mand= ate a required algorithm, you'll get MOSS.

you= _can_ separate the mechanism from the required algorithm, and put the two = in different RFCs. but it doesn't eliminate all risk of non-interoperab= ility, because as soon as you define your first "profile" RFC, yo= u're going to find that someone want's to use a second set of algor= ithms. experience tends to show that only one of these will be predominant.= at that point, people lose interest in the non-predominant profile and bac= k the one which is perceived to have more external support. so at this poin= t the only thing that separating the algorithms out buys you is you get to = defer selection of the "required" algorithm spec.

RFC5280 is probably okay with not specifying a required= algorithm because SHA1+RSA is a de facto standard in this community becaus= e Verisign dominated the industry for so long and only supported SHA1+RSA a= nd *shudder* MD5+RSA.

this doesn't affect organizations that do like usin= g commercial CA's (like the federal bridge CA) because they already hav= e large organizations (like NIST, AMX, etc.) describing a collection of acc= eptable algorithms. in those communities, vendors generally don't talk = about RFC5280 compatibility, but rather "suitability for use with the = federal bridge" or "suitability for use with the automotive infor= mation exchange."

OAuth does _not_ have a pre-existing group which mandat= es algorithms. thus, i think that NOT requiring an algorithm somewhere will= lead to a bit of confusion amongst people wishing to implement the spec.

still, it's not like the sky's falling. but i w= ould offer the predictions:

a. if we don't hav= e a required algorithm somewhere, you will find that OAuth users will selec= t whatever algorithm set they like. many times, they will choose algorithms= that other people don't use. when they start to want to interoperate w= ith these people, there will be a mild gnashing of teeth as the two parties= make a pairwise agreement over which algorithm they'll use. it's n= ot the end of the world, but this sort of pairwise algorithm negotiation wi= ll occur all over the place.

b. if you put required algorithms in a second RFC, dist= inct from the draft defining OAuth mechanisms, you will quickly see someone= write an additional draft with a new set of required algorithms. you'l= l then have a mild amount of confusion over which one should be supported, = possibly ending when everyone decides to support both. in this case, you mi= ght as well have defined both as being REQUIRED.

c. if chaos looms for longer than it takes for a FLOSS = developer to reasonably apply support to PHP, Python/WSGI and Java, then yo= u'll see whatever algorithm choice that developer makes become the de f= acto standard (because it's available everywhere.) if we're unlucky= , that developer will make their algorithm choice based on the 1996 edition= of Applied Crypto which does not have suitable exhortations for developers= to eschew MD5.

so... it's probably less about it being absolutely = necessary to select a required algorithm for the spec, and more about what = kind of chaos can we live with?

-cheers
-meadhbh
--
=A0 infinity linden (aka meadhbh hamrick) =A0* = =A0it's pronounced "maeve"
=A0 =A0 =A0 =A0 http://wiki.secondlife.com/wiki/User:Infinity_Lind= en


On Wed, Nov 25, 2009 at 08:19, Tschofeni= g, Hannes (NSN - FI/Espoo) <hannes.tschofenig@nsn.com> wrote:
This case is interesting.

Until recently I have also thought that one has to specify a
mandatory-to-implement algorithm in a security protocol since otherwise
interoperability would really suffer. When working in KEYPROV I learned
through Russ Housley that this is actually not true.

He said:
"
Some specifications in the security area do not pick a mandatory to
implement algorithm. =A0RFC 5280 is one example. =A0Instead the companion specifications tell what algorithm is appropriate for a particular
environment.
"

There are a few reasons why you often cannot agree on a specific
algorithm. Examples are different usage scenarios that demand a certain
algorithm, certain software packages that may or may not support certain algorithms at a specific point in time, different performance/hardware
requirements, IPR concerns, etc.

In any case it is likely that the chosen algorithm will get replaced in
a few years from now and one does not want to update the specification
every time. Hence, having some form of crypto-agility is generally a
good idea since you might want to negotiate a set of algorithms anyway
and it is quite likely that an algorithm is found that both parties
support.

Ciao
Hannes



________________________________

=A0 =A0 =A0 =A0From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
Behalf Of ext Infinity Linden (Meadhbh Hamrick)
=A0 =A0 =A0 =A0Sent: 25 November, 2009 16:19
=A0 =A0 =A0 =A0To: Stephen Farrell
=A0 =A0 =A0 =A0Cc: OAuth WG (oauth@ietf.org)
=A0 =A0 =A0 =A0Subject: Re: [OAUTH-WG] Signature crypto


=A0 =A0 =A0 =A0+1 to stephen's comment.

=A0 =A0 =A0 =A0when it comes to algorithm support and selection, i think t= he
consensus that's emerged is we should require an algorithm that "l= ooks
good" at the moment the spec is being drafted, but allow the use of other optional algorithms. ("looks good" here means that there ar= e no
known successful attacks against the math of the algorithm and there's = a
general consensus amongst cryptographers that there won't be one in the=
next 20 years.)

=A0 =A0 =A0 =A0the rationale behind this may have to do with the experienc= e
some implementers had with MOSS / MIME Object Security Services (aka
RFC1848.) MOSS was specified to address issues people had raised with
PEM (Privacy Enhanced Mail). The problem with MOSS is that it was near
infinitely flexible and you could create an implementation that strictly adhered to the specification, but was non-interoperable if you chose to
support a different set of optional encipherment algorithms.

=A0 =A0 =A0 =A0so the concern here is that if you allow all hash algorithm= s to
be optional, you'll find some outlier who wants to use HAVAL with Rabin=
Williams to generate signatures and will sell this solution into the
marketplace, then go out of business. people who bought the solution
won't think anything's wrong 'til they try to hook it up to som= eone else
who's using a more traditional SHA256+RSA or ECDSA solution. a great wailing and gnashing of teeth will follow.

=A0 =A0 =A0 =A0but if we REQUIRE that everyone use SHA256 but allow other = hash
algorithms, then we won't have this problem.

=A0 =A0 =A0 =A0-cheers
=A0 =A0 =A0 =A0-meadhbh

=A0 =A0 =A0 =A0--
=A0 =A0 =A0 =A0 =A0infinity linden (aka meadhbh hamrick) =A0* =A0it's = pronounced
"maeve"
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0http://wiki.secondlife.com/wiki/Use= r:Infinity_Linden



=A0 =A0 =A0 =A0On Wed, Nov 25, 2009 at 05:52, Stephen Farrell
<stephen.= farrell@cs.tcd.ie> wrote:




=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Eran Hammer-Lahav wrote:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> I think we have consensus that the spe= c should not
mandate a particular hash algorithm. This still leave the issue of
assigning algorithms short names for the purpose of negotiation and
declaration. Is there a registry available for such algorithms we can
use or do we need to create a new one?


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Sorry to have missed out on the thread wher= e that was
discussed, but
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0it'd be odd for an IETF security spec t= o not mandate
some algorithms
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0and quite likely to generate comments later= in the
process if there's
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0no well-defined way to ensure interop. Do w= e have that?

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Ta,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0S.


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0___________________________________________= ____
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0OAuth mailing list
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0OAuth@ietf.org
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0https://www.ietf.org/mailman/listinfo/oauth<= /a>




--001485f6c7c22bda180479362b28-- From john@jkemp.net Wed Nov 25 11:01:12 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A7F83A6859 for ; Wed, 25 Nov 2009 11:01:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 ly9TFHB0RzyJ for ; Wed, 25 Nov 2009 11:01:11 -0800 (PST) Received: from outbound-mail-159.bluehost.com (outbound-mail-159.bluehost.com [67.222.39.39]) by core3.amsl.com (Postfix) with SMTP id 0D1D43A67A2 for ; Wed, 25 Nov 2009 11:01:11 -0800 (PST) Received: (qmail 18717 invoked by uid 0); 25 Nov 2009 19:01:06 -0000 Received: from unknown (HELO box320.bluehost.com) (69.89.31.120) by outboundproxy5.bluehost.com with SMTP; 25 Nov 2009 19:01:06 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=jkemp.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=hVoOwiDSdTg+jrHF7rh1wuqsjJQ6em8Y0cYuCWxkU5Jur+8lYwNSVa1+I+lvPiyRUYIWvjrqhY+0PbcIhWwmt30alxU8zC4694gMlFVrQ4QK6w/719DwEUSeyFHcNzP4; Received: from cpe-69-205-56-47.nycap.res.rr.com ([69.205.56.47] helo=[192.168.1.110]) by box320.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NDN6v-0003Bs-GR; Wed, 25 Nov 2009 12:01:05 -0700 Message-ID: <4B0D7EF0.5010002@jkemp.net> Date: Wed, 25 Nov 2009 14:01:04 -0500 From: John Kemp User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Infinity Linden (Meadhbh Hamrick)" References: <90C41DD21FB7C64BB94121FBBC2E72343785183009@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B0D3698.8070706@cs.tcd.ie> <3a880e2c0911250618w358579d9o38b5ad90cb9242af@mail.gmail.com> <3D3C75174CB95F42AD6BCC56E5555B4501EE54E2@FIESEXC015.nsn-intra.net> <3a880e2c0911251024g1310d64fld7adf54951433d30@mail.gmail.com> In-Reply-To: <3a880e2c0911251024g1310d64fld7adf54951433d30@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {1122:box320.bluehost.com:jkempnet:jkemp.net} {sentby:smtp auth 69.205.56.47 authed with john+jkemp.net} Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , oauth@ietf.org Subject: Re: [OAUTH-WG] Signature crypto X-BeenThere: oauth@ietf.org X-Mailman-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, 25 Nov 2009 19:01:12 -0000 Infinity Linden (Meadhbh Hamrick) wrote: [...] > > so the moral of the story is that if you don't mandate a required > algorithm, you'll get MOSS. And is that, in practice, a problem for anyone? [...] > a. if we don't have a required algorithm somewhere, you will find that > OAuth users will select whatever algorithm set they like. many times, > they will choose algorithms that other people don't use. when they start > to want to interoperate with these people, there will be a mild gnashing > of teeth as the two parties make a pairwise agreement over which > algorithm they'll use. it's not the end of the world, but this sort of > pairwise algorithm negotiation will occur all over the place. > > b. if you put required algorithms in a second RFC, distinct from the > draft defining OAuth mechanisms, you will quickly see someone write an > additional draft with a new set of required algorithms. you'll then have > a mild amount of confusion over which one should be supported, possibly > ending when everyone decides to support both. in this case, you might as > well have defined both as being REQUIRED. > > c. if chaos looms for longer than it takes for a FLOSS developer to > reasonably apply support to PHP, Python/WSGI and Java, then you'll see > whatever algorithm choice that developer makes become the de facto > standard (because it's available everywhere.) if we're unlucky, that > developer will make their algorithm choice based on the 1996 edition of > Applied Crypto which does not have suitable exhortations for developers > to eschew MD5. > > so... it's probably less about it being absolutely necessary to select a > required algorithm for the spec, and more about what kind of chaos can > we live with? Yes, I'd say that might even be roughly the choice but put it in different terms: What kind of interoperability do we want? If an implementation is forced to implement a particular hash algorithm in order to be "compliant" with the specification when it won't in practice use that algorithm, I don't see that as very useful. Either implementors will say their implementation is compliant, or they'll say that their implementation is not OAuth (or RFCXXXX). How does either of those things help anyone? As Hannes noted, if we require a specific hash algorithm then every time we need to change the MTI algorithm(s) we also need to update the specification. In any case, I wouldn't really call it "chaos" just because there are multiple OSS implementations. I hope that people will develop tools that work for them. And I suspect that the most important parts of OAuth to standardize on are a) the protocol itself, b) the HTTP authentication mechanism and c) a method of negotiating the relevant twiddly bits, as necessary (and where it should be noted that "no signature at all" is potentially an acceptable signature algorithm). - johnk From beaton@google.com Wed Nov 25 11:07:41 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B6083A68E7 for ; Wed, 25 Nov 2009 11:07:41 -0800 (PST) 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 nUzwZ+9koEmZ for ; Wed, 25 Nov 2009 11:07:40 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 0219D3A6875 for ; Wed, 25 Nov 2009 11:07:39 -0800 (PST) Received: from zps75.corp.google.com (zps75.corp.google.com [172.25.146.75]) by smtp-out.google.com with ESMTP id nAPJ7VT4005855 for ; Wed, 25 Nov 2009 19:07:31 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1259176052; bh=M3CJAeMW00nSQuCCj/mJP4ZR/eQ=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=al6J2KMjhXigPiX+07WRJUShPU+KZ1qq8m0PsuX8R9yPANRX1gDakb0P5H4U52PR0 D3W+4jtILdSpl82xOtWrw== 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=noRJsUT+76VFZn5z6QDyfDuXPA6oJBa+g7UskIjCfK/Is/PegZigfWyJBTATv7G+u LnNMSnzqTof3ZQlqGHIGw== Received: from pxi34 (pxi34.prod.google.com [10.243.27.34]) by zps75.corp.google.com with ESMTP id nAPJ72bo021710 for ; Wed, 25 Nov 2009 11:07:29 -0800 Received: by pxi34 with SMTP id 34so1383pxi.8 for ; Wed, 25 Nov 2009 11:07:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.136.21 with SMTP id j21mr481712rvd.184.1259176048037; Wed, 25 Nov 2009 11:07:28 -0800 (PST) In-Reply-To: <4B0D7EF0.5010002@jkemp.net> References: <90C41DD21FB7C64BB94121FBBC2E72343785183009@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B0D3698.8070706@cs.tcd.ie> <3a880e2c0911250618w358579d9o38b5ad90cb9242af@mail.gmail.com> <3D3C75174CB95F42AD6BCC56E5555B4501EE54E2@FIESEXC015.nsn-intra.net> <3a880e2c0911251024g1310d64fld7adf54951433d30@mail.gmail.com> <4B0D7EF0.5010002@jkemp.net> Date: Wed, 25 Nov 2009 11:07:28 -0800 Message-ID: From: Brian Eaton To: John Kemp Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , oauth@ietf.org Subject: Re: [OAUTH-WG] Signature crypto X-BeenThere: oauth@ietf.org X-Mailman-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, 25 Nov 2009 19:07:41 -0000 On Wed, Nov 25, 2009 at 11:01 AM, John Kemp wrote: > In any case, I wouldn't really call it "chaos" just because there are > multiple OSS implementations. I hope that people will develop tools that > work for them. And I suspect that the most important parts of OAuth to > standardize on are a) the protocol itself, b) the HTTP authentication > mechanism and c) a method of negotiating the relevant twiddly bits, as > necessary (and where it should be noted that "no signature at all" is > potentially an acceptable signature algorithm). Yep. Whatever signature scheme we specify here is going to be obsolete in a few years. The most important thing is that there is a smooth upgrade path. Cheers, Brian From email@pbryan.net Wed Nov 25 12:31:59 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C88863A6911 for ; Wed, 25 Nov 2009 12:31:59 -0800 (PST) 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 DRiFLAoJH4jB for ; Wed, 25 Nov 2009 12:31:59 -0800 (PST) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by core3.amsl.com (Postfix) with ESMTP id 638953A6837 for ; Wed, 25 Nov 2009 12:31:58 -0800 (PST) Received: from [192.168.0.4] (S010600095baae0ff.vf.shawcable.net [174.1.50.199]) by maple.anode.ca (Postfix) with ESMTPSA id C1437EA022 for ; Wed, 25 Nov 2009 20:31:52 +0000 (UTC) From: "Paul C. Bryan" To: oauth@ietf.org Content-Type: text/plain; charset="UTF-8" Date: Wed, 25 Nov 2009 12:31:39 -0800 Message-ID: <1259181099.12400.97.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit Subject: [OAUTH-WG] SWT-qualified names X-BeenThere: oauth@ietf.org X-Mailman-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, 25 Nov 2009 20:31:59 -0000 To avoid namespace collisions that may occur as Simple Web Token (or its descendants) evolve or establish further NV-pairs to provide additional context, I propose that official SWT-scoped names have a short qualifier, such as a "swt." prefix. Unqualified (non-prefixed) identifiers would remain private and unofficial. Thoughts? From benl@google.com Wed Nov 25 13:31:14 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90A133A6B52 for ; Wed, 25 Nov 2009 13:31:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[AWL=0.000, 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 ocUfK-IA3Lp4 for ; Wed, 25 Nov 2009 13:31:13 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 5FF073A6820 for ; Wed, 25 Nov 2009 13:31:13 -0800 (PST) Received: from zps18.corp.google.com (zps18.corp.google.com [172.25.146.18]) by smtp-out.google.com with ESMTP id nAPLV5ma001267 for ; Wed, 25 Nov 2009 21:31:07 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1259184667; bh=KN9iO8nD4AY8hJmnNcnYGCZyBok=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=joNV4XdpwOjbe2BYM78Lr9wNX0iNr/iZwkjqe+7Ec9n652AOH+z5q5PP3em2lyRnt uOPHScwD5rBezVXn88K8A== 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=t4ObVmVEuRdqLybbSV3gpVn5DFCX1rUXbUMoPqWRywAh72rfc/6jw7QowTcccczh3 I9ppWnZ30E5LGIfPM/yNQ== Received: from qyk38 (qyk38.prod.google.com [10.241.83.166]) by zps18.corp.google.com with ESMTP id nAPLV2D4015936 for ; Wed, 25 Nov 2009 13:31:02 -0800 Received: by qyk38 with SMTP id 38so64976qyk.25 for ; Wed, 25 Nov 2009 13:31:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.12.212 with SMTP id y20mr1178727qcy.16.1259184662317; Wed, 25 Nov 2009 13:31:02 -0800 (PST) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E72343785183009@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B0D3698.8070706@cs.tcd.ie> <3a880e2c0911250618w358579d9o38b5ad90cb9242af@mail.gmail.com> <3D3C75174CB95F42AD6BCC56E5555B4501EE54E2@FIESEXC015.nsn-intra.net> <3a880e2c0911251024g1310d64fld7adf54951433d30@mail.gmail.com> <4B0D7EF0.5010002@jkemp.net> Date: Wed, 25 Nov 2009 13:31:02 -0800 Message-ID: <1b587cab0911251331l643f003w1d6a630c1244edcf@mail.gmail.com> From: Ben Laurie To: Brian Eaton Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , oauth@ietf.org Subject: Re: [OAUTH-WG] Signature crypto X-BeenThere: oauth@ietf.org X-Mailman-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, 25 Nov 2009 21:31:14 -0000 On Wed, Nov 25, 2009 at 11:07 AM, Brian Eaton wrote: > On Wed, Nov 25, 2009 at 11:01 AM, John Kemp wrote: >> In any case, I wouldn't really call it "chaos" just because there are >> multiple OSS implementations. I hope that people will develop tools that >> work for them. And I suspect that the most important parts of OAuth to >> standardize on are a) the protocol itself, b) the HTTP authentication >> mechanism and c) a method of negotiating the relevant twiddly bits, as >> necessary (and where it should be noted that "no signature at all" is >> potentially an acceptable signature algorithm). > > Yep. > > Whatever signature scheme we specify here is going to be obsolete in a > few years. =A0The most important thing is that there is a smooth upgrade > path. And no smooth downgrade path :-) > > Cheers, > Brian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From hubertlvg@gmail.com Wed Nov 25 14:57:11 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 671F03A67AA for ; Wed, 25 Nov 2009 14:57:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 XhW0LRsJ6pEP for ; Wed, 25 Nov 2009 14:57:10 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 629573A6774 for ; Wed, 25 Nov 2009 14:57:10 -0800 (PST) Received: by bwz23 with SMTP id 23so176059bwz.29 for ; Wed, 25 Nov 2009 14:57:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=a7xOOSt4JsQnCooRcDLVvW+uQlkE7FMhLY3W+ETJ1yI=; b=NUdq/DwL328wN/InoXfIj6sR5ZSKALIGHSOqbKDNHsBXBkWoZlwKSnVPfqFOfcw6i2 gWL2p+1UX5h4cgBCV0LmvCgKU3AzjTZ4xcp934X/5mxpNNZmH3qs8jdJSpbz9Y6kXf60 ZW/xGFmhwARoSEuXKALsMEjDhcNWXQyWiLZRc= 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=FRQSAKOKW6ZqC0QhqA011lSpGahZr057A/1Lt43IxZKAeQ5auIUbhf60ROlbO96nt/ 9i44+VF6+HNlF6JpbEa341Ej5quvs2fY2XgpRlfPu/uamX/BMlfqMMZbSVQ2Om5fS0+b 3tgWLSFnr7ZjnPy/bYI21/mElz2jf7EBmZUqU= MIME-Version: 1.0 Received: by 10.204.153.202 with SMTP id l10mr2350987bkw.92.1259189821905; Wed, 25 Nov 2009 14:57:01 -0800 (PST) In-Reply-To: <1259181099.12400.97.camel@localhost> References: <1259181099.12400.97.camel@localhost> Date: Wed, 25 Nov 2009 23:57:01 +0100 Message-ID: <6c0fd2bc0911251457ve0270baw61d6039e2aa1ddaf@mail.gmail.com> From: Hubert Le Van Gong To: oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [OAUTH-WG] SWT-qualified names X-BeenThere: oauth@ietf.org X-Mailman-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, 25 Nov 2009 22:57:11 -0000 I'd agree it makes sense, assuming you meant only for the public attributes names. That said, it's probably a topic better addressed in the WRAP WG rather than here since OAuth has always remained token agnostic. Unless it's changed and I missed that? Hubert On Wed, Nov 25, 2009 at 9:31 PM, Paul C. Bryan wrote: > To avoid namespace collisions that may occur as Simple Web Token (or its > descendants) evolve or establish further NV-pairs to provide additional > context, I propose that official SWT-scoped names have a short > qualifier, such as a "swt." prefix. Unqualified (non-prefixed) > identifiers would remain private and unofficial. Thoughts? > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From email@pbryan.net Wed Nov 25 14:59:53 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E90B63A698D for ; Wed, 25 Nov 2009 14:59:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 KpFECSJRLIte for ; Wed, 25 Nov 2009 14:59:53 -0800 (PST) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by core3.amsl.com (Postfix) with ESMTP id 293353A6B68 for ; Wed, 25 Nov 2009 14:59:53 -0800 (PST) Received: from [192.168.0.4] (S010600095baae0ff.vf.shawcable.net [174.1.50.199]) by maple.anode.ca (Postfix) with ESMTPSA id AC772EA022 for ; Wed, 25 Nov 2009 22:59:47 +0000 (UTC) From: "Paul C. Bryan" To: oauth@ietf.org In-Reply-To: <6c0fd2bc0911251457ve0270baw61d6039e2aa1ddaf@mail.gmail.com> References: <1259181099.12400.97.camel@localhost> <6c0fd2bc0911251457ve0270baw61d6039e2aa1ddaf@mail.gmail.com> Content-Type: text/plain; charset="UTF-8" Date: Wed, 25 Nov 2009 14:59:33 -0800 Message-ID: <1259189973.12400.100.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit Subject: Re: [OAUTH-WG] SWT-qualified names X-BeenThere: oauth@ietf.org X-Mailman-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, 25 Nov 2009 22:59:54 -0000 Yes, I mean only public attribute names in the SWT to be fully-qualified. The OAuth-WRAP wiki page at http://wiki.oauth.net/OAuth-WRAP indicates that protocol changes should be discussed on this IETF list. On Wed, 2009-11-25 at 23:57 +0100, Hubert Le Van Gong wrote: > I'd agree it makes sense, assuming you meant only for the public > attributes names. > That said, it's probably a topic better addressed in the WRAP WG rather than > here since OAuth has always remained token agnostic. Unless it's > changed and I missed that? > > Hubert > > > On Wed, Nov 25, 2009 at 9:31 PM, Paul C. Bryan wrote: > > To avoid namespace collisions that may occur as Simple Web Token (or its > > descendants) evolve or establish further NV-pairs to provide additional > > context, I propose that official SWT-scoped names have a short > > qualifier, such as a "swt." prefix. Unqualified (non-prefixed) > > identifiers would remain private and unofficial. Thoughts? > > > > _______________________________________________ > > OAuth mailing 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 hubertlvg@gmail.com Wed Nov 25 15:10:06 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E09C3A68E3 for ; Wed, 25 Nov 2009 15:10:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 YntvxqkNiy7m for ; Wed, 25 Nov 2009 15:10:05 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 713913A6B9E for ; Wed, 25 Nov 2009 15:10:04 -0800 (PST) Received: by bwz23 with SMTP id 23so182783bwz.29 for ; Wed, 25 Nov 2009 15:09:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=ksVEjkx9tDU1Q+WiumbkxYbFIKGDwsFa49nyca6Y9u4=; b=bBtQHy5L13FXA8+XBONH5y1TqxVcqJ1LkpqE54tztZ6uDbl0merTDb7EKHezpQ8MvO 3h03VtNrZcTwWeiuJjmTlChjDZ2ZDvld0aqtu7C9oKIEkr/GgwliubcFE+9u7oKg9bl5 UwLzI3yrMIRKExgV5AfLQl8SAnHx15y7rWy/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 :content-type; b=T1euSAxcZWUbdsaSKGXiGITw5+XmPMzFTg02eWQwNW/HIGmaWJgFu23Q/DQMtWHtki go07EyJEXJVAL+mgz8Aw5FdE4mFp//BNNiUPdMLUhu5t7/jBOZzdsop3w0+Znwdcfvqo g2PK8S3dgmNqbabLl9brhMr+GacUo+eS3iNzA= MIME-Version: 1.0 Received: by 10.204.25.152 with SMTP id z24mr1497874bkb.44.1259190596473; Wed, 25 Nov 2009 15:09:56 -0800 (PST) In-Reply-To: <1259189973.12400.100.camel@localhost> References: <1259181099.12400.97.camel@localhost> <6c0fd2bc0911251457ve0270baw61d6039e2aa1ddaf@mail.gmail.com> <1259189973.12400.100.camel@localhost> Date: Thu, 26 Nov 2009 00:09:56 +0100 Message-ID: <6c0fd2bc0911251509j80e3bd9q7e231179e0b961db@mail.gmail.com> From: Hubert Le Van Gong To: oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [OAUTH-WG] SWT-qualified names X-BeenThere: oauth@ietf.org X-Mailman-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, 25 Nov 2009 23:10:06 -0000 Then I guess my question is: is it the intention of the SWT authors/proponents to advocate for the adoption of SWT as "the" official token format for OAuth? Cheers, Hubert On Wed, Nov 25, 2009 at 11:59 PM, Paul C. Bryan wrote: > Yes, I mean only public attribute names in the SWT to be > fully-qualified. > > The OAuth-WRAP wiki page at http://wiki.oauth.net/OAuth-WRAP indicates > that protocol changes should be discussed on this IETF list. > > On Wed, 2009-11-25 at 23:57 +0100, Hubert Le Van Gong wrote: >> I'd agree it makes sense, assuming you meant only for the public >> attributes names. >> That said, it's probably a topic better addressed in the WRAP WG rather than >> here since OAuth has always remained token agnostic. Unless it's >> changed and I missed that? >> >> Hubert >> >> >> On Wed, Nov 25, 2009 at 9:31 PM, Paul C. Bryan wrote: >> > To avoid namespace collisions that may occur as Simple Web Token (or its >> > descendants) evolve or establish further NV-pairs to provide additional >> > context, I propose that official SWT-scoped names have a short >> > qualifier, such as a "swt." prefix. Unqualified (non-prefixed) >> > identifiers would remain private and unofficial. Thoughts? >> > >> > _______________________________________________ >> > OAuth mailing 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 email@pbryan.net Wed Nov 25 16:07:18 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29CB63A6835 for ; Wed, 25 Nov 2009 16:07:18 -0800 (PST) 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 pzTPpmMi9tev for ; Wed, 25 Nov 2009 16:07:16 -0800 (PST) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by core3.amsl.com (Postfix) with ESMTP id BACA73A67E3 for ; Wed, 25 Nov 2009 16:07:16 -0800 (PST) Received: from [192.168.0.4] (S010600095baae0ff.vf.shawcable.net [174.1.50.199]) by maple.anode.ca (Postfix) with ESMTPSA id A0BAC614E for ; Thu, 26 Nov 2009 00:07:11 +0000 (UTC) From: "Paul C. Bryan" To: oauth@ietf.org In-Reply-To: <6c0fd2bc0911251509j80e3bd9q7e231179e0b961db@mail.gmail.com> References: <1259181099.12400.97.camel@localhost> <6c0fd2bc0911251457ve0270baw61d6039e2aa1ddaf@mail.gmail.com> <1259189973.12400.100.camel@localhost> <6c0fd2bc0911251509j80e3bd9q7e231179e0b961db@mail.gmail.com> Content-Type: text/plain; charset="UTF-8" Date: Wed, 25 Nov 2009 16:06:58 -0800 Message-ID: <1259194018.12400.154.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit Subject: Re: [OAUTH-WG] SWT-qualified names X-BeenThere: oauth@ietf.org X-Mailman-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, 26 Nov 2009 00:07:18 -0000 I think given the fact SWT is explicitly named in the OAuth-WRAP specification document, it's likely that SWT will be a commonly-adopted token format. On Thu, 2009-11-26 at 00:09 +0100, Hubert Le Van Gong wrote: > Then I guess my question is: is it the intention of the SWT authors/proponents > to advocate for the adoption of SWT as "the" official token format for OAuth? > > > Cheers, > Hubert > > > On Wed, Nov 25, 2009 at 11:59 PM, Paul C. Bryan wrote: > > Yes, I mean only public attribute names in the SWT to be > > fully-qualified. > > > > The OAuth-WRAP wiki page at http://wiki.oauth.net/OAuth-WRAP indicates > > that protocol changes should be discussed on this IETF list. > > > > On Wed, 2009-11-25 at 23:57 +0100, Hubert Le Van Gong wrote: > >> I'd agree it makes sense, assuming you meant only for the public > >> attributes names. > >> That said, it's probably a topic better addressed in the WRAP WG rather than > >> here since OAuth has always remained token agnostic. Unless it's > >> changed and I missed that? > >> > >> Hubert > >> > >> > >> On Wed, Nov 25, 2009 at 9:31 PM, Paul C. Bryan wrote: > >> > To avoid namespace collisions that may occur as Simple Web Token (or its > >> > descendants) evolve or establish further NV-pairs to provide additional > >> > context, I propose that official SWT-scoped names have a short > >> > qualifier, such as a "swt." prefix. Unqualified (non-prefixed) > >> > identifiers would remain private and unofficial. Thoughts? > >> > > >> > _______________________________________________ > >> > OAuth mailing 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 Dick.Hardt@microsoft.com Wed Nov 25 19:18:40 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7A213A696A for ; Wed, 25 Nov 2009 19:18:40 -0800 (PST) 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 KI4qrdyNbaQZ for ; Wed, 25 Nov 2009 19:18:39 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 94FDE3A6877 for ; Wed, 25 Nov 2009 19:18:39 -0800 (PST) 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; Wed, 25 Nov 2009 19:18:58 -0800 Received: from TK5EX14MBXC101.redmond.corp.microsoft.com ([169.254.1.27]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi; Wed, 25 Nov 2009 19:18:34 -0800 From: Dick Hardt To: Hubert Le Van Gong Thread-Topic: [OAUTH-WG] SWT-qualified names Thread-Index: AQHKbg5z2BVLUaPDZEmxqJCtyn+dZJFH7zGAgAAAtYCAAALnAIAARXUA Date: Thu, 26 Nov 2009 03:18:32 +0000 Message-ID: <4F90DA5D-9765-4623-AD96-C338A119A874@microsoft.com> References: <1259181099.12400.97.camel@localhost> <6c0fd2bc0911251457ve0270baw61d6039e2aa1ddaf@mail.gmail.com> <1259189973.12400.100.camel@localhost> <6c0fd2bc0911251509j80e3bd9q7e231179e0b961db@mail.gmail.com> In-Reply-To: <6c0fd2bc0911251509j80e3bd9q7e231179e0b961db@mail.gmail.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-ID: <333ba031-f799-4658-b707-7b6fb302e6e0> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [OAUTH-WG] SWT-qualified names X-BeenThere: oauth@ietf.org X-Mailman-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, 26 Nov 2009 03:18:41 -0000 No, we did not expect SWT to the the official token format for OAuth. It mi= ght become that, or it might not. OAuth WRAP was intended to be token agnos= tic, and the Client should not care. I have responded to Bryan's question over on the OAuth WRAP WG list on Goog= le as I agree that is where the discussion should be as opposed to here. -- Dick On 2009-11-25, at 1:09 PM, Hubert Le Van Gong wrote: > Then I guess my question is: is it the intention of the SWT authors/propo= nents > to advocate for the adoption of SWT as "the" official token format for OA= uth? >=20 >=20 > Cheers, > Hubert >=20 >=20 > On Wed, Nov 25, 2009 at 11:59 PM, Paul C. Bryan wrote: >> Yes, I mean only public attribute names in the SWT to be >> fully-qualified. >>=20 >> The OAuth-WRAP wiki page at http://wiki.oauth.net/OAuth-WRAP indicates >> that protocol changes should be discussed on this IETF list. >>=20 >> On Wed, 2009-11-25 at 23:57 +0100, Hubert Le Van Gong wrote: >>> I'd agree it makes sense, assuming you meant only for the public >>> attributes names. >>> That said, it's probably a topic better addressed in the WRAP WG rather= than >>> here since OAuth has always remained token agnostic. Unless it's >>> changed and I missed that? >>>=20 >>> Hubert >>>=20 >>>=20 >>> On Wed, Nov 25, 2009 at 9:31 PM, Paul C. Bryan wrote= : >>>> To avoid namespace collisions that may occur as Simple Web Token (or i= ts >>>> descendants) evolve or establish further NV-pairs to provide additiona= l >>>> context, I propose that official SWT-scoped names have a short >>>> qualifier, such as a "swt." prefix. Unqualified (non-prefixed) >>>> identifiers would remain private and unofficial. Thoughts? >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 From breno.demedeiros@gmail.com Wed Nov 25 20:30:10 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C58813A6979 for ; Wed, 25 Nov 2009 20:30:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-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 Vp+5s+4h2BZ9 for ; Wed, 25 Nov 2009 20:30:09 -0800 (PST) Received: from mail-yw0-f185.google.com (mail-yw0-f185.google.com [209.85.211.185]) by core3.amsl.com (Postfix) with ESMTP id AD3633A683D for ; Wed, 25 Nov 2009 20:30:09 -0800 (PST) Received: by ywh15 with SMTP id 15so371368ywh.5 for ; Wed, 25 Nov 2009 20:30:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=NsieOT1LRQpVGbzLq5F+2EgffI3bvaFUYwlSzWzuzYo=; b=IPYH6g6yrPIzrzUaZlqa4T33MTu1B6QfMw8dBWM420pSM4Oix9BnJQ2ZWnXU0CvUWF CTgrLSg0yrXUBfz8SycyvjEpbUApnsVNhT+yPaLduVNf4iggNt5seb/It+DUYWAMRD8u d16ro7h5L7GUrXY6GpVntKnVTkm4aUp2G1pt4= 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=ofYevyZSRFkhfdPV3/DrWymSGcM3Xri6pN7nCNNFotd/65aS/aFrGb7sv1gonurB0W A5vXU5ZAmqc0LzkmAP61IxuH7AkPZXo8qIJHKzN+mi6cJHc9FhP3Rw+wN5qgi6V6QGKo XrJXGUBikmKnVYRo2d4Lw2zgdXuOZI6neeuk0= MIME-Version: 1.0 Received: by 10.101.13.20 with SMTP id q20mr2901577ani.133.1259209800981; Wed, 25 Nov 2009 20:30:00 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343785209782@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343785183009@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B0D3698.8070706@cs.tcd.ie> <90C41DD21FB7C64BB94121FBBC2E72343785209782@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Wed, 25 Nov 2009 20:30:00 -0800 Message-ID: From: Breno To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=005045016f55e29ca804793ea091 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Signature crypto X-BeenThere: oauth@ietf.org X-Mailman-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, 26 Nov 2009 04:30:10 -0000 --005045016f55e29ca804793ea091 Content-Type: text/plain; charset=ISO-8859-1 John Panzer managed that mandated implementation is not the same as mandated support. We could require all OAuth compliant libraries to include support for a particular hash algorithm (to facilitate interoperability testing) but make it clear that no service provider is required to support it. Without a mandatory implemented algorithm it can be difficult to weed out bugs by interoperability exercises among different libraries. On Wed, Nov 25, 2009 at 8:19 AM, Eran Hammer-Lahav wrote: > Mandating a baseline is still something we don't have consensus on. What I > meant is that we agreed to allow crypto negotiation and therefore need a way > to manage the algorithm names somehow. Looks like the IANA registry > mentioned is the way to go. > > EHL > > > -----Original Message----- > > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > > Sent: Wednesday, November 25, 2009 5:52 AM > > To: Eran Hammer-Lahav > > Cc: OAuth WG (oauth@ietf.org) > > Subject: Re: [OAUTH-WG] Signature crypto > > > > > > > > Eran Hammer-Lahav wrote: > > > I think we have consensus that the spec should not mandate a particular > > hash algorithm. This still leave the issue of assigning algorithms short > names > > for the purpose of negotiation and declaration. Is there a registry > available > > for such algorithms we can use or do we need to create a new one? > > > > Sorry to have missed out on the thread where that was discussed, but it'd > be > > odd for an IETF security spec to not mandate some algorithms and quite > likely > > to generate comments later in the process if there's no well-defined way > to > > ensure interop. Do we have that? > > > > Ta, > > S. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Breno de Medeiros --005045016f55e29ca804793ea091 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable John Panzer managed that mandated implementation is not the same as mandate= d support. We could require all OAuth compliant libraries to include suppor= t for a particular hash algorithm (to facilitate interoperability testing) = but make it clear that no service provider is required to support it.

Without a mandatory implemented algorithm it can be difficul= t to weed out bugs by interoperability exercises among different libraries.=

On Wed, Nov 25, 2009 at 8:19 AM, Eran Ha= mmer-Lahav <era= n@hueniverse.com> wrote:
Mandating a baseline is still something we = don't have consensus on. What I meant is that we agreed to allow crypto= negotiation and therefore need a way to manage the algorithm names somehow= . Looks like the IANA registry mentioned is the way to go.

EHL

> -----Original Message-----
> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]
> Sent: Wednesday, November 25, 2009 5:52 AM
> To: Eran Hammer-Lahav
> Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Signature crypto
>
>
>
> Eran Hammer-Lahav wrote:
> > I think we have consensus that the spec should not mandate a part= icular
> hash algorithm. This still leave the issue of assigning algorithms sho= rt names
> for the purpose of negotiation and declaration. Is there a registry av= ailable
> for such algorithms we can use or do we need to create a new one?
>
> Sorry to have missed out on the thread where that was discussed, but i= t'd be
> odd for an IETF security spec to not mandate some algorithms and quite= likely
> to generate comments later in the process if there's no well-defin= ed way to
> ensure interop. Do we have that?
>
> Ta,
> S.

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



--
Breno de Me= deiros

--005045016f55e29ca804793ea091-- From breno.demedeiros@gmail.com Wed Nov 25 20:31:10 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FEB93A6B68 for ; Wed, 25 Nov 2009 20:31:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-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 ZNs9t2cHzO+M for ; Wed, 25 Nov 2009 20:31:09 -0800 (PST) Received: from mail-yw0-f185.google.com (mail-yw0-f185.google.com [209.85.211.185]) by core3.amsl.com (Postfix) with ESMTP id 314EB3A69BE for ; Wed, 25 Nov 2009 20:31:09 -0800 (PST) Received: by ywh15 with SMTP id 15so371817ywh.5 for ; Wed, 25 Nov 2009 20:31:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=nsjoLZ7sM6rE/WpCy9yBAc6Q3JWcLdSb5O63ayccn8g=; b=P2tu/6+nJeH2CbDZMOXt9eHtjlUT4NKtitxrAg0yAdBGybv0/co7v4HJfQG7EghyZz a9rBnqeAkzt1xg2Vo+BceKLw3Tn83wJv664djCc5sOLH9rGHs5e1QctfsWnYXEtNkviS b5qP5z0j8aHlnjWj4qs7gz1N/j1a3EJD+A3gI= 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=FtgGnGXQr4uK+o3Vb1hXU1mCe2AnEPnWGiLJnBnr0UD5MIW5i/6ZOwx5q+AtkdNIJZ HfTqBy10J9qxTzMo3pmZTfcmkbvgpCb2Ef3vnIap3W3d2VKWhq0RaroO3c0Prbn/776x D2SHQR8jbwk3yHqWh/7N/DrxnnAueYjgBWOsY= MIME-Version: 1.0 Received: by 10.101.129.1 with SMTP id g1mr5643248ann.124.1259209859300; Wed, 25 Nov 2009 20:30:59 -0800 (PST) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E72343785183009@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B0D3698.8070706@cs.tcd.ie> <90C41DD21FB7C64BB94121FBBC2E72343785209782@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Wed, 25 Nov 2009 20:30:59 -0800 Message-ID: From: Breno To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=0016e68dd5f25c85ed04793ea442 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Signature crypto X-BeenThere: oauth@ietf.org X-Mailman-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, 26 Nov 2009 04:31:10 -0000 --0016e68dd5f25c85ed04793ea442 Content-Type: text/plain; charset=ISO-8859-1 I meant 'John Panzer suggested' rather than 'John Panzer managed' If I were not in the habit of sending clarification messages I would blame it on the flu I'm recovering from. On Wed, Nov 25, 2009 at 8:30 PM, Breno wrote: > John Panzer managed that mandated implementation is not the same as > mandated support. We could require all OAuth compliant libraries to include > support for a particular hash algorithm (to facilitate interoperability > testing) but make it clear that no service provider is required to support > it. > > Without a mandatory implemented algorithm it can be difficult to weed out > bugs by interoperability exercises among different libraries. > > > On Wed, Nov 25, 2009 at 8:19 AM, Eran Hammer-Lahav wrote: > >> Mandating a baseline is still something we don't have consensus on. What I >> meant is that we agreed to allow crypto negotiation and therefore need a way >> to manage the algorithm names somehow. Looks like the IANA registry >> mentioned is the way to go. >> >> EHL >> >> > -----Original Message----- >> > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] >> > Sent: Wednesday, November 25, 2009 5:52 AM >> > To: Eran Hammer-Lahav >> > Cc: OAuth WG (oauth@ietf.org) >> > Subject: Re: [OAUTH-WG] Signature crypto >> > >> > >> > >> > Eran Hammer-Lahav wrote: >> > > I think we have consensus that the spec should not mandate a >> particular >> > hash algorithm. This still leave the issue of assigning algorithms short >> names >> > for the purpose of negotiation and declaration. Is there a registry >> available >> > for such algorithms we can use or do we need to create a new one? >> > >> > Sorry to have missed out on the thread where that was discussed, but >> it'd be >> > odd for an IETF security spec to not mandate some algorithms and quite >> likely >> > to generate comments later in the process if there's no well-defined way >> to >> > ensure interop. Do we have that? >> > >> > Ta, >> > S. >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > > > -- > Breno de Medeiros > > -- Breno de Medeiros --0016e68dd5f25c85ed04793ea442 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I meant 'John Panzer suggested' rather than 'John Panzer manage= d'

If I were not in the habit of sending clarificati= on messages I would blame it on the flu I'm recovering from.

On Wed, Nov 25, 2009 at 8:30 PM, Breno <breno.demedeiros= @gmail.com> wrote:
John Panzer managed that mandated implementation is not the same as mandate= d support. We could require all OAuth compliant libraries to include suppor= t for a particular hash algorithm (to facilitate interoperability testing) = but make it clear that no service provider is required to support it.

Without a mandatory implemented algorithm it can be difficul= t to weed out bugs by interoperability exercises among different libraries.=


On Wed= , Nov 25, 2009 at 8:19 AM, Eran Hammer-Lahav <eran@hueniverse.com&g= t; wrote:
Mandating a baseline is still something we d= on't have consensus on. What I meant is that we agreed to allow crypto = negotiation and therefore need a way to manage the algorithm names somehow.= Looks like the IANA registry mentioned is the way to go.

EHL

> -----Original Message-----
> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]
> Sent: Wednesday, November 25, 2009 5:52 AM
> To: Eran Hammer-Lahav
> Cc: OAuth WG (oaut= h@ietf.org)
> Subject: Re: [OAUTH-WG] Signature crypto
>
>
>
> Eran Hammer-Lahav wrote:
> > I think we have consensus that the spec should not mandate a part= icular
> hash algorithm. This still leave the issue of assigning algorithms sho= rt names
> for the purpose of negotiation and declaration. Is there a registry av= ailable
> for such algorithms we can use or do we need to create a new one?
>
> Sorry to have missed out on the thread where that was discussed, but i= t'd be
> odd for an IETF security spec to not mandate some algorithms and quite= likely
> to generate comments later in the process if there's no well-defin= ed way to
> ensure interop. Do we have that?
>
> Ta,
> S.

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



-- Breno de Medeiros




--
Breno de Medeiros
--0016e68dd5f25c85ed04793ea442-- From eran@hueniverse.com Wed Nov 25 23:28:49 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 888163A6782 for ; Wed, 25 Nov 2009 23:28:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.404 X-Spam-Level: X-Spam-Status: No, score=-2.404 tagged_above=-999 required=5 tests=[AWL=0.195, 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 JhzFRhnObz4R for ; Wed, 25 Nov 2009 23:28:48 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 71D833A67B4 for ; Wed, 25 Nov 2009 23:28:48 -0800 (PST) Received: (qmail 17276 invoked from network); 26 Nov 2009 07:28:42 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 26 Nov 2009 07:28:41 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 26 Nov 2009 00:28:41 -0700 From: Eran Hammer-Lahav To: Dick Hardt , Hubert Le Van Gong Date: Thu, 26 Nov 2009 00:28:53 -0700 Thread-Topic: [OAUTH-WG] SWT-qualified names Thread-Index: AQHKbg5z2BVLUaPDZEmxqJCtyn+dZJFH7zGAgAAAtYCAAALnAIAARXUA//+/jXA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234378520991F@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <1259181099.12400.97.camel@localhost> <6c0fd2bc0911251457ve0270baw61d6039e2aa1ddaf@mail.gmail.com> <1259189973.12400.100.camel@localhost> <6c0fd2bc0911251509j80e3bd9q7e231179e0b961db@mail.gmail.com> <4F90DA5D-9765-4623-AD96-C338A119A874@microsoft.com> In-Reply-To: <4F90DA5D-9765-4623-AD96-C338A119A874@microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [OAUTH-WG] SWT-qualified names X-BeenThere: oauth@ietf.org X-Mailman-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, 26 Nov 2009 07:28:49 -0000 Token structure is out of scope for this working group. What is in scope is= to make sure proposal such as SWT are enabled by the opaque token supporte= d in the core spec. Thanks Dick for moving this discussion where it is more productive. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Dick Hardt > Sent: Wednesday, November 25, 2009 7:19 PM > To: Hubert Le Van Gong > Cc: > Subject: Re: [OAUTH-WG] SWT-qualified names >=20 > No, we did not expect SWT to the the official token format for OAuth. It > might become that, or it might not. OAuth WRAP was intended to be token > agnostic, and the Client should not care. >=20 > I have responded to Bryan's question over on the OAuth WRAP WG list on > Google as I agree that is where the discussion should be as opposed to he= re. >=20 > -- Dick >=20 > On 2009-11-25, at 1:09 PM, Hubert Le Van Gong wrote: >=20 > > Then I guess my question is: is it the intention of the SWT > > authors/proponents to advocate for the adoption of SWT as "the" officia= l > token format for OAuth? > > > > > > Cheers, > > Hubert > > > > > > On Wed, Nov 25, 2009 at 11:59 PM, Paul C. Bryan > wrote: > >> Yes, I mean only public attribute names in the SWT to be > >> fully-qualified. > >> > >> The OAuth-WRAP wiki page at http://wiki.oauth.net/OAuth-WRAP > >> indicates that protocol changes should be discussed on this IETF list. > >> > >> On Wed, 2009-11-25 at 23:57 +0100, Hubert Le Van Gong wrote: > >>> I'd agree it makes sense, assuming you meant only for the public > >>> attributes names. > >>> That said, it's probably a topic better addressed in the WRAP WG > >>> rather than here since OAuth has always remained token agnostic. > >>> Unless it's changed and I missed that? > >>> > >>> Hubert > >>> > >>> > >>> On Wed, Nov 25, 2009 at 9:31 PM, Paul C. Bryan > wrote: > >>>> To avoid namespace collisions that may occur as Simple Web Token > >>>> (or its > >>>> descendants) evolve or establish further NV-pairs to provide > >>>> additional context, I propose that official SWT-scoped names have a > >>>> short qualifier, such as a "swt." prefix. Unqualified > >>>> (non-prefixed) identifiers would remain private and unofficial. > Thoughts? > >>>> > >>>> _______________________________________________ > >>>> OAuth mailing list > >>>> OAuth@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/oauth > >>>> > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth > >> > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > >> > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From James.H.Manger@team.telstra.com Thu Nov 26 19:42:47 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43D283A687B for ; Thu, 26 Nov 2009 19:42:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tBAXAfRJheQs for ; Thu, 26 Nov 2009 19:42:46 -0800 (PST) Received: from mailipbo.ntcif.telstra.com.au (mailipbo.ntcif.telstra.com.au [202.12.233.29]) by core3.amsl.com (Postfix) with ESMTP id 215543A6874 for ; Thu, 26 Nov 2009 19:42:43 -0800 (PST) Received: from unknown (HELO mailbi.ntcif.telstra.com.au) ([202.12.162.19]) by mailipbi.ntcif.telstra.com.au with ESMTP; 27 Nov 2009 14:42:37 +1100 Received: from mail.cdn.telstra.com.au (localhost [127.0.0.1]) by mailbi.ntcif.telstra.com.au (Postfix) with ESMTP id CE693FF81; Fri, 27 Nov 2009 14:42:36 +1100 (EST) Received: from WSMSG3703.srv.dir.telstra.com (wsmsg3703.srv.dir.telstra.com [172.49.40.171]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id OAA11304; Fri, 27 Nov 2009 14:42:36 +1100 (EST) Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3703.srv.dir.telstra.com ([172.49.40.171]) with mapi; Fri, 27 Nov 2009 14:42:36 +1100 From: "Manger, James H" To: Eran Hammer-Lahav , Stephen Farrell Date: Fri, 27 Nov 2009 14:42:35 +1100 Thread-Topic: [OAUTH-WG] Signature crypto Thread-Index: Acpt7pSuYnX/bLa8QDafocxOnS4STwACWuuwACb5iVA= Message-ID: <255B9BB34FB7D647A506DC292726F6E1124A7241F7@WSMSG3153V.srv.dir.telstra.com> References: <90C41DD21FB7C64BB94121FBBC2E72343785183009@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B0D3698.8070706@cs.tcd.ie> <90C41DD21FB7C64BB94121FBBC2E72343785209782@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B0D5EE1.9000309@cs.tcd.ie> <90C41DD21FB7C64BB94121FBBC2E723437852097FC@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723437852097FC@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US, en-AU Content-Language: en-US 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] Signature crypto X-BeenThere: oauth@ietf.org X-Mailman-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, 27 Nov 2009 03:42:47 -0000 Pj4gU291bmRzIHJlYXNvbmFibGUgaWYgYWxsIHlvdSBuZWVkIHRvIG5lZ290aWF0ZSBhcmUgaGFz aCBhbGdvcml0aG0gbmFtZXMuDQo+PiBJcyB0aGF0IHRoZSBjYXNlPw0KDQo+IFllcy4NCg0KTm90 IHF1aXRlLg0KT0F1dGggKGF0IGxlYXN0IHRoZSBhdXRoZW50aWNhdGlvbiBwYXJ0KSBtYWlubHkg bmVlZHMgYSBNQUMgYWxnb3JpdGhtLCBub3QgYSBoYXNoIGFsZ29yaXRobS4NCkhNQUMgaXMgb25l IHBvcHVsYXIgTUFDIGFsZ29yaXRobSB0aGF0IGlzIGJ1aWxkIGZyb20gYSBoYXNoIGFsZ29yaXRo bS4NCkhvd2V2ZXIsIHRoZXJlIGFyZSBvdGhlciBNQUMgYWxnb3JpdGhtcyDigJQgYmFzZWQgb24g YmxvY2sgY2lwaGVycyBmb3IgaW5zdGFuY2UgKGVnIENNQUMtQUVTKS4NClRoZSBoYXNoIHJlZ2lz dHJ5IGh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvaGFzaC1mdW5jdGlvbi10ZXh0LW5h bWVzLyBpcyBub3QgcmVhbGx5IGdvaW5nIHRvIGhlbHAuDQoNClAuUy4gVGhlIGJvZHktc2lnbmlu ZyBPQXV0aCBleHRlbnNpb24gaXMgdGhlIG9uZSBwbGFjZSB0aGF0IHVzZXMgYSBoYXNoIChub3Qg YSBNQUMpIGRpcmVjdGx5Lg0KDQpKYW1lcyBNYW5nZXINCg== From infinity@lindenlab.com Fri Nov 27 09:45:07 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78D2C3A6901 for ; Fri, 27 Nov 2009 09:45:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 verkA+HnKO+F for ; Fri, 27 Nov 2009 09:45:06 -0800 (PST) Received: from mail-yx0-f174.google.com (mail-yx0-f174.google.com [209.85.210.174]) by core3.amsl.com (Postfix) with ESMTP id E7F713A690D for ; Fri, 27 Nov 2009 09:45:05 -0800 (PST) Received: by yxe4 with SMTP id 4so1614637yxe.32 for ; Fri, 27 Nov 2009 09:44:55 -0800 (PST) Received: by 10.150.171.17 with SMTP id t17mr196895ybe.303.1259343895850; Fri, 27 Nov 2009 09:44:55 -0800 (PST) Received: from localhost (m390536d0.tmodns.net [208.54.5.57]) by mx.google.com with ESMTPS id 15sm747216gxk.0.2009.11.27.09.44.30 (version=SSLv3 cipher=RC4-MD5); Fri, 27 Nov 2009 09:44:54 -0800 (PST) From: "Meadhbh Hamrick (Infinity Linden)" Date: Fri, 27 Nov 2009 09:44:03 -0800 To: "Manger, James H" , Eran Hammer-Lahav , Stephen Farrell Message-ID: <255B9BB34FB7D647A506DC292726F6E1124A7241F7@WSMSG3153V.srv.dir.telstra.com> Content-Type: multipart/mixed; boundary="----9JLUJW25QWWLUCBJIK5JIYNJOCO2EP" MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Signature crypto X-BeenThere: oauth@ietf.org X-Mailman-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, 27 Nov 2009 17:45:07 -0000 ------9JLUJW25QWWLUCBJIK5JIYNJOCO2EP Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SSB0aG91Z2h0IHdlIHdlcmUgdGFsa2luZyBhYm91dCBuZWdvdGlhdGluZyB0aGUgaGFzaCBhc3Nv Y2lhdGVkIHdpdGggcnNhIHNpZ25hdHVyZSBnZW5lcmF0aW9uLiBObyBtYXR0ZXIsIHRoZSBpc3N1 ZXMgYXJlIHRoZSBzYW1lLiBZb3UgaGF2ZSB0byBzZWxlY3QgYSBjb21tb24gc2VsZWN0aW9uIGZy b20gbXVsdGlwbGUgY2hvaWNlcy4gSWYgd2UncmUgdGFsa2luZyBhYm91dCBhbGdvcml0aG0gbmVn b3RpYXRpb24sIHdlIGNvdWxkIGp1c3QgYXMgZWFzaWx5IHVzZSB0aGUgc2FtZSBtZWNoYW5pc20g Zm9yIHNlbGVjdGluZyBhbiBvcHRpb24gZnJvbSBzaGExK3JzYSwgc2hhMjU2K3JzYSwgZWNkc2Es IGV0Yy4gQXMgd2UgdXNlIHRvIHNlbGVjdCBhbiBvcHRpb24gZnJvbSBobWFjLCBtZGMsIGV0Yy4K CiJNYW5nZXIsIEphbWVzIEgiIDxKYW1lcy5ILk1hbmdlckB0ZWFtLnRlbHN0cmEuY29tPiB3cm90 ZToKCj4+PiBTb3VuZHMgcmVhc29uYWJsZSBpZiBhbGwgeW91IG5lZWQgdG8gbmVnb3RpYXRlIGFy ZSBoYXNoIGFsZ29yaXRobSBuYW1lcy4NCj4+PiBJcyB0aGF0IHRoZSBjYXNlPw0KPg0KPj4gWWVz Lg0KPg0KPk5vdCBxdWl0ZS4NCj5PQXV0aCAoYXQgbGVhc3QgdGhlIGF1dGhlbnRpY2F0aW9uIHBh cnQpIG1haW5seSBuZWVkcyBhIE1BQyBhbGdvcml0aG0sIG5vdCBhIGhhc2ggYWxnb3JpdGhtLg0K PkhNQUMgaXMgb25lIHBvcHVsYXIgTUFDIGFsZ29yaXRobSB0aGF0IGlzIGJ1aWxkIGZyb20gYSBo YXNoIGFsZ29yaXRobS4NCj5Ib3dldmVyLCB0aGVyZSBhcmUgb3RoZXIgTUFDIGFsZ29yaXRobXMg 4oCUIGJhc2VkIG9uIGJsb2NrIGNpcGhlcnMgZm9yIGluc3RhbmNlIChlZyBDTUFDLUFFUykuDQo+ VGhlIGhhc2ggcmVnaXN0cnkgaHR0cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9oYXNoLWZ1 bmN0aW9uLXRleHQtbmFtZXMvIGlzIG5vdCByZWFsbHkgZ29pbmcgdG8gaGVscC4NCj4NCj5QLlMu IFRoZSBib2R5LXNpZ25pbmcgT0F1dGggZXh0ZW5zaW9uIGlzIHRoZSBvbmUgcGxhY2UgdGhhdCB1 c2VzIGEgaGFzaCAobm90IGEgTUFDKSBkaXJlY3RseS4NCj4NCj5KYW1lcyBNYW5nZXINCj5fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+T0F1dGggbWFpbGlu ZyBsaXN0Cj5PQXV0aEBpZXRmLm9yZwo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9vYXV0aAo= ------9JLUJW25QWWLUCBJIK5JIYNJOCO2EP-- From eran@hueniverse.com Sat Nov 28 23:59:08 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3FE73A67F6 for ; Sat, 28 Nov 2009 23:59:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.429 X-Spam-Level: X-Spam-Status: No, score=-2.429 tagged_above=-999 required=5 tests=[AWL=0.170, 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 GHwlb0UCEfCO for ; Sat, 28 Nov 2009 23:59:07 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 9FA4A3A6767 for ; Sat, 28 Nov 2009 23:59:07 -0800 (PST) Received: (qmail 27465 invoked from network); 29 Nov 2009 07:59:00 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 29 Nov 2009 07:58:59 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Sun, 29 Nov 2009 00:58:58 -0700 From: Eran Hammer-Lahav To: "Peter Saint-Andre (stpeter@stpeter.im)" , "Lisa Dusseault (lisa.dusseault@gmail.com)" Date: Sun, 29 Nov 2009 00:59:21 -0700 Thread-Topic: OAuth 2.0 / Charter Thread-Index: AcpwydwemcwGclDiS3iUrmJW9KSv5A== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343785209A24@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\)" Subject: [OAUTH-WG] OAuth 2.0 / Charter X-BeenThere: oauth@ietf.org X-Mailman-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, 29 Nov 2009 07:59:08 -0000 With the cleanup of the 1.0 specification [1] and the publication of an inf= ormational RFC (pending IESG approval), I no longer see value in a standard= closely based on the 1.0 specification, which was the original intention o= f this WG. This is also reflected by the recent interest in the WRAP propos= al [2]. Instead, I think we should develop two specifications that while closely in= line with the original plan, represent a significant shift. In other words= , I am proposing we develop OAuth 2.0, not 1.1. The new proposal is to develop two specifications: 1. Token Authorization Method An RFC 2617 Authorization header called 'Token' for authenticating requests= with token-based credentials. Tokens (with optional shared-secret) are usu= ally used in place of other credentials (usernames, etc.) and represent som= e combination of scope and authorization. The token method will include an = extensible signature-based option based on the HMAC-SHA1 method, and a bear= er token (with optional secret) option based on the PLAINTEXT method. The R= SA option will be dropped.=20 2. OAuth 2.0 A specification based on the browser-redirection flow described in OAuth 1.= 0 as well as new methods defined in WRAP (I-D submission pending). OAuth wi= ll be redefined to cover the authorization component only, and will no long= er be bound to a single authentication method. This will make OAuth immedia= tely useful for other protocols than HTTP (while HTTP will be used to obtai= n tokens, tokens will be useful in other protocols, not just with the HTTP = and Token method). --- While the current charter allows much of this work, it contradicts its spir= it and the understanding reached when we created the working group.=20 I would like to ask: - Is this approach favorable by the group? - Do we need to adjust the language in the charter to support? EHL [1] http://tools.ietf.org/html/draft-hammer-oauth [2] http://bit.ly/oauth-wrap From rbarnes@bbn.com Sun Nov 29 13:34:23 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77E8E3A69E0 for ; Sun, 29 Nov 2009 13:34:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 PKIHT4fG3iCK for ; Sun, 29 Nov 2009 13:34:22 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 7FDD03A69C6 for ; Sun, 29 Nov 2009 13:34:22 -0800 (PST) Received: from [128.89.253.130] (helo=[10.242.24.112]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1NErPJ-0002p5-9j; Sun, 29 Nov 2009 16:34:13 -0500 Message-Id: <0169BFEE-2317-4767-B998-4A8B3EA627B2@bbn.com> From: Richard Barnes To: Eran Hammer-Lahav In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343785209A24@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 29 Nov 2009 13:34:11 -0800 References: <90C41DD21FB7C64BB94121FBBC2E72343785209A24@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-Mailer: Apple Mail (2.936) Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] OAuth 2.0 / Charter X-BeenThere: oauth@ietf.org X-Mailman-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, 29 Nov 2009 21:34:23 -0000 Eran, A few thoughts on item (1), the authentication method (it is more properly "authentication"). I would like to get the group's impressions on what the goals are for item (1), i.e., what we want the new authentication method to provide that current methods don't. As I think I said before, my impression is that the whole "token" aspect of the authentication is not the real value (those are just additional semantics layered on the bits that carried in the protocol). Some candidates for goals: 1. Work with a single HTTP request (when no negotiation is required) [as opposed to 2 for Digest] 2. Protect credentials from exposure on the wire (when not PLAINTEXT) [as opposed to Basic] 3. Include non-MAC-based signature methods and method negotiation 4. Bind the authenticated entity to the request Why are we dropping RSA? Because there's no developer interest? Because it's kind of redundant with TLS? Something else? --Richard On Nov 28, 2009, at 11:59 PM, Eran Hammer-Lahav wrote: > With the cleanup of the 1.0 specification [1] and the publication of > an informational RFC (pending IESG approval), I no longer see value > in a standard closely based on the 1.0 specification, which was the > original intention of this WG. This is also reflected by the recent > interest in the WRAP proposal [2]. > > Instead, I think we should develop two specifications that while > closely in line with the original plan, represent a significant > shift. In other words, I am proposing we develop OAuth 2.0, not 1.1. > > The new proposal is to develop two specifications: > > 1. Token Authorization Method > > An RFC 2617 Authorization header called 'Token' for authenticating > requests with token-based credentials. Tokens (with optional shared- > secret) are usually used in place of other credentials (usernames, > etc.) and represent some combination of scope and authorization. The > token method will include an extensible signature-based option based > on the HMAC-SHA1 method, and a bearer token (with optional secret) > option based on the PLAINTEXT method. The RSA option will be dropped. > > 2. OAuth 2.0 > > A specification based on the browser-redirection flow described in > OAuth 1.0 as well as new methods defined in WRAP (I-D submission > pending). OAuth will be redefined to cover the authorization > component only, and will no longer be bound to a single > authentication method. This will make OAuth immediately useful for > other protocols than HTTP (while HTTP will be used to obtain tokens, > tokens will be useful in other protocols, not just with the HTTP and > Token method). > > --- > > While the current charter allows much of this work, it contradicts > its spirit and the understanding reached when we created the working > group. > > I would like to ask: > > - Is this approach favorable by the group? > - Do we need to adjust the language in the charter to support? > > EHL > > [1] http://tools.ietf.org/html/draft-hammer-oauth > [2] http://bit.ly/oauth-wrap > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From email@pbryan.net Sun Nov 29 15:08:15 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04DB73A69F5 for ; Sun, 29 Nov 2009 15:08:15 -0800 (PST) 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 X+e1v9nGMPAX for ; Sun, 29 Nov 2009 15:08:14 -0800 (PST) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by core3.amsl.com (Postfix) with ESMTP id 21F523A6893 for ; Sun, 29 Nov 2009 15:08:14 -0800 (PST) Received: from [192.168.0.4] (S010600095baae0ff.vf.shawcable.net [174.1.50.199]) by maple.anode.ca (Postfix) with ESMTPSA id B50FA614E; Sun, 29 Nov 2009 23:08:06 +0000 (UTC) From: "Paul C. Bryan" To: Eran Hammer-Lahav In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343785209A24@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343785209A24@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset="UTF-8" Date: Sun, 29 Nov 2009 15:07:58 -0800 Message-ID: <1259536078.19069.6.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] OAuth 2.0 / Charter X-BeenThere: oauth@ietf.org X-Mailman-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, 29 Nov 2009 23:08:15 -0000 To the overall approach, +1. Some follow-up questions: 1. Why drop RSA? It seems some form of public key cryptography will be necessary/useful to make web-based-attribute-containing tokens Internet-scalable. 2. Is it an objective to have the Token auth-scheme contain extension points so that new token formats can be introduced without need to redefine the scheme or draft a new one? Paul On Sun, 2009-11-29 at 00:59 -0700, Eran Hammer-Lahav wrote: > With the cleanup of the 1.0 specification [1] and the publication of an informational RFC (pending IESG approval), I no longer see value in a standard closely based on the 1.0 specification, which was the original intention of this WG. This is also reflected by the recent interest in the WRAP proposal [2]. > > Instead, I think we should develop two specifications that while closely in line with the original plan, represent a significant shift. In other words, I am proposing we develop OAuth 2.0, not 1.1. > > The new proposal is to develop two specifications: > > 1. Token Authorization Method > > An RFC 2617 Authorization header called 'Token' for authenticating requests with token-based credentials. Tokens (with optional shared-secret) are usually used in place of other credentials (usernames, etc.) and represent some combination of scope and authorization. The token method will include an extensible signature-based option based on the HMAC-SHA1 method, and a bearer token (with optional secret) option based on the PLAINTEXT method. The RSA option will be dropped. > > 2. OAuth 2.0 > > A specification based on the browser-redirection flow described in OAuth 1.0 as well as new methods defined in WRAP (I-D submission pending). OAuth will be redefined to cover the authorization component only, and will no longer be bound to a single authentication method. This will make OAuth immediately useful for other protocols than HTTP (while HTTP will be used to obtain tokens, tokens will be useful in other protocols, not just with the HTTP and Token method). > > --- > > While the current charter allows much of this work, it contradicts its spirit and the understanding reached when we created the working group. > > I would like to ask: > > - Is this approach favorable by the group? > - Do we need to adjust the language in the charter to support? > > EHL > > [1] http://tools.ietf.org/html/draft-hammer-oauth > [2] http://bit.ly/oauth-wrap > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From James.H.Manger@team.telstra.com Sun Nov 29 15:52:14 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 553D93A68A9 for ; Sun, 29 Nov 2009 15:52:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.151 X-Spam-Level: X-Spam-Status: No, score=-1.151 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oaJLR6peGaQT for ; Sun, 29 Nov 2009 15:52:13 -0800 (PST) Received: from mailipao.ntcif.telstra.com.au (mailipao.ntcif.telstra.com.au [202.12.233.27]) by core3.amsl.com (Postfix) with ESMTP id 6F2103A6870 for ; Sun, 29 Nov 2009 15:52:12 -0800 (PST) Received: from unknown (HELO mailai.ntcif.telstra.com.au) ([202.12.162.17]) by mailipai.ntcif.telstra.com.au with ESMTP; 30 Nov 2009 10:52:04 +1100 Received: from mail2.cdn.telstra.com.au (localhost [127.0.0.1]) by mailai.ntcif.telstra.com.au (Postfix) with ESMTP id 2A692FF83 for ; Mon, 30 Nov 2009 10:52:04 +1100 (EST) Received: from WSMSG3755.srv.dir.telstra.com (wsmsg3755.srv.dir.telstra.com [172.49.40.196]) by mail2.cdn.telstra.com.au (Postfix) with ESMTP id 7BE85420C6 for ; Mon, 30 Nov 2009 10:51:19 +1100 (EST) Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3755.srv.dir.telstra.com ([172.49.40.196]) with mapi; Mon, 30 Nov 2009 10:51:39 +1100 From: "Manger, James H" To: "OAuth WG (oauth@ietf.org)" Date: Mon, 30 Nov 2009 10:51:38 +1100 Thread-Topic: OAuth 2.0 / Charter Thread-Index: AcpwydwemcwGclDiS3iUrmJW9KSv5AAf5AKQ Message-ID: <255B9BB34FB7D647A506DC292726F6E1124A724AE4@WSMSG3153V.srv.dir.telstra.com> References: <90C41DD21FB7C64BB94121FBBC2E72343785209A24@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343785209A24@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] OAuth 2.0 / Charter X-BeenThere: oauth@ietf.org X-Mailman-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, 29 Nov 2009 23:52:14 -0000 PiBJIGFtIHByb3Bvc2luZyB3ZSBkZXZlbG9wIE9BdXRoIDIuMCwgbm90IDEuMS4NCj4g4oCmDQo+ IC0gSXMgdGhpcyBhcHByb2FjaCBmYXZvcmFibGUgYnkgdGhlIGdyb3VwPw0KDQpZRVMuDQoNCg0K SmFtZXMgTWFuZ2VyDQo= From eran@hueniverse.com Sun Nov 29 23:29:54 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CD503A6908 for ; Sun, 29 Nov 2009 23:29:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 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 RYq9V9EGCsXX for ; Sun, 29 Nov 2009 23:29:53 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 669263A68B6 for ; Sun, 29 Nov 2009 23:29:53 -0800 (PST) Received: (qmail 9136 invoked from network); 30 Nov 2009 07:29:41 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 30 Nov 2009 07:29:40 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 30 Nov 2009 00:29:39 -0700 From: Eran Hammer-Lahav To: Richard Barnes Date: Mon, 30 Nov 2009 00:29:41 -0700 Thread-Topic: [OAUTH-WG] OAuth 2.0 / Charter Thread-Index: AcpxO7TB9ZdCyqF4SAC2jxR/p8Ft3AAUyCWg Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343785209A59@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343785209A24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <0169BFEE-2317-4767-B998-4A8B3EA627B2@bbn.com> In-Reply-To: <0169BFEE-2317-4767-B998-4A8B3EA627B2@bbn.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] OAuth 2.0 / Charter X-BeenThere: oauth@ietf.org X-Mailman-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, 30 Nov 2009 07:29:54 -0000 This is very much in line with my thinking. EHL > -----Original Message----- > From: Richard Barnes [mailto:rbarnes@bbn.com] > Sent: Sunday, November 29, 2009 1:34 PM > To: Eran Hammer-Lahav > Cc: Peter Saint-Andre (stpeter@stpeter.im); Lisa Dusseault > (lisa.dusseault@gmail.com); OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] OAuth 2.0 / Charter >=20 > Eran, >=20 > A few thoughts on item (1), the authentication method (it is more properl= y > "authentication"). >=20 > I would like to get the group's impressions on what the goals are for ite= m (1), > i.e., what we want the new authentication method to provide that current > methods don't. As I think I said before, my impression is that the whole > "token" aspect of the authentication is not the real value (those are jus= t > additional semantics layered on the bits that carried in the protocol). = Some > candidates for goals: > 1. Work with a single HTTP request (when no negotiation is required) [as > opposed to 2 for Digest] 2. Protect credentials from exposure on the wire > (when not PLAINTEXT) [as opposed to Basic] 3. Include non-MAC-based > signature methods and method negotiation 4. Bind the authenticated entity > to the request >=20 > Why are we dropping RSA? Because there's no developer interest? > Because it's kind of redundant with TLS? Something else? >=20 > --Richard >=20 >=20 >=20 >=20 >=20 >=20 > On Nov 28, 2009, at 11:59 PM, Eran Hammer-Lahav wrote: >=20 > > With the cleanup of the 1.0 specification [1] and the publication of > > an informational RFC (pending IESG approval), I no longer see value in > > a standard closely based on the 1.0 specification, which was the > > original intention of this WG. This is also reflected by the recent > > interest in the WRAP proposal [2]. > > > > Instead, I think we should develop two specifications that while > > closely in line with the original plan, represent a significant shift. > > In other words, I am proposing we develop OAuth 2.0, not 1.1. > > > > The new proposal is to develop two specifications: > > > > 1. Token Authorization Method > > > > An RFC 2617 Authorization header called 'Token' for authenticating > > requests with token-based credentials. Tokens (with optional shared- > > secret) are usually used in place of other credentials (usernames, > > etc.) and represent some combination of scope and authorization. The > > token method will include an extensible signature-based option based > > on the HMAC-SHA1 method, and a bearer token (with optional secret) > > option based on the PLAINTEXT method. The RSA option will be dropped. > > > > 2. OAuth 2.0 > > > > A specification based on the browser-redirection flow described in > > OAuth 1.0 as well as new methods defined in WRAP (I-D submission > > pending). OAuth will be redefined to cover the authorization component > > only, and will no longer be bound to a single authentication method. > > This will make OAuth immediately useful for other protocols than HTTP > > (while HTTP will be used to obtain tokens, tokens will be useful in > > other protocols, not just with the HTTP and Token method). > > > > --- > > > > While the current charter allows much of this work, it contradicts its > > spirit and the understanding reached when we created the working > > group. > > > > I would like to ask: > > > > - Is this approach favorable by the group? > > - Do we need to adjust the language in the charter to support? > > > > EHL > > > > [1] http://tools.ietf.org/html/draft-hammer-oauth > > [2] http://bit.ly/oauth-wrap > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Sun Nov 29 23:34:08 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1B763A69F7 for ; Sun, 29 Nov 2009 23:34:08 -0800 (PST) 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 krPYEjNnYnLH for ; Sun, 29 Nov 2009 23:34:08 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 18A3A3A6919 for ; Sun, 29 Nov 2009 23:34:08 -0800 (PST) Received: (qmail 9722 invoked from network); 30 Nov 2009 07:34:01 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 30 Nov 2009 07:34:01 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Mon, 30 Nov 2009 00:34:01 -0700 From: Eran Hammer-Lahav To: "Paul C. Bryan" Date: Mon, 30 Nov 2009 00:34:03 -0700 Thread-Topic: [OAUTH-WG] OAuth 2.0 / Charter Thread-Index: AcpxSNFz/MEp+KVqRhe6EKTDjUfKEAARixFg Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343785209A5A@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343785209A24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1259536078.19069.6.camel@localhost> In-Reply-To: <1259536078.19069.6.camel@localhost> 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] OAuth 2.0 / Charter X-BeenThere: oauth@ietf.org X-Mailman-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, 30 Nov 2009 07:34:08 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUGF1bCBDLiBCcnlhbiBb bWFpbHRvOmVtYWlsQHBicnlhbi5uZXRdDQo+IFNlbnQ6IFN1bmRheSwgTm92ZW1iZXIgMjksIDIw MDkgMzowOCBQTQ0KPiBUbzogRXJhbiBIYW1tZXItTGFoYXYNCj4gQ2M6IFBldGVyIFNhaW50LUFu ZHJlIChzdHBldGVyQHN0cGV0ZXIuaW0pOyBMaXNhIER1c3NlYXVsdA0KPiAobGlzYS5kdXNzZWF1 bHRAZ21haWwuY29tKTsgT0F1dGggV0cgKG9hdXRoQGlldGYub3JnKQ0KPiBTdWJqZWN0OiBSZTog W09BVVRILVdHXSBPQXV0aCAyLjAgLyBDaGFydGVyDQo+IA0KPiBUbyB0aGUgb3ZlcmFsbCBhcHBy b2FjaCwgKzEuDQo+IA0KPiBTb21lIGZvbGxvdy11cCBxdWVzdGlvbnM6DQo+IA0KPiAxLiBXaHkg ZHJvcCBSU0E/IEl0IHNlZW1zIHNvbWUgZm9ybSBvZiBwdWJsaWMga2V5IGNyeXB0b2dyYXBoeSB3 aWxsIGJlDQo+IG5lY2Vzc2FyeS91c2VmdWwgdG8gbWFrZSB3ZWItYmFzZWQtYXR0cmlidXRlLWNv bnRhaW5pbmcgdG9rZW5zIEludGVybmV0LQ0KPiBzY2FsYWJsZS4NCg0KTW9zdGx5IGR1ZSB0byBs YWNrIG9mIGltcGxlbWVudGF0aW9uIGV4cGVyaWVuY2Ugb3IgaW50ZXJlc3Qgd2l0aGluIHRoZSBP QXV0aCBjb21tdW5pdHkuIEJ1dCBhbHNvIGJlY2F1c2UgdGhlIFBsYWluIGFuZCBNQUMgdmVyc2lv bnMgYXJlIGJhc2VkIG9uIGEgc2ltcGxlIHN5bW1ldHJpYyBzaGFyZWQgc2VjcmV0LCB3aGlsZSBQ SyByZXF1aXJlcyBtb3JlLiBUaGlzIG1lYW5zIHdlIHdpbGwgbmVlZCB0byBzdXBwb3J0IGRpZmZl cmVudCB0eXBlcyBvZiB0b2tlbnMuIFdoaWxlIEkgYW0gb3BlbiB0byB0aGlzIGlmIG5lZWRlZCwg aXQgc2VlbXMgdG8gYWRkIGEgc2lnbmlmaWNhbnQgY29tcGxleGl0eS4gQWxzbywgcGFydCAyIHdp bGwgdGhlbiBuZWVkIHRvIGJlIGFibGUgdG8gcHJvdmlzaW9uIGJvdGggc3ltbWV0cmljIGFuZCBh c3ltbWV0cmljIHNlY3JldHMgd2hpY2ggYWRkcyB0byB0aGUgY29tcGxleGl0eSB0aGVyZS4NCg0K SW4gb3RoZXIgd29yZHMsIHdoeSBwdXQgdGhlIGVmZm9ydCBpbiBpZiBubyBvbmUgaXMgYXNraW5n IGZvciB0aGlzIChiYXNlZCBvbiAyIHllYXJzIG9mIGRlcGxveW1lbnQgZXhwZXJpZW5jZSkuDQoN Cj4gMi4gSXMgaXQgYW4gb2JqZWN0aXZlIHRvIGhhdmUgdGhlIFRva2VuIGF1dGgtc2NoZW1lIGNv bnRhaW4gZXh0ZW5zaW9uIHBvaW50cw0KPiBzbyB0aGF0IG5ldyB0b2tlbiBmb3JtYXRzIGNhbiBi ZSBpbnRyb2R1Y2VkIHdpdGhvdXQgbmVlZCB0byByZWRlZmluZSB0aGUNCj4gc2NoZW1lIG9yIGRy YWZ0IGEgbmV3IG9uZT8NCg0KWWVzLCBidXQgc2VlIGFib3ZlLg0KDQpFSEwNCg== From eran@hueniverse.com Sun Nov 29 23:36:15 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 319CC3A6911 for ; Sun, 29 Nov 2009 23:36:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.150, 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 wpLa78Mhuyol for ; Sun, 29 Nov 2009 23:36:07 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 93DCA28B56A for ; Sun, 29 Nov 2009 23:36:07 -0800 (PST) Received: (qmail 9859 invoked from network); 30 Nov 2009 07:36:01 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 30 Nov 2009 07:36:00 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Mon, 30 Nov 2009 00:36:00 -0700 From: Eran Hammer-Lahav To: Greg Brail Date: Mon, 30 Nov 2009 00:36:02 -0700 Thread-Topic: OAuth 2.0 / Charter Thread-Index: AcpwydwemcwGclDiS3iUrmJW9KSv5AArlwTgAAXaE8A= Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343785209A5B@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343785209A24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <48AE706BD74FCC4297AD778805CA46F6184C5CF474@usps.sonoa.local> In-Reply-To: <48AE706BD74FCC4297AD778805CA46F6184C5CF474@usps.sonoa.local> 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_90C41DD21FB7C64BB94121FBBC2E72343785209A5BP3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] OAuth 2.0 / Charter X-BeenThere: oauth@ietf.org X-Mailman-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, 30 Nov 2009 07:36:15 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343785209A5BP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Keep in mind that we are not going to include token structure in scope. We = are simply proposing a method in which the token is a string, leaving it up= to other efforts to give it structure if needed. EHL From: Greg Brail [mailto:gbrail@sonoasystems.com] Sent: Sunday, November 29, 2009 9:05 PM To: Eran Hammer-Lahav Cc: OAuth WG (oauth@ietf.org) Subject: RE: OAuth 2.0 / Charter I've been following this discussion for a while now as a relative newcomer = and I think this is a great idea. Forgive me if all you guys have reached t= his conclusion already: Since we all understand OAuth, there are other places where tokens are popp= ing up: * As a "more secure" replacement for username / password authenticatio= n in web services APIs like Amazon's * As a way for the developer of an API to understand which developer's= applications are being used against the API, when it is less important to = identify the actual user (for instance, the classical "API key" use case, o= r "two-legged OAuth") * As a way for the developer of a mobile app to ensure that only that = app can make use of a particular web service, even if it is not important t= o identify the actual user * Lots of others I'm sure I'm missing The sooner there is some movement towards a standard "token," the sooner we= will have token support in a variety of programming environments. Plus, a = standard token will reduce the propensity of web services builders to desig= n their own tokens, with varying levels of security. Plus, the OAuth flow has clearly proven to be useful and it deserves to be = a standard that makes use of the standard token. On the design of the token itself, I hope that it will have a place for one= , two, or even more combinations of keys and secrets, so that it can handle= simple use cases, more complex use cases such as OAuth, and even those tha= t require three or more separate identifiers for a request. greg -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Sunday, November 29, 2009 2:59 AM To: Peter Saint-Andre (stpeter@stpeter.im); Lisa Dusseault (lisa.dusseault@= gmail.com) Cc: OAuth WG (oauth@ietf.org) Subject: [OAUTH-WG] OAuth 2.0 / Charter With the cleanup of the 1.0 specification [1] and the publication of an inf= ormational RFC (pending IESG approval), I no longer see value in a standard= closely based on the 1.0 specification, which was the original intention o= f this WG. This is also reflected by the recent interest in the WRAP propos= al [2]. Instead, I think we should develop two specifications that while closely in= line with the original plan, represent a significant shift. In other words= , I am proposing we develop OAuth 2.0, not 1.1. The new proposal is to develop two specifications: 1. Token Authorization Method An RFC 2617 Authorization header called 'Token' for authenticating requests= with token-based credentials. Tokens (with optional shared-secret) are usu= ally used in place of other credentials (usernames, etc.) and represent som= e combination of scope and authorization. The token method will include an = extensible signature-based option based on the HMAC-SHA1 method, and a bear= er token (with optional secret) option based on the PLAINTEXT method. The R= SA option will be dropped. 2. OAuth 2.0 A specification based on the browser-redirection flow described in OAuth 1.= 0 as well as new methods defined in WRAP (I-D submission pending). OAuth wi= ll be redefined to cover the authorization component only, and will no long= er be bound to a single authentication method. This will make OAuth immedia= tely useful for other protocols than HTTP (while HTTP will be used to obtai= n tokens, tokens will be useful in other protocols, not just with the HTTP = and Token method). --- While the current charter allows much of this work, it contradicts its spir= it and the understanding reached when we created the working group. I would like to ask: - Is this approach favorable by the group? - Do we need to adjust the language in the charter to support? EHL [1] http://tools.ietf.org/html/draft-hammer-oauth [2] http://bit.ly/oauth-wrap _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_90C41DD21FB7C64BB94121FBBC2E72343785209A5BP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Keep in m= ind that we are not going to include token structure in scope. We are simpl= y proposing a method in which the token is a string, leaving it up to other= efforts to give it structure if needed.

 

EHL<= o:p>

 

From: Greg Brail [mailto:gbrail@s= onoasystems.com]
Sent: Sunday, November 29, 2009 9:05 PM
T= o: Eran Hammer-Lahav
Cc: OAuth WG (oauth@ietf.org)
Subj= ect: RE: OAuth 2.0 / Charter

 

I’ve been f= ollowing this discussion for a while now as a relative newcomer and I think= this is a great idea. Forgive me if all you guys have reached this conclus= ion already:

 

Since we all understand OAuth, there are other places = where tokens are popping up:

&nb= sp;

·      = As a “more secure” replacement for username / passwor= d authentication in web services APIs like Amazon’s

·      As a w= ay for the developer of an API to understand which developer’s applic= ations are being used against the API, when it is less important to identif= y the actual user (for instance, the classical “API key” use ca= se, or “two-legged OAuth”)

·  =     As a way for the develope= r of a mobile app to ensure that only that app can make use of a particular= web service, even if it is not important to identify the actual user<= /o:p>

·      Lots of others I’m sure I’m missing

 

The sooner th= ere is some movement towards a standard “token,” the sooner we = will have token support in a variety of programming environments. Plus, a s= tandard token will reduce the propensity of web services builders to design= their own tokens, with varying levels of security.

 

Plus, the OAut= h flow has clearly proven to be useful and it deserves to be a standard tha= t makes use of the standard token.

 

On the design of the token itsel= f, I hope that it will have a place for one, two, or even more combinations= of keys and secrets, so that it can handle simple use cases, more complex = use cases such as OAuth, and even those that require three or more separate= identifiers for a request.

&nbs= p;

      &nb= sp;            =             &nb= sp;            =             &nb= sp;   greg

 

-----Original Message-----
From: oauth-boun= ces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Eran Hammer-Lahav=
Sent: Sunday, November 29, 2009 2:59 AM
To: Peter Saint-Andre (stpet= er@stpeter.im); Lisa Dusseault (lisa.dusseault@gmail.com)
Cc: OAuth WG (= oauth@ietf.org)
Subject: [OAUTH-WG] OAuth 2.0 / Charter

 

With the= cleanup of the 1.0 specification [1] and the publication of an information= al RFC (pending IESG approval), I no longer see value in a standard closely= based on the 1.0 specification, which was the original intention of this W= G. This is also reflected by the recent interest in the WRAP proposal [2].<= o:p>

 

Instead, I think we should develop two specifications that while cl= osely in line with the original plan, represent a significant shift. In oth= er words, I am proposing we develop OAuth 2.0, not 1.1.

 

The new pro= posal is to develop two specifications:

 

1. Token Authorization Meth= od

 

An RFC 2617 Authorization header called 'Token' for authenticati= ng requests with token-based credentials. Tokens (with optional shared-secr= et) are usually used in place of other credentials (usernames, etc.) and re= present some combination of scope and authorization. The token method will = include an extensible signature-based option based on the HMAC-SHA1 method,= and a bearer token (with optional secret) option based on the PLAINTEXT me= thod. The RSA option will be dropped.

 

2. OAuth 2.0

<= p class=3DMsoPlainText> 

A speci= fication based on the browser-redirection flow described in OAuth 1.0 as we= ll as new methods defined in WRAP (I-D submission pending). OAuth will be r= edefined to cover the authorization component only, and will no longer be b= ound to a single authentication method. This will make OAuth immediately us= eful for other protocols than HTTP (while HTTP will be used to obtain token= s, tokens will be useful in other protocols, not just with the HTTP and Tok= en method).

 

---

 

While the current charter allows much of th= is work, it contradicts its spirit and the understanding reached when we cr= eated the working group.

 =

I would like to ask:

 

- Is this ap= proach favorable by the group?

- Do w= e need to adjust the language in the charter to support?

 

EHL

 

[1] http://tool= s.ietf.org/html/draft-hammer-oauth

[2] http://bit.ly/oauth-wrap

 

_______________________________________________

OAuth mailing list

OAuth@ietf.org

htt= ps://www.ietf.org/mailman/listinfo/oauth

= --_000_90C41DD21FB7C64BB94121FBBC2E72343785209A5BP3PW5EX1MB01E_-- From jonathan_moore@comcast.com Mon Nov 30 06:22:21 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50B833A67F9 for ; Mon, 30 Nov 2009 06:22:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.463 X-Spam-Level: X-Spam-Status: No, score=-8.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, 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 f4U+12lc1JMA for ; Mon, 30 Nov 2009 06:22:20 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 3AE683A67B0 for ; Mon, 30 Nov 2009 06:22:19 -0800 (PST) Received: from ([10.52.116.31]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.62519651; Mon, 30 Nov 2009 09:22:09 -0500 Received: from PACORPEXCMB03.cable.comcast.com ([24.40.15.85]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Nov 2009 09:22:09 -0500 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, 30 Nov 2009 09:22:08 -0500 Message-ID: In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343785209A5A@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: keeping support for RSA (Was: RE: [OAUTH-WG] OAuth 2.0 / Charter) Thread-Index: AcpxSNFz/MEp+KVqRhe6EKTDjUfKEAARixFgAA3su5A= References: <90C41DD21FB7C64BB94121FBBC2E72343785209A24@P3PW5EX1MB01.EX1.SECURESERVER.NET><1259536078.19069.6.camel@localhost> <90C41DD21FB7C64BB94121FBBC2E72343785209A5A@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: "Moore, Jonathan (CIM)" To: "Eran Hammer-Lahav" , "Paul C. Bryan" X-OriginalArrivalTime: 30 Nov 2009 14:22:09.0958 (UTC) FILETIME=[80AB2C60:01CA71C8] Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] keeping support for RSA (Was: RE: OAuth 2.0 / Charter) X-BeenThere: oauth@ietf.org X-Mailman-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, 30 Nov 2009 14:22:21 -0000 Eran Hammer-Lahav writes, with respect to RSA support: > In other words, why put the effort in if no one is asking for this > (based on 2 years of deployment experience). Ok, I'll ask for it then! Our main use cases for OAuth 1.0 have been for 2-legged, server-to-server integrations with known third parties. Public key cryptography offers a lot of advantages here in terms of ease of properly making a secure association between organizations. At least in our shop, it's considerably easier for us to deal with PKI than it is to set up SSL endpoints and/or run internal CAs. Also, and especially when the response *body* does not require privacy, I'd much rather spend my CPU cycles doing public-key cryptography on the HTTP headers than encrypting an entire response payload via SSL. I also lose the benefits of HTTP intermediaries when I have to tunnel over SSL. I'm happy to participate here to work to keep this support in OAuth 2.0 (I'm just coming up to speed on the WG here). Thanks, Jon ........ Jon Moore Comcast Interactive Media -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Eran Hammer-Lahav Sent: Monday, November 30, 2009 2:34 AM To: Paul C. Bryan Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] OAuth 2.0 / Charter > -----Original Message----- > From: Paul C. Bryan [mailto:email@pbryan.net] > Sent: Sunday, November 29, 2009 3:08 PM > To: Eran Hammer-Lahav > Cc: Peter Saint-Andre (stpeter@stpeter.im); Lisa Dusseault > (lisa.dusseault@gmail.com); OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] OAuth 2.0 / Charter >=20 > To the overall approach, +1. >=20 > Some follow-up questions: >=20 > 1. Why drop RSA? It seems some form of public key cryptography will be > necessary/useful to make web-based-attribute-containing tokens Internet- > scalable. Mostly due to lack of implementation experience or interest within the OAuth community. But also because the Plain and MAC versions are based on a simple symmetric shared secret, while PK requires more. This means we will need to support different types of tokens. While I am open to this if needed, it seems to add a significant complexity. Also, part 2 will then need to be able to provision both symmetric and asymmetric secrets which adds to the complexity there. In other words, why put the effort in if no one is asking for this (based on 2 years of deployment experience). > 2. Is it an objective to have the Token auth-scheme contain extension points > so that new token formats can be introduced without need to redefine the > scheme or draft a new one? Yes, but see above. EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From lindner@inuus.com Mon Nov 30 06:27:38 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C310A28C112 for ; Mon, 30 Nov 2009 06:27:38 -0800 (PST) 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 U7zDsqQuDBbP for ; Mon, 30 Nov 2009 06:27:37 -0800 (PST) Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by core3.amsl.com (Postfix) with ESMTP id B78093A67F9 for ; Mon, 30 Nov 2009 06:27:37 -0800 (PST) Received: by pzk6 with SMTP id 6so2463518pzk.29 for ; Mon, 30 Nov 2009 06:27:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.142.9.32 with SMTP id 32mr452526wfi.112.1259591248426; Mon, 30 Nov 2009 06:27:28 -0800 (PST) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E72343785209A24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1259536078.19069.6.camel@localhost> <90C41DD21FB7C64BB94121FBBC2E72343785209A5A@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 30 Nov 2009 06:27:28 -0800 Message-ID: From: Paul Lindner To: "Moore, Jonathan (CIM)" Content-Type: multipart/alternative; boundary=00504502b855ecb7f6047997708a Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] keeping support for RSA (Was: RE: OAuth 2.0 / Charter) X-BeenThere: oauth@ietf.org X-Mailman-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, 30 Nov 2009 14:27:38 -0000 --00504502b855ecb7f6047997708a Content-Type: text/plain; charset=ISO-8859-1 Also note that Opensocial uses RSA signed 2-legged requests extensively. Billions of calls are made this way and the code to receive them is in wide use. On Mon, Nov 30, 2009 at 6:22 AM, Moore, Jonathan (CIM) < Jonathan_Moore@comcast.com> wrote: > Eran Hammer-Lahav writes, with respect to RSA support: > > In other words, why put the effort in if no one is asking for this > > (based on 2 years of deployment experience). > > Ok, I'll ask for it then! Our main use cases for OAuth 1.0 have been for > 2-legged, server-to-server integrations with known third parties. Public > key cryptography offers a lot of advantages here in terms of ease of > properly making a secure association between organizations. At least in > our shop, it's considerably easier for us to deal with PKI than it is to > set up SSL endpoints and/or run internal CAs. > > Also, and especially when the response *body* does not require privacy, > I'd much rather spend my CPU cycles doing public-key cryptography on the > HTTP headers than encrypting an entire response payload via SSL. I also > lose the benefits of HTTP intermediaries when I have to tunnel over SSL. > > I'm happy to participate here to work to keep this support in OAuth 2.0 > (I'm just coming up to speed on the WG here). > > Thanks, > Jon > ........ > Jon Moore > Comcast Interactive Media > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Eran Hammer-Lahav > Sent: Monday, November 30, 2009 2:34 AM > To: Paul C. Bryan > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] OAuth 2.0 / Charter > > > > > -----Original Message----- > > From: Paul C. Bryan [mailto:email@pbryan.net] > > Sent: Sunday, November 29, 2009 3:08 PM > > To: Eran Hammer-Lahav > > Cc: Peter Saint-Andre (stpeter@stpeter.im); Lisa Dusseault > > (lisa.dusseault@gmail.com); OAuth WG (oauth@ietf.org) > > Subject: Re: [OAUTH-WG] OAuth 2.0 / Charter > > > > To the overall approach, +1. > > > > Some follow-up questions: > > > > 1. Why drop RSA? It seems some form of public key cryptography will be > > necessary/useful to make web-based-attribute-containing tokens > Internet- > > scalable. > > Mostly due to lack of implementation experience or interest within the > OAuth community. But also because the Plain and MAC versions are based > on a simple symmetric shared secret, while PK requires more. This means > we will need to support different types of tokens. While I am open to > this if needed, it seems to add a significant complexity. Also, part 2 > will then need to be able to provision both symmetric and asymmetric > secrets which adds to the complexity there. > > In other words, why put the effort in if no one is asking for this > (based on 2 years of deployment experience). > > > 2. Is it an objective to have the Token auth-scheme contain extension > points > > so that new token formats can be introduced without need to redefine > the > > scheme or draft a new one? > > Yes, but see above. > > 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 > --00504502b855ecb7f6047997708a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Also note that Opensocial uses RSA signed 2-legged requests extensively. = =A0Billions of calls are made this way and the code to receive them is in w= ide use.

On Mon, Nov 30, 2009 at 6:22 AM,= Moore, Jonathan (CIM) <Jonathan_Moore@comcast.com> wrote:
Eran Hammer-Lahav writes, with respect to R= SA support:
> In other words, why put the effort in if no one is asking for this
> (based on 2 years of deployment experience).

Ok, I'll ask for it then! Our main use cases for OAuth 1.0 have been fo= r
2-legged, server-to-server integrations with known third parties. Public key cryptography offers a lot of advantages here in terms of ease of
properly making a secure association between organizations. At least in
our shop, it's considerably easier for us to deal with PKI than it is t= o
set up SSL endpoints and/or run internal CAs.

Also, and especially when the response *body* does not require privacy,
I'd much rather spend my CPU cycles doing public-key cryptography on th= e
HTTP headers than encrypting an entire response payload via SSL. I also
lose the benefits of HTTP intermediaries when I have to tunnel over SSL.
I'm happy to participate here to work to keep this support in OAuth 2.0=
(I'm just coming up to speed on the WG here).

Thanks,
Jon
........
Jon Moore
Comcast Interactive Media

-----Original Message-----
From: oauth-bounces@ietf.org = [mailto:oauth-bounces@ietf.org] On Behalf
Of Eran Hammer-Lahav
Sent: Monday, November 30, 2009 2:34 AM
To: Paul C. Bryan
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] OAuth 2.0 / Charter



> -----Original Message-----
> From: Paul C. Bryan [mailto:email@= pbryan.net]
> Sent: Sunday, November 29, 2009 3:08 PM
> To: Eran Hammer-Lahav
> Cc: Peter Saint-Andre (stpeter@s= tpeter.im); Lisa Dusseault
> (lisa.dusseault@gmail.com<= /a>); OAuth WG (oauth@ietf.org)
> Subject: Re: [OAUTH-WG] OAuth 2.0 / Charter
>
> To the overall approach, +1.
>
> Some follow-up questions:
>
> 1. Why drop RSA? It seems some form of public key cryptography will be=
> necessary/useful to make web-based-attribute-containing tokens
Internet-
> scalable.

Mostly due to lack of implementation experience or interest within the
OAuth community. But also because the Plain and MAC versions are based
on a simple symmetric shared secret, while PK requires more. This means
we will need to support different types of tokens. While I am open to
this if needed, it seems to add a significant complexity. Also, part 2
will then need to be able to provision both symmetric and asymmetric
secrets which adds to the complexity there.

In other words, why put the effort in if no one is asking for this
(based on 2 years of deployment experience).

> 2. Is it an objective to have the Token auth-scheme contain extension<= br> points
> so that new token formats can be introduced without need to redefine the
> scheme or draft a new one?

Yes, but see above.

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

--00504502b855ecb7f6047997708a-- From pelleb@gmail.com Mon Nov 30 07:53:44 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D79A28C11C for ; Mon, 30 Nov 2009 07:53:44 -0800 (PST) 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 SMPUyOH1qJyQ for ; Mon, 30 Nov 2009 07:53:43 -0800 (PST) Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id 3FA8D3A67E3 for ; Mon, 30 Nov 2009 07:53:42 -0800 (PST) Received: by fxm5 with SMTP id 5so3833897fxm.28 for ; Mon, 30 Nov 2009 07:53:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=MoI4gpa3P5/maUre/zF3iDAgjBHknCDjphzPtkjDwRQ=; b=M5pfI1HI9pHmZsjR5TF6DENaXpH11dORQtOGuJY9OHcbDJcAIPjGAg9U0sqm7pxijv 72KFsvsiTtlTP1+dHuuMIfoyL6lxTd93MvfU4K9Qn6fE0+r/UYfYBapApLfP0ZQrwM52 rZVIhuPFZP8Hj3CXMtJh3dh7pWC8yEHqG0gQk= 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=ST95FYmTOlizu0Gyrq/RHhZVic2la9nN1XK0G+19SMp6BpmDX4prkZRnNV+ivhlx9W vUBeTKhn9lPqxL/Kf9ZuiQOkV30ZwD0Vzb9h/zc6RcocKQnHNnPkFn8OSFQdn6+2l2h/ YPjbPugQhAyHOjonCDH4WxUWpEvJB6PXG0tXE= MIME-Version: 1.0 Sender: pelleb@gmail.com Received: by 10.223.68.155 with SMTP id v27mr681974fai.10.1259596412468; Mon, 30 Nov 2009 07:53:32 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343785209A5A@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343785209A24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1259536078.19069.6.camel@localhost> <90C41DD21FB7C64BB94121FBBC2E72343785209A5A@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 30 Nov 2009 10:53:32 -0500 X-Google-Sender-Auth: e466e7edd46e77bd Message-ID: From: Pelle Braendgaard To: Eran Hammer-Lahav Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] OAuth 2.0 / Charter X-BeenThere: oauth@ietf.org X-Mailman-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, 30 Nov 2009 15:53:44 -0000 +1 for all minus dropping RSA. I think the main reason we haven't seen a lot of RSA implementations yet has been because the kind of businesses who I think would be interested in using this such as banks/payments etc are not traditionally early adopters. If we want to see OAUTH used in these areas in the future I think it would be a very good idea to leave it in. I am personally working on creating new OAuth based financial transaction standard called OpenTransact, where we are planning on standardizing on RSA in the next revision. Regards Pelle On Mon, Nov 30, 2009 at 2:34 AM, Eran Hammer-Lahav wr= ote: > > >> -----Original Message----- >> From: Paul C. Bryan [mailto:email@pbryan.net] >> Sent: Sunday, November 29, 2009 3:08 PM >> To: Eran Hammer-Lahav >> Cc: Peter Saint-Andre (stpeter@stpeter.im); Lisa Dusseault >> (lisa.dusseault@gmail.com); OAuth WG (oauth@ietf.org) >> Subject: Re: [OAUTH-WG] OAuth 2.0 / Charter >> >> To the overall approach, +1. >> >> Some follow-up questions: >> >> 1. Why drop RSA? It seems some form of public key cryptography will be >> necessary/useful to make web-based-attribute-containing tokens Internet- >> scalable. > > Mostly due to lack of implementation experience or interest within the OA= uth community. But also because the Plain and MAC versions are based on a s= imple symmetric shared secret, while PK requires more. This means we will n= eed to support different types of tokens. While I am open to this if needed= , it seems to add a significant complexity. Also, part 2 will then need to = be able to provision both symmetric and asymmetric secrets which adds to th= e complexity there. > > In other words, why put the effort in if no one is asking for this (based= on 2 years of deployment experience). > >> 2. Is it an objective to have the Token auth-scheme contain extension po= ints >> so that new token formats can be introduced without need to redefine the >> scheme or draft a new one? > > Yes, but see above. > > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 http://agree2.com - Reach Agreement! http://extraeagle.com - Solutions for the electronic Extra Legal world http://stakeventures.com - Bootstrapping blog From beaton@google.com Mon Nov 30 09:29:11 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A45323A6AD7 for ; Mon, 30 Nov 2009 09:29:11 -0800 (PST) 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 RJ3Q4mAIcnix for ; Mon, 30 Nov 2009 09:29:11 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id 79AC53A6359 for ; Mon, 30 Nov 2009 09:29:10 -0800 (PST) Received: from zps35.corp.google.com (zps35.corp.google.com [172.25.146.35]) by smtp-out.google.com with ESMTP id nAUHT2vG013046 for ; Mon, 30 Nov 2009 09:29:02 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1259602142; bh=p9pnAeA1bCkXsHFkTMzGgJz2b58=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=aGODAXKiumranAWwnwUI6vtZ7kK2duAvyFu4kTllePxhzUGQWWQGt4tlVEcLsb9+V bLKv0CufDncCcZu31mCng== 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=hE56ALeGkX3qmzYTHpGJpVwVaMOsprcCyfGW58GWGN9ERPxGseSPyzzvuEFg8RnC+ ByQ3rHuo0Xh35Q55SWX2A== Received: from pxi3 (pxi3.prod.google.com [10.243.27.3]) by zps35.corp.google.com with ESMTP id nAUHSRu7028345 for ; Mon, 30 Nov 2009 09:29:00 -0800 Received: by pxi3 with SMTP id 3so2946688pxi.22 for ; Mon, 30 Nov 2009 09:28:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.126.10 with SMTP id y10mr289535rvc.90.1259602138657; Mon, 30 Nov 2009 09:28:58 -0800 (PST) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E72343785209A24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1259536078.19069.6.camel@localhost> <90C41DD21FB7C64BB94121FBBC2E72343785209A5A@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 30 Nov 2009 09:28:58 -0800 Message-ID: From: Brian Eaton To: "Moore, Jonathan (CIM)" Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] keeping support for RSA (Was: RE: OAuth 2.0 / Charter) X-BeenThere: oauth@ietf.org X-Mailman-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, 30 Nov 2009 17:29:11 -0000 On Mon, Nov 30, 2009 at 6:22 AM, Moore, Jonathan (CIM) wrote: > Ok, I'll ask for it then! Our main use cases for OAuth 1.0 have been for > 2-legged, server-to-server integrations with known third parties. Public > key cryptography offers a lot of advantages here in terms of ease of > properly making a secure association between organizations. At least in > our shop, it's considerably easier for us to deal with PKI than it is to > set up SSL endpoints and/or run internal CAs. Yes. This is *huge*. It's not the most visible use case for OAuth (it doesn't demo well, because it just works =), but it is incredibly important. Cheers, Brian From hans@granqvist.com Mon Nov 30 09:31:27 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25A6328C17F for ; Mon, 30 Nov 2009 09:31:27 -0800 (PST) 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 Wf5ineJKmCtZ for ; Mon, 30 Nov 2009 09:31:25 -0800 (PST) Received: from mail-px0-f184.google.com (mail-px0-f184.google.com [209.85.216.184]) by core3.amsl.com (Postfix) with ESMTP id 019C53A67F2 for ; Mon, 30 Nov 2009 09:31:24 -0800 (PST) Received: by pxi14 with SMTP id 14so2822547pxi.31 for ; Mon, 30 Nov 2009 09:31:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.115.84.40 with SMTP id m40mr8130050wal.192.1259602274544; Mon, 30 Nov 2009 09:31:14 -0800 (PST) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E72343785209A24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1259536078.19069.6.camel@localhost> <90C41DD21FB7C64BB94121FBBC2E72343785209A5A@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 30 Nov 2009 09:31:14 -0800 Message-ID: From: Hans Granqvist To: "OAuth WG (oauth@ietf.org)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [OAUTH-WG] OAuth 2.0 / Charter X-BeenThere: oauth@ietf.org X-Mailman-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, 30 Nov 2009 17:31:27 -0000 It's tricky. If you allow only MACs, you have to forgo no only RSA (and ECC...) but also potentially traditional symmetric key schemes -- their usability notwithstanding. On the other hand, if you try to cover all possible key schemes, it quickly becomes unmanageable. Eran, is there a way to define what you want and leave it open for, say an RSA extension, as long as it can be represented as a string, such as {ALGORITHM}:{STRING}, and where any extra protocol flows are out of this specification's scope? -Hans On Mon, Nov 30, 2009 at 7:53 AM, Pelle Braendgaard wrote: > +1 for all minus dropping RSA. > > I think the main reason we haven't seen a lot of RSA implementations > yet has been because the kind of businesses who I think would be > interested in using this such as banks/payments etc are not > traditionally early adopters. If we want to see OAUTH used in these > areas in the future I think it would be a very good idea to leave it > in. > > I am personally working on creating new OAuth based financial > transaction standard called OpenTransact, where we are planning on > standardizing on RSA in the next revision. > > Regards > Pelle > > > On Mon, Nov 30, 2009 at 2:34 AM, Eran Hammer-Lahav = wrote: >> >> >>> -----Original Message----- >>> From: Paul C. Bryan [mailto:email@pbryan.net] >>> Sent: Sunday, November 29, 2009 3:08 PM >>> To: Eran Hammer-Lahav >>> Cc: Peter Saint-Andre (stpeter@stpeter.im); Lisa Dusseault >>> (lisa.dusseault@gmail.com); OAuth WG (oauth@ietf.org) >>> Subject: Re: [OAUTH-WG] OAuth 2.0 / Charter >>> >>> To the overall approach, +1. >>> >>> Some follow-up questions: >>> >>> 1. Why drop RSA? It seems some form of public key cryptography will be >>> necessary/useful to make web-based-attribute-containing tokens Internet= - >>> scalable. >> >> Mostly due to lack of implementation experience or interest within the O= Auth community. But also because the Plain and MAC versions are based on a = simple symmetric shared secret, while PK requires more. This means we will = need to support different types of tokens. While I am open to this if neede= d, it seems to add a significant complexity. Also, part 2 will then need to= be able to provision both symmetric and asymmetric secrets which adds to t= he complexity there. >> >> In other words, why put the effort in if no one is asking for this (base= d on 2 years of deployment experience). >> >>> 2. Is it an objective to have the Token auth-scheme contain extension p= oints >>> so that new token formats can be introduced without need to redefine th= e >>> scheme or draft a new one? >> >> Yes, but see above. >> >> EHL >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > > > -- > http://agree2.com - Reach Agreement! > http://extraeagle.com - Solutions for the electronic Extra Legal world > http://stakeventures.com - Bootstrapping blog > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From jpanzer@google.com Mon Nov 30 09:43:49 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B49FF3A6959 for ; Mon, 30 Nov 2009 09:43:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.842 X-Spam-Level: X-Spam-Status: No, score=-105.842 tagged_above=-999 required=5 tests=[AWL=0.134, 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 RziaOY7DGUUp for ; Mon, 30 Nov 2009 09:43:48 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id EC9DA3A6838 for ; Mon, 30 Nov 2009 09:43:47 -0800 (PST) Received: from wpaz5.hot.corp.google.com (wpaz5.hot.corp.google.com [172.24.198.69]) by smtp-out.google.com with ESMTP id nAUHheHL018660 for ; Mon, 30 Nov 2009 09:43:40 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1259603021; bh=gm56bEkZdQg+JwXW541Mkobffz0=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=ge8fdx6rrzkriSczouKeEYdjXje5XrruNvoHxvS2xUa9EhGxG4KUO40kRy6mMyc1D GD2Yns38PxZYuVQKfPMpg== 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=rtOkAGVt4y8H8QdzzeRs+61T/jWYWFids57UAJxMK3/y8WqlxMteb4vvP17qxpAEg yBX6U0MMg2jfWQVIjsPRA== Received: from pzk12 (pzk12.prod.google.com [10.243.19.140]) by wpaz5.hot.corp.google.com with ESMTP id nAUHhSEV026865 for ; Mon, 30 Nov 2009 09:43:38 -0800 Received: by pzk12 with SMTP id 12so2582680pzk.13 for ; Mon, 30 Nov 2009 09:43:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.115.26.2 with SMTP id d2mr8286118waj.14.1259603011246; Mon, 30 Nov 2009 09:43:31 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343785209A24@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343785209A24@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: John Panzer Date: Mon, 30 Nov 2009 09:43:11 -0800 Message-ID: To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=0016367b6b360b760b04799a2ede X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] OAuth 2.0 / Charter X-BeenThere: oauth@ietf.org X-Mailman-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, 30 Nov 2009 17:43:49 -0000 --0016367b6b360b760b04799a2ede Content-Type: text/plain; charset=ISO-8859-1 I'm +1 on the general approach and splitting the two specifications. I have some concerns that the change in scope of "OAuth" between 1.0 and 2.0 will be confusing. -- John Panzer / Google jpanzer@google.com / abstractioneer.org / @jpanzer On Sat, Nov 28, 2009 at 11:59 PM, Eran Hammer-Lahav wrote: > With the cleanup of the 1.0 specification [1] and the publication of an > informational RFC (pending IESG approval), I no longer see value in a > standard closely based on the 1.0 specification, which was the original > intention of this WG. This is also reflected by the recent interest in the > WRAP proposal [2]. > > Instead, I think we should develop two specifications that while closely in > line with the original plan, represent a significant shift. In other words, > I am proposing we develop OAuth 2.0, not 1.1. > > The new proposal is to develop two specifications: > > 1. Token Authorization Method > > An RFC 2617 Authorization header called 'Token' for authenticating requests > with token-based credentials. Tokens (with optional shared-secret) are > usually used in place of other credentials (usernames, etc.) and represent > some combination of scope and authorization. The token method will include > an extensible signature-based option based on the HMAC-SHA1 method, and a > bearer token (with optional secret) option based on the PLAINTEXT method. > The RSA option will be dropped. > > 2. OAuth 2.0 > > A specification based on the browser-redirection flow described in OAuth > 1.0 as well as new methods defined in WRAP (I-D submission pending). OAuth > will be redefined to cover the authorization component only, and will no > longer be bound to a single authentication method. This will make OAuth > immediately useful for other protocols than HTTP (while HTTP will be used to > obtain tokens, tokens will be useful in other protocols, not just with the > HTTP and Token method). > > --- > > While the current charter allows much of this work, it contradicts its > spirit and the understanding reached when we created the working group. > > I would like to ask: > > - Is this approach favorable by the group? > - Do we need to adjust the language in the charter to support? > > EHL > > [1] http://tools.ietf.org/html/draft-hammer-oauth > [2] http://bit.ly/oauth-wrap > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0016367b6b360b760b04799a2ede Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'm +1 on the general approach and splitting the two specifications. = =A0I have some concerns that the change in scope of "OAuth" betwe= en 1.0 and 2.0 will be confusing.

--
Joh= n Panzer / Google
jpanzer@google.com / abstractioneer.org / @jpanzer



On Sat, Nov 28, 2009 at 11:59 PM, Eran H= ammer-Lahav <er= an@hueniverse.com> wrote:
With the cleanup of the 1.0 specification [1] and the publication of an inf= ormational RFC (pending IESG approval), I no longer see value in a standard= closely based on the 1.0 specification, which was the original intention o= f this WG. This is also reflected by the recent interest in the WRAP propos= al [2].

Instead, I think we should develop two specifications that while closely in= line with the original plan, represent a significant shift. In other words= , I am proposing we develop OAuth 2.0, not 1.1.

The new proposal is to develop two specifications:

1. Token Authorization Method

An RFC 2617 Authorization header called 'Token' for authenticating = requests with token-based credentials. Tokens (with optional shared-secret)= are usually used in place of other credentials (usernames, etc.) and repre= sent some combination of scope and authorization. The token method will inc= lude an extensible signature-based option based on the HMAC-SHA1 method, an= d a bearer token (with optional secret) option based on the PLAINTEXT metho= d. The RSA option will be dropped.

2. OAuth 2.0

A specification based on the browser-redirection flow described in OAuth 1.= 0 as well as new methods defined in WRAP (I-D submission pending). OAuth wi= ll be redefined to cover the authorization component only, and will no long= er be bound to a single authentication method. This will make OAuth immedia= tely useful for other protocols than HTTP (while HTTP will be used to obtai= n tokens, tokens will be useful in other protocols, not just with the HTTP = and Token method).

---

While the current charter allows much of this work, it contradicts its spir= it and the understanding reached when we created the working group.

I would like to ask:

- Is this approach favorable by the group?
- Do we need to adjust the language in the charter to support?

EHL

[1] http://tools.ietf.org/html/draft-hammer-oauth
[2] http://bit.ly/oa= uth-wrap

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

--0016367b6b360b760b04799a2ede-- From jpanzer@google.com Mon Nov 30 09:49:56 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE8763A6AB2 for ; Mon, 30 Nov 2009 09:49:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.875 X-Spam-Level: X-Spam-Status: No, score=-105.875 tagged_above=-999 required=5 tests=[AWL=0.101, 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 YXBtPPjSwSsP for ; Mon, 30 Nov 2009 09:49:55 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id 7C2203A6838 for ; Mon, 30 Nov 2009 09:49:55 -0800 (PST) Received: from spaceape13.eur.corp.google.com (spaceape13.eur.corp.google.com [172.28.16.147]) by smtp-out.google.com with ESMTP id nAUHnlbF007202 for ; Mon, 30 Nov 2009 09:49:47 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1259603388; bh=BcLIg651UJ0Iibp1HQAo+JLVL4E=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=mNplcXukzYMyZOHpRPkyJpsAB1MtxbHAeIAQhqP6c8BEiIRRFwzB9TZj6KJ8ywI69 LHOTeKpt8kolfalv27dmA== 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=wZHXFWtSLuEzLx5rnWg4XX0t+dat7ChwGFUOzmayTIvH8+SzDMiTVQrLBLed44edI UwmEzT8gc6Dq9z12Y2p0A== Received: from pxi15 (pxi15.prod.google.com [10.243.27.15]) by spaceape13.eur.corp.google.com with ESMTP id nAUHnhkM019912 for ; Mon, 30 Nov 2009 09:49:44 -0800 Received: by pxi15 with SMTP id 15so2662099pxi.23 for ; Mon, 30 Nov 2009 09:49:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.253.18 with SMTP id a18mr1665771wai.224.1259603383280; Mon, 30 Nov 2009 09:49:43 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343785209A5A@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343785209A24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1259536078.19069.6.camel@localhost> <90C41DD21FB7C64BB94121FBBC2E72343785209A5A@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: John Panzer Date: Mon, 30 Nov 2009 09:49:23 -0800 Message-ID: To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=0016e68786b837e47004799a4482 X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] OAuth 2.0 / Charter X-BeenThere: oauth@ietf.org X-Mailman-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, 30 Nov 2009 17:49:56 -0000 --0016e68786b837e47004799a4482 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Nov 29, 2009 at 11:34 PM, Eran Hammer-Lahav wrote: > > > > -----Original Message----- > > From: Paul C. Bryan [mailto:email@pbryan.net] > > Sent: Sunday, November 29, 2009 3:08 PM > > To: Eran Hammer-Lahav > > Cc: Peter Saint-Andre (stpeter@stpeter.im); Lisa Dusseault > > (lisa.dusseault@gmail.com); OAuth WG (oauth@ietf.org) > > Subject: Re: [OAUTH-WG] OAuth 2.0 / Charter > > > > To the overall approach, +1. > > > > Some follow-up questions: > > > > 1. Why drop RSA? It seems some form of public key cryptography will be > > necessary/useful to make web-based-attribute-containing tokens Internet- > > scalable. > > Mostly due to lack of implementation experience or interest within the > OAuth community. But also because the Plain and MAC versions are based on a > simple symmetric shared secret, while PK requires more. This means we will > need to support different types of tokens. While I am open to this if > needed, it seems to add a significant complexity. Also, part 2 will then > need to be able to provision both symmetric and asymmetric secrets which > adds to the complexity there. > > In other words, why put the effort in if no one is asking for this (based > on 2 years of deployment experience). > To clarify: I think there is significant value to RSA used in (a profile of?) step 2 in order to bootstrap shared secrets. This proposal is just about narrowing the scope of Token Auth to not support public key signatures, not about dropping RSA more generally, right? > > > 2. Is it an objective to have the Token auth-scheme contain extension > points > > so that new token formats can be introduced without need to redefine the > > scheme or draft a new one? > > Yes, but see above. > > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0016e68786b837e47004799a4482 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sun, Nov 29, 2009 at 11:34 PM, Eran Hammer-Lahav <<= a href=3D"mailto:eran@hueniverse.com">eran@hueniverse.com> wr= ote:


> -----Original Message-----
> From: Paul C. Bryan [mailto:email@= pbryan.net]
> Sent: Sunday, November 29, 2009 3:08 PM
> To: Eran Hammer-Lahav
> Cc: Peter Saint-Andre (stpeter@s= tpeter.im); Lisa Dusseault
> (lisa.dusseault@gmail.com<= /a>); OAuth WG (oauth@ietf.org)
> Subject: Re: [OAUTH-WG] OAuth 2.0 / Charter
>
> To the overall approach, +1.
>
> Some follow-up questions:
>
> 1. Why drop RSA? It seems some form of public key cryptography will be=
> necessary/useful to make web-based-attribute-containing tokens Interne= t-
> scalable.

Mostly due to lack of implementation experience or interest within th= e OAuth community. But also because the Plain and MAC versions are based on= a simple symmetric shared secret, while PK requires more. This means we wi= ll need to support different types of tokens. While I am open to this if ne= eded, it seems to add a significant complexity. Also, part 2 will then need= to be able to provision both symmetric and asymmetric secrets which adds t= o the complexity there.

In other words, why put the effort in if no one is asking for this (based o= n 2 years of deployment experience).

To= clarify: =A0I think there is significant value to RSA used in (a profile o= f?) step 2 in order to bootstrap shared secrets. =A0This proposal is just a= bout narrowing the scope of Token Auth to not support public key signatures= , not about dropping RSA more generally, right?=A0
=A0

> 2. Is it an objective to have the Token auth-scheme contain extension = points
> so that new token formats can be introduced without need to redefine t= he
> scheme or draft a new one?

Yes, but see above.

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

--0016e68786b837e47004799a4482-- From beaton@google.com Mon Nov 30 09:52:20 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1CC93A6899 for ; Mon, 30 Nov 2009 09:52:20 -0800 (PST) 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 gwfLLPy1SKuV for ; Mon, 30 Nov 2009 09:52:20 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id C9EC43A67D4 for ; Mon, 30 Nov 2009 09:52:19 -0800 (PST) Received: from zps19.corp.google.com (zps19.corp.google.com [172.25.146.19]) by smtp-out.google.com with ESMTP id nAUHqBkA029262 for ; Mon, 30 Nov 2009 09:52:12 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1259603532; bh=kB9w4H8cLCZZUF0xn2KPszYsssA=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=RcfOlgNxW8oLw5DR4FP7XfknPzpCgNMiSMB+CZPH12xufsX4f0LKjoLl2XQEk79Up 0Me7Mda3n/QBFVdAk9Rxw== 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=X8IA6pmuDV+cKUVVi6ykPy7MR1XCcvqbjEe99t6HM4JOMdxykIO+TBf4vv8w+xjy0 gNgeekt/9EAOHMZMqOJkA== Received: from pzk37 (pzk37.prod.google.com [10.243.19.165]) by zps19.corp.google.com with ESMTP id nAUHp4mw013265 for ; Mon, 30 Nov 2009 09:52:08 -0800 Received: by pzk37 with SMTP id 37so2581273pzk.10 for ; Mon, 30 Nov 2009 09:52:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.134.17 with SMTP id h17mr277748rvd.282.1259603528521; Mon, 30 Nov 2009 09:52:08 -0800 (PST) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E72343785209A24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1259536078.19069.6.camel@localhost> <90C41DD21FB7C64BB94121FBBC2E72343785209A5A@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 30 Nov 2009 09:52:08 -0800 Message-ID: From: Brian Eaton To: Pelle Braendgaard Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] OAuth 2.0 / Charter X-BeenThere: oauth@ietf.org X-Mailman-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, 30 Nov 2009 17:52:20 -0000 On Mon, Nov 30, 2009 at 7:53 AM, Pelle Braendgaard wrote: > I think the main reason we haven't seen a lot of RSA implementations > yet has been because the kind of businesses who I think would be > interested in using this such as banks/payments etc are not > traditionally early adopters. If we want to see OAUTH used in these > areas in the future I think it would be a very good idea to leave it > in. > > I am personally working on creating new OAuth based financial > transaction standard called OpenTransact, where we are planning on > standardizing on RSA in the next revision. Here's how I'd like to see the public-key vs HMAC vs bearer-token thing rationalized... public key: used for bootstrapping trust. The output of this bootstrap is a token, and possibly a token secret. bearer token: simple way of conveying authorization along with requests. hmac token: higher security way of conveying authorization. Thoughts on dividing up the problem space in that fashion? Would it actually work for most use cases, or do we really need public key signing on every single request? Cheers, Brian From rbarnes@bbn.com Mon Nov 30 09:55:20 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A013628C0D0 for ; Mon, 30 Nov 2009 09:55:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 lfAUtRf+QJLq for ; Mon, 30 Nov 2009 09:55:19 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 7AA9C3A6899 for ; Mon, 30 Nov 2009 09:55:19 -0800 (PST) Received: from [128.89.253.73] (helo=64-129-15-92.static.twtelecom.net) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1NFASr-0005YP-Ax; Mon, 30 Nov 2009 12:55:09 -0500 Message-Id: <9950FC8D-A0CC-4CD6-94BC-B5749CC4E1FE@bbn.com> From: Richard Barnes To: "Moore, Jonathan (CIM)" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 30 Nov 2009 07:55:07 -1000 References: <90C41DD21FB7C64BB94121FBBC2E72343785209A24@P3PW5EX1MB01.EX1.SECURESERVER.NET><1259536078.19069.6.camel@localhost> <90C41DD21FB7C64BB94121FBBC2E72343785209A5A@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-Mailer: Apple Mail (2.936) Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] keeping support for RSA (Was: RE: OAuth 2.0 / Charter) X-BeenThere: oauth@ietf.org X-Mailman-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, 30 Nov 2009 17:55:20 -0000 Jon, One technical point: You don't do appreciably more public-key operations to do a TLS negotiation as you do to sign an OAuth request, since the actual encryption of message is done with a symmetric algorithm (RSA is only used to protect the secrets in the negotiation). --Richard On Nov 30, 2009, at 4:22 AM, Moore, Jonathan (CIM) wrote: > Eran Hammer-Lahav writes, with respect to RSA support: >> In other words, why put the effort in if no one is asking for this >> (based on 2 years of deployment experience). > > Ok, I'll ask for it then! Our main use cases for OAuth 1.0 have been > for > 2-legged, server-to-server integrations with known third parties. > Public > key cryptography offers a lot of advantages here in terms of ease of > properly making a secure association between organizations. At least > in > our shop, it's considerably easier for us to deal with PKI than it > is to > set up SSL endpoints and/or run internal CAs. > > Also, and especially when the response *body* does not require > privacy, > I'd much rather spend my CPU cycles doing public-key cryptography on > the > HTTP headers than encrypting an entire response payload via SSL. I > also > lose the benefits of HTTP intermediaries when I have to tunnel over > SSL. > > I'm happy to participate here to work to keep this support in OAuth > 2.0 > (I'm just coming up to speed on the WG here). > > Thanks, > Jon > ........ > Jon Moore > Comcast Interactive Media > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Eran Hammer-Lahav > Sent: Monday, November 30, 2009 2:34 AM > To: Paul C. Bryan > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] OAuth 2.0 / Charter > > > >> -----Original Message----- >> From: Paul C. Bryan [mailto:email@pbryan.net] >> Sent: Sunday, November 29, 2009 3:08 PM >> To: Eran Hammer-Lahav >> Cc: Peter Saint-Andre (stpeter@stpeter.im); Lisa Dusseault >> (lisa.dusseault@gmail.com); OAuth WG (oauth@ietf.org) >> Subject: Re: [OAUTH-WG] OAuth 2.0 / Charter >> >> To the overall approach, +1. >> >> Some follow-up questions: >> >> 1. Why drop RSA? It seems some form of public key cryptography will >> be >> necessary/useful to make web-based-attribute-containing tokens > Internet- >> scalable. > > Mostly due to lack of implementation experience or interest within the > OAuth community. But also because the Plain and MAC versions are based > on a simple symmetric shared secret, while PK requires more. This > means > we will need to support different types of tokens. While I am open to > this if needed, it seems to add a significant complexity. Also, part 2 > will then need to be able to provision both symmetric and asymmetric > secrets which adds to the complexity there. > > In other words, why put the effort in if no one is asking for this > (based on 2 years of deployment experience). > >> 2. Is it an objective to have the Token auth-scheme contain extension > points >> so that new token formats can be introduced without need to redefine > the >> scheme or draft a new one? > > Yes, but see above. > > 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 stephen.farrell@cs.tcd.ie Mon Nov 30 09:58:14 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 090123A67F3 for ; Mon, 30 Nov 2009 09:58:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 0T9m73f1EI2G for ; Mon, 30 Nov 2009 09:58:13 -0800 (PST) Received: from VA3EHSOBE004.bigfish.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by core3.amsl.com (Postfix) with ESMTP id 1F8D43A67D4 for ; Mon, 30 Nov 2009 09:58:13 -0800 (PST) Received: from mail4-va3-R.bigfish.com (10.7.14.250) by VA3EHSOBE004.bigfish.com (10.7.40.24) with Microsoft SMTP Server id 8.1.340.0; Mon, 30 Nov 2009 17:58:05 +0000 Received: from mail4-va3 (localhost.localdomain [127.0.0.1]) by mail4-va3-R.bigfish.com (Postfix) with ESMTP id 88CC9D08390; Mon, 30 Nov 2009 17:58:05 +0000 (UTC) X-SpamScore: -8 X-BigFish: VPS-8(zz98dN168aJzz1202hzzz2dh6bh87h61h) X-Spam-TCS-SCL: 0:0 X-FB-DOMAIN-IP-MATCH: fail Received: from mail4-va3 (localhost.localdomain [127.0.0.1]) by mail4-va3 (MessageSwitch) id 1259603882546523_17643; Mon, 30 Nov 2009 17:58:02 +0000 (UTC) Received: from VA3EHSMHS027.bigfish.com (unknown [10.7.14.240]) by mail4-va3.bigfish.com (Postfix) with ESMTP id 1DA91E700A3; Mon, 30 Nov 2009 17:58:02 +0000 (UTC) Received: from imx2.tcd.ie (134.226.1.156) by VA3EHSMHS027.bigfish.com (10.7.99.37) with Microsoft SMTP Server id 14.0.482.32; Mon, 30 Nov 2009 17:57:59 +0000 Received: from Vams.imx2 (imx2.tcd.ie [134.226.1.156]) by imx2.tcd.ie (Postfix) with SMTP id 5BB0068003; Mon, 30 Nov 2009 17:57:59 +0000 (GMT) Received: from imx2.tcd.ie ([134.226.1.156]) by imx2.tcd.ie ([134.226.1.156]) with SMTP (gateway) id A0037157DA6; Mon, 30 Nov 2009 17:57:59 +0000 Received: from [134.226.36.180] (sfarrell.dsg.cs.tcd.ie [134.226.36.180]) by imx2.tcd.ie (Postfix) with ESMTP id 2F28368003; Mon, 30 Nov 2009 17:57:59 +0000 (GMT) Message-ID: <4B1407A7.9040907@cs.tcd.ie> Date: Mon, 30 Nov 2009 17:57:59 +0000 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.23 (X11/20090812) MIME-Version: 1.0 To: Eran Hammer-Lahav References: <90C41DD21FB7C64BB94121FBBC2E72343785209A24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <48AE706BD74FCC4297AD778805CA46F6184C5CF474@usps.sonoa.local> <90C41DD21FB7C64BB94121FBBC2E72343785209A5B@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343785209A5B@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-AntiVirus-Status: MessageID = A1037157DA6 X-AntiVirus-Status: Host: imx2.tcd.ie X-AntiVirus-Status: Action Taken: X-AntiVirus-Status: NONE X-AntiVirus-Status: Checked by TCD Vexira. (version=1.60.2 VDF=10.114.4) X-Reverse-DNS: imx2.tcd.ie Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] OAuth 2.0 / Charter X-BeenThere: oauth@ietf.org X-Mailman-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, 30 Nov 2009 17:58:14 -0000 While I think the general goal seems ok, and perhaps even better, I do wonder whether its reasonable to re-charter a WG that has never formally met face to face, nor met any of its current milestones. It may be, I'm just not sure, but what's the reason for not finishing OAuth 1.1 first? (The fact that you "see no value" doesn't explain it to me at least.) I also find the following a bit puzzling: Eran Hammer-Lahav wrote: > Keep in mind that we are not going to include token structure in scope. > We are simply proposing a method in which the token is a string, leaving > it up to other efforts to give it structure if needed. What other efforts? How would the implementer of an RFC achieve interoperability? Wouldn't we need to be able to answer that before proceeding? To answer your specific questions: > - Is this approach favorable by the group? Maybe. > - Do we need to adjust the language in the charter to support? Definitely IMO. The current charter talks about striving to maintain backwards compatibility etc. Ta, S. From beaton@google.com Mon Nov 30 10:03:36 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F3F73A696E for ; Mon, 30 Nov 2009 10:03:36 -0800 (PST) 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 MG16m2Sy8L5s for ; Mon, 30 Nov 2009 10:03:35 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id 82C363A63C9 for ; Mon, 30 Nov 2009 10:03:35 -0800 (PST) Received: from spaceape13.eur.corp.google.com (spaceape13.eur.corp.google.com [172.28.16.147]) by smtp-out.google.com with ESMTP id nAUI3PoS011079 for ; Mon, 30 Nov 2009 10:03:27 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1259604207; bh=yLQKUipnX3UFxpEnXUi3JVXJ4iA=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=Sk3+ZwHZQNwgD/2DY+0fHqkxo1+wdjlE37l/2e4HwUyNfgsCgmBHVS2Ic4PzlHcB9 XJzqDirBW2DLzzam93JoA== 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=HojbfCsvvGQNMIM1CmLV4Up058W4ChalegTPwjR+nsJQ55Ap5QY3LhTZhHNJC8Fg9 oe5nMAtdNeTQrY3Ho+4oA== Received: from pxi34 (pxi34.prod.google.com [10.243.27.34]) by spaceape13.eur.corp.google.com with ESMTP id nAUI36P7002340 for ; Mon, 30 Nov 2009 10:03:21 -0800 Received: by pxi34 with SMTP id 34so2687436pxi.8 for ; Mon, 30 Nov 2009 10:03:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.126.10 with SMTP id y10mr292268rvc.90.1259604199977; Mon, 30 Nov 2009 10:03:19 -0800 (PST) In-Reply-To: <9950FC8D-A0CC-4CD6-94BC-B5749CC4E1FE@bbn.com> References: <90C41DD21FB7C64BB94121FBBC2E72343785209A24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1259536078.19069.6.camel@localhost> <90C41DD21FB7C64BB94121FBBC2E72343785209A5A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <9950FC8D-A0CC-4CD6-94BC-B5749CC4E1FE@bbn.com> Date: Mon, 30 Nov 2009 10:03:19 -0800 Message-ID: From: Brian Eaton To: Richard Barnes Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "Moore, Jonathan \(CIM\)" , oauth@ietf.org Subject: Re: [OAUTH-WG] keeping support for RSA (Was: RE: OAuth 2.0 / Charter) X-BeenThere: oauth@ietf.org X-Mailman-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, 30 Nov 2009 18:03:36 -0000 On Mon, Nov 30, 2009 at 9:55 AM, Richard Barnes wrote: > One technical point: You don't do appreciably more public-key operations to > do a TLS negotiation as you do to sign an OAuth request, since the actual > encryption of message is done with a symmetric algorithm (RSA is only used > to protect the secrets in the negotiation). In fact TLS is far cheaper because it caches the results of the initial RSA negotiation. Cheers, Brian From rbarnes@bbn.com Mon Nov 30 10:08:13 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 356E428C10C for ; Mon, 30 Nov 2009 10:08:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 EHghzkmjH9aW for ; Mon, 30 Nov 2009 10:08:12 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 69D8F3A63C9 for ; Mon, 30 Nov 2009 10:08:12 -0800 (PST) Received: from [128.89.253.73] (helo=64-129-15-92.static.twtelecom.net) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1NFAfM-00062G-Bn; Mon, 30 Nov 2009 13:08:04 -0500 Message-Id: From: Richard Barnes To: Brian Eaton In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 30 Nov 2009 08:08:02 -1000 References: <90C41DD21FB7C64BB94121FBBC2E72343785209A24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1259536078.19069.6.camel@localhost> <90C41DD21FB7C64BB94121FBBC2E72343785209A5A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <9950FC8D-A0CC-4CD6-94BC-B5749CC4E1FE@bbn.com> X-Mailer: Apple Mail (2.936) Cc: "Moore, Jonathan \(CIM\)" , oauth@ietf.org Subject: Re: [OAUTH-WG] keeping support for RSA (Was: RE: OAuth 2.0 / Charter) X-BeenThere: oauth@ietf.org X-Mailman-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, 30 Nov 2009 18:08:13 -0000 Yep. There are also things like hardware accelerators already out there for TLS. On the other hand, you do save yourself the symmetric crypto if you really do just use the RSA signature for authentication. There may be some other advantages (I haven't thought much about it), so I'm not eager to write off RSA yet. --Richard On Nov 30, 2009, at 8:03 AM, Brian Eaton wrote: > On Mon, Nov 30, 2009 at 9:55 AM, Richard Barnes > wrote: >> One technical point: You don't do appreciably more public-key >> operations to >> do a TLS negotiation as you do to sign an OAuth request, since the >> actual >> encryption of message is done with a symmetric algorithm (RSA is >> only used >> to protect the secrets in the negotiation). > > In fact TLS is far cheaper because it caches the results of the > initial RSA negotiation. > > Cheers, > Brian From rbarnes@bbn.com Mon Nov 30 10:10:58 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 771B928C17D for ; Mon, 30 Nov 2009 10:10:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 CbUXXlTGP37w for ; Mon, 30 Nov 2009 10:10:57 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 2B4C528C177 for ; Mon, 30 Nov 2009 10:10:57 -0800 (PST) Received: from [128.89.253.73] (helo=64-129-15-92.static.twtelecom.net) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1NFAi1-00065R-9s; Mon, 30 Nov 2009 13:10:49 -0500 Message-Id: <3346A7EB-8899-499B-9480-12AE8F08EEF8@bbn.com> From: Richard Barnes To: Brian Eaton In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 30 Nov 2009 08:10:46 -1000 References: <90C41DD21FB7C64BB94121FBBC2E72343785209A24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1259536078.19069.6.camel@localhost> <90C41DD21FB7C64BB94121FBBC2E72343785209A5A@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-Mailer: Apple Mail (2.936) Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] OAuth 2.0 / Charter X-BeenThere: oauth@ietf.org X-Mailman-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, 30 Nov 2009 18:10:58 -0000 It's unclear to me that token values need to be protected or involved in the crypto at all. They're always bound to an identity (of the Client/Consumer or the ResourceOwner/User) that the Server should authenticate, so there's no additional authentication to be done beyond presenting the token to the Server. Protecting the token from theft is also not an issue as long as the Server authenticates the requestor, since only an authenticated Client/RO can make use of the token. Suggest just making "token" an opaque field in the authentication. That gives us the flexibility to define the token (formats, etc) elsewhere, and removes the interaction between tokens and crypto. --Richard On Nov 30, 2009, at 7:52 AM, Brian Eaton wrote: > On Mon, Nov 30, 2009 at 7:53 AM, Pelle Braendgaard > wrote: >> I think the main reason we haven't seen a lot of RSA implementations >> yet has been because the kind of businesses who I think would be >> interested in using this such as banks/payments etc are not >> traditionally early adopters. If we want to see OAUTH used in these >> areas in the future I think it would be a very good idea to leave it >> in. >> >> I am personally working on creating new OAuth based financial >> transaction standard called OpenTransact, where we are planning on >> standardizing on RSA in the next revision. > > Here's how I'd like to see the public-key vs HMAC vs bearer-token > thing rationalized... > > public key: used for bootstrapping trust. The output of this > bootstrap is a token, and possibly a token secret. > bearer token: simple way of conveying authorization along with > requests. > hmac token: higher security way of conveying authorization. > > Thoughts on dividing up the problem space in that fashion? Would it > actually work for most use cases, or do we really need public key > signing on every single request? > > Cheers, > Brian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From beaton@google.com Mon Nov 30 10:13:18 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 376A628C12B for ; Mon, 30 Nov 2009 10:13:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[AWL=0.000, 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 YixmUWrvX417 for ; Mon, 30 Nov 2009 10:13:17 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 2FCB03A697F for ; Mon, 30 Nov 2009 10:13:16 -0800 (PST) Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id nAUID64T021260 for ; Mon, 30 Nov 2009 18:13:06 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1259604786; bh=xJvfoo91NFhfkMt38VXHS9GCz4M=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=WWUqPDFCgYQdleTOJIbASAasgs3i9f3wrU/p2hPcH+pcuP7M/GvW3Txf9c2hbP7Md AXsGIJOCDNlEpVjPkVy5A== 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=mVexhK43Bnd8R/3QkDm11yKIMpzXjz6usGxtX2K+fWlsV9n0P+79xO/s3vrZPI450 3zWQ7uRUBQpomfuqxXFmw== Received: from pzk17 (pzk17.prod.google.com [10.243.19.145]) by wpaz17.hot.corp.google.com with ESMTP id nAUICJuW031915 for ; Mon, 30 Nov 2009 10:13:03 -0800 Received: by pzk17 with SMTP id 17so2536435pzk.6 for ; Mon, 30 Nov 2009 10:13:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.33.13 with SMTP id l13mr334419rvj.174.1259604783574; Mon, 30 Nov 2009 10:13:03 -0800 (PST) In-Reply-To: <3346A7EB-8899-499B-9480-12AE8F08EEF8@bbn.com> References: <90C41DD21FB7C64BB94121FBBC2E72343785209A24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1259536078.19069.6.camel@localhost> <90C41DD21FB7C64BB94121FBBC2E72343785209A5A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <3346A7EB-8899-499B-9480-12AE8F08EEF8@bbn.com> Date: Mon, 30 Nov 2009 10:13:03 -0800 Message-ID: From: Brian Eaton To: Richard Barnes Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] OAuth 2.0 / Charter X-BeenThere: oauth@ietf.org X-Mailman-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, 30 Nov 2009 18:13:18 -0000 On Mon, Nov 30, 2009 at 10:10 AM, Richard Barnes wrote: > Protecting the token from theft is also not an issue as long as the > Server authenticates the requestor, since only an authenticated Client/RO > can make use of the token. This seems somewhat circular. How is the requester being authenticated if not with the token? From john@jkemp.net Mon Nov 30 10:22:04 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD3363A693C for ; Mon, 30 Nov 2009 10:22:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 goDluUBzsHmN for ; Mon, 30 Nov 2009 10:22:03 -0800 (PST) Received: from outbound-mail-159.bluehost.com (outbound-mail-159.bluehost.com [67.222.39.39]) by core3.amsl.com (Postfix) with SMTP id 1DABF3A694F for ; Mon, 30 Nov 2009 10:22:03 -0800 (PST) Received: (qmail 13550 invoked by uid 0); 30 Nov 2009 18:21:56 -0000 Received: from unknown (HELO box320.bluehost.com) (69.89.31.120) by outboundproxy5.bluehost.com with SMTP; 30 Nov 2009 18:21:56 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=jkemp.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=ndJjtQtMUT3+LUkm95Q2okZcjSJ8bQtWcWroof/9J0Q6v9hS16liAH+t9P+2jtFMh2Vza/XMXns21eD0Q7sfIweqtQDO/GG4GIOqn7AEjkTZi/37w2w8uSfBdcNvCJLr; Received: from cpe-69-205-56-47.nycap.res.rr.com ([69.205.56.47] helo=[192.168.1.110]) by box320.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NFAsm-0001vX-0k; Mon, 30 Nov 2009 11:21:56 -0700 Message-ID: <4B140D42.6010700@jkemp.net> Date: Mon, 30 Nov 2009 13:21:54 -0500 From: John Kemp User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Brian Eaton References: <90C41DD21FB7C64BB94121FBBC2E72343785209A24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1259536078.19069.6.camel@localhost> <90C41DD21FB7C64BB94121FBBC2E72343785209A5A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <3346A7EB-8899-499B-9480-12AE8F08EEF8@bbn.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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] OAuth 2.0 / Charter X-BeenThere: oauth@ietf.org X-Mailman-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, 30 Nov 2009 18:22:04 -0000 Brian Eaton wrote: > On Mon, Nov 30, 2009 at 10:10 AM, Richard Barnes wrote: >> Protecting the token from theft is also not an issue as long as the >> Server authenticates the requestor, since only an authenticated Client/RO >> can make use of the token. > > This seems somewhat circular. How is the requester being > authenticated if not with the token? Just because a token was earlier presented to something claiming a particular identity doesn't mean (without accounting for external factors) that the thing presenting the token at this time has the same identity as the original token requester. - johnk > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From jonathan_moore@comcast.com Mon Nov 30 10:22:45 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 021E73A692F for ; Mon, 30 Nov 2009 10:22:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.463 X-Spam-Level: X-Spam-Status: No, score=-4.463 tagged_above=-999 required=5 tests=[AWL=-4.000, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PDCvnpJf9MMi for ; Mon, 30 Nov 2009 10:22:44 -0800 (PST) Received: from paoakoavas09.cable.comcast.com (paoakoavas09.cable.comcast.com [208.17.35.58]) by core3.amsl.com (Postfix) with ESMTP id 1DA103A6836 for ; Mon, 30 Nov 2009 10:22:44 -0800 (PST) Received: from ([24.40.15.92]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.83324178; Mon, 30 Nov 2009 13:22:25 -0500 Received: from PACORPEXCMB03.cable.comcast.com ([24.40.15.85]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Nov 2009 13:22:25 -0500 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, 30 Nov 2009 13:22:24 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] keeping support for RSA (Was: RE: OAuth 2.0 / Charter) Thread-Index: Acpx6BLa6vFVIeG9S4SMSNc1Z50jhgAAIXVw References: <90C41DD21FB7C64BB94121FBBC2E72343785209A24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1259536078.19069.6.camel@localhost> <90C41DD21FB7C64BB94121FBBC2E72343785209A5A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <9950FC8D-A0CC-4CD6-94BC-B5749CC4E1FE@bbn.com> From: "Moore, Jonathan (CIM)" To: "Richard Barnes" , "Brian Eaton" X-OriginalArrivalTime: 30 Nov 2009 18:22:25.0450 (UTC) FILETIME=[10F8B0A0:01CA71EA] Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] keeping support for RSA (Was: RE: OAuth 2.0 / Charter) X-BeenThere: oauth@ietf.org X-Mailman-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, 30 Nov 2009 18:22:45 -0000 Thanks for the technical corrections; I think I failed to make my main point when I brought up CPU efficiency (although I'd still prefer not to encrypt my response bodies if I don't have to, even with symmetric keys...). I think Richard sums this up nicely, though. For us, the major advantages of using RSA for authentication only are for operational/management issues. I find it hard to believe that we'd be the only organization that preferred exchanging and verifying public keys with a partner over transmitting shared secrets. Jon -----Original Message----- From: Richard Barnes [mailto:rbarnes@bbn.com]=20 Sent: Monday, November 30, 2009 1:08 PM To: Brian Eaton Cc: Moore, Jonathan (CIM); oauth@ietf.org Subject: Re: [OAUTH-WG] keeping support for RSA (Was: RE: OAuth 2.0 / Charter) Yep. There are also things like hardware accelerators already out =20 there for TLS. On the other hand, you do save yourself the symmetric crypto if you =20 really do just use the RSA signature for authentication. There may be =20 some other advantages (I haven't thought much about it), so I'm not =20 eager to write off RSA yet. --Richard On Nov 30, 2009, at 8:03 AM, Brian Eaton wrote: > On Mon, Nov 30, 2009 at 9:55 AM, Richard Barnes =20 > wrote: >> One technical point: You don't do appreciably more public-key =20 >> operations to >> do a TLS negotiation as you do to sign an OAuth request, since the =20 >> actual >> encryption of message is done with a symmetric algorithm (RSA is =20 >> only used >> to protect the secrets in the negotiation). > > In fact TLS is far cheaper because it caches the results of the > initial RSA negotiation. > > Cheers, > Brian From john@jkemp.net Mon Nov 30 10:25:39 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5256228C134 for ; Mon, 30 Nov 2009 10:25:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 y2ff2v667Czc for ; Mon, 30 Nov 2009 10:25:38 -0800 (PST) Received: from outbound-mail-108.bluehost.com (outbound-mail-108.bluehost.com [69.89.22.8]) by core3.amsl.com (Postfix) with SMTP id 7442928C12B for ; Mon, 30 Nov 2009 10:25:38 -0800 (PST) Received: (qmail 30710 invoked by uid 0); 30 Nov 2009 18:25:15 -0000 Received: from unknown (HELO box320.bluehost.com) (69.89.31.120) by outboundproxy3.bluehost.com with SMTP; 30 Nov 2009 18:25:15 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=jkemp.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=q3BhCjIILA4XApbn+wnILx5no4sVDusAeGj4VykhaAvKgwPKbL7DkTScjm2HMRyAlV4UsdJQ5pEZrSDQHZOhN49xfqCXGDERZUEHExGy/neydYcIWKVz+ygxhFErtBdE; Received: from cpe-69-205-56-47.nycap.res.rr.com ([69.205.56.47] helo=[192.168.1.110]) by box320.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NFAvy-0003Ld-R8; Mon, 30 Nov 2009 11:25:15 -0700 Message-ID: <4B140E09.4020501@jkemp.net> Date: Mon, 30 Nov 2009 13:25:13 -0500 From: John Kemp User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Brian Eaton References: <90C41DD21FB7C64BB94121FBBC2E72343785209A24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1259536078.19069.6.camel@localhost> <90C41DD21FB7C64BB94121FBBC2E72343785209A5A@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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] OAuth 2.0 / Charter X-BeenThere: oauth@ietf.org X-Mailman-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, 30 Nov 2009 18:25:39 -0000 Brian Eaton wrote: > Here's how I'd like to see the public-key vs HMAC vs bearer-token > thing rationalized... > > public key: used for bootstrapping trust. What do you mean by "bootstrapping trust"? > The output of this > bootstrap is a token, and possibly a token secret. > bearer token: simple way of conveying authorization along with requests. > hmac token: higher security way of conveying authorization. Is there not some "bootstrapping" here too? Don't I get a token in response to something else (username/password?) How is that trust conveyed once this bootstrap process is over? - johnk > > Thoughts on dividing up the problem space in that fashion? Would it > actually work for most use cases, or do we really need public key > signing on every single request? > > Cheers, > Brian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From beaton@google.com Mon Nov 30 10:36:19 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 585EE3A68CE for ; Mon, 30 Nov 2009 10:36:19 -0800 (PST) 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 rUbXyvYhyVtq for ; Mon, 30 Nov 2009 10:36:18 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id D83663A684C for ; Mon, 30 Nov 2009 10:36:17 -0800 (PST) Received: from wpaz9.hot.corp.google.com (wpaz9.hot.corp.google.com [172.24.198.73]) by smtp-out.google.com with ESMTP id nAUIa9kq011153 for ; Mon, 30 Nov 2009 18:36:09 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1259606169; bh=EtDsjEbkWLiJ9ldvSSh/0C4cuN4=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=mFb+zsCR82YZ7l+KPrr5KQEFPv2rsjuJvUYnI6PoMjk2TAuy6iZ81B9NsBP0JJqen LJrNiY5YjtlfvdpRhWJGw== 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=A/O2hgjjMX6qixU7stUrVWuh6l8KmyOp5R+J79fiZbIDzskqJPV4ME6xfjkOK2Gb5 TMnJSX+BEcP9lOKW+AFjw== Received: from pxi1 (pxi1.prod.google.com [10.243.27.1]) by wpaz9.hot.corp.google.com with ESMTP id nAUIa5VF029686 for ; Mon, 30 Nov 2009 10:36:06 -0800 Received: by pxi1 with SMTP id 1so91196pxi.25 for ; Mon, 30 Nov 2009 10:36:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.4.12 with SMTP id g12mr307387rvi.189.1259606165762; Mon, 30 Nov 2009 10:36:05 -0800 (PST) In-Reply-To: <4B140E09.4020501@jkemp.net> References: <90C41DD21FB7C64BB94121FBBC2E72343785209A24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1259536078.19069.6.camel@localhost> <90C41DD21FB7C64BB94121FBBC2E72343785209A5A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B140E09.4020501@jkemp.net> Date: Mon, 30 Nov 2009 10:36:05 -0800 Message-ID: From: Brian Eaton To: John Kemp 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.0 / Charter X-BeenThere: oauth@ietf.org X-Mailman-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, 30 Nov 2009 18:36:19 -0000 On Mon, Nov 30, 2009 at 10:25 AM, John Kemp wrote: > Just because a token was earlier presented to something claiming a > particular identity doesn't mean (without accounting for external factors= ) > that the thing presenting the token at this time has the same identity as > the original token requester. Yep. I'm wondering whether those "external factors" in fact need to be built in to OAuth. I don't think they do. >> public key: used for bootstrapping trust. > > What do you mean by "bootstrapping trust"? I probably should have said "bootstrapping authentication". What I mean is that public key cryptography provides a technical foundation for authenticating entities without having them share a secret in advance. That's a common problem, and I think OAuth needs to be compatible with solutions to that problem. >> =A0The output of this >> bootstrap is a token, and possibly a token secret. >> bearer token: simple way of conveying authorization along with requests. >> hmac token: higher security way of conveying authorization. > > Is there not some "bootstrapping" here too? Don't I get a token in respon= se > to something else (username/password?) How is that trust conveyed once th= is > bootstrap process is over? Sure. There are lots of ways to bootstrap a token. Here are some concrete examples of what I mean: Username + password: used to boostrap a session cookie (a bearer token) SAML web single sign on: public-key signed SAML assertion is used to bootstrap a session cookie. OAuth 3-legged delegation flow: uses an authorization token + some sort of client authentication + some sort of end-user authentication to boostrap an OAuth access token The common thread in all of these is that the output of the bootstrapping is a session token of some type. Cheers, Brian From hallam@gmail.com Mon Nov 30 10:51:08 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBB133A6973 for ; Mon, 30 Nov 2009 10:51:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 M7BqdKJYJ9i9 for ; Mon, 30 Nov 2009 10:51:07 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 771513A6AB0 for ; Mon, 30 Nov 2009 10:51:07 -0800 (PST) Received: by yxe30 with SMTP id 30so9260964yxe.29 for ; Mon, 30 Nov 2009 10:50:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=QGPvxBZqrJLqR6+OWJJLoEaKmr2RGjivD3ZQ17HgRKg=; b=fEDAA2739JtPtnvsBtTM6QxJsunV9Qidk+IKUqQrYQkczHk27nOgjjdWiWFvofWGF4 CVofPHdtMjdHWeZcBJDsRczrKTdr9u8MicBcel30vvk2yXfJpnVcT/l2/vOPZd/2wEMX +XHU/Mzckl+LeEbpGsHeIKDRwzruTPdNPnd/c= 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=YPDzSsLiieI/2OtebQ4UuX6Bp2W0sDEbUUQStmOdqrO87JtiTvQ/YkJ2lVxNSiZX4K VR1HIpTq0rs8gMufIzawWKSqqSR5sH5swoOzqTiH6kABJ5uGlmDD2dTSTUQHIXUm7tuW vLDKXEExpBK5w/CZwcmMvFDa65bBQeHaQU5tk= MIME-Version: 1.0 Received: by 10.91.49.13 with SMTP id b13mr6894875agk.34.1259607057609; Mon, 30 Nov 2009 10:50:57 -0800 (PST) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E72343785209A24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1259536078.19069.6.camel@localhost> <90C41DD21FB7C64BB94121FBBC2E72343785209A5A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <9950FC8D-A0CC-4CD6-94BC-B5749CC4E1FE@bbn.com> Date: Mon, 30 Nov 2009 13:50:57 -0500 Message-ID: From: Phillip Hallam-Baker To: Brian Eaton Content-Type: text/plain; charset=ISO-8859-1 Cc: "Moore, Jonathan \(CIM\)" , oauth@ietf.org Subject: Re: [OAUTH-WG] keeping support for RSA (Was: RE: OAuth 2.0 / Charter) X-BeenThere: oauth@ietf.org X-Mailman-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, 30 Nov 2009 18:51:08 -0000 Hmm, not a good time to point that out. That part of te protocol turns out to be problematic On Mon, Nov 30, 2009 at 1:03 PM, Brian Eaton wrote: > On Mon, Nov 30, 2009 at 9:55 AM, Richard Barnes wrote: >> One technical point: You don't do appreciably more public-key operations to >> do a TLS negotiation as you do to sign an OAuth request, since the actual >> encryption of message is done with a symmetric algorithm (RSA is only used >> to protect the secrets in the negotiation). > > In fact TLS is far cheaper because it caches the results of the > initial RSA negotiation. > > Cheers, > Brian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ From Dick.Hardt@microsoft.com Mon Nov 30 11:09:35 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DF0F28C10C for ; Mon, 30 Nov 2009 11:09:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.064 X-Spam-Level: X-Spam-Status: No, score=-10.064 tagged_above=-999 required=5 tests=[AWL=-0.535, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SXLIFE=1.07] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id grJOttJ9z7Lv for ; Mon, 30 Nov 2009 11:09:34 -0800 (PST) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 4BEB53A693C for ; Mon, 30 Nov 2009 11:09:34 -0800 (PST) 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, 30 Nov 2009 11:09:53 -0800 Received: from TK5EX14MBXC101.redmond.corp.microsoft.com ([169.254.1.27]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi; Mon, 30 Nov 2009 11:09:26 -0800 From: Dick Hardt To: "Moore, Jonathan (CIM)" Thread-Topic: [OAUTH-WG] keeping support for RSA (Was: RE: OAuth 2.0 / Charter) Thread-Index: AQHKccir8u9nOpEgQ0isR0l/uunS85FPbwuAgAACS4CAAAFRAIAABAQAgAANIIA= Date: Mon, 30 Nov 2009 19:09:23 +0000 Message-ID: References: <90C41DD21FB7C64BB94121FBBC2E72343785209A24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1259536078.19069.6.camel@localhost> <90C41DD21FB7C64BB94121FBBC2E72343785209A5A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <9950FC8D-A0CC-4CD6-94BC-B5749CC4E1FE@bbn.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-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [OAUTH-WG] keeping support for RSA (Was: RE: OAuth 2.0 / Charter) X-BeenThere: oauth@ietf.org X-Mailman-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, 30 Nov 2009 19:09:35 -0000 On 2009-11-30, at 8:22 AM, Moore, Jonathan (CIM) wrote: >=20 > I think Richard sums this up nicely, though. For us, the major > advantages of using RSA for authentication only are for > operational/management issues. I find it hard to believe that we'd be > the only organization that preferred exchanging and verifying public > keys with a partner over transmitting shared secrets. TLS uses public keys as well. In your original post ... > At least in > our shop, it's considerably easier for us to deal with PKI than it is to > set up SSL endpoints and/or run internal CAs. Do you already have PKI with your partners setup? I'm surprised you would rather manage your own PKI rather then use SSL.=20 -- Dick From john@jkemp.net Mon Nov 30 11:15:28 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 866C928C169 for ; Mon, 30 Nov 2009 11:15:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 PK6D7W9jzSWr for ; Mon, 30 Nov 2009 11:15:27 -0800 (PST) Received: from outbound-mail-32.bluehost.com (outbound-mail-32.bluehost.com [69.89.18.152]) by core3.amsl.com (Postfix) with SMTP id A935C3A6858 for ; Mon, 30 Nov 2009 11:15:27 -0800 (PST) Received: (qmail 10768 invoked by uid 0); 30 Nov 2009 19:15:20 -0000 Received: from unknown (HELO box320.bluehost.com) (69.89.31.120) by outboundproxy2.bluehost.com with SMTP; 30 Nov 2009 19:15:20 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=jkemp.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=tFg+N8JsC1r8iPRjqoUZ1exJ54hS2oqTqETutVOgTBPGpLcoMwcKpefceRsgrpEBUugtW4oS4sqvkKnnffdWurvlaJlJVkEj0h0wKnKfAkHWR89YWmHITLG8vIeLhrEe; Received: from cpe-69-205-56-47.nycap.res.rr.com ([69.205.56.47] helo=[192.168.1.110]) by box320.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NFBiS-0008Nb-Kw; Mon, 30 Nov 2009 12:15:20 -0700 Message-ID: <4B1419C6.5080803@jkemp.net> Date: Mon, 30 Nov 2009 14:15:18 -0500 From: John Kemp User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Brian Eaton References: <90C41DD21FB7C64BB94121FBBC2E72343785209A24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1259536078.19069.6.camel@localhost> <90C41DD21FB7C64BB94121FBBC2E72343785209A5A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B140E09.4020501@jkemp.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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] OAuth 2.0 / Charter X-BeenThere: oauth@ietf.org X-Mailman-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, 30 Nov 2009 19:15:28 -0000 Brian Eaton wrote: > On Mon, Nov 30, 2009 at 10:25 AM, John Kemp wrote: >> Just because a token was earlier presented to something claiming a >> particular identity doesn't mean (without accounting for external factors) >> that the thing presenting the token at this time has the same identity as >> the original token requester. > > Yep. I'm wondering whether those "external factors" in fact need to > be built in to OAuth. I don't think they do. Yes, I think I agree, but we should probably note in the specification how these external factors are related, and which ones are pertinent to OAuth scenarios. > >>> public key: used for bootstrapping trust. >> What do you mean by "bootstrapping trust"? > > I probably should have said "bootstrapping authentication". What I > mean is that public key cryptography provides a technical foundation > for authenticating entities without having them share a secret in > advance. > > That's a common problem, and I think OAuth needs to be compatible with > solutions to that problem. Agreed. > >>> The output of this >>> bootstrap is a token, and possibly a token secret. >>> bearer token: simple way of conveying authorization along with requests. >>> hmac token: higher security way of conveying authorization. >> Is there not some "bootstrapping" here too? Don't I get a token in response >> to something else (username/password?) How is that trust conveyed once this >> bootstrap process is over? > > Sure. There are lots of ways to bootstrap a token. Here are some > concrete examples of what I mean: > > Username + password: used to boostrap a session cookie (a bearer token) > > SAML web single sign on: public-key signed SAML assertion is used to > bootstrap a session cookie. > > OAuth 3-legged delegation flow: uses an authorization token + some > sort of client authentication + some sort of end-user authentication > to boostrap an OAuth access token > > The common thread in all of these is that the output of the > bootstrapping is a session token of some type. Right - so we start off with one entity being directly authenticated by another. This results in the production of a token and optionally a method of binding the token to an arbitrary message which may also authenticate (essentially independently of the token) the entity presenting the token. Would you then also need to allow the association of the entity presenting the token with that which acquired the token? - johnk From Dick.Hardt@microsoft.com Mon Nov 30 11:18:07 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C2D23A6858 for ; Mon, 30 Nov 2009 11:18:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.332 X-Spam-Level: X-Spam-Status: No, score=-10.332 tagged_above=-999 required=5 tests=[AWL=0.268, 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 Mc-C3VNb+RjF for ; Mon, 30 Nov 2009 11:18:06 -0800 (PST) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id AB0C83A6818 for ; Mon, 30 Nov 2009 11:18:06 -0800 (PST) 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; Mon, 30 Nov 2009 11:18:25 -0800 Received: from TK5EX14MBXC101.redmond.corp.microsoft.com ([169.254.1.27]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi; Mon, 30 Nov 2009 11:17:47 -0800 From: Dick Hardt To: Eran Hammer-Lahav Thread-Topic: [OAUTH-WG] why are we signing? Thread-Index: AQHKYPpiJlPvjbF+7Eug3PbIB1m6s5EuVfSAgAED2ACAAt81AIAAASmAgABrE4CAAH1JAIABBIUAgACcJwCAAAx/gIAa2A2A Date: Mon, 30 Nov 2009 19:17:45 +0000 Message-ID: References: <35D50F5C-3982-4298-A9E0-86A528F5C5D3@jkemp.net> <4A956CE47D1066408D5C7EB34368A5110551FFC1@S4DE8PSAAQC.mitte.t-com.de> <90C41DD21FB7C64BB94121FBBC2E72343785102B49@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785102E58@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785102F1F@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343785102F1F@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="us-ascii" Content-ID: <8a46a6db-42d5-4095-86e2-72261e7a02c1> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] why are we signing? X-BeenThere: oauth@ietf.org X-Mailman-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, 30 Nov 2009 19:18:07 -0000 On 2009-11-13, at 7:21 AM, Eran Hammer-Lahav wrote: >=20 > I for one, see great value in offering some form of crypto-based security= for cases where TLS is not suitable. Are these use cases enumerated somewhere? (Apologies for coming into the conversation late) From hannes.tschofenig@nsn.com Mon Nov 30 11:19:15 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B38363A6969 for ; Mon, 30 Nov 2009 11:19:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 UanbTzSiGgOJ for ; Mon, 30 Nov 2009 11:19:15 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 825433A694D for ; Mon, 30 Nov 2009 11:19:14 -0800 (PST) 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 nAUJJ1HP032274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 30 Nov 2009 20:19:01 +0100 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 nAUJJ1N3012485; Mon, 30 Nov 2009 20:19:01 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Nov 2009 20:19:01 +0100 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, 30 Nov 2009 21:22:31 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4501F19743@FIESEXC015.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] why are we signing? Thread-Index: AQHKYPpiJlPvjbF+7Eug3PbIB1m6s5EuVfSAgAED2ACAAt81AIAAASmAgABrE4CAAH1JAIABBIUAgACcJwCAAAx/gIAa2A2A//97K4A= References: <35D50F5C-3982-4298-A9E0-86A528F5C5D3@jkemp.net><4A956CE47D1066408D5C7EB34368A5110551FFC1@S4DE8PSAAQC.mitte.t-com.de><90C41DD21FB7C64BB94121FBBC2E72343785102B49@P3PW5EX1MB01.EX1.SECURESERVER.NET><90C41DD21FB7C64BB94121FBBC2E72343785102E58@P3PW5EX1MB01.EX1.SECURESERVER.NET><90C41DD21FB7C64BB94121FBBC2E72343785102F1F@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Dick Hardt" , "Eran Hammer-Lahav" X-OriginalArrivalTime: 30 Nov 2009 19:19:01.0288 (UTC) FILETIME=[F90C7280:01CA71F1] Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] why are we signing? X-BeenThere: oauth@ietf.org X-Mailman-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, 30 Nov 2009 19:19:15 -0000 I would also like to hear about the cases where TLS is not suitable.=20 Hannes=20 >-----Original Message----- >From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]=20 >On Behalf Of ext Dick Hardt >Sent: 30 November, 2009 21:18 >To: Eran Hammer-Lahav >Cc: oauth@ietf.org >Subject: Re: [OAUTH-WG] why are we signing? > > >On 2009-11-13, at 7:21 AM, Eran Hammer-Lahav wrote: >>=20 >> I for one, see great value in offering some form of=20 >crypto-based security for cases where TLS is not suitable. > > >Are these use cases enumerated somewhere? > >(Apologies for coming into the conversation late) > >_______________________________________________ >OAuth mailing list >OAuth@ietf.org >https://www.ietf.org/mailman/listinfo/oauth > From Dick.Hardt@microsoft.com Mon Nov 30 11:25:03 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8047F3A6AB0 for ; Mon, 30 Nov 2009 11:25:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.421 X-Spam-Level: X-Spam-Status: No, score=-10.421 tagged_above=-999 required=5 tests=[AWL=0.178, 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 tV1f+NRIHNm7 for ; Mon, 30 Nov 2009 11:25:02 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id B10D43A698A for ; Mon, 30 Nov 2009 11:25:02 -0800 (PST) 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; Mon, 30 Nov 2009 11:25:21 -0800 Received: from TK5EX14MBXC101.redmond.corp.microsoft.com ([169.254.1.27]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi; Mon, 30 Nov 2009 11:24:55 -0800 From: Dick Hardt To: John Kemp Thread-Topic: [OAUTH-WG] OAuth 2.0 / Charter Thread-Index: AQHKcUjWs3uQ7EFH4k+3Pm94J9d3u5FOwoWAgACLjgCAACEiAIAACT+AgAADCYCAAAr1AIAAAquA Date: Mon, 30 Nov 2009 19:24:51 +0000 Message-ID: References: <90C41DD21FB7C64BB94121FBBC2E72343785209A24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1259536078.19069.6.camel@localhost> <90C41DD21FB7C64BB94121FBBC2E72343785209A5A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B140E09.4020501@jkemp.net> <4B1419C6.5080803@jkemp.net> In-Reply-To: <4B1419C6.5080803@jkemp.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-ID: <27d7fdd3-2b24-42fd-9aef-603b6d6edc81> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] OAuth 2.0 / Charter X-BeenThere: oauth@ietf.org X-Mailman-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, 30 Nov 2009 19:25:03 -0000 On 2009-11-30, at 9:15 AM, John Kemp wrote: >=20 > Right - so we start off with one entity being directly authenticated by a= nother. This results in the production of a token and optionally a method o= f binding the token to an arbitrary message which may also authenticate (es= sentially independently of the token) the entity presenting the token. Woul= d you then also need to allow the association of the entity presenting the = token with that which acquired the token? In a claims based approach, the Client may only need to prove is is authori= zed and that the claim is authentic in order to have access to a Protected = Resource. The Client may not have identified itself to the Protected Resour= ce. The claim(s) would be contained in the token. -- Dick= From eran@hueniverse.com Mon Nov 30 11:26:07 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 082D53A6988 for ; Mon, 30 Nov 2009 11:26:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.145, 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 FFT3CigKp+M8 for ; Mon, 30 Nov 2009 11:26:06 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id E8CEF3A697F for ; Mon, 30 Nov 2009 11:26:05 -0800 (PST) Received: (qmail 17750 invoked from network); 30 Nov 2009 19:25:57 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 30 Nov 2009 19:25:55 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 30 Nov 2009 12:25:55 -0700 From: Eran Hammer-Lahav To: "Moore, Jonathan (CIM)" , "Paul C. Bryan" Date: Mon, 30 Nov 2009 12:25:59 -0700 Thread-Topic: keeping support for RSA (Was: RE: [OAUTH-WG] OAuth 2.0 / Charter) Thread-Index: AcpxSNFz/MEp+KVqRhe6EKTDjUfKEAARixFgAA3su5AACpmiUA== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343785209B82@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343785209A24@P3PW5EX1MB01.EX1.SECURESERVER.NET><1259536078.19069.6.camel@localhost> <90C41DD21FB7C64BB94121FBBC2E72343785209A5A@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@ietf.org" Subject: Re: [OAUTH-WG] keeping support for RSA (Was: RE: OAuth 2.0 / Charter) X-BeenThere: oauth@ietf.org X-Mailman-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, 30 Nov 2009 19:26:07 -0000 This is a discussion worth having now. 1. We are going to drop some use cases for the sake of simplicity. This wil= l not prevent extensions, and a PK signature method might be something to s= tandardize, but there is a lot more to it to make it useful including key r= otation, and the initial exchange of credentials. Obtaining and managing a = token-PK pair is more complex than a simple token-secret pair. 2. There is no requirement for 2.0 to support every existing use case for 1= .0. This is why I put so much effort into the 1.0 RFC - so you can still us= e it when appropriate. If 1.0 provides a useful RSA-SHA1 method for doing 2= -legged, use it. If it is not sufficient or has problems, we need to know a= bout it. So far, the vast majority of development experience comes from the= HMAC-SHA1 method. The RSA method was intentionally underspecified as no on= e had any real interest in it at the time (except for Google, which since t= hen deployed HMAC as well). 3. I will leave it up to the security experts to figure out if a PK option = in the *authentication* spec is worth having, compared to TLS/SSL. OAuth di= d not require TLS because it was designed to be friendly to small sites loo= king to deploy an API without having to deal with certificates. The perform= ance overhead wasn't really the main issue, it was practicality. For exampl= e, I would like to be able to write a Wordpress plugin that exposes an addr= ess book API using OAuth, without being required to enable SSL on my blog. 4. We are still very likely to have a PK-based method for obtaining *author= ization* (a token). So PK will be still available for obtaining a token. I = know this does not address the 2-legged scenario, but whatever we come up t= here should be the same with whatever we may end up including in the authen= tication part. EHL > -----Original Message----- > From: Moore, Jonathan (CIM) [mailto:Jonathan_Moore@Comcast.com] > Sent: Monday, November 30, 2009 6:22 AM > To: Eran Hammer-Lahav; Paul C. Bryan > Cc: oauth@ietf.org > Subject: Re: keeping support for RSA (Was: RE: [OAUTH-WG] OAuth 2.0 / > Charter) >=20 > Eran Hammer-Lahav writes, with respect to RSA support: > > In other words, why put the effort in if no one is asking for this > > (based on 2 years of deployment experience). >=20 > Ok, I'll ask for it then! Our main use cases for OAuth 1.0 have been for = 2- > legged, server-to-server integrations with known third parties. Public ke= y > cryptography offers a lot of advantages here in terms of ease of properly > making a secure association between organizations. At least in our shop, = it's > considerably easier for us to deal with PKI than it is to set up SSL endp= oints > and/or run internal CAs. >=20 > Also, and especially when the response *body* does not require privacy, I= 'd > much rather spend my CPU cycles doing public-key cryptography on the HTTP > headers than encrypting an entire response payload via SSL. I also lose t= he > benefits of HTTP intermediaries when I have to tunnel over SSL. >=20 > I'm happy to participate here to work to keep this support in OAuth 2.0 (= I'm > just coming up to speed on the WG here). >=20 > Thanks, > Jon > ........ > Jon Moore > Comcast Interactive Media >=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Eran Hammer-Lahav > Sent: Monday, November 30, 2009 2:34 AM > To: Paul C. Bryan > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] OAuth 2.0 / Charter >=20 >=20 >=20 > > -----Original Message----- > > From: Paul C. Bryan [mailto:email@pbryan.net] > > Sent: Sunday, November 29, 2009 3:08 PM > > To: Eran Hammer-Lahav > > Cc: Peter Saint-Andre (stpeter@stpeter.im); Lisa Dusseault > > (lisa.dusseault@gmail.com); OAuth WG (oauth@ietf.org) > > Subject: Re: [OAUTH-WG] OAuth 2.0 / Charter > > > > To the overall approach, +1. > > > > Some follow-up questions: > > > > 1. Why drop RSA? It seems some form of public key cryptography will be > > necessary/useful to make web-based-attribute-containing tokens > Internet- > > scalable. >=20 > Mostly due to lack of implementation experience or interest within the > OAuth community. But also because the Plain and MAC versions are based > on a simple symmetric shared secret, while PK requires more. This means w= e > will need to support different types of tokens. While I am open to this i= f > needed, it seems to add a significant complexity. Also, part 2 will then = need > to be able to provision both symmetric and asymmetric secrets which adds = to > the complexity there. >=20 > In other words, why put the effort in if no one is asking for this (based= on 2 > years of deployment experience). >=20 > > 2. Is it an objective to have the Token auth-scheme contain extension > points > > so that new token formats can be introduced without need to redefine > the > > scheme or draft a new one? >=20 > Yes, but see above. >=20 > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From mjmalone@gmail.com Mon Nov 30 11:26:47 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC9923A6988 for ; Mon, 30 Nov 2009 11:26:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 wDn875kDeQOM for ; Mon, 30 Nov 2009 11:26:46 -0800 (PST) Received: from mail-qy0-f183.google.com (mail-qy0-f183.google.com [209.85.221.183]) by core3.amsl.com (Postfix) with ESMTP id 83AA03A6AD5 for ; Mon, 30 Nov 2009 11:26:46 -0800 (PST) Received: by qyk13 with SMTP id 13so207522qyk.31 for ; Mon, 30 Nov 2009 11:26:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=2XM5dU+mumSWD1r5GCDEuMAz231eP3DVvZeCQsOKDBY=; b=sLyn/U+kuOChH3wRGqqEUt4mi4ygEoy5EU+VJ8GBnVYw5CtMaNsuTpwnL0czUhXHLb 3Oq8z6I5Ef54zbrCKB+vzDMkaVmjUHphAy7cA78QWfFX7nV4P6Tp4uKpnKEl1iATiuPG PHKG+wuItV3L/z1vAI0MQdyxvda4cX9a6ZhgQ= 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=ZeFPLoyc/aZCx6+FV2/3gECxDi40yWFkjyNzrqbN+NV25WsSrp0fmeYNh9nGT/wI14 JlbLmqSO2L0AJB3yB6q7w69nvdKWQM+k1u0Xi3KzXQNjeG45Wf/5C10T70+aR4zD8GNU GxWJEKT2M1HkxJngu5vu6QlEo9HRzi8Yea4gQ= MIME-Version: 1.0 Received: by 10.229.31.9 with SMTP id w9mr644223qcc.17.1259609195086; Mon, 30 Nov 2009 11:26:35 -0800 (PST) In-Reply-To: References: Date: Mon, 30 Nov 2009 11:26:35 -0800 Message-ID: From: Mike Malone To: Brent Goldman Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: Naitik Shah , "oauth@ietf.org" , Luke Shepard Subject: Re: [OAUTH-WG] WRAP session fixation? X-BeenThere: oauth@ietf.org X-Mailman-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, 30 Nov 2009 19:26:48 -0000 Interesting, but presumably if the callback is transferred securely (e.g., if it's transmitted from the consumer with a signature) none of this is really necessary. You'd probably want to blacklist some URI schemes (like javascript:) but other than that as long as you can verify that the consumer is sending the callback then what's wrong with assuming it's legitimate? Of course that doesn't work with Connect, since the browser-based flow complicates things, but for OAuth I think formalizing more rigorous rules for validating the callback isn't necessary. Mike On Wed, Nov 25, 2009 at 6:57 AM, Brent Goldman wrote: > Facebook Platform/Connect has some pretty interesting logic involving > registered callback URLs in our proprietary auth flows. Much of this is > because we hate showing error messages.=A0Maybe OAuth could borrow some o= f > these ideas? Here's some more info. > I'm using the terminology "specified callback URL" to refer to the callba= ck > URL specified in the request, and "registered callback URL" to refer to t= he > callback URL configured with us in advance. There are two types of callba= ck > URLs that can be specified in a request: absolute and relative. > Case 1. Specified callback URL is absolute. > If the specified callback URL is "safe", we redirect to it. Otherwise, > instead of throwing an error,=A0we redirect to the registered callback UR= L, > with the specified callback URL in a GET param called "next". It's up to = the > developer of the registered callback URL to use the "next" param, or they > can just ignore it. > To determine if the specified callback URL is safe: if the registered > callback URL is a directory, then the specified callback URL has to be > within that subdirectory. Otherwise, the specified callback URL has to po= int > to the same file as the registered callback URL, and any query params on = the > registered callback URL have to also be present in the specified callback > URL > For example, if the registered callback URL is > http://www.foobar.com/callback/, and the specified callback URL is > http://www.foobar.com/callback/method2, we know the specified callback UR= L > is safe and thus redirect directly there. But if the specified callback U= RL > is http://www.facebook.com/logged-into-foobar, which is unsafe, we redire= ct > to > http://www.foobar.com/callback?next=3D{urlencode(http://www.facebook.com/= logged-into-foobar)} > Note: we also support the concept of a "base domain", which essentially > whitelists every page on that domain, and every page on all subdomains of > that domain, as safe. > Case 2. Specified callback URL is relative. > In this case, there's no issue of safety, since we'll always redirect to = a > URL constructed based on the registered callback URL, which is by definit= ion > safe. > More information about constructing the URL to redirect to: > 2.1. If the registered callback URL doesn't have a question mark anywhere= in > it, we can just append the specified callback URL to it and redirect. For > example, with a registered callback of http://www.foobar.com/callback/ an= d a > specified callback URL of "loggedin.php?done=3Dtrue", we redirect to > http://www.foobar.com/callback/loggedin.php?done=3Dtrue. > 2.2 If the registered callback URL has a question mark, we append the > specified callback URL directly, but do some munging to the params to get > everything on the same level. For example, with a registered callback of > "http://www.foobar.com/callback?page=3D" and a specified callback URL of > "loggedin.php?done=3Dtrue", we redirect to > http://www.foobar.com/callback?page=3Dloggedin.php&done=3Dtrue (notice ho= w the > second ? changed to a &). > Case 3. Unspecified callback URL. > I lied, there's actually a third case. We support auth flows with > unspecified callback URLs in the request. If there's a registered callbac= k > URL, we just redirect there. Otherwise, we show an error message. So > basically the only way to get an error message is if there is no specifie= d > callback URL or registered callback URL. > -Brent > > On Nov 24, 2009, at 6:17 PM, Brian Eaton wrote: > > On Tue, Nov 24, 2009 at 6:14 PM, Luke Shepard wro= te: > > Yup, that=92s basically what we do today- throw an error and don=92t retu= rn. But > > this is less than ideal. > > We have discussed that we=92d probably like to return, but with an error > > message. This would be in section 5.4.4 of the spec (=93Authorization ser= ver > > directs user back to the client=94) we would like to pass additional > > parameters for the error message- something other than user_denied, but > > which indicates that the application was just misconfigured. > > I guess it depends on the business requirements that led to callback > URL preregistration. =A0Some sites require callback URL registration so > they don't need to redirect to unknown third-party sites... in which > case redirecting with an error message doesn't really fix the issue. > > Other sites require callback URL registration for security reasons, in > which case an error message is just fine. > > Cheers, > Brian > > From eran@hueniverse.com Mon Nov 30 11:32:15 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 391833A693C for ; Mon, 30 Nov 2009 11:32:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.46 X-Spam-Level: X-Spam-Status: No, score=-2.46 tagged_above=-999 required=5 tests=[AWL=0.139, 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 1lF44bmn0p+r for ; Mon, 30 Nov 2009 11:32:14 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 33A923A6916 for ; Mon, 30 Nov 2009 11:32:14 -0800 (PST) Received: (qmail 25519 invoked from network); 30 Nov 2009 19:32:07 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 30 Nov 2009 19:32:07 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 30 Nov 2009 12:32:06 -0700 From: Eran Hammer-Lahav To: Hans Granqvist , "OAuth WG (oauth@ietf.org)" Date: Mon, 30 Nov 2009 12:32:10 -0700 Thread-Topic: [OAUTH-WG] OAuth 2.0 / Charter Thread-Index: Acpx4uzUWn4j0+FMT5iy3ARUlfNu2AAECwCw Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343785209B8C@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343785209A24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1259536078.19069.6.camel@localhost> <90C41DD21FB7C64BB94121FBBC2E72343785209A5A@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] OAuth 2.0 / Charter X-BeenThere: oauth@ietf.org X-Mailman-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, 30 Nov 2009 19:32:15 -0000 The issue with RSA-SHA1-like method isn't the signature or crypto. Those ar= e trivial to spec out. The issue is everything else we didn't cover in 1.0 = including key management and rotation, and how to establish it. We had rough consensus about dropping the client credentials (consumer key)= from protected resources requests. This means you may use client credentia= ls to request a token, but once you have the token, you don't need to use t= he client credentials anymore. The implications of this are that any PK-bas= ed method will need to work at the token level, not the client level. With this approach, it will be easy to include a PK method alongside an HMA= C method, but it is not clear how the secret portion of the token pair will= be obtained and managed. My limited understanding suggests that issuing a = token-secret pair isn't the same as a token-Private Key pair. Maybe I'm wro= ng and it can be made as trivial. And no, there will be nothing to prevent such an extension. EHL > -----Original Message----- > From: Hans Granqvist [mailto:hans@granqvist.com] > Sent: Monday, November 30, 2009 9:31 AM > To: OAuth WG (oauth@ietf.org) > Cc: Eran Hammer-Lahav; Pelle Braendgaard > Subject: Re: [OAUTH-WG] OAuth 2.0 / Charter >=20 > It's tricky. If you allow only MACs, you have to forgo no only RSA (and E= CC...) > but also potentially traditional symmetric key schemes -- their usability > notwithstanding. >=20 > On the other hand, if you try to cover all possible key schemes, it quick= ly > becomes unmanageable. >=20 > Eran, is there a way to define what you want and leave it open for, say a= n > RSA extension, as long as it can be represented as a string, such as > {ALGORITHM}:{STRING}, and where any extra protocol flows are out of this > specification's scope? >=20 > -Hans >=20 >=20 > On Mon, Nov 30, 2009 at 7:53 AM, Pelle Braendgaard > wrote: > > +1 for all minus dropping RSA. > > > > I think the main reason we haven't seen a lot of RSA implementations > > yet has been because the kind of businesses who I think would be > > interested in using this such as banks/payments etc are not > > traditionally early adopters. If we want to see OAUTH used in these > > areas in the future I think it would be a very good idea to leave it > > in. > > > > I am personally working on creating new OAuth based financial > > transaction standard called OpenTransact, where we are planning on > > standardizing on RSA in the next revision. > > > > Regards > > Pelle > > > > > > On Mon, Nov 30, 2009 at 2:34 AM, Eran Hammer-Lahav > wrote: > >> > >> > >>> -----Original Message----- > >>> From: Paul C. Bryan [mailto:email@pbryan.net] > >>> Sent: Sunday, November 29, 2009 3:08 PM > >>> To: Eran Hammer-Lahav > >>> Cc: Peter Saint-Andre (stpeter@stpeter.im); Lisa Dusseault > >>> (lisa.dusseault@gmail.com); OAuth WG (oauth@ietf.org) > >>> Subject: Re: [OAUTH-WG] OAuth 2.0 / Charter > >>> > >>> To the overall approach, +1. > >>> > >>> Some follow-up questions: > >>> > >>> 1. Why drop RSA? It seems some form of public key cryptography will > >>> be necessary/useful to make web-based-attribute-containing tokens > >>> Internet- scalable. > >> > >> Mostly due to lack of implementation experience or interest within the > OAuth community. But also because the Plain and MAC versions are based > on a simple symmetric shared secret, while PK requires more. This means w= e > will need to support different types of tokens. While I am open to this i= f > needed, it seems to add a significant complexity. Also, part 2 will then = need > to be able to provision both symmetric and asymmetric secrets which adds = to > the complexity there. > >> > >> In other words, why put the effort in if no one is asking for this (ba= sed on > 2 years of deployment experience). > >> > >>> 2. Is it an objective to have the Token auth-scheme contain > >>> extension points so that new token formats can be introduced without > >>> need to redefine the scheme or draft a new one? > >> > >> Yes, but see above. > >> > >> EHL > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > >> > > > > > > > > -- > > http://agree2.com - Reach Agreement! > > http://extraeagle.com - Solutions for the electronic Extra Legal world > > http://stakeventures.com - Bootstrapping blog > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > From eran@hueniverse.com Mon Nov 30 11:33:28 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9B273A695A for ; Mon, 30 Nov 2009 11:33:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.134, 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 AhZnpWiF9gmk for ; Mon, 30 Nov 2009 11:33:20 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id A0CE03A6916 for ; Mon, 30 Nov 2009 11:33:20 -0800 (PST) Received: (qmail 26790 invoked from network); 30 Nov 2009 19:33:13 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 30 Nov 2009 19:33:12 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 30 Nov 2009 12:33:11 -0700 From: Eran Hammer-Lahav To: Greg Brail Date: Mon, 30 Nov 2009 12:33:15 -0700 Thread-Topic: OAuth 2.0 / Charter Thread-Index: AcpwydwemcwGclDiS3iUrmJW9KSv5AArlwTgAAXaE8AAFPHpgAAEHj5Q Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343785209B8E@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343785209A24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <48AE706BD74FCC4297AD778805CA46F6184C5CF474@usps.sonoa.local> <90C41DD21FB7C64BB94121FBBC2E72343785209A5B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <48AE706BD74FCC4297AD778805CA46F6184C5CF49B@usps.sonoa.local> In-Reply-To: <48AE706BD74FCC4297AD778805CA46F6184C5CF49B@usps.sonoa.local> 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_90C41DD21FB7C64BB94121FBBC2E72343785209B8EP3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] OAuth 2.0 / Charter X-BeenThere: oauth@ietf.org X-Mailman-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, 30 Nov 2009 19:33:28 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343785209B8EP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable SWT is one. http://groups.google.com/group/oauth-wrap-wg EHL From: Greg Brail [mailto:gbrail@sonoasystems.com] Sent: Monday, November 30, 2009 9:35 AM To: Eran Hammer-Lahav Cc: OAuth WG (oauth@ietf.org) Subject: RE: OAuth 2.0 / Charter Thanks for the clarification. I do think that a standard token structure would be a good thing for the In= ternet in general. Is there another effort I should be following regarding = the token structure itself? ________________________________ From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Monday, November 30, 2009 2:36 AM To: Greg Brail Cc: OAuth WG (oauth@ietf.org) Subject: RE: OAuth 2.0 / Charter Keep in mind that we are not going to include token structure in scope. We = are simply proposing a method in which the token is a string, leaving it up= to other efforts to give it structure if needed. EHL From: Greg Brail [mailto:gbrail@sonoasystems.com] Sent: Sunday, November 29, 2009 9:05 PM To: Eran Hammer-Lahav Cc: OAuth WG (oauth@ietf.org) Subject: RE: OAuth 2.0 / Charter I've been following this discussion for a while now as a relative newcomer = and I think this is a great idea. Forgive me if all you guys have reached t= his conclusion already: Since we all understand OAuth, there are other places where tokens are popp= ing up: * As a "more secure" replacement for username / password authentication in= web services APIs like Amazon's * As a way for the developer of an API to understand which developer's app= lications are being used against the API, when it is less important to iden= tify the actual user (for instance, the classical "API key" use case, or "t= wo-legged OAuth") * As a way for the developer of a mobile app to ensure that only that app = can make use of a particular web service, even if it is not important to id= entify the actual user * Lots of others I'm sure I'm missing The sooner there is some movement towards a standard "token," the sooner we= will have token support in a variety of programming environments. Plus, a = standard token will reduce the propensity of web services builders to desig= n their own tokens, with varying levels of security. Plus, the OAuth flow has clearly proven to be useful and it deserves to be = a standard that makes use of the standard token. On the design of the token itself, I hope that it will have a place for one= , two, or even more combinations of keys and secrets, so that it can handle= simple use cases, more complex use cases such as OAuth, and even those tha= t require three or more separate identifiers for a request. greg -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Sunday, November 29, 2009 2:59 AM To: Peter Saint-Andre (stpeter@stpeter.im); Lisa Dusseault (lisa.dusseault@= gmail.com) Cc: OAuth WG (oauth@ietf.org) Subject: [OAUTH-WG] OAuth 2.0 / Charter With the cleanup of the 1.0 specification [1] and the publication of an inf= ormational RFC (pending IESG approval), I no longer see value in a standard= closely based on the 1.0 specification, which was the original intention o= f this WG. This is also reflected by the recent interest in the WRAP propos= al [2]. Instead, I think we should develop two specifications that while closely in= line with the original plan, represent a significant shift. In other words= , I am proposing we develop OAuth 2.0, not 1.1. The new proposal is to develop two specifications: 1. Token Authorization Method An RFC 2617 Authorization header called 'Token' for authenticating requests= with token-based credentials. Tokens (with optional shared-secret) are usu= ally used in place of other credentials (usernames, etc.) and represent som= e combination of scope and authorization. The token method will include an = extensible signature-based option based on the HMAC-SHA1 method, and a bear= er token (with optional secret) option based on the PLAINTEXT method. The R= SA option will be dropped. 2. OAuth 2.0 A specification based on the browser-redirection flow described in OAuth 1.= 0 as well as new methods defined in WRAP (I-D submission pending). OAuth wi= ll be redefined to cover the authorization component only, and will no long= er be bound to a single authentication method. This will make OAuth immedia= tely useful for other protocols than HTTP (while HTTP will be used to obtai= n tokens, tokens will be useful in other protocols, not just with the HTTP = and Token method). --- While the current charter allows much of this work, it contradicts its spir= it and the understanding reached when we created the working group. I would like to ask: - Is this approach favorable by the group? - Do we need to adjust the language in the charter to support? EHL [1] http://tools.ietf.org/html/draft-hammer-oauth [2] http://bit.ly/oauth-wrap _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_90C41DD21FB7C64BB94121FBBC2E72343785209B8EP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

SWT is on= e.

 

http://groups.google.com/group/oauth-wrap-= wg

 

EHL

 

From: Greg Brail [mailto:gbrail@sonoasystems.com]
Sent: Mond= ay, November 30, 2009 9:35 AM
To: Eran Hammer-Lahav
Cc:= OAuth WG (oauth@ietf.org)
Subject: RE: OAuth 2.0 / Charter<= /o:p>

 

Thanks for the clarification.

=  

I do think that a standard token structu= re would be a good thing for the Internet in general. Is there another effo= rt I should be following regarding the token structure itself?

 

From: Eran Hammer-Lahav [mailto:eran@= hueniverse.com]
Sent: Monday, November 30, 2009 2:36 AM
To= : Greg Brail
Cc: OAuth WG (oauth@ietf.org)
Subject:= RE: OAuth 2.0 / Charter

 

Keep in mind that we are not= going to include token structure in scope. We are simply proposing a metho= d in which the token is a string, leaving it up to other efforts to give it= structure if needed.

 

EHL

 

From: Greg Brail [mailto:gbrail@sonoasystems.com] Sent: Sunday, November 29, 2009 9:05 PM
To: Eran Hammer-= Lahav
Cc: OAuth WG (oauth@ietf.org)
Subject: RE: OAuth = 2.0 / Charter

&n= bsp;

I’ve been following this discus= sion for a while now as a relative newcomer and I think this is a great ide= a. Forgive me if all you guys have reached this conclusion already:

 

Since we all understand OAuth, there are other places where tokens are pop= ping up:

 

·  As a way for the developer of an API to understand which developer’s= applications are being used against the API, when it is less important to = identify the actual user (for instance, the classical “API key”= use case, or “two-legged OAuth”)

· = ; As a way for the developer of a mobile app= to ensure that only that app can make use of a particular web service, eve= n if it is not important to identify the actual user

·

 

2. OAuth 2.0

 

A specification based on the browser-redirection = flow described in OAuth 1.0 as well as new methods defined in WRAP (I-D sub= mission pending). OAuth will be redefined to cover the authorization compon= ent only, and will no longer be bound to a single authentication method. Th= is will make OAuth immediately useful for other protocols than HTTP (while = HTTP will be used to obtain tokens, tokens will be useful in other protocol= s, not just with the HTTP and Token method).

 

---

 

While the = current charter allows much of this work, it contradicts its spirit and the= understanding reached when we created the working group.

 

I would = like to ask:

 

- Is this approach favorable by the group?<= /p>

- Do we need to adjust the language in the chart= er to support?

 

<= p class=3DMsoPlainText>EHL

 = ;

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

[2] http://bit.ly/oauth-wrap

&n= bsp;

_____________________________________= __________

OAuth mailing list

OAuth@ietf= .org

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

= --_000_90C41DD21FB7C64BB94121FBBC2E72343785209B8EP3PW5EX1MB01E_-- From mjmalone@gmail.com Mon Nov 30 11:44:13 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C6383A699C for ; Mon, 30 Nov 2009 11:44:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Spmzz0YaE8R for ; Mon, 30 Nov 2009 11:44:12 -0800 (PST) Received: from mail-qy0-f183.google.com (mail-qy0-f183.google.com [209.85.221.183]) by core3.amsl.com (Postfix) with ESMTP id 9CB303A6998 for ; Mon, 30 Nov 2009 11:44:12 -0800 (PST) Received: by qyk13 with SMTP id 13so216272qyk.31 for ; Mon, 30 Nov 2009 11:44:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ZLfmY+oY9SDutkSzUrr4PMWJh/ot5I6HFN9VJMDVS2k=; b=bYcxfPyrEpRzVlrip6FoksEiNvv+BFV0iTvvsrEqWeGOXUgSZxZg7gHKx2sIbRgSAP 6/UGkQ0DgSJlzL7QQSNSVzuV9w59fBUNn6AzvQjydmPkOV+2y+i/6To1SSJqwJzH+r3T aFJR1vcKjFRTnouYS6SbsU7n24XBqgThyBW8w= 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=fJx4eKPNTebYl8vS/OxqShoKS00cWz3+df1egWZ0ULeSyi86cS8UJbnqtWc9dUMkZe m9+6j+6EhE30zsg79lVvAyEYKbi3YCGwhEuKD/+Zoz14ocygQGYrkfJMfU5gbS+HA8Hc wSIc4x6y+jIApMopS3Vg8Db/+AA674eBjn67E= MIME-Version: 1.0 Received: by 10.229.1.139 with SMTP id 11mr637211qcf.2.1259610241979; Mon, 30 Nov 2009 11:44:01 -0800 (PST) In-Reply-To: References: <148C596691F29F4EA6968577BE2CDFAE06A1B9FE@SC-MBXC1.TheFacebook.com> Date: Mon, 30 Nov 2009 11:44:01 -0800 Message-ID: From: Mike Malone To: Brent Goldman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Naitik Shah , Luke Shepard , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Facebook, OAuth, and WRAP X-BeenThere: oauth@ietf.org X-Mailman-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, 30 Nov 2009 19:44:13 -0000 On Wed, Nov 25, 2009 at 6:03 AM, Brent Goldman wrote: > This is a really interesting idea that I think makes a lot of sense. I do= n't > see why the various WRAP profiles couldn't work almost identically in OAu= th > 2.0, with the main differences being that=A0OAuth 2.0 would have an extra= step > to exchange a secret (or perhaps even reuse a step if it makes sense, and > then API calls would have a signature instead of being called over SSL. Yes. > Good point about the tokens. One of us should make a list of all the term= s > in each spec, and then set up a mapping between the sets, to see if the > number of concepts is really all that different. My informal list (from a cursory read of the spec): OAuth / WRAP Consumer / Client Request Token / Refresh Token Access Token / Access Token Consumer Token / Client identifier & secret OAuth Verifier / Verification Code There are probably others that I'm missing. > Why does the lack of signatures mean we can't use GET params? We can stil= l > trust everything because it's happening over SSL. I guess technically GET params are secure with HTTPS, it just _feels_ kinda dirty since the URL (including params) is often bandied about without a lot of thought. It may show up in logs, web server scoreboards (Twitter's recent Apache scoreboard snafu comes to mind), error messages, etc. Since a request doesn't have a nonce or timestamp they can be replayed until the access token expires. Then again, maybe I'm just being paranoid / playing devil's advocate here. Mike From Dick.Hardt@microsoft.com Mon Nov 30 11:57:15 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC89A3A68C9 for ; Mon, 30 Nov 2009 11:57:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.465 X-Spam-Level: X-Spam-Status: No, score=-10.465 tagged_above=-999 required=5 tests=[AWL=0.134, 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 5opXawqZqZx6 for ; Mon, 30 Nov 2009 11:57:15 -0800 (PST) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 239493A6890 for ; Mon, 30 Nov 2009 11:57:15 -0800 (PST) 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; Mon, 30 Nov 2009 11:57:33 -0800 Received: from TK5EX14MBXC101.redmond.corp.microsoft.com ([169.254.1.27]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi; Mon, 30 Nov 2009 11:57:07 -0800 From: Dick Hardt To: Eran Hammer-Lahav Thread-Topic: [OAUTH-WG] keeping support for RSA (Was: RE: OAuth 2.0 / Charter) Thread-Index: AQHKcfMcSQLjO+xFt0m7d8bLMYTtBJFPkMqA Date: Mon, 30 Nov 2009 19:57:05 +0000 Message-ID: <5A9DD209-E811-4591-A26E-287B337082E9@microsoft.com> References: <90C41DD21FB7C64BB94121FBBC2E72343785209A24@P3PW5EX1MB01.EX1.SECURESERVER.NET><1259536078.19069.6.camel@localhost> <90C41DD21FB7C64BB94121FBBC2E72343785209A5A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785209B82@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343785209B82@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="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Moore, Jonathan \(CIM\)" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] keeping support for RSA (Was: RE: OAuth 2.0 / Charter) X-BeenThere: oauth@ietf.org X-Mailman-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, 30 Nov 2009 19:57:15 -0000 On 2009-11-30, at 9:25 AM, Eran Hammer-Lahav wrote: > 3. I will leave it up to the security experts to figure out if a PK optio= n in the *authentication* spec is worth having, compared to TLS/SSL. OAuth = did not require TLS because it was designed to be friendly to small sites l= ooking to deploy an API without having to deal with certificates. The perfo= rmance overhead wasn't really the main issue, it was practicality. For exam= ple, I would like to be able to write a Wordpress plugin that exposes an ad= dress book API using OAuth, without being required to enable SSL on my blog= . Are there implementations of Wordpress plugins using OAuth? ie., was there = a real market need for this, or just a perceived need? If you don't have SSL on your blog management endpoint, then your blog cred= entials are being transported in the clear. I don't have SSL on my Wordpres= s blogs, and I'm ok with the risk given the tradeoffs. It seems like many o= ther people are as well currently.=20 While I agree it is desirable to improve security, is there real demand for= it?=20 In choosing where to put efforts, would it be "better" to drive down the ba= rriers to deploying SSL? -- Dick= From stpeter@stpeter.im Mon Nov 30 11:59:03 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19CB03A693F for ; Mon, 30 Nov 2009 11:59:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 wWcUot-6CKtx for ; Mon, 30 Nov 2009 11:59:02 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id E99CC3A68C9 for ; Mon, 30 Nov 2009 11:59:01 -0800 (PST) Received: from dhcp-64-101-72-196.cisco.com (dhcp-64-101-72-196.cisco.com [64.101.72.196]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 50E5040D26; Mon, 30 Nov 2009 12:58:53 -0700 (MST) Message-ID: <4B1423FB.2070506@stpeter.im> Date: Mon, 30 Nov 2009 12:58:51 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Stephen Farrell References: <90C41DD21FB7C64BB94121FBBC2E72343785209A24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <48AE706BD74FCC4297AD778805CA46F6184C5CF474@usps.sonoa.local> <90C41DD21FB7C64BB94121FBBC2E72343785209A5B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B1407A7.9040907@cs.tcd.ie> In-Reply-To: <4B1407A7.9040907@cs.tcd.ie> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050805050402060502050000" Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] OAuth 2.0 / Charter X-BeenThere: oauth@ietf.org X-Mailman-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, 30 Nov 2009 19:59:03 -0000 This is a cryptographically signed message in MIME format. --------------ms050805050402060502050000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 11/30/09 10:57 AM, Stephen Farrell wrote: > While I think the general goal seems ok, and perhaps even better, I do think it is worthwhile to have a discussion about the proper "general goal" for this WG, especially given the changing landscape regarding OAuth[-ish] technologies. > I do wonder whether its reasonable to re-charter a WG that has > never formally met face to face, The chairs take responsibility for the lack of a meeting, but I can guarantee you that the group will meet at IETF 77. > nor met any of its current > milestones. Given that the WG was chartered on May 13, it was perhaps a bit aggressive to "Submit 'OAuth: HTTP Authorization Delegation Protocol' as working group item" in Apr 2009. :) Based on list discussion in May and June, we came to consensus to split draft-hammer-oauth into two specifications, which Eran did in early July, resulting in draft-ietf-oauth-authentication and draft-ietf-oauth-web-delegation as WG items. We've had quite a bit of discussion about those on the list, but it seems to me that the discussion here and elsewhere has led to a desire for something more than a simple, backwards-compatible specification of "OAuth 1.1" as described in the charter. In particular, the scope of "OAuth 1.1" appears to have been limited to improving terminology, embodying good security practices, promoting interoperability, and providing guidelines for extensibility. > It may be, I'm just not sure, but what's the reason for not > finishing OAuth 1.1 first? (The fact that you "see no value" > doesn't explain it to me at least.) I agree that we need to get the reasons out on the table so that we can have an open discussion about problems and objectives. > I also find the following a bit puzzling: > > Eran Hammer-Lahav wrote: >> Keep in mind that we are not going to include token structure in scope. >> We are simply proposing a method in which the token is a string, leaving >> it up to other efforts to give it structure if needed. > > What other efforts? How would the implementer of an RFC achieve > interoperability? Wouldn't we need to be able to answer that before > proceeding? Those are good questions. > To answer your specific questions: > >> - Is this approach favorable by the group? > > Maybe. > >> - Do we need to adjust the language in the charter to support? > > Definitely IMO. The current charter talks about striving to > maintain backwards compatibility etc. The charter also says: However, changes that are not backwards compatible might be accepted if the group determines that the changes are required to meet the group's technical objectives and the group clearly documents the reasons for making them. That implies the need to, above all, clarify the group's technical objectives. IMHO the problem statement is not fully clear in the existing charter, and furthermore it appears that some people now might be trying to solve related but somewhat different problems with OAuth (or something similar enough to OAuth that it can retain the name). That might be either exciting or worrisome, depending on your perspective. Peter -- Peter Saint-Andre https://stpeter.im/ --------------ms050805050402060502050000 Content-Type: application/x-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 hvcNAQkFMQ8XDTA5MTEzMDE5NTg1MVowIwYJKoZIhvcNAQkEMRYEFKJDC9ux5lLvkJ3djavk hk3LtbKJMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAR0+oe16V+5KjqlL7HU/8uwQabvUp3DSgMtrcvpI7 IibWRY4nalJd2Nqp0NTzpfLeBOnoIWyzwwu0oZh0MAZr9RhWqkvDlkNASAh8/UA2BMdq67mZ PL/GWPYUK4eZhphwRLKB3CJeObDcX+tgLyZyHyBBW/QArEW1NTL7uk9z3FDv48XZ3HRyxTRu QRuK21+CUwJHa2z/TtYmMMz64Onw9T3hb2zPjL/6aARbvZ/8wcvlRz1/yWOAKDrjkT5vYxzL lf0ObITiFGuqvjwEN2OlAN/IxJxphUHaE/qBAkq1dJ1iZoMt7V+3wjef49FWMHuk5mTANuk9 /FJQG7uGxjt5/wAAAAAAAA== --------------ms050805050402060502050000-- From eran@hueniverse.com Mon Nov 30 12:06:15 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2C673A6992 for ; Mon, 30 Nov 2009 12:06:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, 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 s5yPUZE8Iple for ; Mon, 30 Nov 2009 12:06:14 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 897833A68FD for ; Mon, 30 Nov 2009 12:06:14 -0800 (PST) Received: (qmail 3813 invoked from network); 30 Nov 2009 20:06:01 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 30 Nov 2009 20:06:01 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 30 Nov 2009 13:06:01 -0700 From: Eran Hammer-Lahav To: Stephen Farrell Date: Mon, 30 Nov 2009 13:06:05 -0700 Thread-Topic: [OAUTH-WG] OAuth 2.0 / Charter Thread-Index: Acpx5qyoMpJpgHfVT9O/h2GHAUzjUQADbmdA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343785209BA7@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343785209A24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <48AE706BD74FCC4297AD778805CA46F6184C5CF474@usps.sonoa.local> <90C41DD21FB7C64BB94121FBBC2E72343785209A5B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B1407A7.9040907@cs.tcd.ie> In-Reply-To: <4B1407A7.9040907@cs.tcd.ie> 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] OAuth 2.0 / Charter X-BeenThere: oauth@ietf.org X-Mailman-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, 30 Nov 2009 20:06:15 -0000 > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Monday, November 30, 2009 9:58 AM > To: Eran Hammer-Lahav > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] OAuth 2.0 / Charter >=20 >=20 > While I think the general goal seems ok, and perhaps even better, I do > wonder whether its reasonable to re-charter a WG that has never formally > met face to face, nor met any of its current milestones. This is a valid concern. I personally consider face to face meetings to be over rated and hardly eve= r worth the effort. Meetings are great for people involved in many IETF eff= orts, but I believe the majority of active WG members are not likely to tra= vel more than a couple hours for a 2-hour meeting. Of course, this is all u= p to the chair to decide. > It may be, I'm just not sure, but what's the reason for not finishing OAu= th 1.1 > first? (The fact that you "see no value" > doesn't explain it to me at least.) The people who cared most about this approach didn't really bother to show = up to the table. The 1.0 community for the most part has shown no interest = in this work or the value of it (patching up 1.0). I am not interest in wor= king on 1.1 as an editor or otherwise. It would be a waste of my time. I th= ink the question is, who here is interested in finishing 1.1 as currently c= hartered? Also, who is going to implement it? Instead, I spend a significant effort to clean up 1.0 and make it useful an= d presentable for those wishing to use it. I think that in order to fix OAu= th and reach the right balance of security and interop, we need a different= approach that is not backward compatible. I never cared much for the backw= ard compatibility argument, which proved to be wrong when 50 companies upgr= aded their OAuth implementation practically overnight when a security probl= em was found. > I also find the following a bit puzzling: >=20 > Eran Hammer-Lahav wrote: > > Keep in mind that we are not going to include token structure in scope. > > We are simply proposing a method in which the token is a string, > > leaving it up to other efforts to give it structure if needed. >=20 > What other efforts? How would the implementer of an RFC achieve > interoperability? Wouldn't we need to be able to answer that before > proceeding? No. The current model isn't changing, and tokens are still being issued by = the server. Therefore, only the server needs to understand its structure an= d no interop is affected. Extending the model to self-issued tokens is cert= ainly possible but outside the proposed scope. It would be vastly premature= to standardize token structures at this point. EHL From prateek.mishra@oracle.com Mon Nov 30 12:07:49 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F6663A68FF for ; Mon, 30 Nov 2009 12:07:49 -0800 (PST) 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 fwWbNdUsWF-q for ; Mon, 30 Nov 2009 12:07:48 -0800 (PST) Received: from acsinet11.oracle.com (acsinet11.oracle.com [141.146.126.233]) by core3.amsl.com (Postfix) with ESMTP id DF8DC3A684C for ; Mon, 30 Nov 2009 12:07:47 -0800 (PST) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by acsinet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id nAUK7a55020488 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 30 Nov 2009 20:07:37 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id nAUJ9LlG022691; Mon, 30 Nov 2009 20:07:41 GMT Received: from abhmt017.oracle.com by acsmt357.oracle.com with ESMTP id 693243151259611642; Mon, 30 Nov 2009 14:07:22 -0600 Received: from [141.144.121.46] (/141.144.121.46) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 30 Nov 2009 12:07:21 -0800 Message-ID: <4B1425D3.5070909@oracle.com> Date: Mon, 30 Nov 2009 15:06:43 -0500 From: Prateek Mishra Organization: Oracle Corporation User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Eran Hammer-Lahav References: <90C41DD21FB7C64BB94121FBBC2E72343785209A24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <48AE706BD74FCC4297AD778805CA46F6184C5CF474@usps.sonoa.local> <90C41DD21FB7C64BB94121FBBC2E72343785209A5B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <48AE706BD74FCC4297AD778805CA46F6184C5CF49B@usps.sonoa.local> <90C41DD21FB7C64BB94121FBBC2E72343785209B8E@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343785209B8E@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Source-IP: acsmt356.oracle.com [141.146.40.156] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4B142607.00D9:SCFMA4539814,ss=1,fgs=0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] OAuth 2.0 / Charter X-BeenThere: oauth@ietf.org X-Mailman-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, 30 Nov 2009 20:07:49 -0000 Would a SAML assertion be an example of a "standard token structure"? > > SWT is one. > > http://groups.google.com/group/oauth-wrap-wg > > EHL > > *From:* Greg Brail [mailto:gbrail@sonoasystems.com] > *Sent:* Monday, November 30, 2009 9:35 AM > *To:* Eran Hammer-Lahav > *Cc:* OAuth WG (oauth@ietf.org) > *Subject:* RE: OAuth 2.0 / Charter > > Thanks for the clarification. > > I do think that a standard token structure would be a good thing for > the Internet in general. Is there another effort I should be following > regarding the token structure itself? > > ------------------------------------------------------------------------ > > *From:* Eran Hammer-Lahav [mailto:eran@hueniverse.com] > *Sent:* Monday, November 30, 2009 2:36 AM > *To:* Greg Brail > *Cc:* OAuth WG (oauth@ietf.org) > *Subject:* RE: OAuth 2.0 / Charter > > Keep in mind that we are not going to include token structure in > scope. We are simply proposing a method in which the token is a > string, leaving it up to other efforts to give it structure if needed. > > EHL > > *From:* Greg Brail [mailto:gbrail@sonoasystems.com] > *Sent:* Sunday, November 29, 2009 9:05 PM > *To:* Eran Hammer-Lahav > *Cc:* OAuth WG (oauth@ietf.org) > *Subject:* RE: OAuth 2.0 / Charter > > I’ve been following this discussion for a while now as a relative > newcomer and I think this is a great idea. Forgive me if all you guys > have reached this conclusion already: > > Since we all understand OAuth, there are other places where tokens are > popping up: > > · As a “more secure” replacement for username / password > authentication in web services APIs like Amazon’s > > · As a way for the developer of an API to understand which developer’s > applications are being used against the API, when it is less important > to identify the actual user (for instance, the classical “API key” use > case, or “two-legged OAuth”) > > · As a way for the developer of a mobile app to ensure that only that > app can make use of a particular web service, even if it is not > important to identify the actual user > > · Lots of others I’m sure I’m missing > > The sooner there is some movement towards a standard “token,” the > sooner we will have token support in a variety of programming > environments. Plus, a standard token will reduce the propensity of web > services builders to design their own tokens, with varying levels of > security. > > Plus, the OAuth flow has clearly proven to be useful and it deserves > to be a standard that makes use of the standard token. > > On the design of the token itself, I hope that it will have a place > for one, two, or even more combinations of keys and secrets, so that > it can handle simple use cases, more complex use cases such as OAuth, > and even those that require three or more separate identifiers for a > request. > > greg > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Eran Hammer-Lahav > Sent: Sunday, November 29, 2009 2:59 AM > To: Peter Saint-Andre (stpeter@stpeter.im); Lisa Dusseault > (lisa.dusseault@gmail.com) > Cc: OAuth WG (oauth@ietf.org) > Subject: [OAUTH-WG] OAuth 2.0 / Charter > > With the cleanup of the 1.0 specification [1] and the publication of > an informational RFC (pending IESG approval), I no longer see value in > a standard closely based on the 1.0 specification, which was the > original intention of this WG. This is also reflected by the recent > interest in the WRAP proposal [2]. > > Instead, I think we should develop two specifications that while > closely in line with the original plan, represent a significant shift. > In other words, I am proposing we develop OAuth 2.0, not 1.1. > > The new proposal is to develop two specifications: > > 1. Token Authorization Method > > An RFC 2617 Authorization header called 'Token' for authenticating > requests with token-based credentials. Tokens (with optional > shared-secret) are usually used in place of other credentials > (usernames, etc.) and represent some combination of scope and > authorization. The token method will include an extensible > signature-based option based on the HMAC-SHA1 method, and a bearer > token (with optional secret) option based on the PLAINTEXT method. The > RSA option will be dropped. > > 2. OAuth 2.0 > > A specification based on the browser-redirection flow described in > OAuth 1.0 as well as new methods defined in WRAP (I-D submission > pending). OAuth will be redefined to cover the authorization component > only, and will no longer be bound to a single authentication method. > This will make OAuth immediately useful for other protocols than HTTP > (while HTTP will be used to obtain tokens, tokens will be useful in > other protocols, not just with the HTTP and Token method). > > --- > > While the current charter allows much of this work, it contradicts its > spirit and the understanding reached when we created the working group. > > I would like to ask: > > - Is this approach favorable by the group? > > - Do we need to adjust the language in the charter to support? > > EHL > > [1] http://tools.ietf.org/html/draft-hammer-oauth > > [2] http://bit.ly/oauth-wrap > > _______________________________________________ > > OAuth mailing 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 Nov 30 12:28:39 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B32D3A697E for ; Mon, 30 Nov 2009 12:28:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=0.126, 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 PIro-r3KY8xN for ; Mon, 30 Nov 2009 12:28:38 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 2D9B33A6979 for ; Mon, 30 Nov 2009 12:28:38 -0800 (PST) Received: (qmail 22643 invoked from network); 30 Nov 2009 20:28:29 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 30 Nov 2009 20:28:29 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 30 Nov 2009 13:27:22 -0700 From: Eran Hammer-Lahav To: "Tschofenig, Hannes (NSN - FI/Espoo)" , ext Dick Hardt Date: Mon, 30 Nov 2009 13:27:26 -0700 Thread-Topic: [OAUTH-WG] why are we signing? Thread-Index: AQHKYPpiJlPvjbF+7Eug3PbIB1m6s5EuVfSAgAED2ACAAt81AIAAASmAgABrE4CAAH1JAIABBIUAgACcJwCAAAx/gIAa2A2A//97K4CAAA8m8A== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343785209BBB@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <35D50F5C-3982-4298-A9E0-86A528F5C5D3@jkemp.net><4A956CE47D1066408D5C7EB34368A5110551FFC1@S4DE8PSAAQC.mitte.t-com.de><90C41DD21FB7C64BB94121FBBC2E72343785102B49@P3PW5EX1MB01.EX1.SECURESERVER.NET><90C41DD21FB7C64BB94121FBBC2E72343785102E58@P3PW5EX1MB01.EX1.SECURESERVER.NET><90C41DD21FB7C64BB94121FBBC2E72343785102F1F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <3D3C75174CB95F42AD6BCC56E5555B4501F19743@FIESEXC015.nsn-intra.net> In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B4501F19743@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 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] why are we signing? X-BeenThere: oauth@ietf.org X-Mailman-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, 30 Nov 2009 20:28:39 -0000 OAuth is being proposed as a generally useful method for securing API calls= . I expect many open source libraries to implement it on the server side an= d use it for blog plugins, widgets, and other highly distributed software. = If OAuth required the use of TLS, it would simply be ignored by all those a= pplications which will likely continue using Basic. With all due respect to big companies, their resources, and ability to effo= rtlessly deploy SSL/TLS, it is still an expensive and complex process for m= ore developers deploying small scale server components. EHL > -----Original Message----- > From: Tschofenig, Hannes (NSN - FI/Espoo) > [mailto:hannes.tschofenig@nsn.com] > Sent: Monday, November 30, 2009 11:23 AM > To: ext Dick Hardt; Eran Hammer-Lahav > Cc: oauth@ietf.org > Subject: RE: [OAUTH-WG] why are we signing? >=20 > I would also like to hear about the cases where TLS is not suitable. >=20 > Hannes >=20 > >-----Original Message----- > >From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > >Of ext Dick Hardt > >Sent: 30 November, 2009 21:18 > >To: Eran Hammer-Lahav > >Cc: oauth@ietf.org > >Subject: Re: [OAUTH-WG] why are we signing? > > > > > >On 2009-11-13, at 7:21 AM, Eran Hammer-Lahav wrote: > >> > >> I for one, see great value in offering some form of > >crypto-based security for cases where TLS is not suitable. > > > > > >Are these use cases enumerated somewhere? > > > >(Apologies for coming into the conversation late) > > > >_______________________________________________ > >OAuth mailing list > >OAuth@ietf.org > >https://www.ietf.org/mailman/listinfo/oauth > > From eran@hueniverse.com Mon Nov 30 12:40:14 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 253F23A693F for ; Mon, 30 Nov 2009 12:40:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.122, 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 qbK5ZHHIo1z5 for ; Mon, 30 Nov 2009 12:40:13 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 429AF3A67D9 for ; Mon, 30 Nov 2009 12:40:13 -0800 (PST) Received: (qmail 29760 invoked from network); 30 Nov 2009 20:40:06 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 30 Nov 2009 20:40:06 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Mon, 30 Nov 2009 13:40:05 -0700 From: Eran Hammer-Lahav To: Dick Hardt Date: Mon, 30 Nov 2009 13:40:09 -0700 Thread-Topic: [OAUTH-WG] keeping support for RSA (Was: RE: OAuth 2.0 / Charter) Thread-Index: AQHKcfMcSQLjO+xFt0m7d8bLMYTtBJFPkMqA//+C1ZA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343785209BC8@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343785209A24@P3PW5EX1MB01.EX1.SECURESERVER.NET><1259536078.19069.6.camel@localhost> <90C41DD21FB7C64BB94121FBBC2E72343785209A5A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785209B82@P3PW5EX1MB01.EX1.SECURESERVER.NET> <5A9DD209-E811-4591-A26E-287B337082E9@microsoft.com> In-Reply-To: <5A9DD209-E811-4591-A26E-287B337082E9@microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Moore, Jonathan \(CIM\)" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] keeping support for RSA (Was: RE: OAuth 2.0 / Charter) X-BeenThere: oauth@ietf.org X-Mailman-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, 30 Nov 2009 20:40:14 -0000 > -----Original Message----- > From: Dick Hardt [mailto:Dick.Hardt@microsoft.com] > Sent: Monday, November 30, 2009 11:57 AM > To: Eran Hammer-Lahav > Cc: Moore, Jonathan (CIM); Paul C. Bryan; oauth@ietf.org > Subject: Re: [OAUTH-WG] keeping support for RSA (Was: RE: OAuth 2.0 / > Charter) >=20 >=20 > On 2009-11-30, at 9:25 AM, Eran Hammer-Lahav wrote: >=20 > > 3. I will leave it up to the security experts to figure out if a PK opt= ion in the > *authentication* spec is worth having, compared to TLS/SSL. OAuth did not > require TLS because it was designed to be friendly to small sites looking= to > deploy an API without having to deal with certificates. The performance > overhead wasn't really the main issue, it was practicality. For example, = I > would like to be able to write a Wordpress plugin that exposes an address > book API using OAuth, without being required to enable SSL on my blog. >=20 > Are there implementations of Wordpress plugins using OAuth? ie., was ther= e > a real market need for this, or just a perceived need? Everything I'm working on or involved in (discovery, webfinger, portable co= ntacts, content sharing, etc.) is heading this way. It is critical that OAu= th will not create a barrier to entry for these technologies. For example, = we are now discussing how to manage access to machine-readable profiles for= people in webfinger. This technology will only work if it is easily availa= ble to self-hosted sites that deserve to be able to implement the same prot= ocols the big guys get to push. > If you don't have SSL on your blog management endpoint, then your blog > credentials are being transported in the clear. I don't have SSL on my > Wordpress blogs, and I'm ok with the risk given the tradeoffs. It seems l= ike > many other people are as well currently. >=20 > While I agree it is desirable to improve security, is there real demand f= or it? >=20 > In choosing where to put efforts, would it be "better" to drive down the > barriers to deploying SSL? This is clearly outside the scope of this work... :-) I doubt this will become simpler and cheaper anytime soon. The bottom line is that the new proposal separate the two, allowing people = who plan to use SSL across the board to focus on the other stuff. If OAuth = 1.0 requires SSL, it will accomplish nothing but a fork in the community an= d two competing solutions. Instead, my proposal makes it modular and allows= everyone to play along. EHL From jpanzer@google.com Mon Nov 30 12:41:21 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B575E3A69A0 for ; Mon, 30 Nov 2009 12:41:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.895 X-Spam-Level: X-Spam-Status: No, score=-105.895 tagged_above=-999 required=5 tests=[AWL=0.081, 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 Uv0gSf8bfQGl for ; Mon, 30 Nov 2009 12:41:20 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id DDF493A693F for ; Mon, 30 Nov 2009 12:41:18 -0800 (PST) Received: from zps18.corp.google.com (zps18.corp.google.com [172.25.146.18]) by smtp-out.google.com with ESMTP id nAUKfB3d005711 for ; Mon, 30 Nov 2009 12:41:11 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1259613671; bh=A5AGP6FFKf1PpckH2XX5V2m/moI=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=eUSr8p9LKWFB4r1r3xww0oVa5sqXJ1cPsycM/2cu72L3qYn0NBNbaX3Ww6yF2J9QQ hiJDXclQVncaCWGKfc63w== 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=K35xq30vQxzyG82cOndlOihoCi0R9dpmaYkCnil5aMTcIXeecFNuf/rrmymL3xmhG wrHFlI37D2F7JIIVMMJgQ== Received: from pxi11 (pxi11.prod.google.com [10.243.27.11]) by zps18.corp.google.com with ESMTP id nAUKdJ3e029777 for ; Mon, 30 Nov 2009 12:41:09 -0800 Received: by pxi11 with SMTP id 11so3021292pxi.9 for ; Mon, 30 Nov 2009 12:41:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.215.14 with SMTP id n14mr8642151wag.99.1259613669097; Mon, 30 Nov 2009 12:41:09 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343785209BBB@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343785102B49@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785102E58@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785102F1F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <3D3C75174CB95F42AD6BCC56E5555B4501F19743@FIESEXC015.nsn-intra.net> <90C41DD21FB7C64BB94121FBBC2E72343785209BBB@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: John Panzer Date: Mon, 30 Nov 2009 12:40:49 -0800 Message-ID: To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=0016e64b96024d009a04799ca92c X-System-Of-Record: true Cc: ext Dick Hardt , "Tschofenig, Hannes \(NSN - FI/Espoo\)" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] why are we signing? X-BeenThere: oauth@ietf.org X-Mailman-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, 30 Nov 2009 20:41:21 -0000 --0016e64b96024d009a04799ca92c Content-Type: text/plain; charset=ISO-8859-1 A possible path for a TLS-challenged site is to simply send tokens in the clear. This has security implications of course -- though if you're talking about server to server calls, it's not nearly as bad as browser side cookies -- but combined with a way to rotate tokens automatically is still a major improvement over HTTP Basic. My question is, how large is the set of possible server implementors that cannot implement TLS, yet still need security better than the clear-tokens method above? Can I suggest that if they comprise less than 10% of usage -- however we want to measure that -- then they could dealt with via extensions rather than core? (Note also that if someone is just setting up a test service or a fun startup, they could start without TLS and upgrade without changing their code at all, which isn't a horribly bad story -- if you want more security, you can buy it for a nominal fee. This has worked pretty well for online merchants.) -- John Panzer / Google jpanzer@google.com / abstractioneer.org / @jpanzer On Mon, Nov 30, 2009 at 12:27 PM, Eran Hammer-Lahav wrote: > OAuth is being proposed as a generally useful method for securing API > calls. I expect many open source libraries to implement it on the server > side and use it for blog plugins, widgets, and other highly distributed > software. If OAuth required the use of TLS, it would simply be ignored by > all those applications which will likely continue using Basic. > > With all due respect to big companies, their resources, and ability to > effortlessly deploy SSL/TLS, it is still an expensive and complex process > for more developers deploying small scale server components. > > EHL > > > -----Original Message----- > > From: Tschofenig, Hannes (NSN - FI/Espoo) > > [mailto:hannes.tschofenig@nsn.com] > > Sent: Monday, November 30, 2009 11:23 AM > > To: ext Dick Hardt; Eran Hammer-Lahav > > Cc: oauth@ietf.org > > Subject: RE: [OAUTH-WG] why are we signing? > > > > I would also like to hear about the cases where TLS is not suitable. > > > > Hannes > > > > >-----Original Message----- > > >From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > >Of ext Dick Hardt > > >Sent: 30 November, 2009 21:18 > > >To: Eran Hammer-Lahav > > >Cc: oauth@ietf.org > > >Subject: Re: [OAUTH-WG] why are we signing? > > > > > > > > >On 2009-11-13, at 7:21 AM, Eran Hammer-Lahav wrote: > > >> > > >> I for one, see great value in offering some form of > > >crypto-based security for cases where TLS is not suitable. > > > > > > > > >Are these use cases enumerated somewhere? > > > > > >(Apologies for coming into the conversation late) > > > > > >_______________________________________________ > > >OAuth mailing list > > >OAuth@ietf.org > > >https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0016e64b96024d009a04799ca92c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable A possible path for a TLS-challenged site is to simply send tokens in the c= lear. This has security implications of course -- though if you're talk= ing about server to server calls, it's not nearly as bad as browser sid= e cookies -- but combined with a way to rotate tokens automatically is stil= l a major improvement over HTTP Basic.

My question is, how large is the set of possible server impl= ementors that cannot implement TLS, yet still need security better than the= clear-tokens method above? =A0Can I suggest that if they comprise less tha= n 10% of usage -- however we want to measure that -- then they could dealt = with via extensions rather than core?

(Note also that if someone is just setting up a test se= rvice or a fun startup, they could start without TLS and upgrade without ch= anging their code at all, which isn't a horribly bad story -- if you wa= nt more security, you can buy it for a nominal fee. =A0This has worked pret= ty well for online merchants.)

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



On Mon, Nov 30, 2009 at 12:27 PM, Eran H= ammer-Lahav <er= an@hueniverse.com> wrote:
OAuth is being proposed as a generally useful method for securing API calls= . I expect many open source libraries to implement it on the server side an= d use it for blog plugins, widgets, and other highly distributed software. = If OAuth required the use of TLS, it would simply be ignored by all those a= pplications which will likely continue using Basic.

With all due respect to big companies, their resources, and ability to effo= rtlessly deploy SSL/TLS, it is still an expensive and complex process for m= ore developers deploying small scale server components.

EHL

> -----Original Message-----
> From: Tschofenig, Hannes (NSN - FI/Espoo)
> [mailto:hannes.tschofenig= @nsn.com]
> Sent: Monday, November 30, 2009 11:23 AM
> To: ext Dick Hardt; Eran Hammer-Lahav
> Cc: oauth@ietf.org
> Subject: RE: [OAUTH-WG] why ar= e we signing?
>
> I would also like to hear about the cases where TLS is not suitable. >
> Hannes
>
> >-----Original Message-----
> >From: oauth-bounces@ietf= .org [mailto:oauth-bounces@ie= tf.org] On Behalf
> >Of ext Dick Hardt
> >Sent: 30 November, 2009 21:18
> >To: Eran Hammer-Lahav
> >Cc: oauth@ietf.org
> >Subject: Re: [OAUTH-WG] why are we signing?
> >
> >
> >On 2009-11-13, at 7:21 AM, Eran Hammer-Lahav wrote:
> >>
> >> I for one, see great value in offering some form of
> >crypto-based security for cases where TLS is not suitable.
> >
> >
> >Are these use cases enumerated somewhere?
> >
> >(Apologies for coming into the conversation late)
> >
> >_______________________________________________
> >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

--0016e64b96024d009a04799ca92c-- From jpanzer@google.com Mon Nov 30 12:50:00 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 102E93A6979 for ; Mon, 30 Nov 2009 12:50:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.909 X-Spam-Level: X-Spam-Status: No, score=-105.909 tagged_above=-999 required=5 tests=[AWL=0.067, 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 2HRlx0SH+4DE for ; Mon, 30 Nov 2009 12:49:58 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id 8CBFA3A689A for ; Mon, 30 Nov 2009 12:49:58 -0800 (PST) Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id nAUKnoDq002779 for ; Mon, 30 Nov 2009 12:49:51 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1259614191; bh=xWHHQy3CSK194dUoOShxGjf2vi4=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=Sz1/okfg9560KKy1NIKkHdtUisFZw81B0Gb6ez+Lc2wNqcrU82f6gH45kGQYrL4Tw v6OGknH8vkApfB9PfarzA== 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=xc9GZeK9vLT3+jrJ+IzOdOux4RRSK51s5oVqVTUUZyViEkTmLGlZnwIALUjWAqZae SopdXTsmi/P6J88t6spXw== Received: from pzk34 (pzk34.prod.google.com [10.243.19.162]) by wpaz17.hot.corp.google.com with ESMTP id nAUKkqAB031812 for ; Mon, 30 Nov 2009 12:49:48 -0800 Received: by pzk34 with SMTP id 34so2936008pzk.11 for ; Mon, 30 Nov 2009 12:49:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.7.15 with SMTP id 15mr8671984wag.209.1259614187460; Mon, 30 Nov 2009 12:49:47 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343785209BC8@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343785209A24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1259536078.19069.6.camel@localhost> <90C41DD21FB7C64BB94121FBBC2E72343785209A5A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785209B82@P3PW5EX1MB01.EX1.SECURESERVER.NET> <5A9DD209-E811-4591-A26E-287B337082E9@microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343785209BC8@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: John Panzer Date: Mon, 30 Nov 2009 12:49:27 -0800 Message-ID: To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=0016e648cb2032973104799cc855 X-System-Of-Record: true Cc: Dick Hardt , "Moore, Jonathan \(CIM\)" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] keeping support for RSA (Was: RE: OAuth 2.0 / Charter) X-BeenThere: oauth@ietf.org X-Mailman-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, 30 Nov 2009 20:50:00 -0000 --0016e648cb2032973104799cc855 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Nov 30, 2009 at 12:40 PM, Eran Hammer-Lahav wrote: > > > > -----Original Message----- > > From: Dick Hardt [mailto:Dick.Hardt@microsoft.com] > > Sent: Monday, November 30, 2009 11:57 AM > > To: Eran Hammer-Lahav > > Cc: Moore, Jonathan (CIM); Paul C. Bryan; oauth@ietf.org > > Subject: Re: [OAUTH-WG] keeping support for RSA (Was: RE: OAuth 2.0 / > > Charter) > > > > > > On 2009-11-30, at 9:25 AM, Eran Hammer-Lahav wrote: > > > > > 3. I will leave it up to the security experts to figure out if a PK > option in the > > *authentication* spec is worth having, compared to TLS/SSL. OAuth did not > > require TLS because it was designed to be friendly to small sites looking > to > > deploy an API without having to deal with certificates. The performance > > overhead wasn't really the main issue, it was practicality. For example, > I > > would like to be able to write a Wordpress plugin that exposes an address > > book API using OAuth, without being required to enable SSL on my blog. > > > > Are there implementations of Wordpress plugins using OAuth? ie., was > there > > a real market need for this, or just a perceived need? > > Everything I'm working on or involved in (discovery, webfinger, portable > contacts, content sharing, etc.) is heading this way. It is critical that > OAuth will not create a barrier to entry for these technologies. For > example, we are now discussing how to manage access to machine-readable > profiles for people in webfinger. This technology will only work if it is > easily available to self-hosted sites that deserve to be able to implement > the same protocols the big guys get to push. > > > If you don't have SSL on your blog management endpoint, then your blog > > credentials are being transported in the clear. I don't have SSL on my > > Wordpress blogs, and I'm ok with the risk given the tradeoffs. It seems > like > > many other people are as well currently. > > > > While I agree it is desirable to improve security, is there real demand > for it? > > > > In choosing where to put efforts, would it be "better" to drive down the > > barriers to deploying SSL? > > This is clearly outside the scope of this work... :-) > > I doubt this will become simpler and cheaper anytime soon. > > The bottom line is that the new proposal separate the two, allowing people > who plan to use SSL across the board to focus on the other stuff. If OAuth > 1.0 requires SSL, it will accomplish nothing but a fork in the community and > two competing solutions. Instead, my proposal makes it modular and allows > everyone to play along. > I agree with Eran's point that requiring TLS for OAuth "authentication" (Token, in 2.0 proposal) to work would be a nonstarter and I would vote against it. However, this is a bit of a straw man, since that's not what Dick suggested. He suggested that TLS need not be required for all OAuth scenarios and I also agree with that. So, I'm in the happy position of agreeing with everyone on this thread! > > > EHL > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0016e648cb2032973104799cc855 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Nov 30, 2009 at 12:40 PM, Eran Hammer-La= hav <eran@hueni= verse.com> wrote:


> -----Original Message-----
> From: Dick Hardt [mailto:D= ick.Hardt@microsoft.com]
> Sent: Monday, November 30, 2009 11:57 AM
> To: Eran Hammer-Lahav
> Cc: Moore, Jonathan (CIM); Paul C. Bryan; oauth@ietf.org
> Subject: Re: [OAUTH-WG] keeping support for RSA (Was: RE: OAuth 2.0 /<= br> > Charter)
>
>
> On 2009-11-30, at 9:25 AM, Eran Hammer-Lahav wrote:
>
> > 3. I will leave it up to the security experts to figure out if a = PK option in the
> *authentication* spec is worth having, compared to TLS/SSL. OAuth did = not
> require TLS because it was designed to be friendly to small sites look= ing to
> deploy an API without having to deal with certificates. The performanc= e
> overhead wasn't really the main issue, it was practicality. For ex= ample, I
> would like to be able to write a Wordpress plugin that exposes an addr= ess
> book API using OAuth, without being required to enable SSL on my blog.=
>
> Are there implementations of Wordpress plugins using OAuth? ie., was t= here
> a real market need for this, or just a perceived need?

Everything I'm working on or involved in (discovery, webfinger, p= ortable contacts, content sharing, etc.) is heading this way. It is critica= l that OAuth will not create a barrier to entry for these technologies. For= example, we are now discussing how to manage access to machine-readable pr= ofiles for people in webfinger. This technology will only work if it is eas= ily available to self-hosted sites that deserve to be able to implement the= same protocols the big guys get to push.

> If you don't have SSL on your blog management endpoint, then your = blog
> credentials are being transported in the clear. I don't have SSL o= n my
> Wordpress blogs, and I'm ok with the risk given the tradeoffs. It = seems like
> many other people are as well currently.
>
> While I agree it is desirable to improve security, is there real deman= d for it?
>
> In choosing where to put efforts, would it be "better" to dr= ive down the
> barriers to deploying SSL?

This is clearly outside the scope of this work... :-)

I doubt this will become simpler and cheaper anytime soon.

The bottom line is that the new proposal separate the two, allowing people = who plan to use SSL across the board to focus on the other stuff. If OAuth = 1.0 requires SSL, it will accomplish nothing but a fork in the community an= d two competing solutions. Instead, my proposal makes it modular and allows= everyone to play along.

I agree with Eran's point that requiri= ng TLS for OAuth "authentication" (Token, in 2.0 proposal) to wor= k would be a nonstarter and I would vote against it.

However, this is a bit of a straw man, since that's not what Dick = suggested. =A0He suggested that TLS need not be required for all OAuth scen= arios and I also agree with that.

So, I'm in t= he happy position of agreeing with everyone on this thread!


=A0


EHL

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

--0016e648cb2032973104799cc855-- From benl@google.com Mon Nov 30 13:10:36 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 591803A6A93 for ; Mon, 30 Nov 2009 13:10:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[AWL=0.000, 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 oqs4eAmw9kBR for ; Mon, 30 Nov 2009 13:10:33 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 9CD243A6894 for ; Mon, 30 Nov 2009 13:10:32 -0800 (PST) Received: from spaceape23.eur.corp.google.com (spaceape23.eur.corp.google.com [172.28.16.75]) by smtp-out.google.com with ESMTP id nAULAOTL027974 for ; Mon, 30 Nov 2009 21:10:24 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1259615424; bh=Okf4wA/M6pOAGG9OEu+JPSxd9LI=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=RJtWAwZ1z5kuzI6sQ48cWDyd1/z5olZyMkeuNhtDf+12PiAj6NvjPhFQVaWAKKnQh s72Iaa9li6vxTRLN7rBQA== 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=uMm2NfmrBoDP5a20KbqXcfxo4OTi8i6lOfoHO0BpNB9b2uD3zD8xw95DXgzVJ3OxO 67aC6LNoLY1/oryNLclYw== Received: from qyk2 (qyk2.prod.google.com [10.241.83.130]) by spaceape23.eur.corp.google.com with ESMTP id nAULALCv031661 for ; Mon, 30 Nov 2009 13:10:22 -0800 Received: by qyk2 with SMTP id 2so1775180qyk.21 for ; Mon, 30 Nov 2009 13:10:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.38.206 with SMTP id c14mr640324qce.89.1259615421239; Mon, 30 Nov 2009 13:10:21 -0800 (PST) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E72343785209A24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1259536078.19069.6.camel@localhost> <90C41DD21FB7C64BB94121FBBC2E72343785209A5A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <9950FC8D-A0CC-4CD6-94BC-B5749CC4E1FE@bbn.com> Date: Mon, 30 Nov 2009 13:10:21 -0800 Message-ID: <1b587cab0911301310g283449bek529f1d895aa4f135@mail.gmail.com> From: Ben Laurie To: Phillip Hallam-Baker Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "Moore, Jonathan \(CIM\)" , oauth@ietf.org Subject: Re: [OAUTH-WG] keeping support for RSA (Was: RE: OAuth 2.0 / Charter) X-BeenThere: oauth@ietf.org X-Mailman-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, 30 Nov 2009 21:10:36 -0000 On Mon, Nov 30, 2009 at 10:50 AM, Phillip Hallam-Baker wrote: > Hmm, not a good time to point that out. That part of te protocol turns > out to be problematic Actually not. Renegotiation is problematic. Session resumption is not. > > On Mon, Nov 30, 2009 at 1:03 PM, Brian Eaton wrote: >> On Mon, Nov 30, 2009 at 9:55 AM, Richard Barnes wrote: >>> One technical point: You don't do appreciably more public-key operations to >>> do a TLS negotiation as you do to sign an OAuth request, since the actual >>> encryption of message is done with a symmetric algorithm (RSA is only used >>> to protect the secrets in the negotiation). >> >> In fact TLS is far cheaper because it caches the results of the >> initial RSA negotiation. >> >> Cheers, >> Brian >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > > > -- > -- > New Website: http://hallambaker.com/ > View Quantum of Stupid podcasts, Tuesday and Thursday each week, > http://quantumofstupid.com/ > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From eran@hueniverse.com Mon Nov 30 13:17:51 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5206A3A68FD for ; Mon, 30 Nov 2009 13:17:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.481 X-Spam-Level: X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.118, 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 g2rD4-Q6xP8u for ; Mon, 30 Nov 2009 13:17:49 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id D09973A6894 for ; Mon, 30 Nov 2009 13:17:49 -0800 (PST) Received: (qmail 17903 invoked from network); 30 Nov 2009 21:17:42 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 30 Nov 2009 21:17:42 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 30 Nov 2009 14:17:03 -0700 From: Eran Hammer-Lahav To: Peter Saint-Andre , Stephen Farrell Date: Mon, 30 Nov 2009 14:17:07 -0700 Thread-Topic: [OAUTH-WG] OAuth 2.0 / Charter Thread-Index: Acpx941SjNscyF+WSXWSZPKciNvQ9QABqCgA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343785209BE7@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343785209A24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <48AE706BD74FCC4297AD778805CA46F6184C5CF474@usps.sonoa.local> <90C41DD21FB7C64BB94121FBBC2E72343785209A5B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B1407A7.9040907@cs.tcd.ie> <4B1423FB.2070506@stpeter.im> In-Reply-To: <4B1423FB.2070506@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 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] OAuth 2.0 / Charter X-BeenThere: oauth@ietf.org X-Mailman-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, 30 Nov 2009 21:17:51 -0000 RHVyaW5nIHRoZSBjaGFydGVyIGRpc2N1c3Npb25zIGFuZCBlYXJsaWVyIGR1cmluZyB0aGUgQk9G IGRpc2N1c3Npb25zLCB0aGUgY29uc2Vuc3VzIHdhcyB0aGF0IGFueSBlZmZvcnQgdG8gYWRkcmVz cyB0aGUgZ2VuZXJhbCBwcm9ibGVtIGZyb20gc2NyYXRjaCB3YXMgZG9vbWVkLiBUaGUgSUVURiBh bmQgb3RoZXIgYm9kaWVzIGhhdmUgYSB2ZXJ5IHBvb3IgdHJhY2sgcmVjb3JkIG9mIHN1Y2Nlc3Nm dWxseSBjcmVhdGluZyBuZXcgc2VjdXJpdHkgdGVjaG5vbG9naWVzIHdpdGggd2lkZSBhZG9wdGlv bi4gT0F1dGggcmVwcmVzZW50ZWQgYSByYXJlIG9wcG9ydHVuaXR5IG9mIHVzaW5nIHRoZSBjb21t dW5pdHkgd29yayB0byBib290c3RyYXAgYSBzdGFuZGFyZHMgdHJhY2sgZWZmb3J0Lg0KDQpEaWZm ZXJlbnQgcGVvcGxlIHRha2UgdGhhdCB0byBtZWFuIGRpZmZlcmVudCB0aGluZ3MuIEZvciBzb21l LCB0aGUgZ29hbCBzaG91bGQgYmUgdG8gcnViYmVyIHN0YW1wIDEuMCBvciBhcyBjbG9zZSB0byB0 aGF0IGFzIHBvc3NpYmxlLiBUbyBvdGhlcnMsIHRoaXMgbWVhbnMgdGFraW5nIHdoYXRldmVyIHRo ZXkgZmVlbCBpcyB0aGUgY29yZSBjb21wb25lbnQgb2YgdGhlIHByb3RvY29sIGFuZCByZXVzaW5n IGl0IChmcm9tIHRoZSBzaWduYXR1cmUgbWV0aG9kcyB0byB0aGUgd2ViLXJlZGlyZWN0aW9uIGZs b3cpLg0KDQpUbyBtZSwgdGhlIG1vc3QgdXNlZnVsIHBhcnQgb2YgT0F1dGggZm9yIHRoZSBwdXJw b3NlIG9mIGNyZWF0aW5nIG5ldyB3b3JrIGlzIHRoZSBtb2RlbCwgbm90IHRoZSB0ZWNobmljYWwg ZGV0YWlscy4gVGhpcyBpcyBub3QgdG8gaW1wbHkgdGhhdCB0aGUgbW9kZWwgaXMgYmV0dGVyIHRo YW4gb3RoZXJzLCBqdXN0IHRoYXQgd2UgaGF2ZSBjb25zZW5zdXMgb24gdGhhdCwgYW5kIGl0IGlz IHRoZSBoYXJkZXN0IHBhcnQgdG8gYWdyZWUgb24uIFRoZSBPQXV0aCBtb2RlbCBpbmNsdWRlcyBz b21lIHNwZWNpZmljIGNob2ljZXM6DQoNCjEuIFJlc291cmNlIG93bmVyIGNyZWRlbnRpYWxzIGFy ZSBub3Qgc2hhcmVkIHdpdGggdGhpcmQgcGFydGllcy4gSW5zdGVhZCwgYSB0b2tlbiBpcyB1c2Vk IHRvIHJlcHJlc2VudCBhIHNwZWNpZmljIGFjY2VzcyBzY29wZS4NCjIuIFRva2VucyBhcmUgaXNz dWVkIGJ5IHRoZSBzZXJ2ZXIsIG5vdCBieSB0aGUgcmVzb3VyY2Ugb3duZXIuIE9BdXRoIHRva2Vu cyBhcmUgdHJlYXRlZCBhcyBvcGFxdWUgc3RyaW5ncywgYW5kIHdoaWxlIHN0cnVjdHVyZWQgdG9r ZW5zIGFyZSBwb3NzaWJsZSwgdGhleSBhcmUgZXh0ZXJuYWwgdG8gdGhlIG1vZGVsLg0KMy4gVG9r ZW4gYXV0aGVudGljYXRpb24gZG9lcyBub3QgcmVxdWlyZSBTU0wvVExTLCBidXQgaXMgZnVsbHkg Y29tcGF0aWJsZSB3aXRoIGl0Lg0KDQpJIHdvdWxkIHN0cm9uZ2x5IGNhdXRpb24gdGhpcyB3b3Jr aW5nIGdyb3VwIGZyb20gcmVvcGVuaW5nIHRoZXNlIGJhc2ljIGVsZW1lbnRzIGFzIGl0IGlzIG1v cmUgbGlrZWx5IHRvIGxlYWQgdG8gYSBmb3JraW5nIG9mIHRoaXMgZWZmb3J0IHRoYW4gYW55IHN1 Y2Nlc3NmdWwgc3BlY2lmaWNhdGlvbi4gT0F1dGgncyBncmVhdGVzdCB2YWx1ZSBpcyB0aGUgY29t cHJvbWlzZSBpdCByZXByZXNlbnRzIGluIGl0cyBkZXNpZ24uIEdpdmUgdXAgdGhhdCBhbmQgd2Ug YXJlIGJhY2sgdG8gc3F1YXJlIG9uZS4gSSBoYXZlIG5vIGludGVyZXN0IGluIHN0YXJ0aW5nIGZy b20gc2NyYXRjaCBvciBhIGRpZmZlcmVudCBiYXNlIHRlY2hub2xvZ3kuDQoNClRoZSBtYWluIGlz c3VlIHdpdGggdGhlIGN1cnJlbnQgY2hhcnRlciBpcyB0aGUgYmFja3dhcmQtY29tcGF0aWJpbGl0 eSBzZWN0aW9uLCBub3QgdGhlIDEuMSBsYWJlbC4gSXQgd291bGQgYmUgYSBtb2NrZXJ5IG9mIHBy b2Nlc3MgYW5kIGNvbW1vbiBzZW5zZSB0byBqdXN0aWZ5IGVhY2ggb2YgdGhlIHByb3Bvc2VkIGNo YW5nZXMgYXMgcmVxdWlyZWQgZm9yIHNlY3VyaXR5IGFuZCBpbnRlcm9wZXJhYmlsaXR5IGFuZCB3 b3J0aCBicmVha2luZyBjb21wYXRpYmlsaXR5LiBOb25lIG9mIHRoaXMgbWF0dGVycyBvbmNlIHdl IGNoYW5nZSBhIHNpbmdsZSB0aGluZywgYW5kIHdlIGFscmVhZHkga25vdyB3ZSBhcmUgZ29pbmcg dG8uDQoNCk15IHByb3Bvc2FsIGRvZXNuJ3QgY2hhbmdlIHRoZSBjb3JlIG1vZGVsLiBJdCBjbGVh bnMgdXAgdGhlIGF1dGhlbnRpY2F0aW9uIHBhcnQgYnkgc2ltcGxpZnlpbmcgaXQgYW5kIG1ha2lu ZyBpdCBtb3JlIGV4dGVuc2libGUgYW5kIGl0IHByb3Bvc2VzIHRvIGV4dGVuZCB0aGUgc2V0IG9m IGF2YWlsYWJsZSBtZXRob2RzIHRvIG9idGFpbiBhIHRva2VuIGZyb20gYSBzaW5nbGUgcmVkaXJl Y3Rpb24tYmFzZWQgcHJvY2VzcyB0byBhIGZldyBvdGhlciBvcHRpb25zLg0KDQpXZSBjYW4gY2Vy dGFpbmx5IHN0cmV0Y2ggdGhlIGV4aXN0aW5nIGNoYXJ0ZXIgYnkgdXNpbmcgb3VyIG1hbmRhdGUg dG8gY3JlYXRlIGEgbmV3IGF1dGhlbnRpY2F0ZSBzY2hlbWUgYW5kIGZvY3VzIG9uIHRoYXQsIGNh bGxpbmcgaXQgVG9rZW4gQXV0aGVudGljYXRpb24uIFRoZW4gd2UgY2FuIGhhdmUgdGhpcyBkaXNj dXNzaW9uIGFib3V0IGhvdyBtdWNoIHRvIGFkZCB0byB0aGUgc2luZ2xlIGRlbGVnYXRpb24gbWV0 aG9kIHByb3ZpZGVkLiBJIGxlYXZlIHRoaXMgdXAgdG8gdGhlIGNoYWlyIHRvIGRlY2lkZSB3aGF0 IGlzIGJlc3QuDQoNCk15IGZvY3VzIGlzIG5vdyBvbiBwcm9kdWNpbmcgYSBkcmFmdCBmb3IgdGhl IFRva2VuIEF1dGhlbnRpY2F0aW9uIG1ldGhvZCB3aGljaCBpcyB2ZXJ5IG11Y2ggaW4gbGluZSB3 aXRoIHRoZSBjaGFydGVyIGFuZCBiYXNlZCBvbiBXRyBkaXNjdXNzaW9ucyBmcm9tIGEgY291cGxl IG9mIG1vbnRocyBhZ28uDQoNCkVITA0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gRnJvbTogUGV0ZXIgU2FpbnQtQW5kcmUgW21haWx0bzpzdHBldGVyQHN0cGV0ZXIuaW1dDQo+ IFNlbnQ6IE1vbmRheSwgTm92ZW1iZXIgMzAsIDIwMDkgMTE6NTkgQU0NCj4gVG86IFN0ZXBoZW4g RmFycmVsbA0KPiBDYzogRXJhbiBIYW1tZXItTGFoYXY7IE9BdXRoIFdHIChvYXV0aEBpZXRmLm9y ZykNCj4gU3ViamVjdDogUmU6IFtPQVVUSC1XR10gT0F1dGggMi4wIC8gQ2hhcnRlcg0KPiANCj4g PGhhdCB0eXBlPSdjaGFpcicvPg0KPiANCj4gT24gMTEvMzAvMDkgMTA6NTcgQU0sIFN0ZXBoZW4g RmFycmVsbCB3cm90ZToNCj4gPiBXaGlsZSBJIHRoaW5rIHRoZSBnZW5lcmFsIGdvYWwgc2VlbXMg b2ssIGFuZCBwZXJoYXBzIGV2ZW4gYmV0dGVyLA0KPiANCj4gSSBkbyB0aGluayBpdCBpcyB3b3J0 aHdoaWxlIHRvIGhhdmUgYSBkaXNjdXNzaW9uIGFib3V0IHRoZSBwcm9wZXINCj4gImdlbmVyYWwg Z29hbCIgZm9yIHRoaXMgV0csIGVzcGVjaWFsbHkgZ2l2ZW4gdGhlIGNoYW5naW5nIGxhbmRzY2Fw ZQ0KPiByZWdhcmRpbmcgT0F1dGhbLWlzaF0gdGVjaG5vbG9naWVzLg0KPiANCj4gPiBJIGRvIHdv bmRlciB3aGV0aGVyIGl0cyByZWFzb25hYmxlIHRvIHJlLWNoYXJ0ZXIgYSBXRyB0aGF0IGhhcw0K PiA+IG5ldmVyIGZvcm1hbGx5IG1ldCBmYWNlIHRvIGZhY2UsDQo+IA0KPiBUaGUgY2hhaXJzIHRh a2UgcmVzcG9uc2liaWxpdHkgZm9yIHRoZSBsYWNrIG9mIGEgbWVldGluZywgYnV0IEkgY2FuDQo+ IGd1YXJhbnRlZSB5b3UgdGhhdCB0aGUgZ3JvdXAgd2lsbCBtZWV0IGF0IElFVEYgNzcuDQo+IA0K PiA+IG5vciBtZXQgYW55IG9mIGl0cyBjdXJyZW50DQo+ID4gbWlsZXN0b25lcy4NCj4gDQo+IEdp dmVuIHRoYXQgdGhlIFdHIHdhcyBjaGFydGVyZWQgb24gTWF5IDEzLCBpdCB3YXMgcGVyaGFwcyBh IGJpdA0KPiBhZ2dyZXNzaXZlIHRvICJTdWJtaXQgJ09BdXRoOiBIVFRQIEF1dGhvcml6YXRpb24g RGVsZWdhdGlvbiBQcm90b2NvbCcgYXMNCj4gd29ya2luZyBncm91cCBpdGVtIiBpbiBBcHIgMjAw OS4gOikNCj4gDQo+IEJhc2VkIG9uIGxpc3QgZGlzY3Vzc2lvbiBpbiBNYXkgYW5kIEp1bmUsIHdl IGNhbWUgdG8gY29uc2Vuc3VzIHRvIHNwbGl0DQo+IGRyYWZ0LWhhbW1lci1vYXV0aCBpbnRvIHR3 byBzcGVjaWZpY2F0aW9ucywgd2hpY2ggRXJhbiBkaWQgaW4gZWFybHkNCj4gSnVseSwgcmVzdWx0 aW5nIGluIGRyYWZ0LWlldGYtb2F1dGgtYXV0aGVudGljYXRpb24gYW5kDQo+IGRyYWZ0LWlldGYt b2F1dGgtd2ViLWRlbGVnYXRpb24gYXMgV0cgaXRlbXMuIFdlJ3ZlIGhhZCBxdWl0ZSBhIGJpdCBv Zg0KPiBkaXNjdXNzaW9uIGFib3V0IHRob3NlIG9uIHRoZSBsaXN0LCBidXQgaXQgc2VlbXMgdG8g bWUgdGhhdCB0aGUNCj4gZGlzY3Vzc2lvbiBoZXJlIGFuZCBlbHNld2hlcmUgaGFzIGxlZCB0byBh IGRlc2lyZSBmb3Igc29tZXRoaW5nIG1vcmUNCj4gdGhhbiBhIHNpbXBsZSwgYmFja3dhcmRzLWNv bXBhdGlibGUgc3BlY2lmaWNhdGlvbiBvZiAiT0F1dGggMS4xIiBhcw0KPiBkZXNjcmliZWQgaW4g dGhlIGNoYXJ0ZXIuIEluIHBhcnRpY3VsYXIsIHRoZSBzY29wZSBvZiAiT0F1dGggMS4xIg0KPiBh cHBlYXJzIHRvIGhhdmUgYmVlbiBsaW1pdGVkIHRvIGltcHJvdmluZyB0ZXJtaW5vbG9neSwgZW1i b2R5aW5nIGdvb2QNCj4gc2VjdXJpdHkgcHJhY3RpY2VzLCBwcm9tb3RpbmcgaW50ZXJvcGVyYWJp bGl0eSwgYW5kIHByb3ZpZGluZyBndWlkZWxpbmVzDQo+IGZvciBleHRlbnNpYmlsaXR5Lg0KPiAN Cj4gPiBJdCBtYXkgYmUsIEknbSBqdXN0IG5vdCBzdXJlLCBidXQgd2hhdCdzIHRoZSByZWFzb24g Zm9yIG5vdA0KPiA+IGZpbmlzaGluZyBPQXV0aCAxLjEgZmlyc3Q/IChUaGUgZmFjdCB0aGF0IHlv dSAic2VlIG5vIHZhbHVlIg0KPiA+IGRvZXNuJ3QgZXhwbGFpbiBpdCB0byBtZSBhdCBsZWFzdC4p DQo+IA0KPiBJIGFncmVlIHRoYXQgd2UgbmVlZCB0byBnZXQgdGhlIHJlYXNvbnMgb3V0IG9uIHRo ZSB0YWJsZSBzbyB0aGF0IHdlIGNhbg0KPiBoYXZlIGFuIG9wZW4gZGlzY3Vzc2lvbiBhYm91dCBw cm9ibGVtcyBhbmQgb2JqZWN0aXZlcy4NCj4gDQo+ID4gSSBhbHNvIGZpbmQgdGhlIGZvbGxvd2lu ZyBhIGJpdCBwdXp6bGluZzoNCj4gPg0KPiA+IEVyYW4gSGFtbWVyLUxhaGF2IHdyb3RlOg0KPiA+ PiBLZWVwIGluIG1pbmQgdGhhdCB3ZSBhcmUgbm90IGdvaW5nIHRvIGluY2x1ZGUgdG9rZW4gc3Ry dWN0dXJlIGluIHNjb3BlLg0KPiA+PiBXZSBhcmUgc2ltcGx5IHByb3Bvc2luZyBhIG1ldGhvZCBp biB3aGljaCB0aGUgdG9rZW4gaXMgYSBzdHJpbmcsIGxlYXZpbmcNCj4gPj4gaXQgdXAgdG8gb3Ro ZXIgZWZmb3J0cyB0byBnaXZlIGl0IHN0cnVjdHVyZSBpZiBuZWVkZWQuDQo+ID4NCj4gPiBXaGF0 IG90aGVyIGVmZm9ydHM/IEhvdyB3b3VsZCB0aGUgaW1wbGVtZW50ZXIgb2YgYW4gUkZDIGFjaGll dmUNCj4gPiBpbnRlcm9wZXJhYmlsaXR5PyBXb3VsZG4ndCB3ZSBuZWVkIHRvIGJlIGFibGUgdG8g YW5zd2VyIHRoYXQgYmVmb3JlDQo+ID4gcHJvY2VlZGluZz8NCj4gDQo+IFRob3NlIGFyZSBnb29k IHF1ZXN0aW9ucy4NCj4gDQo+ID4gVG8gYW5zd2VyIHlvdXIgc3BlY2lmaWMgcXVlc3Rpb25zOg0K PiA+DQo+ID4+IC0gSXMgdGhpcyBhcHByb2FjaCBmYXZvcmFibGUgYnkgdGhlIGdyb3VwPw0KPiA+ DQo+ID4gTWF5YmUuDQo+ID4NCj4gPj4gLSBEbyB3ZSBuZWVkIHRvIGFkanVzdCB0aGUgbGFuZ3Vh Z2UgaW4gdGhlIGNoYXJ0ZXIgdG8gc3VwcG9ydD8NCj4gPg0KPiA+IERlZmluaXRlbHkgSU1PLiBU aGUgY3VycmVudCBjaGFydGVyIHRhbGtzIGFib3V0IHN0cml2aW5nIHRvDQo+ID4gbWFpbnRhaW4g YmFja3dhcmRzIGNvbXBhdGliaWxpdHkgZXRjLg0KPiANCj4gVGhlIGNoYXJ0ZXIgYWxzbyBzYXlz Og0KPiANCj4gICBIb3dldmVyLCBjaGFuZ2VzIHRoYXQgYXJlIG5vdCBiYWNrd2FyZHMNCj4gICBj b21wYXRpYmxlIG1pZ2h0IGJlIGFjY2VwdGVkIGlmIHRoZSBncm91cCBkZXRlcm1pbmVzIHRoYXQN Cj4gICB0aGUgY2hhbmdlcyBhcmUgcmVxdWlyZWQgdG8gbWVldCB0aGUgZ3JvdXAncyB0ZWNobmlj YWwNCj4gICBvYmplY3RpdmVzIGFuZCB0aGUgZ3JvdXAgY2xlYXJseSBkb2N1bWVudHMgdGhlIHJl YXNvbnMgZm9yDQo+ICAgbWFraW5nIHRoZW0uDQo+IA0KPiBUaGF0IGltcGxpZXMgdGhlIG5lZWQg dG8sIGFib3ZlIGFsbCwgY2xhcmlmeSB0aGUgZ3JvdXAncyB0ZWNobmljYWwNCj4gb2JqZWN0aXZl cy4gSU1ITyB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQgaXMgbm90IGZ1bGx5IGNsZWFyIGluIHRoZQ0K PiBleGlzdGluZyBjaGFydGVyLCBhbmQgZnVydGhlcm1vcmUgaXQgYXBwZWFycyB0aGF0IHNvbWUg cGVvcGxlIG5vdyBtaWdodA0KPiBiZSB0cnlpbmcgdG8gc29sdmUgcmVsYXRlZCBidXQgc29tZXdo YXQgZGlmZmVyZW50IHByb2JsZW1zIHdpdGggT0F1dGgNCj4gKG9yIHNvbWV0aGluZyBzaW1pbGFy IGVub3VnaCB0byBPQXV0aCB0aGF0IGl0IGNhbiByZXRhaW4gdGhlIG5hbWUpLiBUaGF0DQo+IG1p Z2h0IGJlIGVpdGhlciBleGNpdGluZyBvciB3b3JyaXNvbWUsIGRlcGVuZGluZyBvbiB5b3VyIHBl cnNwZWN0aXZlLg0KPiANCj4gUGV0ZXINCj4gDQo+IC0tDQo+IFBldGVyIFNhaW50LUFuZHJlDQo+ IGh0dHBzOi8vc3RwZXRlci5pbS8NCj4gDQoNCg== From jpanzer@google.com Mon Nov 30 13:46:54 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CDC83A69E2 for ; Mon, 30 Nov 2009 13:46:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.918 X-Spam-Level: X-Spam-Status: No, score=-105.918 tagged_above=-999 required=5 tests=[AWL=0.058, 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 mqYdzcHpOXgs for ; Mon, 30 Nov 2009 13:46:52 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id 42F4B3A6924 for ; Mon, 30 Nov 2009 13:46:52 -0800 (PST) Received: from spaceape8.eur.corp.google.com (spaceape8.eur.corp.google.com [172.28.16.142]) by smtp-out.google.com with ESMTP id nAULkhMl004285 for ; Mon, 30 Nov 2009 13:46:44 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1259617605; bh=MxMnxO1e0q57VaDA39hM9ixonEU=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=qz51FWo8jiAgqk1NrmZcX/qcHIKY/18+8RWZqrAmF2EJgIqJu3dVDCT4ln5A1gPsW XmPFEgBtwhk+JA5hXcPTA== 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=e1FPQsqdPLII38w/JGRgW2JfzrV2DFlJg0OsLoLwHtexT7MhTuw/OJJVqa9mDBvbq 68B16gBgDfYk6TeylZsdA== Received: from pxi5 (pxi5.prod.google.com [10.243.27.5]) by spaceape8.eur.corp.google.com with ESMTP id nAULkWl3007358 for ; Mon, 30 Nov 2009 13:46:40 -0800 Received: by pxi5 with SMTP id 5so2921827pxi.12 for ; Mon, 30 Nov 2009 13:46:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.115.84.32 with SMTP id m32mr8877400wal.7.1259617599234; Mon, 30 Nov 2009 13:46:39 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343785209BE7@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343785209A24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <48AE706BD74FCC4297AD778805CA46F6184C5CF474@usps.sonoa.local> <90C41DD21FB7C64BB94121FBBC2E72343785209A5B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B1407A7.9040907@cs.tcd.ie> <4B1423FB.2070506@stpeter.im> <90C41DD21FB7C64BB94121FBBC2E72343785209BE7@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: John Panzer Date: Mon, 30 Nov 2009 13:46:19 -0800 Message-ID: To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=0016e64cc8808e246704799d9358 X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] OAuth 2.0 / Charter X-BeenThere: oauth@ietf.org X-Mailman-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, 30 Nov 2009 21:46:54 -0000 --0016e64cc8808e246704799d9358 Content-Type: text/plain; charset=ISO-8859-1 FWIW, I agree with Eran's three point model, and on not re-debating these core ideas absent some compelling reason. My take on the strategy that motivates them: OAuth's intent is to provide a simple, scalable, interoperable web API auth mechanism that both services and other open standards will build upon. It also raises the current bar for interoperable auth from the current state of the practice. Non-backwards-compatible changes are warranted if they are necessary to meet these goals (and of course detailed technical justifications need to be provided as well.) -- John Panzer / Google jpanzer@google.com / abstractioneer.org / @jpanzer On Mon, Nov 30, 2009 at 1:17 PM, Eran Hammer-Lahav wrote: > During the charter discussions and earlier during the BOF discussions, the > consensus was that any effort to address the general problem from scratch > was doomed. The IETF and other bodies have a very poor track record of > successfully creating new security technologies with wide adoption. OAuth > represented a rare opportunity of using the community work to bootstrap a > standards track effort. > > Different people take that to mean different things. For some, the goal > should be to rubber stamp 1.0 or as close to that as possible. To others, > this means taking whatever they feel is the core component of the protocol > and reusing it (from the signature methods to the web-redirection flow). > > To me, the most useful part of OAuth for the purpose of creating new work > is the model, not the technical details. This is not to imply that the model > is better than others, just that we have consensus on that, and it is the > hardest part to agree on. The OAuth model includes some specific choices: > > 1. Resource owner credentials are not shared with third parties. Instead, a > token is used to represent a specific access scope. > 2. Tokens are issued by the server, not by the resource owner. OAuth tokens > are treated as opaque strings, and while structured tokens are possible, > they are external to the model. > 3. Token authentication does not require SSL/TLS, but is fully compatible > with it. > > I would strongly caution this working group from reopening these basic > elements as it is more likely to lead to a forking of this effort than any > successful specification. OAuth's greatest value is the compromise it > represents in its design. Give up that and we are back to square one. I have > no interest in starting from scratch or a different base technology. > > The main issue with the current charter is the backward-compatibility > section, not the 1.1 label. It would be a mockery of process and common > sense to justify each of the proposed changes as required for security and > interoperability and worth breaking compatibility. None of this matters once > we change a single thing, and we already know we are going to. > > My proposal doesn't change the core model. It cleans up the authentication > part by simplifying it and making it more extensible and it proposes to > extend the set of available methods to obtain a token from a single > redirection-based process to a few other options. > > We can certainly stretch the existing charter by using our mandate to > create a new authenticate scheme and focus on that, calling it Token > Authentication. Then we can have this discussion about how much to add to > the single delegation method provided. I leave this up to the chair to > decide what is best. > > My focus is now on producing a draft for the Token Authentication method > which is very much in line with the charter and based on WG discussions from > a couple of months ago. > > EHL > > > > -----Original Message----- > > From: Peter Saint-Andre [mailto:stpeter@stpeter.im] > > Sent: Monday, November 30, 2009 11:59 AM > > To: Stephen Farrell > > Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org) > > Subject: Re: [OAUTH-WG] OAuth 2.0 / Charter > > > > > > > > On 11/30/09 10:57 AM, Stephen Farrell wrote: > > > While I think the general goal seems ok, and perhaps even better, > > > > I do think it is worthwhile to have a discussion about the proper > > "general goal" for this WG, especially given the changing landscape > > regarding OAuth[-ish] technologies. > > > > > I do wonder whether its reasonable to re-charter a WG that has > > > never formally met face to face, > > > > The chairs take responsibility for the lack of a meeting, but I can > > guarantee you that the group will meet at IETF 77. > > > > > nor met any of its current > > > milestones. > > > > Given that the WG was chartered on May 13, it was perhaps a bit > > aggressive to "Submit 'OAuth: HTTP Authorization Delegation Protocol' as > > working group item" in Apr 2009. :) > > > > Based on list discussion in May and June, we came to consensus to split > > draft-hammer-oauth into two specifications, which Eran did in early > > July, resulting in draft-ietf-oauth-authentication and > > draft-ietf-oauth-web-delegation as WG items. We've had quite a bit of > > discussion about those on the list, but it seems to me that the > > discussion here and elsewhere has led to a desire for something more > > than a simple, backwards-compatible specification of "OAuth 1.1" as > > described in the charter. In particular, the scope of "OAuth 1.1" > > appears to have been limited to improving terminology, embodying good > > security practices, promoting interoperability, and providing guidelines > > for extensibility. > > > > > It may be, I'm just not sure, but what's the reason for not > > > finishing OAuth 1.1 first? (The fact that you "see no value" > > > doesn't explain it to me at least.) > > > > I agree that we need to get the reasons out on the table so that we can > > have an open discussion about problems and objectives. > > > > > I also find the following a bit puzzling: > > > > > > Eran Hammer-Lahav wrote: > > >> Keep in mind that we are not going to include token structure in > scope. > > >> We are simply proposing a method in which the token is a string, > leaving > > >> it up to other efforts to give it structure if needed. > > > > > > What other efforts? How would the implementer of an RFC achieve > > > interoperability? Wouldn't we need to be able to answer that before > > > proceeding? > > > > Those are good questions. > > > > > To answer your specific questions: > > > > > >> - Is this approach favorable by the group? > > > > > > Maybe. > > > > > >> - Do we need to adjust the language in the charter to support? > > > > > > Definitely IMO. The current charter talks about striving to > > > maintain backwards compatibility etc. > > > > The charter also says: > > > > However, changes that are not backwards > > compatible might be accepted if the group determines that > > the changes are required to meet the group's technical > > objectives and the group clearly documents the reasons for > > making them. > > > > That implies the need to, above all, clarify the group's technical > > objectives. IMHO the problem statement is not fully clear in the > > existing charter, and furthermore it appears that some people now might > > be trying to solve related but somewhat different problems with OAuth > > (or something similar enough to OAuth that it can retain the name). That > > might be either exciting or worrisome, depending on your perspective. > > > > Peter > > > > -- > > Peter Saint-Andre > > https://stpeter.im/ > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0016e64cc8808e246704799d9358 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable FWIW, I agree with Eran's three point model, and on not re-debating the= se core ideas absent some compelling reason. =A0My take on the strategy tha= t motivates them: OAuth's intent is to provide a simple, scalable, inte= roperable web API auth mechanism that both services and other open standard= s will build upon. =A0It also raises the current bar for interoperable auth= from the current state of the practice. =A0Non-backwards-compatible change= s are warranted if they are necessary to meet these goals (and of course de= tailed technical justifications need to be provided as well.)

--
John Panzer / Google
jpanzer@google.com / a= bstractioneer.org / @jpanzer



On Mon, Nov 30, 2009 at 1:17 PM, Eran Ha= mmer-Lahav <era= n@hueniverse.com> wrote:
During the charter discussions and earlier during the BOF discussions, the = consensus was that any effort to address the general problem from scratch w= as doomed. The IETF and other bodies have a very poor track record of succe= ssfully creating new security technologies with wide adoption. OAuth repres= ented a rare opportunity of using the community work to bootstrap a standar= ds track effort.

Different people take that to mean different things. For some, the goal sho= uld be to rubber stamp 1.0 or as close to that as possible. To others, this= means taking whatever they feel is the core component of the protocol and = reusing it (from the signature methods to the web-redirection flow).

To me, the most useful part of OAuth for the purpose of creating new work i= s the model, not the technical details. This is not to imply that the model= is better than others, just that we have consensus on that, and it is the = hardest part to agree on. The OAuth model includes some specific choices:
1. Resource owner credentials are not shared with third parties. Instead, a= token is used to represent a specific access scope.
2. Tokens are issued by the server, not by the resource owner. OAuth tokens= are treated as opaque strings, and while structured tokens are possible, t= hey are external to the model.
3. Token authentication does not require SSL/TLS, but is fully compatible w= ith it.

I would strongly caution this working group from reopening these basic elem= ents as it is more likely to lead to a forking of this effort than any succ= essful specification. OAuth's greatest value is the compromise it repre= sents in its design. Give up that and we are back to square one. I have no = interest in starting from scratch or a different base technology.

The main issue with the current charter is the backward-compatibility secti= on, not the 1.1 label. It would be a mockery of process and common sense to= justify each of the proposed changes as required for security and interope= rability and worth breaking compatibility. None of this matters once we cha= nge a single thing, and we already know we are going to.

My proposal doesn't change the core model. It cleans up the authenticat= ion part by simplifying it and making it more extensible and it proposes to= extend the set of available methods to obtain a token from a single redire= ction-based process to a few other options.

We can certainly stretch the existing charter by using our mandate to creat= e a new authenticate scheme and focus on that, calling it Token Authenticat= ion. Then we can have this discussion about how much to add to the single d= elegation method provided. I leave this up to the chair to decide what is b= est.

My focus is now on producing a draft for the Token Authentication method wh= ich is very much in line with the charter and based on WG discussions from = a couple of months ago.

EHL


> -----Original Message-----
> From: Peter Saint-Andre [mailto:= stpeter@stpeter.im]
> Sent: Monday, November 30, 2009 11:59 AM
> To: Stephen Farrell
> Cc: Eran Hammer-Lahav; OAuth WG (oau= th@ietf.org)
> Subject: Re: [OAUTH-WG] OAuth 2.0 / Charter
>
> <hat type=3D'chair'/>
>
> On 11/30/09 10:57 AM, Stephen Farrell wrote:
> > While I think the general goal seems ok, and perhaps even better,=
>
> I do think it is worthwhile to have a discussion about the proper
> "general goal" for this WG, especially given the changing la= ndscape
> regarding OAuth[-ish] technologies.
>
> > I do wonder whether its reasonable to re-charter a WG that has > > never formally met face to face,
>
> The chairs take responsibility for the lack of a meeting, but I can > guarantee you that the group will meet at IETF 77.
>
> > nor met any of its current
> > milestones.
>
> Given that the WG was chartered on May 13, it was perhaps a bit
> aggressive to "Submit 'OAuth: HTTP Authorization Delegation P= rotocol' as
> working group item" in Apr 2009. :)
>
> Based on list discussion in May and June, we came to consensus to spli= t
> draft-hammer-oauth into two specifications, which Eran did in early > July, resulting in draft-ietf-oauth-authentication and
> draft-ietf-oauth-web-delegation as WG items. We've had quite a bit= of
> discussion about those on the list, but it seems to me that the
> discussion here and elsewhere has led to a desire for something more > than a simple, backwards-compatible specification of "OAuth 1.1&q= uot; as
> described in the charter. In particular, the scope of "OAuth 1.1&= quot;
> appears to have been limited to improving terminology, embodying good<= br> > security practices, promoting interoperability, and providing guidelin= es
> for extensibility.
>
> > It may be, I'm just not sure, but what's the reason for n= ot
> > finishing OAuth 1.1 first? (The fact that you "see no value&= quot;
> > doesn't explain it to me at least.)
>
> I agree that we need to get the reasons out on the table so that we ca= n
> have an open discussion about problems and objectives.
>
> > I also find the following a bit puzzling:
> >
> > Eran Hammer-Lahav wrote:
> >> Keep in mind that we are not going to include token structure= in scope.
> >> We are simply proposing a method in which the token is a stri= ng, leaving
> >> it up to other efforts to give it structure if needed.
> >
> > What other efforts? How would the implementer of an RFC achieve > > interoperability? Wouldn't we need to be able to answer that = before
> > proceeding?
>
> Those are good questions.
>
> > To answer your specific questions:
> >
> >> - Is this approach favorable by the group?
> >
> > Maybe.
> >
> >> - Do we need to adjust the language in the charter to support= ?
> >
> > Definitely IMO. The current charter talks about striving to
> > maintain backwards compatibility etc.
>
> The charter also says:
>
> =A0 However, changes that are not backwards
> =A0 compatible might be accepted if the group determines that
> =A0 the changes are required to meet the group's technical
> =A0 objectives and the group clearly documents the reasons for
> =A0 making them.
>
> That implies the need to, above all, clarify the group's technical=
> objectives. IMHO the problem statement is not fully clear in the
> existing charter, and furthermore it appears that some people now migh= t
> be trying to solve related but somewhat different problems with OAuth<= br> > (or something similar enough to OAuth that it can retain the name). Th= at
> might be either exciting or worrisome, depending on your perspective.<= br> >
> Peter
>
> --
> Peter Saint-Andre
> https://stpeter.im/<= /a>
>


--0016e64cc8808e246704799d9358-- From beaton@google.com Mon Nov 30 13:50:01 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2A0228C148 for ; Mon, 30 Nov 2009 13:50:00 -0800 (PST) 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 8EDNCVT-ie9x for ; Mon, 30 Nov 2009 13:50:00 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id 267B33A684C for ; Mon, 30 Nov 2009 13:50:00 -0800 (PST) Received: from wpaz13.hot.corp.google.com (wpaz13.hot.corp.google.com [172.24.198.77]) by smtp-out.google.com with ESMTP id nAULnp5P006105 for ; Mon, 30 Nov 2009 13:49:52 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1259617792; bh=YaDmFP3vk1VI7vqMfiYw6nILqww=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=q3XY2IWsYO2LKc5o5rVxYp8owrzvpH3PwijCmp8mrmPKwFi/cKWV2ElIRLFHqvTQU wooO2ffjz7yOQ+/HmNlzg== 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=fhGHSG4/LKda6GE63qxxwkAbAde531+w8P9OjJsNl0YEfWtHxSZX3bfrIQytNkAnF NbONOqxojy+HFz2Yypjlw== Received: from pzk7 (pzk7.prod.google.com [10.243.19.135]) by wpaz13.hot.corp.google.com with ESMTP id nAULl7cK001901 for ; Mon, 30 Nov 2009 13:49:49 -0800 Received: by pzk7 with SMTP id 7so6479990pzk.30 for ; Mon, 30 Nov 2009 13:49:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.164.2 with SMTP id m2mr341677rve.191.1259617788019; Mon, 30 Nov 2009 13:49:48 -0800 (PST) In-Reply-To: References: <148C596691F29F4EA6968577BE2CDFAE06A1B9FE@SC-MBXC1.TheFacebook.com> Date: Mon, 30 Nov 2009 13:49:47 -0800 Message-ID: From: Brian Eaton To: Mike Malone Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "oauth@ietf.org" , Naitik Shah , Luke Shepard Subject: Re: [OAUTH-WG] Facebook, OAuth, and WRAP X-BeenThere: oauth@ietf.org X-Mailman-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, 30 Nov 2009 21:50:01 -0000 On Mon, Nov 30, 2009 at 11:44 AM, Mike Malone wrote: >> Good point about the tokens. One of us should make a list of all the ter= ms >> in each spec, and then set up a mapping between the sets, to see if the >> number of concepts is really all that different. > > My informal list (from a cursory read of the spec): > =A0OAuth / WRAP > =A0Consumer / Client > =A0Request Token / Refresh Token WRAP has no equivalent of the request token. The closest thing is the verification code. > =A0Access Token / Access Token > =A0Consumer Token / Client identifier & secret > =A0OAuth Verifier / Verification Code WRAP has a refresh token. The closest OAuth analog is the session handle used in the scalable OAuth extension. Cheers, Brian From beaton@google.com Mon Nov 30 13:53:23 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7317D3A693C for ; Mon, 30 Nov 2009 13:53:23 -0800 (PST) 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 Gm+f9atwHyuH for ; Mon, 30 Nov 2009 13:53:22 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 52EB23A69B8 for ; Mon, 30 Nov 2009 13:53:21 -0800 (PST) Received: from wpaz13.hot.corp.google.com (wpaz13.hot.corp.google.com [172.24.198.77]) by smtp-out.google.com with ESMTP id nAULrCMP008081 for ; Mon, 30 Nov 2009 21:53:12 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1259617993; bh=Da6cL/+iwEUVN8anhXlmbiUirfY=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=D+7KrZimNF9EnLW3cni2phM8AHut9ZPvoUPP3oM57q6KDQrx+8iDvs0AJyUlR3Z4m hINoeyAA1DcicGzVOAB3w== 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=uDisRta/FjVGMGh4mHQDa6SeFsKkAH/8WhrvfzuPXuB9Yewf7Gt+Rs/ctqUPghjCo 8n8G722Mn0NzVw7C+jB6Q== Received: from pzk14 (pzk14.prod.google.com [10.243.19.142]) by wpaz13.hot.corp.google.com with ESMTP id nAULr0dW009038 for ; Mon, 30 Nov 2009 13:53:10 -0800 Received: by pzk14 with SMTP id 14so2855490pzk.23 for ; Mon, 30 Nov 2009 13:53:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.4.12 with SMTP id g12mr322860rvi.189.1259617989594; Mon, 30 Nov 2009 13:53:09 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343785209B82@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343785209A24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1259536078.19069.6.camel@localhost> <90C41DD21FB7C64BB94121FBBC2E72343785209A5A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785209B82@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 30 Nov 2009 13:53:09 -0800 Message-ID: From: Brian Eaton To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "Moore, Jonathan \(CIM\)" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] keeping support for RSA (Was: RE: OAuth 2.0 / Charter) X-BeenThere: oauth@ietf.org X-Mailman-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, 30 Nov 2009 21:53:23 -0000 On Mon, Nov 30, 2009 at 11:25 AM, Eran Hammer-Lahav wrote: > > 4. We are still very likely to have a PK-based method for obtaining *authorization* (a token). So > PK will be still available for obtaining a token. I know this does not address the 2-legged > scenario, but whatever we come up there should be the same with whatever we may end > up including in the authentication part. This does actually address the two-legged scenario quite nicely. Client sends PK-signed message to Authorization Server. Authorization Server returns token. Client uses token. Cheers, Brian From beaton@google.com Mon Nov 30 13:56:44 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65A093A68FD for ; Mon, 30 Nov 2009 13:56:44 -0800 (PST) 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 dMiF1pa0+h7p for ; Mon, 30 Nov 2009 13:56:43 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id 754CF3A67B3 for ; Mon, 30 Nov 2009 13:56:43 -0800 (PST) Received: from wpaz21.hot.corp.google.com (wpaz21.hot.corp.google.com [172.24.198.85]) by smtp-out.google.com with ESMTP id nAULuZ3h015473 for ; Mon, 30 Nov 2009 13:56:36 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1259618196; bh=E1KyVKDwdYIqMtAgkd6qC/wzbLY=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=FjSz9H6w+hwKohMJdMvmtuSL9d7ZAo39yaJsWk73CXZHKN2bOaKAd3M+cg++WYA05 waF33gtxk9zLXNq0JZwkA== 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=sbQpY2ONp7ijRgbnNwf0ayrQjZdHV8FaDFSvZGs11KqF6TwMGHWHJoQw2TqIvfppg YBhwINKukYnAmaPgZMVng== Received: from pxi6 (pxi6.prod.google.com [10.243.27.6]) by wpaz21.hot.corp.google.com with ESMTP id nAULsuYY029033 for ; Mon, 30 Nov 2009 13:56:33 -0800 Received: by pxi6 with SMTP id 6so2695726pxi.0 for ; Mon, 30 Nov 2009 13:56:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.143.2 with SMTP id q2mr303492rvd.0.1259618192059; Mon, 30 Nov 2009 13:56:32 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343785209B82@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343785209A24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1259536078.19069.6.camel@localhost> <90C41DD21FB7C64BB94121FBBC2E72343785209A5A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785209B82@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 30 Nov 2009 13:56:32 -0800 Message-ID: From: Brian Eaton To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "Moore, Jonathan \(CIM\)" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] keeping support for RSA (Was: RE: OAuth 2.0 / Charter) X-BeenThere: oauth@ietf.org X-Mailman-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, 30 Nov 2009 21:56:44 -0000 On Mon, Nov 30, 2009 at 11:25 AM, Eran Hammer-Lahav wrote: > 1. We are going to drop some use cases for the sake of simplicity. This will not prevent > extensions, and a PK signature method might be something to standardize, but there i > a lot more to it to make it useful including key rotation, and the initial exchange of > credentials. In my experience, most SAML deployments use self-signed keys, with out-of-band key management. Not having automated key management is not a barrier to adoption of public key, nor does it make public key useless. > Obtaining and managing a token-PK pair is more complex than a simple > token-secret pair. This I agree with 100%. Cheers, Brian From eran@hueniverse.com Mon Nov 30 13:58:48 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC3433A68FD for ; Mon, 30 Nov 2009 13:58:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.484 X-Spam-Level: X-Spam-Status: No, score=-2.484 tagged_above=-999 required=5 tests=[AWL=0.115, 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 ZPsJoeUUU9Ll for ; Mon, 30 Nov 2009 13:58:48 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 09A663A67B3 for ; Mon, 30 Nov 2009 13:58:48 -0800 (PST) Received: (qmail 17155 invoked from network); 30 Nov 2009 21:58:40 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 30 Nov 2009 21:58:40 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Mon, 30 Nov 2009 14:58:33 -0700 From: Eran Hammer-Lahav To: Brian Eaton Date: Mon, 30 Nov 2009 14:58:38 -0700 Thread-Topic: [OAUTH-WG] keeping support for RSA (Was: RE: OAuth 2.0 / Charter) Thread-Index: AcpyB4YOPzEGC0K4Rbu93k1fRCBinwAAGi5g Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343785209C21@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343785209A24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1259536078.19069.6.camel@localhost> <90C41DD21FB7C64BB94121FBBC2E72343785209A5A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785209B82@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: "Moore, Jonathan \(CIM\)" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] keeping support for RSA (Was: RE: OAuth 2.0 / Charter) X-BeenThere: oauth@ietf.org X-Mailman-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, 30 Nov 2009 21:58:48 -0000 I think what most people miss about this is that addition of a new method t= o obtain a *token* without a third party (resource owner, etc.) present. So= instead of the current way OAuth is used for 2-legged, as a dumb substitut= ion for Basic auth, this new approach works the same way across the two use= cases (2, 3-legged), by always requiring the exchange of credentials for a= token, even for 2-legged. And as stated above, this will require some other means to obtain a token w= ithout the use of browser redirection and user authorization. EHL > -----Original Message----- > From: Brian Eaton [mailto:beaton@google.com] > Sent: Monday, November 30, 2009 1:53 PM > To: Eran Hammer-Lahav > Cc: Moore, Jonathan (CIM); Paul C. Bryan; oauth@ietf.org > Subject: Re: [OAUTH-WG] keeping support for RSA (Was: RE: OAuth 2.0 / > Charter) >=20 > On Mon, Nov 30, 2009 at 11:25 AM, Eran Hammer-Lahav > wrote: > > > > 4. We are still very likely to have a PK-based method for obtaining > > *authorization* (a token). So PK will be still available for obtaining > > a token. I know this does not address the 2-legged scenario, but > > whatever we come up there should be the same with whatever we may > end up including in the authentication part. >=20 > This does actually address the two-legged scenario quite nicely. >=20 > Client sends PK-signed message to Authorization Server. > Authorization Server returns token. > Client uses token. >=20 > Cheers, > Brian From mjmalone@gmail.com Mon Nov 30 14:32:42 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 231703A68AF for ; Mon, 30 Nov 2009 14:32:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 ZhujRufm09IC for ; Mon, 30 Nov 2009 14:32:41 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by core3.amsl.com (Postfix) with ESMTP id 9D7B73A6827 for ; Mon, 30 Nov 2009 14:32:38 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 9so833855qwb.31 for ; Mon, 30 Nov 2009 14:32:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Pg9kqPSfP7SCpGMBTq6HgRC4rfPRV/xLGrEHz+mSsUk=; b=msWzn8tx++vgR6bjGJ1SwzlHL+Iqzsgo21tdVoMO2t09dxBDdJbe2GVWdmfnWgkSPI uwhLpgyyARIib90diJUnoAhe71Fwz28tDHdPrwuhI1hzZgNuI0gSMSwFtVlq0JhbtHvC p/0PU1VdC5LuYvEcOpc74Pc7FuOdA1TTqFVKQ= 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=Qk1OBpiR1cCH8hEoZnvb8BQZZMG4pT+Y+jsfMCNUqjVq4ouDV3Yv3MyAiUL2wydx8/ Va/L1qYVP+zxH2NR5bSIEanFpGSdDJI5bBv/crhv0XM8/aflOH2e/Ge389gisRcJ9Ce4 InazCYhBtBPR5bQ4KYT87vw7rSXLjNGRa7Zq4= MIME-Version: 1.0 Received: by 10.229.33.15 with SMTP id f15mr700460qcd.59.1259620348695; Mon, 30 Nov 2009 14:32:28 -0800 (PST) In-Reply-To: References: <4A956CE47D1066408D5C7EB34368A5110551FFC1@S4DE8PSAAQC.mitte.t-com.de> <90C41DD21FB7C64BB94121FBBC2E72343785102B49@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785102E58@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785102F1F@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 30 Nov 2009 14:32:28 -0800 Message-ID: From: Mike Malone To: Dick Hardt Content-Type: text/plain; charset=ISO-8859-1 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] why are we signing? X-BeenThere: oauth@ietf.org X-Mailman-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, 30 Nov 2009 22:32:42 -0000 On Mon, Nov 30, 2009 at 11:17 AM, Dick Hardt wrote: > > On 2009-11-13, at 7:21 AM, Eran Hammer-Lahav wrote: >> >> I for one, see great value in offering some form of crypto-based security for cases where TLS is not suitable. > > Are these use cases enumerated somewhere? I'm not completely opposed to the TLS route, but since you asked... off the top of my head, here are a couple drawbacks to using TLS instead of signing: - Bigger burden on developers who need to debug this stuff (i.e., you can't sniff your own traffic to debug requests & responses). - Properly setting up TLS can be complicated and expensive. For developers who don't have a lot of ops skills the barrier may be too high. - You can no longer pass around signed URLs as another level of delegation (a use case that I use regularly for making XHR & POST requests from the browser). This could be a non-issue if some other mechanism for fourth-party delegation existed. If we were coming up with a more secure replacement for browser-based HTTP basic auth (and looking at Aza Raskin's work with identity in Firefox, OAuth in the browser doesn't appear to be that far off) would you want to mandate that all auth'd HTTP traffic use TLS? Not sure if the answer is yes or no, but I'm guessing many of the advantages/drawbacks will be the same. Mike From mjmalone@gmail.com Mon Nov 30 14:52:38 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5EBB3A68D8 for ; Mon, 30 Nov 2009 14:52:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 zKN0PN5lVM8h for ; Mon, 30 Nov 2009 14:52:38 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by core3.amsl.com (Postfix) with ESMTP id CD0C33A6861 for ; Mon, 30 Nov 2009 14:52:37 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 9so837078qwb.31 for ; Mon, 30 Nov 2009 14:52:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=yDjrMl1U3Tv2sgLwjYDjAmu+PNWmX96i1AO1ar7nB9A=; b=vpXNOBumr/SPwiFa1AIjfksw2DGrEifWth/c1ec5Yc0YyKHLviiJEFFSbhaCFmJaRQ 20j/Yp110NlRDdSW0mk712BmT0AbKngyTdpEUJ3nrNGAIEQJJwXZ+p6jSjKn1wESzJtz Zz0Lt97Fd5QOdj2rorGlUFhmvFwxIbGuHibag= 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=Br62vyZtrfpYhgrUIaXFDUTjNGsS8hlElZkfcV2iyZ23WqTiKkitiya+z/ykdCBHyG A6d5OdkoWMCXGpTw3QMSvbNUl4GLISl8gfdxi+8bQoXyklPqZRPHMHCQvDg3SFeXBTae zize8DID+x7QWG0iPWbWb3xOER2S8+EOeuaqg= MIME-Version: 1.0 Received: by 10.229.92.68 with SMTP id q4mr390206qcm.94.1259621547153; Mon, 30 Nov 2009 14:52:27 -0800 (PST) In-Reply-To: References: <148C596691F29F4EA6968577BE2CDFAE06A1B9FE@SC-MBXC1.TheFacebook.com> Date: Mon, 30 Nov 2009 14:52:27 -0800 Message-ID: From: Mike Malone To: Brian Eaton Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "oauth@ietf.org" , Naitik Shah , Luke Shepard Subject: Re: [OAUTH-WG] Facebook, OAuth, and WRAP X-BeenThere: oauth@ietf.org X-Mailman-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, 30 Nov 2009 22:52:38 -0000 On Mon, Nov 30, 2009 at 1:49 PM, Brian Eaton wrote: > On Mon, Nov 30, 2009 at 11:44 AM, Mike Malone wrote: >>> Good point about the tokens. One of us should make a list of all the te= rms >>> in each spec, and then set up a mapping between the sets, to see if the >>> number of concepts is really all that different. >> >> My informal list (from a cursory read of the spec): >> =A0OAuth / WRAP >> =A0Consumer / Client >> =A0Request Token / Refresh Token > > WRAP has no equivalent of the request token. =A0The closest thing is the > verification code. > >> =A0Access Token / Access Token >> =A0Consumer Token / Client identifier & secret >> =A0OAuth Verifier / Verification Code > > WRAP has a refresh token. =A0The closest OAuth analog is the session > handle used in the scalable OAuth extension. As far as I can tell, if we're treating everything as opaque strings, the only real difference between a WRAP "refresh token" and an OAuth "request token" is that a "refresh token" can be exchanged for an "access token" multiple times in WRAP (since the access tokens expire). Is there some other non-trivial difference that I'm missing? Again, maybe I'm mistaken, but the verification code seems to be included in WRAP to protect against the sort of session fixation attack that OAuth 1.0 was susceptible to. In OAuth 1.0a the OAuth Verifier was added to fix that vulnerability, which is why I said the OAuth Verifier and WRAP Verification Code were essentially equivalent. Mike From beaton@google.com Mon Nov 30 16:14:50 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD8963A69EB for ; Mon, 30 Nov 2009 16:14:50 -0800 (PST) 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 CG7LtUUNm-Dx for ; Mon, 30 Nov 2009 16:14:49 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 611663A6898 for ; Mon, 30 Nov 2009 16:14:49 -0800 (PST) Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id nB10EeYj013383 for ; Tue, 1 Dec 2009 00:14:40 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1259626480; bh=wt7SRS0zbYgiRBuv4ZxEpEbKDes=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=hIi5A08g4sjQdOkwIjz/sx8xzG4+GL6wDw2vZ5jIZtU9YeRVDusPcp9CdId9p0oBo tSjqKwmbHLgB5aYhM1Gzw== 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=YqWAKBJCzxIlXXsxBcwV3/c+wvquIIkhukcjkiMY+wlRYNrkKINutn0paDUxkE98d 8YdwKaVJwMVBnQQTGaMOw== Received: from pwi6 (pwi6.prod.google.com [10.241.219.6]) by wpaz24.hot.corp.google.com with ESMTP id nB10ES3n013622 for ; Mon, 30 Nov 2009 16:14:37 -0800 Received: by pwi6 with SMTP id 6so2282574pwi.29 for ; Mon, 30 Nov 2009 16:14:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.202.20 with SMTP id z20mr348405rvf.28.1259626477052; Mon, 30 Nov 2009 16:14:37 -0800 (PST) In-Reply-To: References: <4A956CE47D1066408D5C7EB34368A5110551FFC1@S4DE8PSAAQC.mitte.t-com.de> <90C41DD21FB7C64BB94121FBBC2E72343785102B49@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785102E58@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785102F1F@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 30 Nov 2009 16:14:36 -0800 Message-ID: From: Brian Eaton To: Mike Malone Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: Dick Hardt , "oauth@ietf.org" Subject: Re: [OAUTH-WG] why are we signing? X-BeenThere: oauth@ietf.org X-Mailman-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 Dec 2009 00:14:50 -0000 On Mon, Nov 30, 2009 at 2:32 PM, Mike Malone wrote: > If we were coming up with a more secure replacement for browser-based > HTTP basic auth (and looking at Aza Raskin's work with identity in > Firefox, OAuth in the browser doesn't appear to be that far off) would > you want to mandate that all auth'd HTTP traffic use TLS? Not sure if > the answer is yes or no, but I'm guessing many of the > advantages/drawbacks will be the same. We should be really cautious about claiming that *anything* we do replaces TLS. I've seen at least one academic paper criticizing OAuth on the basis that OAuth was designed to be secure in the absence of TLS, yet doesn't actually achieve that goal. Cheers, Brian From beaton@google.com Mon Nov 30 16:20:39 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FF8B28C15C for ; Mon, 30 Nov 2009 16:20:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[AWL=0.000, 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 oIUhCydcSZdo for ; Mon, 30 Nov 2009 16:20:38 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 8E06228C177 for ; Mon, 30 Nov 2009 16:20:38 -0800 (PST) Received: from wpaz5.hot.corp.google.com (wpaz5.hot.corp.google.com [172.24.198.69]) by smtp-out.google.com with ESMTP id nB10KTMx024916 for ; Tue, 1 Dec 2009 00:20:30 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1259626830; bh=WmKAe41ZNo3uOAdAp7n4IK5i0vM=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=WEHMcvDwO5Hmfu8ZSguW/yV93s3ghHFmFdVuFYoZk0NZaDKfsMs5lCD4Lo/F8h8zu sZ9eZzKYK+g8t9tm8l4Tw== 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=rhccix0NRNT52U3HRYnJ1pI6JO/TkkbAJieuW5q4PBOpBHSWg3150c5H/NFPFsOUm obA8d9CJX2EePtwAGngdg== Received: from pxi39 (pxi39.prod.google.com [10.243.27.39]) by wpaz5.hot.corp.google.com with ESMTP id nB10KQsL001372 for ; Mon, 30 Nov 2009 16:20:27 -0800 Received: by pxi39 with SMTP id 39so3344101pxi.2 for ; Mon, 30 Nov 2009 16:20:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.127.8 with SMTP id z8mr337863rvc.156.1259626826769; Mon, 30 Nov 2009 16:20:26 -0800 (PST) In-Reply-To: References: <148C596691F29F4EA6968577BE2CDFAE06A1B9FE@SC-MBXC1.TheFacebook.com> Date: Mon, 30 Nov 2009 16:20:26 -0800 Message-ID: From: Brian Eaton To: Mike Malone Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "oauth@ietf.org" , Naitik Shah , Luke Shepard Subject: Re: [OAUTH-WG] Facebook, OAuth, and WRAP X-BeenThere: oauth@ietf.org X-Mailman-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 Dec 2009 00:20:39 -0000 On Mon, Nov 30, 2009 at 2:52 PM, Mike Malone wrote: > As far as I can tell, if we're treating everything as opaque strings, > the only real difference between a WRAP "refresh token" and an OAuth > "request token" is that a "refresh token" can be exchanged for an > "access token" multiple times in WRAP (since the access tokens > expire). Is there some other non-trivial difference that I'm missing? The main difference between the OAuth request token and the WRAP refresh token is when they are generated and how they are used. > Again, maybe I'm mistaken, but the verification code seems to be > included in WRAP to protect against the sort of session fixation > attack that OAuth 1.0 was susceptible to. In OAuth 1.0a the OAuth > Verifier was added to fix that vulnerability, which is why I said the > OAuth Verifier and WRAP Verification Code were essentially equivalent. In WRAP we combined the OAuth request token and the OAuth verification code into a single value. It saves a round trip in the protocol. The verification code serves both as a form of user identifier and as an unguessable value used to prevent session fixation. Cheers, Brian From faynberg@alcatel-lucent.com Mon Nov 30 16:23:08 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C1383A6928 for ; Mon, 30 Nov 2009 16:23:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 pZ-0Wk-Siao1 for ; Mon, 30 Nov 2009 16:23:07 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id A59DB3A68D8 for ; Mon, 30 Nov 2009 16:23:07 -0800 (PST) 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 nB10MvA0016430 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Nov 2009 18:22:57 -0600 (CST) Received: from [135.244.32.51] (talbers.lra.lucent.com [135.244.32.51] (may be forged)) by umail.lucent.com (8.13.8/TPES) with ESMTP id nB10Mshb013701; Mon, 30 Nov 2009 18:22:55 -0600 (CST) Message-ID: <4B1461DE.9070803@alcatel-lucent.com> Date: Mon, 30 Nov 2009 19:22:54 -0500 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Moore, Jonathan (CIM)" References: <90C41DD21FB7C64BB94121FBBC2E72343785209A24@P3PW5EX1MB01.EX1.SECURESERVER.NET><1259536078.19069.6.camel@localhost> <90C41DD21FB7C64BB94121FBBC2E72343785209A5A@P3PW5EX1MB01.EX1.SECURESERVER.NET> 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.35 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] keeping support for RSA (Was: RE: OAuth 2.0 / Charter) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: faynberg@alcatel-lucent.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 00:23:08 -0000 First, I second Jonathan's motion. I thought that we had discussed this issue, and it appeared to me that there was an agreement on the necessity of the signatures. Then I raised the issue of limiting ourselves to RSA (vs. ECC or other public-key mechanisms), and there was a good discussion of this subject, too. I thought that the outcome of it was that we keep RSA mandatory and, in addition, allow other mechanisms. Maybe I have misinterpreted the outcome of that discussion? Igor Moore, Jonathan (CIM) wrote: > Eran Hammer-Lahav writes, with respect to RSA support: > >> In other words, why put the effort in if no one is asking for this >> (based on 2 years of deployment experience). >> > > Ok, I'll ask for it then! Our main use cases for OAuth 1.0 have been for > 2-legged, server-to-server integrations with known third parties. Public > key cryptography offers a lot of advantages here in terms of ease of > properly making a secure association between organizations. At least in > our shop, it's considerably easier for us to deal with PKI than it is to > set up SSL endpoints and/or run internal CAs. > > Also, and especially when the response *body* does not require privacy, > I'd much rather spend my CPU cycles doing public-key cryptography on the > HTTP headers than encrypting an entire response payload via SSL. I also > lose the benefits of HTTP intermediaries when I have to tunnel over SSL. > > I'm happy to participate here to work to keep this support in OAuth 2.0 > (I'm just coming up to speed on the WG here). > > Thanks, > Jon > ........ > Jon Moore > Comcast Interactive Media > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Eran Hammer-Lahav > Sent: Monday, November 30, 2009 2:34 AM > To: Paul C. Bryan > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] OAuth 2.0 / Charter > > > > >> -----Original Message----- >> From: Paul C. Bryan [mailto:email@pbryan.net] >> Sent: Sunday, November 29, 2009 3:08 PM >> To: Eran Hammer-Lahav >> Cc: Peter Saint-Andre (stpeter@stpeter.im); Lisa Dusseault >> (lisa.dusseault@gmail.com); OAuth WG (oauth@ietf.org) >> Subject: Re: [OAUTH-WG] OAuth 2.0 / Charter >> >> To the overall approach, +1. >> >> Some follow-up questions: >> >> 1. Why drop RSA? It seems some form of public key cryptography will be >> necessary/useful to make web-based-attribute-containing tokens >> > Internet- > >> scalable. >> > > Mostly due to lack of implementation experience or interest within the > OAuth community. But also because the Plain and MAC versions are based > on a simple symmetric shared secret, while PK requires more. This means > we will need to support different types of tokens. While I am open to > this if needed, it seems to add a significant complexity. Also, part 2 > will then need to be able to provision both symmetric and asymmetric > secrets which adds to the complexity there. > > In other words, why put the effort in if no one is asking for this > (based on 2 years of deployment experience). > > >> 2. Is it an objective to have the Token auth-scheme contain extension >> > points > >> so that new token formats can be introduced without need to redefine >> > the > >> scheme or draft a new one? >> > > Yes, but see above. > > 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 stpeter@stpeter.im Mon Nov 30 18:10:14 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C5A43A6AB2 for ; Mon, 30 Nov 2009 18:10:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 8V6ZCuDx3JCx for ; Mon, 30 Nov 2009 18:10:12 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 875753A6405 for ; Mon, 30 Nov 2009 18:10:10 -0800 (PST) Received: from squire.local (dsl-175-187.dynamic-dsl.frii.net [216.17.175.187]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7085D40D16; Mon, 30 Nov 2009 19:10:02 -0700 (MST) Message-ID: <4B147AF9.5060506@stpeter.im> Date: Mon, 30 Nov 2009 19:10:01 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Brian Eaton References: <4A956CE47D1066408D5C7EB34368A5110551FFC1@S4DE8PSAAQC.mitte.t-com.de> <90C41DD21FB7C64BB94121FBBC2E72343785102B49@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785102E58@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785102F1F@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060809040108000301050508" Cc: Dick Hardt , "oauth@ietf.org" Subject: Re: [OAUTH-WG] why are we signing? X-BeenThere: oauth@ietf.org X-Mailman-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 Dec 2009 02:10:14 -0000 This is a cryptographically signed message in MIME format. --------------ms060809040108000301050508 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 11/30/09 5:14 PM, Brian Eaton wrote: > On Mon, Nov 30, 2009 at 2:32 PM, Mike Malone wrote: >> If we were coming up with a more secure replacement for browser-based >> HTTP basic auth (and looking at Aza Raskin's work with identity in >> Firefox, OAuth in the browser doesn't appear to be that far off) would >> you want to mandate that all auth'd HTTP traffic use TLS? Not sure if >> the answer is yes or no, but I'm guessing many of the >> advantages/drawbacks will be the same. > > We should be really cautious about claiming that *anything* we do > replaces TLS. I've seen at least one academic paper criticizing OAuth > on the basis that OAuth was designed to be secure in the absence of > TLS, yet doesn't actually achieve that goal. And given that TLS isn't even as secure as we thought it was (cf. the current issues with a renegotiation attack), we really should be doubly cautious about security technologies (like OAuth 1.0 signatures) that have experienced significantly less implementation and deployment than SSL/TLS (which is one of the few successful security technologies). Peter -- Peter Saint-Andre https://stpeter.im/ --------------ms060809040108000301050508 Content-Type: application/x-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 hvcNAQkFMQ8XDTA5MTIwMTAyMTAwMVowIwYJKoZIhvcNAQkEMRYEFIBvv7q//9Q+TdVErUsN Zba3eJo8MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAdIYROg8CMhM91Tv5Da9Mf6MSfF6OHlEefuoPFuCg AFCqyP/nVzniLQrVNBAzf76t6FO7Zro8jnSLaKTUsdm+QSfaUDyDcuqtt1DbZq9ezSQxFClK G8bwLJ4PAsrpYViJZ9Qc9bb/oB8RzeTPR8othDF0RlYjUsIvfsLzjR8YMUlULSVLfrLepIvm A5xAEq+zld5tI43sss5BP/xwVCAYgD1V/leiY0G7wXIE2Vh85ODcNrxoRsFD6j3t5rE1mYHP ww0YVFw2MUxNcTFnoHdj8zxkgB3YOFji+iYe6ETiME6azbxhBKuAsx2K5v3kNay5YrwLunrv znQiCPRGnPigiAAAAAAAAA== --------------ms060809040108000301050508-- From pelleb@gmail.com Mon Nov 30 19:08:46 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B11623A67C2 for ; Mon, 30 Nov 2009 19:08:46 -0800 (PST) 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 551AcVwXLtqr for ; Mon, 30 Nov 2009 19:08:45 -0800 (PST) Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id D40293A67E4 for ; Mon, 30 Nov 2009 19:08:44 -0800 (PST) Received: by fxm5 with SMTP id 5so4466352fxm.28 for ; Mon, 30 Nov 2009 19:08:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=mEhsaUvklkte0xrKc9sDAxZwiL9GjlLvCUoKpBVvBFc=; b=duUUhLo3ArA0Xie07Urb0kQUr3k5xjOFPuzl7fo3t7K5JoyBNwrAdhmY5Zxm1ebayj h2ozDDhNXfgf7vtWN8nxIObFaOyUtro9E3xA/YXKKhRH2kp1HuolNons3mSUtdWvoBTE ka/moKw6qT4bdFLOW80ioQbTkMmVIP+JKwEB0= 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=BCIKXGqzCv/14fURgenWYrdb/C397LGfCNpbBdVvXAq2Unv3763+kyndpx4YlDysuz p4yMYm2L0626Wj5f4a2v6uJD9Ss4Ygwye/rdQmGUXgwIDX8kGIQagJCzZYd+pxl4GWuZ obkjierI6HBfw4SAK6X8XElAKSf2ZB6h9g80I= MIME-Version: 1.0 Sender: pelleb@gmail.com Received: by 10.223.15.4 with SMTP id i4mr58720faa.39.1259636914270; Mon, 30 Nov 2009 19:08:34 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343785209BE7@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343785209A24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <48AE706BD74FCC4297AD778805CA46F6184C5CF474@usps.sonoa.local> <90C41DD21FB7C64BB94121FBBC2E72343785209A5B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B1407A7.9040907@cs.tcd.ie> <4B1423FB.2070506@stpeter.im> <90C41DD21FB7C64BB94121FBBC2E72343785209BE7@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 30 Nov 2009 22:08:34 -0500 X-Google-Sender-Auth: ad8615f48320cf46 Message-ID: From: Pelle Braendgaard To: Eran Hammer-Lahav Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] OAuth 2.0 / Charter X-BeenThere: oauth@ietf.org X-Mailman-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 Dec 2009 03:08:46 -0000 I agree completely with these steps as well. While OAuth has had a few implementation difficulties that I think Eran has done a good job of fixing in the revised 1.0 spec there is a clear danger for OAuth 2.0 to stray to much from the original ideas. If we add too many different variations and features into the standard we risk becoming WS-deathstar 2.0 and no small developers will deal with it. Of course our respective companies all have specific use cases we would like to implement like me wanting to keep some sort of generic model for asymmetric signing in the standard. It would really help us by not including those in the base standard and having various extensions outside. For example as much as I don't like the OAuth Session Extension for the additional complexity it adds for developers, I am much happier with it being an extension where a vendor decides if they are willing to add a complexity tax for their client developers. It is their choice. If for the sake of simplicity it would be better create some kind of simple optional public key signing into an extension, then I would be for it. So as a general approach keep it simple. Pelle I think the idea of splitting the standard up in two as suggested really helps this approach. On Mon, Nov 30, 2009 at 4:17 PM, Eran Hammer-Lahav wr= ote: > During the charter discussions and earlier during the BOF discussions, th= e consensus was that any effort to address the general problem from scratch= was doomed. The IETF and other bodies have a very poor track record of suc= cessfully creating new security technologies with wide adoption. OAuth repr= esented a rare opportunity of using the community work to bootstrap a stand= ards track effort. > > Different people take that to mean different things. For some, the goal s= hould be to rubber stamp 1.0 or as close to that as possible. To others, th= is means taking whatever they feel is the core component of the protocol an= d reusing it (from the signature methods to the web-redirection flow). > > To me, the most useful part of OAuth for the purpose of creating new work= is the model, not the technical details. This is not to imply that the mod= el is better than others, just that we have consensus on that, and it is th= e hardest part to agree on. The OAuth model includes some specific choices: > > 1. Resource owner credentials are not shared with third parties. Instead,= a token is used to represent a specific access scope. > 2. Tokens are issued by the server, not by the resource owner. OAuth toke= ns are treated as opaque strings, and while structured tokens are possible,= they are external to the model. > 3. Token authentication does not require SSL/TLS, but is fully compatible= with it. > > I would strongly caution this working group from reopening these basic el= ements as it is more likely to lead to a forking of this effort than any su= ccessful specification. OAuth's greatest value is the compromise it represe= nts in its design. Give up that and we are back to square one. I have no in= terest in starting from scratch or a different base technology. > > The main issue with the current charter is the backward-compatibility sec= tion, not the 1.1 label. It would be a mockery of process and common sense = to justify each of the proposed changes as required for security and intero= perability and worth breaking compatibility. None of this matters once we c= hange a single thing, and we already know we are going to. > > My proposal doesn't change the core model. It cleans up the authenticatio= n part by simplifying it and making it more extensible and it proposes to e= xtend the set of available methods to obtain a token from a single redirect= ion-based process to a few other options. > > We can certainly stretch the existing charter by using our mandate to cre= ate a new authenticate scheme and focus on that, calling it Token Authentic= ation. Then we can have this discussion about how much to add to the single= delegation method provided. I leave this up to the chair to decide what is= best. > > My focus is now on producing a draft for the Token Authentication method = which is very much in line with the charter and based on WG discussions fro= m a couple of months ago. > > EHL > > >> -----Original Message----- >> From: Peter Saint-Andre [mailto:stpeter@stpeter.im] >> Sent: Monday, November 30, 2009 11:59 AM >> To: Stephen Farrell >> Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org) >> Subject: Re: [OAUTH-WG] OAuth 2.0 / Charter >> >> >> >> On 11/30/09 10:57 AM, Stephen Farrell wrote: >> > While I think the general goal seems ok, and perhaps even better, >> >> I do think it is worthwhile to have a discussion about the proper >> "general goal" for this WG, especially given the changing landscape >> regarding OAuth[-ish] technologies. >> >> > I do wonder whether its reasonable to re-charter a WG that has >> > never formally met face to face, >> >> The chairs take responsibility for the lack of a meeting, but I can >> guarantee you that the group will meet at IETF 77. >> >> > nor met any of its current >> > milestones. >> >> Given that the WG was chartered on May 13, it was perhaps a bit >> aggressive to "Submit 'OAuth: HTTP Authorization Delegation Protocol' as >> working group item" in Apr 2009. :) >> >> Based on list discussion in May and June, we came to consensus to split >> draft-hammer-oauth into two specifications, which Eran did in early >> July, resulting in draft-ietf-oauth-authentication and >> draft-ietf-oauth-web-delegation as WG items. We've had quite a bit of >> discussion about those on the list, but it seems to me that the >> discussion here and elsewhere has led to a desire for something more >> than a simple, backwards-compatible specification of "OAuth 1.1" as >> described in the charter. In particular, the scope of "OAuth 1.1" >> appears to have been limited to improving terminology, embodying good >> security practices, promoting interoperability, and providing guidelines >> for extensibility. >> >> > It may be, I'm just not sure, but what's the reason for not >> > finishing OAuth 1.1 first? (The fact that you "see no value" >> > doesn't explain it to me at least.) >> >> I agree that we need to get the reasons out on the table so that we can >> have an open discussion about problems and objectives. >> >> > I also find the following a bit puzzling: >> > >> > Eran Hammer-Lahav wrote: >> >> Keep in mind that we are not going to include token structure in scop= e. >> >> We are simply proposing a method in which the token is a string, leav= ing >> >> it up to other efforts to give it structure if needed. >> > >> > What other efforts? How would the implementer of an RFC achieve >> > interoperability? Wouldn't we need to be able to answer that before >> > proceeding? >> >> Those are good questions. >> >> > To answer your specific questions: >> > >> >> - Is this approach favorable by the group? >> > >> > Maybe. >> > >> >> - Do we need to adjust the language in the charter to support? >> > >> > Definitely IMO. The current charter talks about striving to >> > maintain backwards compatibility etc. >> >> The charter also says: >> >> =C2=A0 However, changes that are not backwards >> =C2=A0 compatible might be accepted if the group determines that >> =C2=A0 the changes are required to meet the group's technical >> =C2=A0 objectives and the group clearly documents the reasons for >> =C2=A0 making them. >> >> That implies the need to, above all, clarify the group's technical >> objectives. IMHO the problem statement is not fully clear in the >> existing charter, and furthermore it appears that some people now might >> be trying to solve related but somewhat different problems with OAuth >> (or something similar enough to OAuth that it can retain the name). That >> might be either exciting or worrisome, depending on your perspective. >> >> Peter >> >> -- >> Peter Saint-Andre >> https://stpeter.im/ >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 http://agree2.com - Reach Agreement! http://extraeagle.com - Solutions for the electronic Extra Legal world http://stakeventures.com - Bootstrapping blog From leah.culver@gmail.com Mon Nov 30 20:17:23 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80C633A68BA for ; Mon, 30 Nov 2009 20:17:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-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 Msajg2fpzmvT for ; Mon, 30 Nov 2009 20:17:22 -0800 (PST) Received: from mail-px0-f184.google.com (mail-px0-f184.google.com [209.85.216.184]) by core3.amsl.com (Postfix) with ESMTP id 6F2FA3A680E for ; Mon, 30 Nov 2009 20:17:22 -0800 (PST) Received: by pxi14 with SMTP id 14so3390967pxi.31 for ; Mon, 30 Nov 2009 20:17:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type; bh=o3LmJd4x2cdoCpDnAH0TeTeDahnGVk/SuBzqKxaXBeI=; b=xxAmFpOtW+lSW3AtodwgPwFbcjsEU4mYWT182HBuRsiyTKGeHunm2kiWQPoSOeB+0i xfCcp9qUiFF/Of8Dm9rQRnShe+yBNhsET3YDdslXbWkrucw0a/a/D9CtgSd5EhxuesIy 0qCgptQsVIdIYGm4PY5AnnWzpfGez/e9CU+hg= 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; b=scgt4inNMIMKFNZfOmANQhJlS+0VfirraZxH1rKZ0FyqliXlj6CBLJG8FaVYqK5D06 90/KYiP50/q9IYrRpjx1hFayZFOFYe1RRp79ovA31d+RCYAhw8H3AHE9FXmZV8UPosoi zBXlmuj1HUHh6BK4Dt6HF45n05L2lOt3T/uvA= MIME-Version: 1.0 Received: by 10.140.202.16 with SMTP id z16mr339141rvf.233.1259641032083; Mon, 30 Nov 2009 20:17:12 -0800 (PST) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E72343785209A24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <48AE706BD74FCC4297AD778805CA46F6184C5CF474@usps.sonoa.local> <90C41DD21FB7C64BB94121FBBC2E72343785209A5B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B1407A7.9040907@cs.tcd.ie> <4B1423FB.2070506@stpeter.im> <90C41DD21FB7C64BB94121FBBC2E72343785209BE7@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Leah Culver Date: Mon, 30 Nov 2009 20:16:52 -0800 Message-ID: <9184e2a80911302016r1094ac67v2704d36e6b1b9aa6@mail.gmail.com> To: Pelle Braendgaard Content-Type: multipart/alternative; boundary=000e0cd29db44308bb0479a3080c Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] OAuth 2.0 / Charter X-BeenThere: oauth@ietf.org X-Mailman-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 Dec 2009 04:17:23 -0000 --000e0cd29db44308bb0479a3080c Content-Type: text/plain; charset=ISO-8859-1 > > If we add too many different variations and features into the standard > we risk becoming WS-deathstar 2.0 and no small developers will deal > with it. > > http://www.dailymotion.com/video/x6woyj_death-star-over-san-francisco_travel --000e0cd29db44308bb0479a3080c Content-Type: text/html; charset=ISO-8859-1

If we add too many different variations and features into the standard
we risk becoming WS-deathstar 2.0 and no small developers will deal
with it.

--000e0cd29db44308bb0479a3080c-- From pelleb@gmail.com Mon Nov 30 20:32:25 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A204128C1AD for ; Mon, 30 Nov 2009 20:32:25 -0800 (PST) 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 F4u0pnTAgCT7 for ; Mon, 30 Nov 2009 20:32:24 -0800 (PST) Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id 4505A28C14C for ; Mon, 30 Nov 2009 20:32:24 -0800 (PST) Received: by fxm5 with SMTP id 5so4502018fxm.28 for ; Mon, 30 Nov 2009 20:32:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=rNccbC+Fh8UQsBFQmtVPkKrolmYsevLtS//8+TbRsq0=; b=I/qgjJsCSEUfNFjDKALgjH9VDDG0mnJ7uv3JUGv/jCXzWtl4yr8mCFexANH+awyvB9 h1U8vgw9IRdYb5a3mOjC6sOxDVu7fI++qpI3NUpTePwoZ6y6t/RcJNPaIMeQKXE0bCQX 1nY6P056rLhiNOkbl24qoLzK7j667drw+oDfY= 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; b=ed/u3O34G/gG/kzEmtLpsPfWQedX8j1JzqKWQQRIQcbKVkAVv9da+wd5X+dp+R9syE 2flGXJNqlQhxR/oEpJf7V8W6AnMZLEw08S8YPOJ7F6wXQ/6zKBNB5l/PScMeOMK2Q57R MTlgvgWUew2M0x5lAuLcQzyT27KzOi5RKQW1Y= MIME-Version: 1.0 Sender: pelleb@gmail.com Received: by 10.223.76.91 with SMTP id b27mr825789fak.16.1259641935206; Mon, 30 Nov 2009 20:32:15 -0800 (PST) In-Reply-To: <4B1461DE.9070803@alcatel-lucent.com> References: <90C41DD21FB7C64BB94121FBBC2E72343785209A24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1259536078.19069.6.camel@localhost> <90C41DD21FB7C64BB94121FBBC2E72343785209A5A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B1461DE.9070803@alcatel-lucent.com> Date: Mon, 30 Nov 2009 23:32:15 -0500 X-Google-Sender-Auth: 5b27e2f52a3ed9ae Message-ID: From: Pelle Braendgaard To: faynberg@alcatel-lucent.com Content-Type: text/plain; charset=UTF-8 Cc: "Moore, Jonathan \(CIM\)" , oauth@ietf.org Subject: Re: [OAUTH-WG] keeping support for RSA (Was: RE: OAuth 2.0 / Charter) X-BeenThere: oauth@ietf.org X-Mailman-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 Dec 2009 04:32:25 -0000 I'm in agreement with this as well. We should not attempt any kind of key management or anything here, but some kind of method of signing which would theoretically work with any public/private key signing solution. Once the pattern for RSA is defined is there it would just mean changing over the signature type parameter for future algorithms. P On Mon, Nov 30, 2009 at 7:22 PM, Igor Faynberg wrote: > First, I second Jonathan's motion. > > I thought that we had discussed this issue, and it appeared to me that there > was an agreement on the necessity of the signatures. Then I raised the issue > of limiting ourselves to RSA (vs. ECC or other public-key mechanisms), and > there was a good discussion of this subject, too. I thought that the outcome > of it was that we keep RSA mandatory and, in addition, allow other > mechanisms. Maybe I have misinterpreted the outcome of that discussion? > > Igor > > > > Moore, Jonathan (CIM) wrote: >> >> Eran Hammer-Lahav writes, with respect to RSA support: >> >>> >>> In other words, why put the effort in if no one is asking for this >>> (based on 2 years of deployment experience). >>> >> >> Ok, I'll ask for it then! Our main use cases for OAuth 1.0 have been for >> 2-legged, server-to-server integrations with known third parties. Public >> key cryptography offers a lot of advantages here in terms of ease of >> properly making a secure association between organizations. At least in >> our shop, it's considerably easier for us to deal with PKI than it is to >> set up SSL endpoints and/or run internal CAs. >> >> Also, and especially when the response *body* does not require privacy, >> I'd much rather spend my CPU cycles doing public-key cryptography on the >> HTTP headers than encrypting an entire response payload via SSL. I also >> lose the benefits of HTTP intermediaries when I have to tunnel over SSL. >> >> I'm happy to participate here to work to keep this support in OAuth 2.0 >> (I'm just coming up to speed on the WG here). >> >> Thanks, >> Jon >> ........ >> Jon Moore >> Comcast Interactive Media >> >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Eran Hammer-Lahav >> Sent: Monday, November 30, 2009 2:34 AM >> To: Paul C. Bryan >> Cc: OAuth WG (oauth@ietf.org) >> Subject: Re: [OAUTH-WG] OAuth 2.0 / Charter >> >> >> >> >>> >>> -----Original Message----- >>> From: Paul C. Bryan [mailto:email@pbryan.net] >>> Sent: Sunday, November 29, 2009 3:08 PM >>> To: Eran Hammer-Lahav >>> Cc: Peter Saint-Andre (stpeter@stpeter.im); Lisa Dusseault >>> (lisa.dusseault@gmail.com); OAuth WG (oauth@ietf.org) >>> Subject: Re: [OAUTH-WG] OAuth 2.0 / Charter >>> >>> To the overall approach, +1. >>> >>> Some follow-up questions: >>> >>> 1. Why drop RSA? It seems some form of public key cryptography will be >>> necessary/useful to make web-based-attribute-containing tokens >>> >> >> Internet- >> >>> >>> scalable. >>> >> >> Mostly due to lack of implementation experience or interest within the >> OAuth community. But also because the Plain and MAC versions are based >> on a simple symmetric shared secret, while PK requires more. This means >> we will need to support different types of tokens. While I am open to >> this if needed, it seems to add a significant complexity. Also, part 2 >> will then need to be able to provision both symmetric and asymmetric >> secrets which adds to the complexity there. >> >> In other words, why put the effort in if no one is asking for this >> (based on 2 years of deployment experience). >> >> >>> >>> 2. Is it an objective to have the Token auth-scheme contain extension >>> >> >> points >> >>> >>> so that new token formats can be introduced without need to redefine >>> >> >> the >> >>> >>> scheme or draft a new one? >>> >> >> Yes, but see above. >> >> 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 > -- http://agree2.com - Reach Agreement! http://extraeagle.com - Solutions for the electronic Extra Legal world http://stakeventures.com - Bootstrapping blog