From rbarnes@bbn.com Mon Jul 6 11:57: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 4FA903A6D5E for ; Mon, 6 Jul 2009 11:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.105, 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 dNEJs7ykwX30 for ; Mon, 6 Jul 2009 11:57:47 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 821363A6D5A for ; Mon, 6 Jul 2009 11:57:47 -0700 (PDT) Received: from ros-dhcp192-1-51-37.bbn.com ([192.1.51.37]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1MNsRZ-0003SH-F4 for oauth@ietf.org; Mon, 06 Jul 2009 13:57:33 -0400 Message-ID: <4A52491D.3050507@bbn.com> Date: Mon, 06 Jul 2009 14:57:33 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: "oauth@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [OAUTH-WG] [Fwd: New Version Notification for draft-barnes-oauth-model-00] X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 18:57:48 -0000 Hi all, As promised at IETF 74, Matt and I spent some time thinking about the security model underlying OAuth, abstracted from the specific HTTP mechanics. This draft attempts to explain how the OAuth authorization model works, what security features it provides, and how. Hopefully this will help make the protocol documents more comprehensible, and maybe even provide a framework to extend OAuth to other protocols than HTTP. Until it gets mirrored over to the tools site, you can find the draft here: Questions, comments, and all other feedback are welcome. Thanks a lot, --Richard -------- Original Message -------- Subject: New Version Notification for draft-barnes-oauth-model-00 Date: Mon, 6 Jul 2009 11:52:05 -0700 (PDT) From: IETF I-D Submission Tool To: rbarnes@bbn.com CC: mlepinski@bbn.com A new version of I-D, draft-barnes-oauth-model-00.txt has been successfuly submitted by Richard Barnes and posted to the IETF repository. Filename: draft-barnes-oauth-model Revision: 00 Title: The OAuth Security Model for Delegated Authorization Creation_date: 2009-07-06 WG ID: Independent Submission Number_of_pages: 20 Abstract: This document describes the security model for the OAuth authorization system, which allows a party that holds some authorization to delegate a subset of that authorization to another party, without requiring either party to disclose its credentials to the other. In this document, we describe a set of design constraints, a high-level work flow for establishing authorizations subject to those constraints, and set of security requirements for protocols that implement this model. The IETF Secretariat. From stpeter@stpeter.im Mon Jul 6 12:20: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 8878928C42B for ; Mon, 6 Jul 2009 12:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[AWL=0.164, 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 GiY96jFs4Rex for ; Mon, 6 Jul 2009 12:20:20 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 8CD7028C408 for ; Mon, 6 Jul 2009 12:20:20 -0700 (PDT) Received: from dhcp-64-101-72-227.cisco.com (dhcp-64-101-72-227.cisco.com [64.101.72.227]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id EABE840CF3 for ; Mon, 6 Jul 2009 13:20:06 -0600 (MDT) Message-ID: <4A524E66.40400@stpeter.im> Date: Mon, 06 Jul 2009 13:20:06 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: "oauth@ietf.org" X-Enigmail-Version: 0.95.7 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [OAUTH-WG] [Fwd: I-D Action:draft-ietf-oauth-web-delegation-00.txt] X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 19:20:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The web delegation spec, too... - -------- Original Message -------- Subject: I-D Action:draft-ietf-oauth-web-delegation-00.txt Date: Mon, 6 Jul 2009 12:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: oauth@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Authentication Protocol Working Group of the IETF. Title : The OAuth Protocol: Web Delegation Author(s) : E. Hammer-Lahav Filename : draft-ietf-oauth-web-delegation-00.txt Pages : 18 Date : 2009-07-06 This document specifies the OAuth protocol web delegation method. OAuth allows clients to access server resources on behalf of another party (such a different client or an end user). This document defines a redirection-based user-agent process for end users to authorize access to clients by substituting their credentials (typically, a username and password pair) with a different set of delegation-specific credentials. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-web-delegation-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpSTmYACgkQNL8k5A2w/vxUEQCgxuN4ikzmjI/uKOr6xcD088hg qfcAoK9pN3S98stqLDLI3Y32fMaT6pr3 =WJOQ -----END PGP SIGNATURE----- From eran@hueniverse.com Mon Jul 6 12:29: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 2603C28C2AB for ; Mon, 6 Jul 2009 12:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 nBmPuFKvEH7E for ; Mon, 6 Jul 2009 12:29:55 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 17E2C28C249 for ; Mon, 6 Jul 2009 12:29:55 -0700 (PDT) Received: (qmail 9921 invoked from network); 6 Jul 2009 19:29:19 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 6 Jul 2009 19:29:19 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 6 Jul 2009 12:29:19 -0700 From: Eran Hammer-Lahav To: "oauth@ietf.org" Date: Mon, 6 Jul 2009 12:29:21 -0700 Thread-Topic: [OAUTH-WG] [Fwd: I-D Action:draft-ietf-oauth-web-delegation-00.txt] Thread-Index: Acn+bt6bhWgLxz8cTa6b7aKQKDtB6QAAQ0PQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343783398A6F@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4A524E66.40400@stpeter.im> In-Reply-To: <4A524E66.40400@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] [Fwd: I-D Action:draft-ietf-oauth-web-delegation-00.txt] X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 19:29:56 -0000 I would like to aim at a new draft every 2-3 weeks which will include all t= he changes we are able to reach a consensus on. This will allow us to make = progress without having to wait too long between drafts. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Peter Saint-Andre > Sent: Monday, July 06, 2009 12:20 PM > To: oauth@ietf.org > Subject: [OAUTH-WG] [Fwd: I-D Action:draft-ietf-oauth-web-delegation- > 00.txt] >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > The web delegation spec, too... >=20 >=20 > - -------- Original Message -------- > Subject: I-D Action:draft-ietf-oauth-web-delegation-00.txt > Date: Mon, 6 Jul 2009 12:15:01 -0700 (PDT) > From: Internet-Drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > CC: oauth@ietf.org >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Open Authentication Protocol Working > Group of the IETF. >=20 >=20 > Title : The OAuth Protocol: Web Delegation > Author(s) : E. Hammer-Lahav > Filename : draft-ietf-oauth-web-delegation-00.txt > Pages : 18 > Date : 2009-07-06 >=20 > This document specifies the OAuth protocol web delegation method. > OAuth allows clients to access server resources on behalf of another > party (such a different client or an end user). This document > defines a redirection-based user-agent process for end users to > authorize access to clients by substituting their credentials > (typically, a username and password pair) with a different set of > delegation-specific credentials. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-oauth-web-delegation- > 00.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >=20 > iEYEARECAAYFAkpSTmYACgkQNL8k5A2w/vxUEQCgxuN4ikzmjI/uKOr6xcD088hg > qfcAoK9pN3S98stqLDLI3Y32fMaT6pr3 > =3DWJOQ > -----END PGP SIGNATURE----- > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From stpeter@stpeter.im Mon Jul 6 12:37: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 C08133A6D0E for ; Mon, 6 Jul 2009 12:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.149, 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 MWYFhl3ZWGNG for ; Mon, 6 Jul 2009 12:37:37 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id DAB0C3A6A11 for ; Mon, 6 Jul 2009 12:37:37 -0700 (PDT) Received: from dhcp-64-101-72-227.cisco.com (dhcp-64-101-72-227.cisco.com [64.101.72.227]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C876F4007B for ; Mon, 6 Jul 2009 13:19:25 -0600 (MDT) Message-ID: <4A524E3C.8020002@stpeter.im> Date: Mon, 06 Jul 2009 13:19:24 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: "oauth@ietf.org" X-Enigmail-Version: 0.95.7 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [OAUTH-WG] [Fwd: I-D Action:draft-ietf-oauth-authentication-00.txt] X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 19:37:38 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 FYI, Eran has submitted the first version of the authentication spec. Thanks, Eran! Peter - -------- Original Message -------- Subject: I-D Action:draft-ietf-oauth-authentication-00.txt Date: Mon, 6 Jul 2009 09:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: oauth@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Authentication Protocol Working Group of the IETF. Title : The OAuth Protocol: Authentication Author(s) : E. Hammer-Lahav Filename : draft-ietf-oauth-authentication-00.txt Pages : 21 Date : 2009-07-06 This document specifies the OAuth protocol authentication method. OAuth allows clients to access server resources on behalf of another party (such a different client or an end user). This document defines an HTTP authentication method which supports the ability to include two sets of credential with each request, one identifying the client and another identifying the resource owner on whose behalf the request is made. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-authentication-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpSTjwACgkQNL8k5A2w/vwNrwCfZjvaAiiF3Id4RGI1OYZmLqCn x8AAoNCwMKUULRuK8E3OOf5IJEAlOFT3 =GBHg -----END PGP SIGNATURE----- From beaton@google.com Mon Jul 6 13:04:09 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 E87AF28C14F for ; Mon, 6 Jul 2009 13:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6HtaAeJbt5lF for ; Mon, 6 Jul 2009 13:04:09 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id 59DB73A6D2B for ; Mon, 6 Jul 2009 13:04:09 -0700 (PDT) Received: from zps19.corp.google.com (zps19.corp.google.com [172.25.146.19]) by smtp-out.google.com with ESMTP id n66K40Go027521 for ; Mon, 6 Jul 2009 13:04:00 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1246910640; bh=YWftOFjO574TDpX6HKE798p46Qs=; h=DomainKey-Signature:MIME-Version:Date:Message-ID:Subject:From:To: Content-Type:Content-Transfer-Encoding:X-System-Of-Record; b=ShaPw wtHtaqdybJo6TeTI6+7OacTaBkafJz6ahisw/qbQLiXqgomQ9fViUdQHXssSKR/gq9x aAIC/1+7vnBMBg== 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: content-transfer-encoding:x-system-of-record; b=e/Q5fbYE/aQUA/26g7zsqI4B1hqQPrWFzTZdp0YsKmqv21fXPq2J8O5WSN16Ks3Vi 6cR5PuC4ZZLkbOrxuScsA== Received: from qyk5 (qyk5.prod.google.com [10.241.83.133]) by zps19.corp.google.com with ESMTP id n66K2d8q028737 for ; Mon, 6 Jul 2009 13:03:58 -0700 Received: by qyk5 with SMTP id 5so1385752qyk.8 for ; Mon, 06 Jul 2009 13:03:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.70.139 with SMTP id d11mr2675551qcj.51.1246910637857; Mon, 06 Jul 2009 13:03:57 -0700 (PDT) Date: Mon, 6 Jul 2009 13:03:57 -0700 Message-ID: From: Brian Eaton To: oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-System-Of-Record: true Subject: [OAUTH-WG] nonce and timestamp X-BeenThere: oauth@ietf.org X-Mailman-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, 06 Jul 2009 20:04:10 -0000 Can we rewrite the nonce and timestamp section of http://www.ietf.org/internet-drafts/draft-ietf-oauth-authentication-00.txt? Some specific gripes: "The timestamp value MUST be a positive integer and MUST be equal or greater than the timestamp used in previous requests with the same client credentials and token credentials combination." Monotonically increasing clocks are not practical if you are sending requests in parallel. "Server applying such restriction SHOULD provide a way for the client to sync its clock with the server's clock." This is important for desktop clients. We should define a method, in the protocol, for a client to synchronize with the server's clock. I like the method defined in the OAuth problem reporting extension (server returns a special error code along with a range of acceptable timestamps.) "To avoid the need to retain an infinite number of nonce values for future checks, servers MAY choose to restrict the time period after which a request with an old timestamp is rejected." Is there any other reasonable way to implement the protocol? AFAICT, a server that does not implement time stamp checks is broken. Cheers, Brian From root@core3.amsl.com Mon Jul 6 09:45:01 2009 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id AF07E28C2EF; Mon, 6 Jul 2009 09:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090706164501.AF07E28C2EF@core3.amsl.com> Date: Mon, 6 Jul 2009 09:45:01 -0700 (PDT) X-Mailman-Approved-At: Mon, 06 Jul 2009 13:10:17 -0700 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-authentication-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 16:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Authentication Protocol Working Group of the IETF. Title : The OAuth Protocol: Authentication Author(s) : E. Hammer-Lahav Filename : draft-ietf-oauth-authentication-00.txt Pages : 21 Date : 2009-07-06 This document specifies the OAuth protocol authentication method. OAuth allows clients to access server resources on behalf of another party (such a different client or an end user). This document defines an HTTP authentication method which supports the ability to include two sets of credential with each request, one identifying the client and another identifying the resource owner on whose behalf the request is made. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-authentication-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-oauth-authentication-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-06093646.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Jul 6 12:15:01 2009 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 6849828C1A4; Mon, 6 Jul 2009 12:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090706191501.6849828C1A4@core3.amsl.com> Date: Mon, 6 Jul 2009 12:15:01 -0700 (PDT) X-Mailman-Approved-At: Mon, 06 Jul 2009 13:10:17 -0700 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-web-delegation-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 19:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Authentication Protocol Working Group of the IETF. Title : The OAuth Protocol: Web Delegation Author(s) : E. Hammer-Lahav Filename : draft-ietf-oauth-web-delegation-00.txt Pages : 18 Date : 2009-07-06 This document specifies the OAuth protocol web delegation method. OAuth allows clients to access server resources on behalf of another party (such a different client or an end user). This document defines a redirection-based user-agent process for end users to authorize access to clients by substituting their credentials (typically, a username and password pair) with a different set of delegation-specific credentials. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-web-delegation-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-oauth-web-delegation-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-06121118.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Jul 6 12:45:01 2009 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id EB4E628C14F; Mon, 6 Jul 2009 12:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090706194501.EB4E628C14F@core3.amsl.com> Date: Mon, 6 Jul 2009 12:45:01 -0700 (PDT) X-Mailman-Approved-At: Mon, 06 Jul 2009 13:10:17 -0700 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-authentication-01.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, 06 Jul 2009 19:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Authentication Protocol Working Group of the IETF. Title : The OAuth Protocol: Authentication Author(s) : E. Hammer-Lahav Filename : draft-ietf-oauth-authentication-01.txt Pages : 21 Date : 2009-07-06 This document specifies the OAuth protocol authentication method. OAuth allows clients to access server resources on behalf of another party (such a different client or an end user). This document defines an HTTP authentication method which supports the ability to include two sets of credential with each request, one identifying the client and another identifying the resource owner on whose behalf the request is made. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-authentication-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-oauth-authentication-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-06124347.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Jul 6 12:45:02 2009 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id EE1F43A68A0; Mon, 6 Jul 2009 12:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090706194501.EE1F43A68A0@core3.amsl.com> Date: Mon, 6 Jul 2009 12:45:01 -0700 (PDT) X-Mailman-Approved-At: Mon, 06 Jul 2009 13:10:17 -0700 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-web-delegation-01.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, 06 Jul 2009 19:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Authentication Protocol Working Group of the IETF. Title : The OAuth Protocol: Web Delegation Author(s) : E. Hammer-Lahav Filename : draft-ietf-oauth-web-delegation-01.txt Pages : 18 Date : 2009-07-06 This document specifies the OAuth protocol web delegation method. OAuth allows clients to access server resources on behalf of another party (such a different client or an end user). This document defines a redirection-based user-agent process for end users to authorize access to clients by substituting their credentials (typically, a username and password pair) with a different set of delegation-specific credentials. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-web-delegation-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-oauth-web-delegation-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-06124424.I-D@ietf.org> --NextPart-- From trac@tools.ietf.org Mon Jul 6 12:56: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 B00C028C2D1 for ; Mon, 6 Jul 2009 12:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7uzYeFHn+3xy for ; Mon, 6 Jul 2009 12:56:47 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id E31F23A688F for ; Mon, 6 Jul 2009 12:56:47 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1MNuJG-0003kN-4W; Mon, 06 Jul 2009 12:57:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="ascii" Content-Transfer-Encoding: 7bit From: "oauth issue tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: stpeter@stpeter.im X-Trac-Project: oauth Date: Mon, 06 Jul 2009 19:57:06 -0000 X-URL: http://tools.ietf.org/oauth/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/oauth/trac/ticket/1#comment:1 Message-ID: <067.935bbc22112a78f4337e1f1dec47d4a8@tools.ietf.org> References: <058.e713ae6557cb39775b60a8c81073c3ab@tools.ietf.org> X-Trac-Ticket-ID: 1 In-Reply-To: <058.e713ae6557cb39775b60a8c81073c3ab@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: stpeter@stpeter.im, oauth@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Mon, 06 Jul 2009 13:10:16 -0700 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] [oauth] #1: Split core spec into two documents X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 19:56:48 -0000 #1: Split core spec into two documents --------------------------------+------------------------------------------- Reporter: stpeter@stpeter.im | Owner: Eran Hammer-Lahav Type: task | Status: closed Priority: major | Milestone: milestone1 Component: authentication | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by stpeter@stpeter.im): * status: new => closed * resolution: => fixed * component: => authentication -- Ticket URL: oauth From stpeter@stpeter.im Mon Jul 6 13:10: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 205E928C189 for ; Mon, 6 Jul 2009 13:10:24 -0700 (PDT) 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 wD70-jqj3ZxN for ; Mon, 6 Jul 2009 13:10:23 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 094C028C337 for ; Mon, 6 Jul 2009 13:10:23 -0700 (PDT) Received: from dhcp-64-101-72-227.cisco.com (dhcp-64-101-72-227.cisco.com [64.101.72.227]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C1AF140CF3; Mon, 6 Jul 2009 13:58:40 -0600 (MDT) Message-ID: <4A52576F.8070702@stpeter.im> Date: Mon, 06 Jul 2009 13:58:39 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Eran Hammer-Lahav References: <4A524E66.40400@stpeter.im> <90C41DD21FB7C64BB94121FBBC2E72343783398A6F@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343783398A6F@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-Enigmail-Version: 0.95.7 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] [Fwd: I-D Action:draft-ietf-oauth-web-delegation-00.txt] X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 20:10:24 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/6/09 1:29 PM, Eran Hammer-Lahav wrote: > I would like to aim at a new draft every 2-3 weeks which will include > all the changes we are able to reach a consensus on. This will allow > us to make progress without having to wait too long between drafts. Eran (or anyone else), if you would would like to use the issue tracker, we have one available here: http://tools.ietf.org/wg/oauth/ If you need an account, you can create it here: http://tools.ietf.org/newlogin I have closed Issue #1 with the submission of separate Internet-Drafts for authentication and web-delegation. 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 iEYEARECAAYFAkpSV28ACgkQNL8k5A2w/vxedgCg1dyWmcqh/UjD5W6reGncXbFO 7VwAoOmGjglPFckAsXVAoYGYM8UtjVtD =XtHu -----END PGP SIGNATURE----- From stpeter@stpeter.im Mon Jul 6 14:13: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 B8AAE3A6B83 for ; Mon, 6 Jul 2009 14:13:33 -0700 (PDT) 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 TLyfvWG0qh7D for ; Mon, 6 Jul 2009 14:13:32 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id DDFE33A6B97 for ; Mon, 6 Jul 2009 14:13:31 -0700 (PDT) Received: from dhcp-64-101-72-227.cisco.com (dhcp-64-101-72-227.cisco.com [64.101.72.227]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 934384007B; Mon, 6 Jul 2009 14:47:40 -0600 (MDT) Message-ID: <4A5262EB.30802@stpeter.im> Date: Mon, 06 Jul 2009 14:47:39 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Brian Eaton References: In-Reply-To: X-Enigmail-Version: 0.95.7 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] nonce and timestamp X-BeenThere: oauth@ietf.org X-Mailman-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, 06 Jul 2009 21:13:33 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/6/09 2:03 PM, Brian Eaton wrote: > Can we rewrite the nonce and timestamp section of > http://www.ietf.org/internet-drafts/draft-ietf-oauth-authentication-00.txt? > > Some specific gripes: > > "The timestamp value MUST be a positive integer and MUST be equal or > greater than the timestamp used in previous requests with the same > client credentials and token credentials combination." > > Monotonically increasing clocks are not practical if you are sending > requests in parallel. A more general point: monotonically increasing clocks are not practical. For example, an NTP update might result in a clock change backwards. > "Server applying such restriction SHOULD provide a way for the client > to sync its clock with the server's clock." > > This is important for desktop clients. We should define a method, in > the protocol, for a client to synchronize with the server's clock. I > like the method defined in the OAuth problem reporting extension > (server returns a special error code along with a range of acceptable > timestamps.) How does the client know when it needs to synchronize with the server? 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 iEYEARECAAYFAkpSYusACgkQNL8k5A2w/vz+uwCgp5nSUoixwayXcHPXzYQNQuxF ifEAnRKATkAsLoYUMkIhblCmPLm7zDb9 =nYUG -----END PGP SIGNATURE----- From eran@hueniverse.com Mon Jul 6 14:39: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 022D53A67F1 for ; Mon, 6 Jul 2009 14:39:49 -0700 (PDT) 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.076, 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 6kUQGcPm4yha for ; Mon, 6 Jul 2009 14:39:48 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 37FE63A68AC for ; Mon, 6 Jul 2009 14:39:48 -0700 (PDT) Received: (qmail 18246 invoked from network); 6 Jul 2009 19:52:14 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 6 Jul 2009 19:52:14 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Mon, 6 Jul 2009 12:52:14 -0700 From: Eran Hammer-Lahav To: "oauth@ietf.org" Date: Mon, 6 Jul 2009 12:52:18 -0700 Thread-Topic: First WG drafts Thread-Index: Acn+c0SjS714GrOjRqq8mXPwSGgIpA== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343783398A7A@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OAUTH-WG] First WG drafts X-BeenThere: oauth@ietf.org X-Mailman-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, 06 Jul 2009 21:39:49 -0000 (Please note that the current version is -01 for both drafts. It is importa= nt to use the latest version due to change in section numbers.) The OAuth Protocol: Authentication http://www.ietf.org/internet-drafts/draft-ietf-oauth-authentication-01.txt Describes the signature methods and making authenticated requests with two = sets of credentials. The OAuth Protocol: Web Delegation http://www.ietf.org/internet-drafts/draft-ietf-oauth-web-delegation-01.txt Describes how to obtain a set of token credentials by redirecting the resou= rce owner over to the server to obtain authorization. The old draft-hammer-oauth is now obsolete and will not be updated. Please = submit feedback and issues and reference the relevant sections in these two= drafts.=20 The only significant changes in these two drafts from draft-hammer-oauth ar= e: * Break the specification into two parts, one dealing with making authentic= ated requests (previously section 3) and one dealing with obtaining authori= zation via web redirection (previously section 4). * Apply the protocol changes from OAuth Core 1.0 Revision A to bring the we= b delegation draft (authentication was no affected) to the same place the O= Auth Core 1.0 protocol is now. This was done to fix a session fixation atta= ck found earlier this year. EHL From stpeter@stpeter.im Mon Jul 6 15: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 5DDD93A6870 for ; Mon, 6 Jul 2009 15:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.117, 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 f3KnALyoSsaR for ; Mon, 6 Jul 2009 15:15:27 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 4BC133A6819 for ; Mon, 6 Jul 2009 15:15:27 -0700 (PDT) Received: from dhcp-64-101-72-227.cisco.com (dhcp-64-101-72-227.cisco.com [64.101.72.227]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 4D3964007B; Mon, 6 Jul 2009 16:14:45 -0600 (MDT) Message-ID: <4A527754.1000602@stpeter.im> Date: Mon, 06 Jul 2009 16:14:44 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Brian Eaton References: <4A5262EB.30802@stpeter.im> In-Reply-To: X-Enigmail-Version: 0.95.7 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] nonce and timestamp X-BeenThere: oauth@ietf.org X-Mailman-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, 06 Jul 2009 22:15:28 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/6/09 3:52 PM, Brian Eaton wrote: > On Mon, Jul 6, 2009 at 1:47 PM, Peter Saint-Andre wrote: >>> This is important for desktop clients. We should define a method, in >>> the protocol, for a client to synchronize with the server's clock. I >>> like the method defined in the OAuth problem reporting extension >>> (server returns a special error code along with a range of acceptable >>> timestamps.) >> How does the client know when it needs to synchronize with the server? > > The server tells it so. The OAuth problem reporting extension defined > a way to do this that is a tad verbose, but it gets the job done. > > (See http://wiki.oauth.net/ProblemReporting "timestamp_refused"). Aha, I was looking in draft-ietf-oauth-authentication. It strikes me as somewhat sub-optimal to define the error reporting codes related to authentication in a document other than the core specification, but I'll give it more in-depth thought sometime soon... 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 iEYEARECAAYFAkpSd1QACgkQNL8k5A2w/vw+jACgpN+nMglxv2/NlP7qOOHfR8Ud rHQAnRXZNGRglpycONkLFfcj5kjJO6Ln =1a7H -----END PGP SIGNATURE----- From beaton@google.com Mon Jul 6 15:24: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 325EE3A6A19 for ; Mon, 6 Jul 2009 15:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w+Y+PKlbV2rW for ; Mon, 6 Jul 2009 15:24:18 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id CA6193A69B6 for ; Mon, 6 Jul 2009 15:24:17 -0700 (PDT) Received: from zps37.corp.google.com (zps37.corp.google.com [172.25.146.37]) by smtp-out.google.com with ESMTP id n66LqFwg017121 for ; Mon, 6 Jul 2009 22:52:15 +0100 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1246917136; bh=kqGw1xzK2DO+EecIem+zEDK0I3Q=; h=DomainKey-Signature:MIME-Version:In-Reply-To:References:Date: Message-ID:Subject:From:To:Cc:Content-Type: Content-Transfer-Encoding:X-System-Of-Record; b=URuLWTQHuAnOSS35QA 7QOILjrQO7Y1NH+Mmn5PytM+Tf98RUemIeAUT6PYCZO+UGanELE/GvoriMqbMRobujr Q== 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=NWzmby9UKK9PIILqBBL/PsMJAsiL36Pqpt1bzGHLfkKGBtB3JZLU3fKlmTkw8KEGE wPleTopMlc+GQqKXUJteQ== Received: from ewy11 (ewy11.prod.google.com [10.241.103.11]) by zps37.corp.google.com with ESMTP id n66LqCwU016345 for ; Mon, 6 Jul 2009 14:52:12 -0700 Received: by ewy11 with SMTP id 11so1864825ewy.27 for ; Mon, 06 Jul 2009 14:52:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.210.20.6 with SMTP id 6mr5453577ebt.73.1246917131637; Mon, 06 Jul 2009 14:52:11 -0700 (PDT) In-Reply-To: <4A5262EB.30802@stpeter.im> References: <4A5262EB.30802@stpeter.im> Date: Mon, 6 Jul 2009 14:52:11 -0700 Message-ID: From: Brian Eaton To: Peter Saint-Andre 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] nonce and timestamp X-BeenThere: oauth@ietf.org X-Mailman-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, 06 Jul 2009 22:24:19 -0000 On Mon, Jul 6, 2009 at 1:47 PM, Peter Saint-Andre wrote= : >> This is important for desktop clients. =A0We should define a method, in >> the protocol, for a client to synchronize with the server's clock. =A0I >> like the method defined in the OAuth problem reporting extension >> (server returns a special error code along with a range of acceptable >> timestamps.) > > How does the client know when it needs to synchronize with the server? The server tells it so. The OAuth problem reporting extension defined a way to do this that is a tad verbose, but it gets the job done. (See http://wiki.oauth.net/ProblemReporting "timestamp_refused"). Cheers, Brian From stpeter@stpeter.im Tue Jul 7 08:19: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 621A328C4B9 for ; Tue, 7 Jul 2009 08:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 SPqjcLxWYwtQ for ; Tue, 7 Jul 2009 08:19:28 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 133ED3A6B5D for ; Tue, 7 Jul 2009 08:19:25 -0700 (PDT) Received: from dhcp-64-101-72-227.cisco.com (dhcp-64-101-72-227.cisco.com [64.101.72.227]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id CBF924007B for ; Tue, 7 Jul 2009 09:18:37 -0600 (MDT) Message-ID: <4A53674C.60409@stpeter.im> Date: Tue, 07 Jul 2009 09:18:36 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: oauth@ietf.org X-Enigmail-Version: 0.95.7 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [OAUTH-WG] IETF 75 X-BeenThere: oauth@ietf.org X-Mailman-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, 07 Jul 2009 15:19:29 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 As you might have noticed, there is no session for the OAuth WG on the final agenda for IETF 75: https://datatracker.ietf.org/meeting/75/agenda.html Unfortunately, because the working group was approved relatively recently, some of the key participants were unable to make travel arrangements in time for the meeting. Even though we will not hold an official session, perhaps it would be productive to hold a "Bar BOF" or other informal get-together in Stockholm. If you are interested, please post to the list so we can arrange a time and place. 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 iEUEARECAAYFAkpTZ0wACgkQNL8k5A2w/vyaAgCY1XkvAH3kEZ/g2xzCaEvxlydM BACg37aocupEpZ+bO8pDAaVE9VSG6Pk= =GtiC -----END PGP SIGNATURE----- From rbarnes@bbn.com Tue Jul 7 09:02: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 B090228C1D3 for ; Tue, 7 Jul 2009 09:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.095, 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 v9TrFvWVBQYV for ; Tue, 7 Jul 2009 09:02:55 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 93A583A6E66 for ; Tue, 7 Jul 2009 09:02:55 -0700 (PDT) Received: from [192.1.255.197] by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1MOCCN-0000fo-Fw; Tue, 07 Jul 2009 11:03:12 -0400 Message-ID: <4A5371BE.8030202@bbn.com> Date: Tue, 07 Jul 2009 12:03:10 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Peter Saint-Andre References: <4A53674C.60409@stpeter.im> In-Reply-To: <4A53674C.60409@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] IETF 75 X-BeenThere: oauth@ietf.org X-Mailman-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, 07 Jul 2009 16:02:56 -0000 Count me in. Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > As you might have noticed, there is no session for the OAuth WG on the > final agenda for IETF 75: > > https://datatracker.ietf.org/meeting/75/agenda.html > > Unfortunately, because the working group was approved relatively > recently, some of the key participants were unable to make travel > arrangements in time for the meeting. > > Even though we will not hold an official session, perhaps it would be > productive to hold a "Bar BOF" or other informal get-together in > Stockholm. If you are interested, please post to the list so we can > arrange a time and place. > > 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 > > iEUEARECAAYFAkpTZ0wACgkQNL8k5A2w/vyaAgCY1XkvAH3kEZ/g2xzCaEvxlydM > BACg37aocupEpZ+bO8pDAaVE9VSG6Pk= > =GtiC > -----END PGP SIGNATURE----- > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From llynch@civil-tongue.net Tue Jul 7 09:11:09 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 7F85B3A690F for ; Tue, 7 Jul 2009 09:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yMUOMOfJAjSi for ; Tue, 7 Jul 2009 09:11:08 -0700 (PDT) Received: from hiroshima.bogus.com (hiroshima.bogus.com [IPv6:2001:418:1::80]) by core3.amsl.com (Postfix) with ESMTP id 50EF83A6ABE for ; Tue, 7 Jul 2009 09:11:08 -0700 (PDT) Received: from hiroshima.bogus.com (localhost [127.0.0.1]) by hiroshima.bogus.com (8.14.3/8.14.3) with ESMTP id n67GBBCb009469; Tue, 7 Jul 2009 09:11:12 -0700 (PDT) (envelope-from llynch@civil-tongue.net) Received: from localhost (llynch@localhost) by hiroshima.bogus.com (8.14.3/8.14.3/Submit) with ESMTP id n67GBBIK009466; Tue, 7 Jul 2009 09:11:11 -0700 (PDT) (envelope-from llynch@civil-tongue.net) Date: Tue, 7 Jul 2009 09:11:11 -0700 (PDT) From: Lucy Lynch X-X-Sender: llynch@hiroshima.bogus.com To: Richard Barnes In-Reply-To: <4A5371BE.8030202@bbn.com> Message-ID: References: <4A53674C.60409@stpeter.im> <4A5371BE.8030202@bbn.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] IETF 75 X-BeenThere: oauth@ietf.org X-Mailman-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, 07 Jul 2009 16:11:09 -0000 On Tue, 7 Jul 2009, Richard Barnes wrote: > Count me in. +1, and you may want to ping the Open Grid Protocol (OGPX) folk. They've scheduled a BOF and include as one of their work items: - Security (use of TLS and OAuth for origin authentication) - Lucy > Peter Saint-Andre wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> >> >> As you might have noticed, there is no session for the OAuth WG on the >> final agenda for IETF 75: >> >> https://datatracker.ietf.org/meeting/75/agenda.html >> >> Unfortunately, because the working group was approved relatively >> recently, some of the key participants were unable to make travel >> arrangements in time for the meeting. >> >> Even though we will not hold an official session, perhaps it would be >> productive to hold a "Bar BOF" or other informal get-together in >> Stockholm. If you are interested, please post to the list so we can >> arrange a time and place. >> >> 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 >> >> iEUEARECAAYFAkpTZ0wACgkQNL8k5A2w/vyaAgCY1XkvAH3kEZ/g2xzCaEvxlydM >> BACg37aocupEpZ+bO8pDAaVE9VSG6Pk= >> =GtiC >> -----END PGP SIGNATURE----- >> _______________________________________________ >> OAuth mailing 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 llynch@civil-tongue.net Tue Jul 7 09:15: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 0BFA63A67A8 for ; Tue, 7 Jul 2009 09:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 UgGHliol+kPd for ; Tue, 7 Jul 2009 09:15:40 -0700 (PDT) Received: from hiroshima.bogus.com (hiroshima.bogus.com [IPv6:2001:418:1::80]) by core3.amsl.com (Postfix) with ESMTP id DA97128C4EC for ; Tue, 7 Jul 2009 09:15:39 -0700 (PDT) Received: from hiroshima.bogus.com (localhost [127.0.0.1]) by hiroshima.bogus.com (8.14.3/8.14.3) with ESMTP id n67GG3N0009820 for ; Tue, 7 Jul 2009 09:16:03 -0700 (PDT) (envelope-from llynch@civil-tongue.net) Received: from localhost (llynch@localhost) by hiroshima.bogus.com (8.14.3/8.14.3/Submit) with ESMTP id n67GG33k009817 for ; Tue, 7 Jul 2009 09:16:03 -0700 (PDT) (envelope-from llynch@civil-tongue.net) Date: Tue, 7 Jul 2009 09:16:03 -0700 (PDT) From: Lucy Lynch X-X-Sender: llynch@hiroshima.bogus.com To: oauth@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: [OAUTH-WG] OAuth featured in new IETF Journal X-BeenThere: oauth@ietf.org X-Mailman-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, 07 Jul 2009 16:15:41 -0000 All - See: http://ietfjournal.isoc.org "The IETF Journal meets with OAuth experts Hannes Tschofenig, Blaine Cook, and Eran Hammer-Lahav to discuss the decision to bring OAuth to the IETF..." http://www.isoc.org/tools/blogs/ietfjournal/?p=871#more-871 This issue will be distributed at the Stockholm IETF. - Lucy From cs@comlounge.net Tue Jul 7 09:16: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 6BE6728C4C4 for ; Tue, 7 Jul 2009 09:16:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.001 X-Spam-Level: *** X-Spam-Status: No, score=3.001 tagged_above=-999 required=5 tests=[AWL=5.000, BAYES_00=-2.599, J_CHICKENPOX_36=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KnDld9MfYPLa for ; Tue, 7 Jul 2009 09:16:29 -0700 (PDT) Received: from post.comlounge.net (post.comlounge.net [85.214.59.142]) by core3.amsl.com (Postfix) with ESMTP id 20CFB3A6E9C for ; Tue, 7 Jul 2009 09:16:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by post.comlounge.net (Postfix) with ESMTP id AB2AC1CE0341; Tue, 7 Jul 2009 18:16:13 +0200 (CEST) Received: from post.comlounge.net ([127.0.0.1]) by localhost (h1346004.stratoserver.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZBkXTRU7yzt5; Tue, 7 Jul 2009 18:16:12 +0200 (CEST) Received: from [192.168.178.34] (p5B396292.dip.t-dialin.net [91.57.98.146]) by post.comlounge.net (Postfix) with ESMTP id 8DCA81CE0340; Tue, 7 Jul 2009 18:16:12 +0200 (CEST) Message-ID: <4A5374CA.7050006@comlounge.net> Date: Tue, 07 Jul 2009 18:16:10 +0200 From: Christian Scholz User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Lucy Lynch References: <4A53674C.60409@stpeter.im> <4A5371BE.8030202@bbn.com> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] IETF 75 X-BeenThere: oauth@ietf.org X-Mailman-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, 07 Jul 2009 16:16:30 -0000 Lucy Lynch wrote: > On Tue, 7 Jul 2009, Richard Barnes wrote: > >> Count me in. > > +1, and you may want to ping the Open Grid Protocol (OGPX) folk. > > They've scheduled a BOF and include as one of their work items: > - Security (use of TLS and OAuth for origin authentication Right, and convince them to use OAuth also after the initial authentication step instead of their capabilities system ;-) -- Christian  > > - Lucy > >> Peter Saint-Andre wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> >>> >>> As you might have noticed, there is no session for the OAuth WG on the >>> final agenda for IETF 75: >>> >>> https://datatracker.ietf.org/meeting/75/agenda.html >>> >>> Unfortunately, because the working group was approved relatively >>> recently, some of the key participants were unable to make travel >>> arrangements in time for the meeting. >>> >>> Even though we will not hold an official session, perhaps it would be >>> productive to hold a "Bar BOF" or other informal get-together in >>> Stockholm. If you are interested, please post to the list so we can >>> arrange a time and place. >>> >>> 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 >>> >>> iEUEARECAAYFAkpTZ0wACgkQNL8k5A2w/vyaAgCY1XkvAH3kEZ/g2xzCaEvxlydM >>> BACg37aocupEpZ+bO8pDAaVE9VSG6Pk= >>> =GtiC >>> -----END PGP SIGNATURE----- >>> _______________________________________________ >>> OAuth mailing 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 -- Christian Scholz Homepage: http://comlounge.net COM.lounge GmbH blog: http://mrtopf.de/blog Hanbrucher Str. 33 Skype: HerrTopf 52064 Aachen Video Blog: http://comlounge.tv Tel: +49 241 400 730 0 E-Mail cs@comlounge.net Fax: +49 241 979 00 850 IRC: MrTopf, Tao_T neuer Podcast: Der OpenWeb-Podcast (http://openwebpodcast.de) new podcast: Data Without Borders (http://datawithoutborders.net) From GFFletch@aol.com Tue Jul 7 09:54: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 25D973A6961 for ; Tue, 7 Jul 2009 09:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qeg2tcMfHUwz for ; Tue, 7 Jul 2009 09:54:53 -0700 (PDT) Received: from imr-ma01.mx.aol.com (imr-ma01.mx.aol.com [64.12.206.39]) by core3.amsl.com (Postfix) with ESMTP id EC1663A6955 for ; Tue, 7 Jul 2009 09:54:52 -0700 (PDT) Received: from imo-ma04.mx.aol.com (imo-ma04.mx.aol.com [64.12.78.139]) by imr-ma01.mx.aol.com (8.14.1/8.14.1) with ESMTP id n67GsobT026193; Tue, 7 Jul 2009 12:54:51 -0400 Received: from GFFletch@aol.com by imo-ma04.mx.aol.com (mail_out_v40_r1.5.) id r.bef.493ea836 (37692); Tue, 7 Jul 2009 12:54:46 -0400 (EDT) Received: from palantir.local ([10.172.0.124]) by cia-mb08.mx.aol.com (v124.15) with ESMTP id MAILCIAMB088-933c4a537dd51d3; Tue, 07 Jul 2009 12:54:45 -0400 Message-ID: <4A537DD5.90005@aol.com> Date: Tue, 07 Jul 2009 12:54:45 -0400 From: George Fletcher Organization: AOL LLC User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Peter Saint-Andre References: <4A5262EB.30802@stpeter.im> <4A527754.1000602@stpeter.im> In-Reply-To: <4A527754.1000602@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AOL-IP: 10.172.0.124 X-Mailer: Unknown (No Version) Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] nonce and timestamp X-BeenThere: oauth@ietf.org X-Mailman-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, 07 Jul 2009 16:54:54 -0000 +1 to pulling the error-reporting extension into the core spec Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > On 7/6/09 3:52 PM, Brian Eaton wrote: > >> On Mon, Jul 6, 2009 at 1:47 PM, Peter Saint-Andre wrote: >> >>>> This is important for desktop clients. We should define a method, in >>>> the protocol, for a client to synchronize with the server's clock. I >>>> like the method defined in the OAuth problem reporting extension >>>> (server returns a special error code along with a range of acceptable >>>> timestamps.) >>>> >>> How does the client know when it needs to synchronize with the server? >>> >> The server tells it so. The OAuth problem reporting extension defined >> a way to do this that is a tad verbose, but it gets the job done. >> >> (See http://wiki.oauth.net/ProblemReporting "timestamp_refused"). >> > > Aha, I was looking in draft-ietf-oauth-authentication. It strikes me as > somewhat sub-optimal to define the error reporting codes related to > authentication in a document other than the core specification, but I'll > give it more in-depth thought sometime soon... > > 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 > > iEYEARECAAYFAkpSd1QACgkQNL8k5A2w/vw+jACgpN+nMglxv2/NlP7qOOHfR8Ud > rHQAnRXZNGRglpycONkLFfcj5kjJO6Ln > =1a7H > -----END PGP SIGNATURE----- > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From leifj@it.su.se Tue Jul 7 11:16: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 94A1E28C505 for ; Tue, 7 Jul 2009 11:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=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 xVkIKrBTKgIj for ; Tue, 7 Jul 2009 11:16:05 -0700 (PDT) Received: from smtp.su.se (smtp3.su.se [130.237.93.228]) by core3.amsl.com (Postfix) with ESMTP id 938C128C503 for ; Tue, 7 Jul 2009 11:16:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.su.se (Postfix) with ESMTP id 28AD43C464; Tue, 7 Jul 2009 20:14:18 +0200 (CEST) Received: from smtp.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 14611-01-42; Tue, 7 Jul 2009 20:14:17 +0200 (CEST) Received: from k2.mnt.se (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.su.se (Postfix) with ESMTP id 1B93B3C460; Tue, 7 Jul 2009 20:14:17 +0200 (CEST) From: Leif Johansson Organization: Stockholm university To: oauth@ietf.org Date: Tue, 7 Jul 2009 20:14:15 +0200 User-Agent: KMail/1.11.2 (Linux/2.6.28-11-generic; KDE/4.2.2; i686; ; ) References: <4A53674C.60409@stpeter.im> <4A5374CA.7050006@comlounge.net> In-Reply-To: <4A5374CA.7050006@comlounge.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1591072.zWxqekRKxC"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200907072014.16124.leifj@it.su.se> X-Virus-Scanned: by amavisd-new at smtp.su.se Subject: Re: [OAUTH-WG] IETF 75 X-BeenThere: oauth@ietf.org X-Mailman-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, 07 Jul 2009 18:16:06 -0000 --nextPart1591072.zWxqekRKxC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 07 July 2009 18.16.10 Christian Scholz wrote: > Lucy Lynch wrote: > > On Tue, 7 Jul 2009, Richard Barnes wrote: > >> Count me in. > > > > +1, and you may want to ping the Open Grid Protocol (OGPX) folk. > > > > They've scheduled a BOF and include as one of their work items: > > - Security (use of TLS and OAuth for origin authentication > > Right, and convince them to use OAuth also after the initial > authentication step instead of their capabilities system ;-) > +1=20 I wish oauth could have been around a couple of years ago when they were still digging tunnels through Switzerland. Now barring=20 another magnet exploding, what passes for security architecture in grid space isn't going anywhere. Cheers Leif --nextPart1591072.zWxqekRKxC Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkpTkHgACgkQ8Jx8FtbMZndR6wCfd8NfYOlJtS7Rw87HNmPuyetv 01IAnRXT9g9RpWUOyNAOjrS9uYtnxYSh =qhuv -----END PGP SIGNATURE----- --nextPart1591072.zWxqekRKxC-- From barryleiba.mailing.lists@gmail.com Tue Jul 7 11:17: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 148CA28C50C for ; Tue, 7 Jul 2009 11:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.936 X-Spam-Level: X-Spam-Status: No, score=-1.936 tagged_above=-999 required=5 tests=[AWL=0.041, 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 0UK-ImD8BR-E for ; Tue, 7 Jul 2009 11:17:03 -0700 (PDT) Received: from mail-bw0-f225.google.com (mail-bw0-f225.google.com [209.85.218.225]) by core3.amsl.com (Postfix) with ESMTP id 4027C3A6C79 for ; Tue, 7 Jul 2009 11:17:01 -0700 (PDT) Received: by bwz25 with SMTP id 25so2251552bwz.37 for ; Tue, 07 Jul 2009 11:16:02 -0700 (PDT) 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=QHZLHs3YSzBUMv95iQ7bn86kpDvfAfKyg8ZB+coCloA=; b=oKfcog6kbzZAP4B3a8dBFGBUecRvspG5c5pjMxpedzRcflHvaQBRjRlP5ImgPZVXsD mAbAfIsmiaQOeMxYkS8kSET9a0gfjV0sSQagDkbeNPrFr7eujmru/bU5QPrqkLmQ4Ws4 mHrPs2x2tDIN80V5btufUBr0cgbDW17miB1WE= 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=Q8kI9CYemdmDBm/dS2Mvb0/Ogb7KWZYAq0qB5NZlNlkSu775Y6XrKK75LSeByaJeGj Uj4TUZtne5AxDWhhPc9EqWTy2Iy+u79Lb4ASWBWrwuhpe7TY4WTUg8Ki1mQXFkvFqtFn YVv3LWvQy5BhlRMZoxibi2csPAjJGLXvlxDZE= MIME-Version: 1.0 Sender: barryleiba.mailing.lists@gmail.com Received: by 10.239.149.206 with SMTP id k14mr487116hbb.115.1246990562180; Tue, 07 Jul 2009 11:16:02 -0700 (PDT) In-Reply-To: <4A53674C.60409@stpeter.im> References: <4A53674C.60409@stpeter.im> Date: Tue, 7 Jul 2009 14:16:02 -0400 X-Google-Sender-Auth: b2241ffe961b1c4c Message-ID: <6c9fcc2a0907071116i36b91e14u92fba0e7c9e5f54e@mail.gmail.com> From: Barry Leiba To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] IETF 75 X-BeenThere: oauth@ietf.org X-Mailman-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, 07 Jul 2009 18:17:04 -0000 > Even though we will not hold an official session, perhaps it would be > productive to hold a "Bar BOF" or other informal get-together in > Stockholm. If you are interested, please post to the list so we can > arrange a time and place. I'd like to attend. Time's always tight, though, so it might be a challenge to find something that works for most. Important Swedish word: =F6l -- Barry Leiba (who will be chairing the OGPX BOF, by the way) From stpeter@stpeter.im Tue Jul 7 13:43: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 920843A696D for ; Tue, 7 Jul 2009 13:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.121, 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 Pq7fyqQBtrh0 for ; Tue, 7 Jul 2009 13:43:37 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 3E38D3A682B for ; Tue, 7 Jul 2009 13:43:37 -0700 (PDT) Received: from dhcp-64-101-72-227.cisco.com (dhcp-64-101-72-227.cisco.com [64.101.72.227]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 77ACE4007B; Tue, 7 Jul 2009 14:43:24 -0600 (MDT) Message-ID: <4A53B36B.5000605@stpeter.im> Date: Tue, 07 Jul 2009 14:43:23 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Richard Barnes References: <4A52491D.3050507@bbn.com> In-Reply-To: <4A52491D.3050507@bbn.com> X-Enigmail-Version: 0.95.7 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] [Fwd: New Version Notification for draft-barnes-oauth-model-00] X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 20:43:38 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/6/09 12:57 PM, Richard Barnes wrote: > Hi all, > > As promised at IETF 74, Matt and I spent some time thinking about the > security model underlying OAuth, abstracted from the specific HTTP > mechanics. This draft attempts to explain how the OAuth authorization > model works, what security features it provides, and how. Hopefully > this will help make the protocol documents more comprehensible, and > maybe even provide a framework to extend OAuth to other protocols than > HTTP. > > Until it gets mirrored over to the tools site, you can find the draft here: > > > Questions, comments, and all other feedback are welcome. IMHO this document provides a very clear introduction to the concepts behind OAuth. It has quite a bit of overlap with the web-delegation I-D; do you have plans to merge the two or at least cross-pollinate? A few relatively minor comments... 1. The document is not always internally consistent regarding terminology (e.g., it sometimes uses "Consumer" instead of "Client"). Furthermore, consistency across OAuth documents would be helpful for implementers (e.g., the pages at http://oauth.net/ use the terms "Consumer", "Service Provider", and "User"). I do like the use of the terms "Server" and "Client" because then the term "Resource Owner" can be seen as an addition to the standard client-server model, as pointed out in the spec. 2. I found the definitions of "request token", "verification token", and "access token" to be unclear, specifically the use of "is associated" as definitional (perhaps it would help to describe the purpose of each token and the data that they contain, not merely the entities that are "associated" via the tokens). 3. It's not clear to me what this means under Section 3.1 ("Trust Assumptions"): We do not assume that any entity acting as an RO is the genuine RO for the protected resources. This assurance will need to be provided by the authorization system. Do you mean one of the following, or something different? (3a) We cannot know if the principal (human) controlling an RO-agent is the correct principal. (3b) The Server determines if the purported RO is the genuine RO via standard authentication mechanisms. If (3b) then I think we want to use the term "authentication" here, not "authorization". 4. Under Section 4.1 ("General Requirements and Assumptions"), I find this text strange: The Server MUST be able to authenticate both to the Client and the RO, but may use different identities for each. Why would the Server need to use different identities? Perhaps there is a use case for that, but it might be helpful to spell it out. 5. Under Section 4.3.2 ("Verification Token Issuance"), it appears that authentication of the Resource Owner by the Server occurs before the channel between those two parties is protected with regard to integrity and confidentiality. It might be helpful to spell out the reasons for this order. 6. Under Section 5.1 ("Protection from Outside Interference"), there is a simple typo "The Client knows that the Client is the genuine RO..." (change second instance of "Client" to "RO"). That's it for now. Thanks for working on this document. 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 iEYEARECAAYFAkpTs2sACgkQNL8k5A2w/vzSGACgkEL6Ou6eD0WkJWydAKu4HS0P E1MAnAjLFxkco4lJvCNjuWlzkTsFUfUk =vH1P -----END PGP SIGNATURE----- From zeltsan@alcatel-lucent.com Tue Jul 7 14:07: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 9F8E43A682B for ; Tue, 7 Jul 2009 14:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.117 X-Spam-Level: X-Spam-Status: No, score=-1.117 tagged_above=-999 required=5 tests=[AWL=-0.594, BAYES_00=-2.599, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RAPTiv3D2oIb for ; Tue, 7 Jul 2009 14:07:29 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id AD25C3A67E4 for ; Tue, 7 Jul 2009 14:07:29 -0700 (PDT) Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id n67L6U44009593; Tue, 7 Jul 2009 16:06:30 -0500 (CDT) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by ihrh1.emsr.lucent.com (8.13.8/emsr) with ESMTP id n67L6Uxg001188; Tue, 7 Jul 2009 16:06:30 -0500 (CDT) Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.124]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Tue, 7 Jul 2009 16:06:30 -0500 From: "Zeltsan, Zachary (Zachary)" To: Peter Saint-Andre , "oauth@ietf.org" Date: Tue, 7 Jul 2009 16:06:28 -0500 Thread-Topic: [OAUTH-WG] IETF 75 Thread-Index: Acn/FoIAeqABdHZ9Ry6VR7R67VSEKwAL5lKg Message-ID: <5710F82C0E73B04FA559560098BF95B124EC239D3B@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <4A53674C.60409@stpeter.im> In-Reply-To: <4A53674C.60409@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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Subject: Re: [OAUTH-WG] IETF 75 X-BeenThere: oauth@ietf.org X-Mailman-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, 07 Jul 2009 21:07:30 -0000 I am interested. Zachary Zeltsan=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]=20 > On Behalf Of Peter Saint-Andre > Sent: Tuesday, July 07, 2009 11:19 AM > To: oauth@ietf.org > Subject: [OAUTH-WG] IETF 75 >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > >=20 > As you might have noticed, there is no session for the OAuth=20 > WG on the final agenda for IETF 75: >=20 > https://datatracker.ietf.org/meeting/75/agenda.html >=20 > Unfortunately, because the working group was approved=20 > relatively recently, some of the key participants were unable=20 > to make travel arrangements in time for the meeting. >=20 > Even though we will not hold an official session, perhaps it=20 > would be productive to hold a "Bar BOF" or other informal=20 > get-together in Stockholm. If you are interested, please post=20 > to the list so we can arrange a time and place. >=20 > Thanks! >=20 > Peter >=20 > - -- > Peter Saint-Andre > https://stpeter.im/ >=20 >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >=20 > iEUEARECAAYFAkpTZ0wACgkQNL8k5A2w/vyaAgCY1XkvAH3kEZ/g2xzCaEvxlydM > BACg37aocupEpZ+bO8pDAaVE9VSG6Pk=3D > =3DGtiC > -----END PGP SIGNATURE----- > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > = From rbarnes@bbn.com Wed Jul 8 14:20: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 C09973A6AE0 for ; Wed, 8 Jul 2009 14:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 HcLJydnUfTuv for ; Wed, 8 Jul 2009 14:20:14 -0700 (PDT) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id E9F373A6C0E for ; Wed, 8 Jul 2009 14:20:13 -0700 (PDT) Received: from [192.1.255.197] by mx3.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1MOeZC-0002DX-Ce; Wed, 08 Jul 2009 17:20:39 -0400 Message-ID: <4A550DA5.8080209@bbn.com> Date: Wed, 08 Jul 2009 17:20:37 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Peter Saint-Andre References: <4A52491D.3050507@bbn.com> <4A53B36B.5000605@stpeter.im> In-Reply-To: <4A53B36B.5000605@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org" Subject: [OAUTH-WG] OAuth Security Model (was: Re: [Fwd: New Version Notification for draft-barnes-oauth-model-00]) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 21:20:15 -0000 Hey Peter, Thanks for your comments. I've submitted -01 with changes that I hope will address most of them: (Thank goodness for the later revised draft deadline!) Responses to your comments inline below. --Richard > IMHO this document provides a very clear introduction to the concepts > behind OAuth. It has quite a bit of overlap with the web-delegation I-D; > do you have plans to merge the two or at least cross-pollinate? Not concretely, but I agree that it makes sense to align the two. Separate drafts probably still makes sense, but maybe this draft can relieve -web-delegation of the need to explain big-picture stuff, allowing it to focus more on how information gets carried between parties and how authentication is done. > 1. The document is not always internally consistent regarding > terminology (e.g., it sometimes uses "Consumer" instead of "Client"). > Furthermore, consistency across OAuth documents would be helpful for > implementers (e.g., the pages at http://oauth.net/ use the terms > "Consumer", "Service Provider", and "User"). I do like the use of the > terms "Server" and "Client" because then the term "Resource Owner" can > be seen as an addition to the standard client-server model, as pointed > out in the spec. Geez, there was *one* "Consumer" that slipped in! I deleted it, and replaced with Client. I'm really agnostic as to the terminology; I just went with "Client/Server/RO" because that was what draft-hammer-oauth used. > 2. I found the definitions of "request token", "verification token", and > "access token" to be unclear, specifically the use of "is associated" as > definitional (perhaps it would help to describe the purpose of each > token and the data that they contain, not merely the entities that are > "associated" via the tokens). I changed the definitions in -01 to try to clarify (1) that the Server issues them as temporary identifiers for things (Clients, authorizations), and (2) what the tokens mean when they come back to the Server ("give me a verfication token for this Client", "I've been granted this authorization"). Let me know whether the current text is better. > 3. It's not clear to me what this means under Section 3.1 ("Trust > Assumptions"): ... > If (3b) then I think we want to use the term "authentication" here, not > "authorization". Replaced this sentence with one that is hopefully a little clearer: " We do not assume that any entity acting as an RO is the genuine RO for the protected resources. It will be necessary for the OAuth system to provide the Client and Server assurance that the RO in the process is the genuine owner of the resources in question. (The Server can verify this directly, with standard authentication mechanisms; the Client will rely on an authenticated assertion by the Server.) " > 4. Under Section 4.1 ("General Requirements and Assumptions"), I find > this text strange: > > The Server MUST be able to authenticate both to the Client and the > RO, but may use different identities for each. > > Why would the Server need to use different identities? Perhaps there is > a use case for that, but it might be helpful to spell it out. Don't have a use case, just wanted to be clear that the "same identity" requirement for the other two entities doesn't apply to the Server (primarily since the server is authoritative -- if someone impersonates it, the process just fails) Changed to: " The Server MUST be able to authenticate both to the Client and the RO, but it is not required to use the same identity for both. " > 5. Under Section 4.3.2 ("Verification Token Issuance"), it appears that > authentication of the Resource Owner by the Server occurs before the > channel between those two parties is protected with regard to integrity > and confidentiality. It might be helpful to spell out the reasons for > this order. The reason for this is that there are different requirements for the *request* for a verification token and the *response* containing the token: The request just needs RO authentication, while the response also needs confidentiality protection. Added a para to clarify: " Some might note that there is an asymmetry to the security requirements for the two halves of this transaction: The request for a verification token is only authenticated, while the response also needs to be confidentiality- and integrity-protected. This is because the injection of a false request token can only cause the process to fail (since the Client identity provided by the server will be wrong), while leakage of the verification token can cause used to grant an unintended authorization. For simplicity, it is RECOMMENDED that the same channel (with full protections) be used for the request and the response. " > 6. Under Section 5.1 ("Protection from Outside Interference"), there is > a simple typo "The Client knows that the Client is the genuine RO..." > (change second instance of "Client" to "RO"). Fixed. From stpeter@stpeter.im Wed Jul 8 16:05: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 A751D28C105 for ; Wed, 8 Jul 2009 16:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.117, 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 eHCWgZsCka4R for ; Wed, 8 Jul 2009 16:05:21 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 96B993A68CD for ; Wed, 8 Jul 2009 16:05:21 -0700 (PDT) Received: from dhcp-64-101-72-227.cisco.com (dhcp-64-101-72-227.cisco.com [64.101.72.227]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6732E40CF3; Wed, 8 Jul 2009 17:05:48 -0600 (MDT) Message-ID: <4A55264B.4040209@stpeter.im> Date: Wed, 08 Jul 2009 17:05:47 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Richard Barnes References: <4A52491D.3050507@bbn.com> <4A53B36B.5000605@stpeter.im> <4A550DA5.8080209@bbn.com> In-Reply-To: <4A550DA5.8080209@bbn.com> X-Enigmail-Version: 0.95.7 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] OAuth Security Model X-BeenThere: oauth@ietf.org X-Mailman-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, 08 Jul 2009 23:05:22 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thanks, Richard! A few comments below. On 7/8/09 3:20 PM, Richard Barnes wrote: >> IMHO this document provides a very clear introduction to the concepts >> behind OAuth. It has quite a bit of overlap with the web-delegation I-D; >> do you have plans to merge the two or at least cross-pollinate? > > Not concretely, but I agree that it makes sense to align the two. > Separate drafts probably still makes sense, but maybe this draft can > relieve -web-delegation of the need to explain big-picture stuff, > allowing it to focus more on how information gets carried between > parties and how authentication is done. That makes sense. >> 2. I found the definitions of "request token", "verification token", and >> "access token" to be unclear, specifically the use of "is associated" as >> definitional (perhaps it would help to describe the purpose of each >> token and the data that they contain, not merely the entities that are >> "associated" via the tokens). > > I changed the definitions in -01 to try to clarify (1) that the Server > issues them as temporary identifiers for things (Clients, > authorizations), and (2) what the tokens mean when they come back to the > Server ("give me a verfication token for this Client", "I've been > granted this authorization"). Let me know whether the current text is > better. Will do. >> 4. Under Section 4.1 ("General Requirements and Assumptions"), I find >> this text strange: >> >> The Server MUST be able to authenticate both to the Client and the >> RO, but may use different identities for each. >> >> Why would the Server need to use different identities? Perhaps there is >> a use case for that, but it might be helpful to spell it out. > > Don't have a use case, just wanted to be clear that the "same identity" > requirement for the other two entities doesn't apply to the Server > (primarily since the server is authoritative -- if someone impersonates > it, the process just fails) Changed to: > " > The Server MUST be able to authenticate both to the Client and the RO, > but it is not required to use the same identity for both. > " The vague thought in my head was that if the Client and RO want to compare notes about the Server, it would be helpful for the Server to appear the same to the other parties. >> 5. Under Section 4.3.2 ("Verification Token Issuance"), it appears that >> authentication of the Resource Owner by the Server occurs before the >> channel between those two parties is protected with regard to integrity >> and confidentiality. It might be helpful to spell out the reasons for >> this order. > > The reason for this is that there are different requirements for the > *request* for a verification token and the *response* containing the > token: The request just needs RO authentication, while the response also > needs confidentiality protection. Added a para to clarify: > " > Some might note that there is an asymmetry to the security > requirements for the two halves of this transaction: The request for > a verification token is only authenticated, while the response also > needs to be confidentiality- and integrity-protected. This is > because the injection of a false request token can only cause the > process to fail (since the Client identity provided by the server > will be wrong), while leakage of the verification token can cause > used to grant an unintended authorization. For simplicity, it is > RECOMMENDED that the same channel (with full protections) be used for > the request and the response. > " My concern was that there might be an authentication downgrade attack (e.g., downgrade DIGEST to PLAIN) if the channel is not protected before authentication occurs, but I did not give it a great deal of thought before formulating my question so I might be off-base here. I'll ponder it further before raising the issue again. :) 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 iEYEARECAAYFAkpVJksACgkQNL8k5A2w/vy1VwCgidu7leEgKEbsHCR/RvjKvM9m iHwAnRVE+ZwiXG4fqUj4X9kBUVXxz5BP =SdkZ -----END PGP SIGNATURE----- From stpeter@stpeter.im Fri Jul 17 14:08: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 32BC93A69BA for ; Fri, 17 Jul 2009 14:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.497 X-Spam-Level: X-Spam-Status: No, score=-2.497 tagged_above=-999 required=5 tests=[AWL=0.102, 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 wYfRCDOX5zVr for ; Fri, 17 Jul 2009 14:08:16 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id F0A833A6EE0 for ; Fri, 17 Jul 2009 14:07:47 -0700 (PDT) Received: from dhcp-64-101-72-227.cisco.com (dhcp-64-101-72-227.cisco.com [64.101.72.227]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9A9E84007B for ; Fri, 17 Jul 2009 15:08:19 -0600 (MDT) Message-ID: <4A60E842.2070003@stpeter.im> Date: Fri, 17 Jul 2009 15:08:18 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: oauth@ietf.org References: <4A53674C.60409@stpeter.im> <6c9fcc2a0907071116i36b91e14u92fba0e7c9e5f54e@mail.gmail.com> In-Reply-To: <6c9fcc2a0907071116i36b91e14u92fba0e7c9e5f54e@mail.gmail.com> X-Enigmail-Version: 0.95.7 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] IETF 75 X-BeenThere: oauth@ietf.org X-Mailman-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, 17 Jul 2009 21:08:17 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/7/09 12:16 PM, Barry Leiba wrote: >> Even though we will not hold an official session, perhaps it would be >> productive to hold a "Bar BOF" or other informal get-together in >> Stockholm. If you are interested, please post to the list so we can >> arrange a time and place. > > I'd like to attend. > Time's always tight, though, so it might be a challenge to find > something that works for most. How about a breakfast BoF instead of a bar BoF? The AppArea meeting is Monday morning, thus I suggest Tuesday or Wednesday morning so that we can announce it at the AppArea meeting. 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 iEYEARECAAYFAkpg6EIACgkQNL8k5A2w/vw/IwCgzvldmIrJq9GJiJIPcq+DaFqy sBYAn3Lv8b8ZAjgppFYXcPoovsJIn8kU =7tFE -----END PGP SIGNATURE----- From rbarnes@bbn.com Fri Jul 17 14:13: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 66BB03A68EC for ; Fri, 17 Jul 2009 14:13:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, 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 NCD1G1TrlCFW for ; Fri, 17 Jul 2009 14:13:53 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 3964E3A69D5 for ; Fri, 17 Jul 2009 14:13:53 -0700 (PDT) Received: from [192.1.255.201] (helo=col-rbarnes-l1.local) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1MRtp3-00044u-FF; Fri, 17 Jul 2009 16:14:25 -0400 Message-ID: <4A60E9B2.8070906@bbn.com> Date: Fri, 17 Jul 2009 17:14:26 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Peter Saint-Andre References: <4A53674C.60409@stpeter.im> <6c9fcc2a0907071116i36b91e14u92fba0e7c9e5f54e@mail.gmail.com> <4A60E842.2070003@stpeter.im> In-Reply-To: <4A60E842.2070003@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] IETF 75 X-BeenThere: oauth@ietf.org X-Mailman-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, 17 Jul 2009 21:13:54 -0000 Breakfast is fine with me in concept, but I'm a little worried about running into the morning sessions on Tue/Wed. Those sessions have XMPP and ECRIT, respectively, which both might have some overlap with the OAuth crowd. --Richard Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 7/7/09 12:16 PM, Barry Leiba wrote: >>> Even though we will not hold an official session, perhaps it would be >>> productive to hold a "Bar BOF" or other informal get-together in >>> Stockholm. If you are interested, please post to the list so we can >>> arrange a time and place. >> I'd like to attend. >> Time's always tight, though, so it might be a challenge to find >> something that works for most. > > How about a breakfast BoF instead of a bar BoF? The AppArea meeting is > Monday morning, thus I suggest Tuesday or Wednesday morning so that we > can announce it at the AppArea meeting. > > 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 > > iEYEARECAAYFAkpg6EIACgkQNL8k5A2w/vw/IwCgzvldmIrJq9GJiJIPcq+DaFqy > sBYAn3Lv8b8ZAjgppFYXcPoovsJIn8kU > =7tFE > -----END PGP SIGNATURE----- > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From alexey.melnikov@isode.com Sat Jul 18 08:14: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 BAD853A695D for ; Sat, 18 Jul 2009 08:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.416 X-Spam-Level: X-Spam-Status: No, score=-0.416 tagged_above=-999 required=5 tests=[AWL=0.324, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gi3da3q9o1c2 for ; Sat, 18 Jul 2009 08:14:05 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id B67663A68BC for ; Sat, 18 Jul 2009 08:14:04 -0700 (PDT) Received: from [92.40.162.39] (92.40.162.39.sub.mbb.three.co.uk [92.40.162.39]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sat, 18 Jul 2009 16:14:03 +0100 Message-ID: <4A61E681.1030406@isode.com> Date: Sat, 18 Jul 2009 16:13:05 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Peter Saint-Andre References: <4A53674C.60409@stpeter.im> <6c9fcc2a0907071116i36b91e14u92fba0e7c9e5f54e@mail.gmail.com> <4A60E842.2070003@stpeter.im> In-Reply-To: <4A60E842.2070003@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] IETF 75 X-BeenThere: oauth@ietf.org X-Mailman-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, 18 Jul 2009 15:14:05 -0000 Peter Saint-Andre wrote: >On 7/7/09 12:16 PM, Barry Leiba wrote: > >>>Even though we will not hold an official session, perhaps it would be >>>productive to hold a "Bar BOF" or other informal get-together in >>>Stockholm. If you are interested, please post to the list so we can >>>arrange a time and place. >>> >>> >>I'd like to attend. >>Time's always tight, though, so it might be a challenge to find >>something that works for most. >> >> >How about a breakfast BoF instead of a bar BoF? The AppArea meeting is >Monday morning, thus I suggest Tuesday or Wednesday morning so that we >can announce it at the AppArea meeting. > Wednesday morning would be better for Lisa and myself, as we will not have an IESG breakfast on this day. From stpeter@stpeter.im Sat Jul 18 09:48:09 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 4B8843A6A47 for ; Sat, 18 Jul 2009 09:48:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jCGDCU-MjsA7 for ; Sat, 18 Jul 2009 09:48:08 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 51BF23A69E4 for ; Sat, 18 Jul 2009 09:48:08 -0700 (PDT) Received: from squire.local (dsl-175-124.dynamic-dsl.frii.net [216.17.175.124]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A385B4007B; Sat, 18 Jul 2009 10:48:07 -0600 (MDT) Message-ID: <4A61FCBE.8040908@stpeter.im> Date: Sat, 18 Jul 2009 10:47:58 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Alexey Melnikov References: <4A53674C.60409@stpeter.im> <6c9fcc2a0907071116i36b91e14u92fba0e7c9e5f54e@mail.gmail.com> <4A60E842.2070003@stpeter.im> <4A61E681.1030406@isode.com> In-Reply-To: <4A61E681.1030406@isode.com> X-Enigmail-Version: 0.95.7 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] IETF 75 X-BeenThere: oauth@ietf.org X-Mailman-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, 18 Jul 2009 16:48:09 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/18/09 9:13 AM, Alexey Melnikov wrote: > Peter Saint-Andre wrote: > >> On 7/7/09 12:16 PM, Barry Leiba wrote: >>>> Even though we will not hold an official session, perhaps it would be >>>> productive to hold a "Bar BOF" or other informal get-together in >>>> Stockholm. If you are interested, please post to the list so we can >>>> arrange a time and place. >>>> >>> I'd like to attend. >>> Time's always tight, though, so it might be a challenge to find >>> something that works for most. >>> >> How about a breakfast BoF instead of a bar BoF? The AppArea meeting is >> Monday morning, thus I suggest Tuesday or Wednesday morning so that we >> can announce it at the AppArea meeting. >> > Wednesday morning would be better for Lisa and myself, as we will not > have an IESG breakfast on this day. Duly noted. :) 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 iEYEARECAAYFAkph/L4ACgkQNL8k5A2w/vyhegCeP4lu1e6Gs68W1nGQTXwKfH8+ hfMAoOOqa6vDrrRNtygzutIsAAo6U3O+ =XcZc -----END PGP SIGNATURE----- From faynberg@alcatel-lucent.com Sat Jul 18 11:02: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 214A73A6B07 for ; Sat, 18 Jul 2009 11:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lNEeGNGnoBDB for ; Sat, 18 Jul 2009 11:02:43 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id DAB3F3A6AB3 for ; Sat, 18 Jul 2009 11:02:42 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id n6II2d5h029106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 18 Jul 2009 13:02:39 -0500 (CDT) Received: from alcatel-lucent.com (faynberg.lra.lucent.com [135.244.34.104]) by umail.lucent.com (8.13.8/TPES) with ESMTP id n6II2cR3015455; Sat, 18 Jul 2009 13:02:39 -0500 (CDT) Message-ID: <4A620E3D.5030708@alcatel-lucent.com> Date: Sat, 18 Jul 2009 14:02:37 -0400 From: Igor Faynberg Organization: Bell Labs, Lucent Technologies User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 (CK-LucentTPES) X-Accept-Language: en,el MIME-Version: 1.0 To: Peter Saint-Andre References: <4A53674C.60409@stpeter.im> <6c9fcc2a0907071116i36b91e14u92fba0e7c9e5f54e@mail.gmail.com> <4A60E842.2070003@stpeter.im> <4A61E681.1030406@isode.com> <4A61FCBE.8040908@stpeter.im> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] IETF 75 X-BeenThere: oauth@ietf.org X-Mailman-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, 18 Jul 2009 18:02:44 -0000 Peter, Could you please suggest the exact place of the breakfast meeting? With thanks, Igor On 7/18/2009 12:47 PM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 7/18/09 9:13 AM, Alexey Melnikov wrote: > >>Peter Saint-Andre wrote: >> >> >>>On 7/7/09 12:16 PM, Barry Leiba wrote: >>> >>>>>Even though we will not hold an official session, perhaps it would be >>>>>productive to hold a "Bar BOF" or other informal get-together in >>>>>Stockholm. If you are interested, please post to the list so we can >>>>>arrange a time and place. >>>>> >>>> >>>>I'd like to attend. >>>>Time's always tight, though, so it might be a challenge to find >>>>something that works for most. >>>> >>> >>>How about a breakfast BoF instead of a bar BoF? The AppArea meeting is >>>Monday morning, thus I suggest Tuesday or Wednesday morning so that we >>>can announce it at the AppArea meeting. >>> >> >>Wednesday morning would be better for Lisa and myself, as we will not >>have an IESG breakfast on this day. > > > Duly noted. :) > > 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 > > iEYEARECAAYFAkph/L4ACgkQNL8k5A2w/vyhegCeP4lu1e6Gs68W1nGQTXwKfH8+ > hfMAoOOqa6vDrrRNtygzutIsAAo6U3O+ > =XcZc > -----END PGP SIGNATURE----- > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From alexey.melnikov@isode.com Mon Jul 20 15:49: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 E9F443A6A50 for ; Mon, 20 Jul 2009 15:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.753 X-Spam-Level: X-Spam-Status: No, score=-0.753 tagged_above=-999 required=5 tests=[AWL=0.717, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hIIpLD44MG6B for ; Mon, 20 Jul 2009 15:49:22 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id DE5BD3A6AB1 for ; Mon, 20 Jul 2009 15:49:21 -0700 (PDT) Received: from [172.16.2.186] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 20 Jul 2009 23:43:54 +0100 Message-ID: <4A64F2F3.6080909@isode.com> Date: Mon, 20 Jul 2009 23:42:59 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Peter Saint-Andre References: <4A53674C.60409@stpeter.im> <6c9fcc2a0907071116i36b91e14u92fba0e7c9e5f54e@mail.gmail.com> <4A60E842.2070003@stpeter.im> <4A61E681.1030406@isode.com> <4A61FCBE.8040908@stpeter.im> In-Reply-To: <4A61FCBE.8040908@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] IETF 75 X-BeenThere: oauth@ietf.org X-Mailman-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, 20 Jul 2009 22:49:23 -0000 Peter Saint-Andre wrote: >On 7/18/09 9:13 AM, Alexey Melnikov wrote: > > >>Peter Saint-Andre wrote: >> >> >>>On 7/7/09 12:16 PM, Barry Leiba wrote: >>> >>> >>>>>Even though we will not hold an official session, perhaps it would be >>>>>productive to hold a "Bar BOF" or other informal get-together in >>>>>Stockholm. If you are interested, please post to the list so we can >>>>>arrange a time and place. >>>>> >>>>> >>>>I'd like to attend. >>>>Time's always tight, though, so it might be a challenge to find >>>>something that works for most. >>>> >>>> >>>How about a breakfast BoF instead of a bar BoF? The AppArea meeting is >>>Monday morning, thus I suggest Tuesday or Wednesday morning so that we >>>can announce it at the AppArea meeting. >>> >>> >>Wednesday morning would be better for Lisa and myself, as we will not >>have an IESG breakfast on this day. >> >> >Duly noted. :) > > Peter, can you please add a wiki page for this on . Thanks. From trac@tools.ietf.org Tue Jul 21 15:19: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 7E73228C3BE for ; Tue, 21 Jul 2009 15:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3zflImdgMR4D for ; Tue, 21 Jul 2009 15:19:19 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id 9FC8028C3BC for ; Tue, 21 Jul 2009 15:19:19 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1MTNg8-0000W1-58; Tue, 21 Jul 2009 15:19:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="ascii" Content-Transfer-Encoding: 7bit From: "oauth issue tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: eran@hueniverse.com X-Trac-Project: oauth Date: Tue, 21 Jul 2009 22:19:20 -0000 X-URL: http://tools.ietf.org/oauth/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/oauth/trac/ticket/2 Message-ID: <059.448e0b5ce4a5c1783037fbe21d9531fa@tools.ietf.org> X-Trac-Ticket-ID: 2 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: eran@hueniverse.com, oauth@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: oauth@ietf.org Subject: [OAUTH-WG] [oauth] #2: No Required Signature Method X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 22:19:20 -0000 #2: No Required Signature Method ---------------------------------+------------------------------------------ Reporter: eran@hueniverse.com | Owner: Type: defect | Status: new Priority: major | Milestone: Component: authentication | Version: Severity: Active WG Document | Keywords: ---------------------------------+------------------------------------------ The protocol currently supports three separate signature methods but does not mandate any. This implies that clients must support all methods in order to inter-operate. The spec should either spell that out as a client requirement or pick at least one method as required for both the client and server. -- Ticket URL: oauth From trac@tools.ietf.org Tue Jul 21 15:31: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 329DA28C1DE for ; Tue, 21 Jul 2009 15:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z8HN5q2AkrJe for ; Tue, 21 Jul 2009 15:31:27 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id 7C3633A6DF1 for ; Tue, 21 Jul 2009 15:31:27 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1MTNrs-0005UZ-31; Tue, 21 Jul 2009 15:31:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="ascii" Content-Transfer-Encoding: 7bit From: "oauth issue tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: eran@hueniverse.com X-Trac-Project: oauth Date: Tue, 21 Jul 2009 22:31:28 -0000 X-URL: http://tools.ietf.org/oauth/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/oauth/trac/ticket/3 Message-ID: <059.93566784ff77fdb326fb5f22b11c9b17@tools.ietf.org> X-Trac-Ticket-ID: 3 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: eran@hueniverse.com, oauth@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: oauth@ietf.org Subject: [OAUTH-WG] [oauth] #3: Discovery Outline / Boundries X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 22:31:28 -0000 #3: Discovery Outline / Boundries ---------------------------------+------------------------------------------ Reporter: eran@hueniverse.com | Owner: Type: task | Status: new Priority: major | Milestone: Component: web-delegation | Version: Severity: Active WG Document | Keywords: ---------------------------------+------------------------------------------ The delegation workflow includes two HTTP requests (sections 4 and 6) but only recommends the use of POST. It defines three endpoints (sections 4, 5, and 6) but their URI is identified manually. This pose a significant interoperability issue without a complementary discovery mechanism (which is currently out of scope). A client receiving a 401 has no way of interacting with an unknown client. The WG has to decide how much should be left for a separate discovery specification and how much should be made mandatory in the current specification. -- Ticket URL: oauth From trac@tools.ietf.org Tue Jul 21 15:35: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 ABE493A6967 for ; Tue, 21 Jul 2009 15:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OC00D0QIpZ4T for ; Tue, 21 Jul 2009 15:35:46 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id E067D3A67A3 for ; Tue, 21 Jul 2009 15:35:46 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1MTNw2-0005be-TN; Tue, 21 Jul 2009 15:35:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="ascii" Content-Transfer-Encoding: 7bit From: "oauth issue tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: eran@hueniverse.com X-Trac-Project: oauth Date: Tue, 21 Jul 2009 22:35:46 -0000 X-URL: http://tools.ietf.org/oauth/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/oauth/trac/ticket/4 Message-ID: <059.36f227d7f81e520e6c5fec0b2a5faab4@tools.ietf.org> X-Trac-Ticket-ID: 4 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: eran@hueniverse.com, oauth@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: oauth@ietf.org Subject: [OAUTH-WG] [oauth] #4: Error Codes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 22:35:47 -0000 #4: Error Codes ---------------------------------+------------------------------------------ Reporter: eran@hueniverse.com | Owner: Type: defect | Status: new Priority: critical | Milestone: Component: authentication | Version: Severity: Active WG Document | Keywords: ---------------------------------+------------------------------------------ Section 8 poorly defines the HTTP response status codes (400 and 401), and does not provide for any mechanism to convey the actual protocol errors preventing the client from successfully authenticating. A proposed 'problem reporting' extension has been proposed for the Core 1.0 protocol: http://wiki.oauth.net/ProblemReporting -- Ticket URL: oauth From stpeter@stpeter.im Thu Jul 23 10:13: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 3D2B83A6A83 for ; Thu, 23 Jul 2009 10:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qpli1YyAzMcd for ; Thu, 23 Jul 2009 10:13:46 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 514B13A6A0D for ; Thu, 23 Jul 2009 10:13:46 -0700 (PDT) Received: from squire.local (ip-216-17-182-211.rev.frii.com [216.17.182.211]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 948474007B; Thu, 23 Jul 2009 11:12:46 -0600 (MDT) Message-ID: <4A689A0D.50201@stpeter.im> Date: Thu, 23 Jul 2009 10:12:45 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Alexey Melnikov References: <4A53674C.60409@stpeter.im> <6c9fcc2a0907071116i36b91e14u92fba0e7c9e5f54e@mail.gmail.com> <4A60E842.2070003@stpeter.im> <4A61E681.1030406@isode.com> <4A61FCBE.8040908@stpeter.im> <4A64F2F3.6080909@isode.com> In-Reply-To: <4A64F2F3.6080909@isode.com> X-Enigmail-Version: 0.95.7 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] IETF 75 X-BeenThere: oauth@ietf.org X-Mailman-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, 23 Jul 2009 17:13:47 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/20/09 3:42 PM, Alexey Melnikov wrote: > Peter Saint-Andre wrote: > >> On 7/18/09 9:13 AM, Alexey Melnikov wrote: >> >> >>> Peter Saint-Andre wrote: >>> >>>> On 7/7/09 12:16 PM, Barry Leiba wrote: >>>>>> Even though we will not hold an official session, perhaps it would be >>>>>> productive to hold a "Bar BOF" or other informal get-together in >>>>>> Stockholm. If you are interested, please post to the list so we can >>>>>> arrange a time and place. >>>>>> >>>>> I'd like to attend. >>>>> Time's always tight, though, so it might be a challenge to find >>>>> something that works for most. >>>> How about a breakfast BoF instead of a bar BoF? The AppArea meeting is >>>> Monday morning, thus I suggest Tuesday or Wednesday morning so that we >>>> can announce it at the AppArea meeting. >>>> >>> Wednesday morning would be better for Lisa and myself, as we will not >>> have an IESG breakfast on this day. >>> >> Duly noted. :) >> >> > Peter, can you please add a wiki page for this on > . Thanks. Done: http://trac.tools.ietf.org/area/app/trac/wiki/BarBofs/IETF75/OAuth Feel free to edit that page. I'm still working to find a place to meet. 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 iEYEARECAAYFAkpomg0ACgkQNL8k5A2w/vyDdQCglec5BzTGZ7uz3zgK9rJPP9UL rDcAoMDm3TibTF9UOUNghvUx9GluF0+S =RDUK -----END PGP SIGNATURE----- From stpeter@stpeter.im Mon Jul 27 05:49: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 17CA03A6C5E for ; Mon, 27 Jul 2009 05:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2WUFk7JIjwdw for ; Mon, 27 Jul 2009 05:49:21 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 329753A6C5A for ; Mon, 27 Jul 2009 05:49:21 -0700 (PDT) Received: from dhcp-11ba.meeting.ietf.org (64-103-25-233.cisco.com [64.103.25.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 717524007B for ; Mon, 27 Jul 2009 06:49:22 -0600 (MDT) Message-ID: <4A6DA250.5010504@stpeter.im> Date: Mon, 27 Jul 2009 14:49:20 +0200 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) 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] Bar BoF @ IETF 75 X-BeenThere: oauth@ietf.org X-Mailman-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, 27 Jul 2009 12:49:22 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 For our Bar BOF, we have reserved room 202 at the Stockholm City Conference Center (the "IESG Room") from 07:30 to 09:30 on Wednesday morning (July 29). Details are here: http://trac.tools.ietf.org/area/app/trac/wiki/BarBofs/IETF75/OAuth Feel free to add more agenda items at that page, or bring them to the BoF with you (along with some coffee, I suppose!). 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/ iEYEARECAAYFAkptolAACgkQNL8k5A2w/vw+aQCfdNlfB7/O4H4sdBgT6UnJ/ZIC ZAoAnAqM3AsV4/ur4Ttn9lP7nVDxRf4t =GgLi -----END PGP SIGNATURE----- From stpeter@stpeter.im Tue Jul 28 23:50: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 126F63A6965 for ; Tue, 28 Jul 2009 23:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HISg3cRr0XNS for ; Tue, 28 Jul 2009 23:50:09 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 1CE303A68BB for ; Tue, 28 Jul 2009 23:50:09 -0700 (PDT) Received: from dhcp-12cb.meeting.ietf.org (64-103-25-233.cisco.com [64.103.25.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 29FC14007B for ; Wed, 29 Jul 2009 00:50:04 -0600 (MDT) Message-ID: <4A6FF11A.40208@stpeter.im> Date: Wed, 29 Jul 2009 08:50:02 +0200 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: "oauth@ietf.org" 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] Breakfast BoF minutes X-BeenThere: oauth@ietf.org X-Mailman-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, 29 Jul 2009 06:50:10 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We just finished an OAuth breakfast Bof at IETF 75. Here are the topics we discussed, in no particular order. Various folks at the meeting volunteered to start separate threads about some of these. 1. OAuth for delegation. Currently the spec addresses only single-layer delegation ("three-legged") and is silent about multi-layer delegation. If we don't define this in a standard way, different people will find different, non-standard ways to do it. We need to gather use cases and work on specifying it. 2. Non-WWW use cases. Let's gather these (shared calendaring, XMPP chatroom ownership, exchange of app-level blobs, etc.). 3. OAuth for authentication. In this case, OAuth could be used to replace DIGEST for authn. It's possible that SCRAM could be used as a signing method. The group also talked about defining various related SASL mechanisms (SAML, OpenID, OAuth). 4. Channel bindings. There are similarities here to HTTPS/DIGEST (Leif Johansson mentioned an expired I-D about this and volunteered to post to the list). 5. Attribute extensions. Could we use OAuth for transporting existing SAML formats? 6. Split off the header signing aspects of OAuth, or at least call that out more clearly in the spec? Someone at the BoF likened this to "DKIM for the Web". 7. The spec is not designed to be profiled and extended. Is this OK? 8. Do callbacks need to be forward-ported to the I-D? 9. Discussion redirects. Currently most folks still take their items to the googlegroups list. That's fine, but going forward we would like to use the WG list for topics related to the core specifications. If you were at the BoF and see errors in what I've reported, please post in reply. 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/ iEYEARECAAYFAkpv8RkACgkQNL8k5A2w/vzfHACeOelyjPVk94WH5QkHmEv1oEnt DX8Ani+zGPn2Yx34/EpIKeInDtmQnBaj =tiM7 -----END PGP SIGNATURE----- From leifj@mnt.se Tue Jul 28 23:51: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 5A6BC3A6DB8 for ; Tue, 28 Jul 2009 23:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZlBRvCbfMyyW for ; Tue, 28 Jul 2009 23:51:49 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 2A8F03A682D for ; Tue, 28 Jul 2009 23:51:49 -0700 (PDT) Received: by fxm18 with SMTP id 18so196876fxm.37 for ; Tue, 28 Jul 2009 23:51:47 -0700 (PDT) Received: by 10.103.160.9 with SMTP id m9mr4462170muo.96.1248850307443; Tue, 28 Jul 2009 23:51:47 -0700 (PDT) Received: from klapautius.localnet (dhcp-16e2.meeting.ietf.org [130.129.22.226]) by mx.google.com with ESMTPS id j9sm2908665mue.56.2009.07.28.23.51.45 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 28 Jul 2009 23:51:45 -0700 (PDT) From: Leif Johansson Organization: mnt.se To: oauth@ietf.org Date: Wed, 29 Jul 2009 08:51:42 +0200 User-Agent: KMail/1.11.2 (Linux/2.6.28-13-generic; KDE/4.2.2; i686; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907290851.42447.leifj@mnt.se> Subject: [OAUTH-WG] channel bindings X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: leifj@mnt.se List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 06:51:50 -0000 Here is a topic I raised at the mic at the first OAuth BOF: Should OAuth grow channel bindings in the sense of RFC5056? The purpose would be to bind the OAuth exchange to an underlying secure channel (eg HTTPS) if present. Background reading for this (apart from RFC5056) might be http://tools.ietf.org/html/draft-santesson-digestbind-01 that defines channel bindings for another HTTP authentication mechanism as well as the IANA registry: http://www.iana.org/assignments/channel-binding-types/ Cheers Leif From faynberg@alcatel-lucent.com Wed Jul 29 00:28:09 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 D48143A6B24 for ; Wed, 29 Jul 2009 00:28:09 -0700 (PDT) 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 STvKI3iydOVe for ; Wed, 29 Jul 2009 00:28:08 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id C37893A6452 for ; Wed, 29 Jul 2009 00:28:08 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id n6T7S8qD022524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Jul 2009 02:28:09 -0500 (CDT) Received: from alcatel-lucent.com (faynberg.lra.lucent.com [135.244.224.32]) by umail.lucent.com (8.13.8/TPES) with ESMTP id n6T7S6WI004045; Wed, 29 Jul 2009 02:28:06 -0500 (CDT) Message-ID: <4A6FFA05.6050809@alcatel-lucent.com> Date: Wed, 29 Jul 2009 03:28:05 -0400 From: Igor Faynberg Organization: Bell Labs, Lucent Technologies User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 (CK-LucentTPES) X-Accept-Language: en,el MIME-Version: 1.0 To: Peter Saint-Andre References: <4A6FF11A.40208@stpeter.im> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Breakfast BoF minutes X-BeenThere: oauth@ietf.org X-Mailman-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, 29 Jul 2009 07:28:09 -0000 Peter, Excellent notes and meteoric delivery. Many thanks! Igor On 7/29/2009 2:50 AM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > We just finished an OAuth breakfast Bof at IETF 75. Here are the topics > we discussed, in no particular order. Various folks at the meeting > volunteered to start separate threads about some of these. > > 1. OAuth for delegation. Currently the spec addresses only single-layer > delegation ("three-legged") and is silent about multi-layer delegation. > If we don't define this in a standard way, different people will find > different, non-standard ways to do it. We need to gather use cases and > work on specifying it. > > 2. Non-WWW use cases. Let's gather these (shared calendaring, XMPP > chatroom ownership, exchange of app-level blobs, etc.). > > 3. OAuth for authentication. In this case, OAuth could be used to > replace DIGEST for authn. It's possible that SCRAM could be used as a > signing method. The group also talked about defining various related > SASL mechanisms (SAML, OpenID, OAuth). > > 4. Channel bindings. There are similarities here to HTTPS/DIGEST (Leif > Johansson mentioned an expired I-D about this and volunteered to post to > the list). > > 5. Attribute extensions. Could we use OAuth for transporting existing > SAML formats? > > 6. Split off the header signing aspects of OAuth, or at least call that > out more clearly in the spec? Someone at the BoF likened this to "DKIM > for the Web". > > 7. The spec is not designed to be profiled and extended. Is this OK? > > 8. Do callbacks need to be forward-ported to the I-D? > > 9. Discussion redirects. Currently most folks still take their items to > the googlegroups list. That's fine, but going forward we would like to > use the WG list for topics related to the core specifications. > > If you were at the BoF and see errors in what I've reported, please post > in reply. > > 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/ > > iEYEARECAAYFAkpv8RkACgkQNL8k5A2w/vzfHACeOelyjPVk94WH5QkHmEv1oEnt > DX8Ani+zGPn2Yx34/EpIKeInDtmQnBaj > =tiM7 > -----END PGP SIGNATURE----- > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From rbarnes@bbn.com Wed Jul 29 00:54: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 62CE73A69BA for ; Wed, 29 Jul 2009 00:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.662 X-Spam-Level: X-Spam-Status: No, score=-2.662 tagged_above=-999 required=5 tests=[AWL=-0.063, 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 1Uc8AWCJyrXA for ; Wed, 29 Jul 2009 00:54:53 -0700 (PDT) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id BF9D13A6452 for ; Wed, 29 Jul 2009 00:54:53 -0700 (PDT) Received: from [128.89.253.199] (helo=col-rbarnes-l1.local) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1MW3zy-0002fj-CR for oauth@ietf.org; Wed, 29 Jul 2009 03:54:55 -0400 Message-ID: <4A70004E.3000000@bbn.com> Date: Wed, 29 Jul 2009 09:54:54 +0200 From: Richard Barnes User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: "oauth@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [OAUTH-WG] What is 4-legged OAuth? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 07:54:54 -0000 There has been a lot of talk about many-legged OAuth usages. I think most people are familiar with the authentication and delegation (2- and 3-legged) cases. Could someone summarize the 4-legged case? Thanks, --Richard From llynch@civil-tongue.net Wed Jul 29 01:08: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 00F8A3A681A for ; Wed, 29 Jul 2009 01:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6Ge+OqP948t for ; Wed, 29 Jul 2009 01:08:07 -0700 (PDT) Received: from hiroshima.bogus.com (hiroshima.bogus.com [IPv6:2001:418:1::80]) by core3.amsl.com (Postfix) with ESMTP id 089553A6908 for ; Wed, 29 Jul 2009 01:08:06 -0700 (PDT) Received: from hiroshima.bogus.com (localhost [127.0.0.1]) by hiroshima.bogus.com (8.14.3/8.14.3) with ESMTP id n6T87xTF081562; Wed, 29 Jul 2009 01:07:59 -0700 (PDT) (envelope-from llynch@civil-tongue.net) Received: from localhost (llynch@localhost) by hiroshima.bogus.com (8.14.3/8.14.3/Submit) with ESMTP id n6T87wLt081559; Wed, 29 Jul 2009 01:07:58 -0700 (PDT) (envelope-from llynch@civil-tongue.net) Date: Wed, 29 Jul 2009 01:07:58 -0700 (PDT) From: Lucy Lynch X-X-Sender: llynch@hiroshima.bogus.com To: Richard Barnes In-Reply-To: <4A70004E.3000000@bbn.com> Message-ID: References: <4A70004E.3000000@bbn.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] What is 4-legged OAuth? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 08:08:08 -0000 On Wed, 29 Jul 2009, Richard Barnes wrote: > There has been a lot of talk about many-legged OAuth usages. I think most > people are familiar with the authentication and delegation (2- and 3-legged) > cases. Could someone summarize the 4-legged case? Richard - You might want to look at Eve Maler's message (and blog posts) concerning ProtectServe http://www.google.com/url?sa=t&source=web&ct=res&cd=4&url=http%3A%2F%2Fgroups.google.com%2Fgroup%2Foauth-extensions%2Fbrowse_thread%2Fthread%2F35992a5955216d66&ei=nwFwSoOyCZCi_gbV8uiiCQ&rct=j&q=oauth+multi-legged+site%3Agoogle.com&usg=AFQjCNHHccgokFB3WTyy5kjiat84hkXCoA If you’re an OAuth aficionado, ProtectServe is something like four-legged OAuth or higher-order OAuth, with the effect of separating out an authorization job for the Relationship Manager that today’s OAuth SPs do all by themselves. - Lucy > Thanks, > --Richard > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From faynberg@alcatel-lucent.com Wed Jul 29 01:23: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 34AE53A6ECD for ; Wed, 29 Jul 2009 01:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 R0NtValKNa+R for ; Wed, 29 Jul 2009 01:23:29 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 66BE53A6ECA for ; Wed, 29 Jul 2009 01:23:29 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id n6T8NHNH025154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Jul 2009 03:23:17 -0500 (CDT) Received: from alcatel-lucent.com (faynberg.lra.lucent.com [135.244.224.32]) by umail.lucent.com (8.13.8/TPES) with ESMTP id n6T8NFZl005186; Wed, 29 Jul 2009 03:23:16 -0500 (CDT) Message-ID: <4A7006F3.4040405@alcatel-lucent.com> Date: Wed, 29 Jul 2009 04:23:15 -0400 From: Igor Faynberg Organization: Bell Labs, Lucent Technologies User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 (CK-LucentTPES) X-Accept-Language: en,el MIME-Version: 1.0 To: Richard Barnes References: <4A70004E.3000000@bbn.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] What is 4-legged OAuth? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 08:23:30 -0000 Richard, This is what we plan to do in an I-D, which we should submit prior to the next meeting. Igor On 7/29/2009 3:54 AM, Richard Barnes wrote: > There has been a lot of talk about many-legged OAuth usages. I think > most people are familiar with the authentication and delegation (2- and > 3-legged) cases. Could someone summarize the 4-legged case? > > Thanks, > --Richard > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From rbarnes@bbn.com Wed Jul 29 01:51:02 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 38FAA3A6F7F for ; Wed, 29 Jul 2009 01:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.65 X-Spam-Level: X-Spam-Status: No, score=-2.65 tagged_above=-999 required=5 tests=[AWL=-0.051, 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 3HLIrdRw76cl for ; Wed, 29 Jul 2009 01:51:01 -0700 (PDT) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 7ED063A6F6F for ; Wed, 29 Jul 2009 01:49:18 -0700 (PDT) Received: from [128.89.253.199] (helo=col-rbarnes-l1.local) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1MW4qc-0003LV-BX; Wed, 29 Jul 2009 04:49:18 -0400 Message-ID: <4A700D0D.1000609@bbn.com> Date: Wed, 29 Jul 2009 10:49:17 +0200 From: Richard Barnes User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Igor Faynberg References: <4A70004E.3000000@bbn.com> <4A7006F3.4040405@alcatel-lucent.com> In-Reply-To: <4A7006F3.4040405@alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] What is 4-legged OAuth? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 08:51:02 -0000 Such a draft would be greatly appreciated. More so if it could be done slightly sooner than October :) --Richard Igor Faynberg wrote: > Richard, > > This is what we plan to do in an I-D, which we should submit prior to the next > meeting. > > Igor > > On 7/29/2009 3:54 AM, Richard Barnes wrote: >> There has been a lot of talk about many-legged OAuth usages. I think >> most people are familiar with the authentication and delegation (2- and >> 3-legged) cases. Could someone summarize the 4-legged case? >> >> Thanks, >> --Richard >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > > From stpeter@stpeter.im Wed Jul 29 02: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 D13D83A6EB7 for ; Wed, 29 Jul 2009 02:10:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mrk0K5HTNj1O for ; Wed, 29 Jul 2009 02:10:05 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id C7EF83A6AFA for ; Wed, 29 Jul 2009 02:10:05 -0700 (PDT) Received: from squire.local (unknown [212.112.167.85]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 49E8F4007B; Wed, 29 Jul 2009 03:10:05 -0600 (MDT) Message-ID: <4A7011EB.9050609@stpeter.im> Date: Wed, 29 Jul 2009 11:10:03 +0200 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Igor Faynberg References: <4A70004E.3000000@bbn.com> <4A7006F3.4040405@alcatel-lucent.com> In-Reply-To: <4A7006F3.4040405@alcatel-lucent.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] What is 4-legged OAuth? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 09:10:06 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thanks, Igor! That sounds very helpful. On 7/29/09 10:23 AM, Igor Faynberg wrote: > Richard, > > This is what we plan to do in an I-D, which we should submit prior to the next > meeting. > > Igor > > On 7/29/2009 3:54 AM, Richard Barnes wrote: >> There has been a lot of talk about many-legged OAuth usages. I think >> most people are familiar with the authentication and delegation (2- and >> 3-legged) cases. Could someone summarize the 4-legged case? >> >> Thanks, >> --Richard >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkpwEesACgkQNL8k5A2w/vyAmQCguwVpaFr9pH+XDkd2pwm4UJvB bqkAn133MS8fZs1WZ0sUeKo3Re584O6B =D8id -----END PGP SIGNATURE----- From stpeter@stpeter.im Wed Jul 29 02:12: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 4B7873A6FAB for ; Wed, 29 Jul 2009 02:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.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 CkxFRup-rMSp for ; Wed, 29 Jul 2009 02:12:32 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 2CDF43A6FA9 for ; Wed, 29 Jul 2009 02:12:32 -0700 (PDT) Received: from squire.local (unknown [212.112.167.85]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 83F1E4007B; Wed, 29 Jul 2009 03:12:33 -0600 (MDT) Message-ID: <4A70127F.8090009@stpeter.im> Date: Wed, 29 Jul 2009 11:12:31 +0200 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Richard Barnes References: <4A70004E.3000000@bbn.com> In-Reply-To: <4A70004E.3000000@bbn.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] What is 4-legged OAuth? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 09:12:33 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/29/09 9:54 AM, Richard Barnes wrote: > There has been a lot of talk about many-legged OAuth usages. I think > most people are familiar with the authentication and delegation (2- and > 3-legged) cases. Could someone summarize the 4-legged case? One thing we discussed this morning was that all this talk of legs is confusing. I think we had rough consensus on something like the following terminology... "two-legged" = authentication "three-legged" = single-layer delegation "four-legged" (and more) = multi-layer delegation 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/ iEYEARECAAYFAkpwEn8ACgkQNL8k5A2w/vys3ACcC+KNd7w54eOX4dDCgJ+S0KDD p2kAoIgFWSiyL1DalicnIlTnPtCWgD9q =At+M -----END PGP SIGNATURE----- From rbarnes@bbn.com Wed Jul 29 02:25: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 B6DE53A6F02 for ; Wed, 29 Jul 2009 02:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.646 X-Spam-Level: X-Spam-Status: No, score=-2.646 tagged_above=-999 required=5 tests=[AWL=-0.047, 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 XqyTDa+tY3EH for ; Wed, 29 Jul 2009 02:25:48 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id B8AB43A681A for ; Wed, 29 Jul 2009 02:25:48 -0700 (PDT) Received: from [128.89.253.199] (helo=col-rbarnes-l1.local) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1MW4Tq-00049T-EQ; Wed, 29 Jul 2009 04:25:46 -0400 Message-ID: <4A70159A.5040206@bbn.com> Date: Wed, 29 Jul 2009 11:25:46 +0200 From: Richard Barnes User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Peter Saint-Andre References: <4A70004E.3000000@bbn.com> <4A70127F.8090009@stpeter.im> In-Reply-To: <4A70127F.8090009@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] What is 4-legged OAuth? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 09:25:49 -0000 That of course raises another point that I'm not clear on: Why is the 3-legged case not composable? Once an authorization has been delegated to the Client, it seems like the Client could in principle act as a Resource Owner for that authorization, so that he could delegate to the next tier. There may be a desire for the RO to be able to flag that the Client can sub-delegate his delegated authorization, but that would seem to be an issue of the scope of the authorization, which has been outside the scope of the protocol. --Richard Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 7/29/09 9:54 AM, Richard Barnes wrote: >> There has been a lot of talk about many-legged OAuth usages. I think >> most people are familiar with the authentication and delegation (2- and >> 3-legged) cases. Could someone summarize the 4-legged case? > > One thing we discussed this morning was that all this talk of legs is > confusing. I think we had rough consensus on something like the > following terminology... > > "two-legged" = authentication > > "three-legged" = single-layer delegation > > "four-legged" (and more) = multi-layer delegation > > 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/ > > iEYEARECAAYFAkpwEn8ACgkQNL8k5A2w/vys3ACcC+KNd7w54eOX4dDCgJ+S0KDD > p2kAoIgFWSiyL1DalicnIlTnPtCWgD9q > =At+M > -----END PGP SIGNATURE----- > From diego.lopez@rediris.es Wed Jul 29 02:59: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 C8BFE3A6EE4 for ; Wed, 29 Jul 2009 02:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vW+k8cFMWzzv for ; Wed, 29 Jul 2009 02:59:34 -0700 (PDT) Received: from irisout1.rediris.es (irisout1.rediris.es [130.206.24.3]) by core3.amsl.com (Postfix) with ESMTP id 606D13A6DB8 for ; Wed, 29 Jul 2009 02:59:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.43,288,1246831200"; d="scan'208";a="9339397" Received: from incal.rediris.es ([130.206.6.47]) by abel.rediris.es with ESMTP/TLS/AES128-SHA; 29 Jul 2009 11:59:39 +0200 Message-Id: From: "Diego R. Lopez" To: Richard Barnes In-Reply-To: <4A70159A.5040206@bbn.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 29 Jul 2009 11:59:32 +0200 References: <4A70004E.3000000@bbn.com> <4A70127F.8090009@stpeter.im> <4A70159A.5040206@bbn.com> X-Mailer: Apple Mail (2.935.3) Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] What is 4-legged OAuth? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 09:59:35 -0000 On 29 Jul 2009, at 11:25, Richard Barnes wrote: > That of course raises another point that I'm not clear on: Why is > the 3-legged case not composable? Once an authorization has been > delegated to the Client, it seems like the Client could in principle > act as a Resource Owner for that authorization, so that he could > delegate to the next tier. > > There may be a desire for the RO to be able to flag that the Client > can sub-delegate his delegated authorization, but that would seem to > be an issue of the scope of the authorization, which has been > outside the scope of the protocol. I'm afraid that, unless you define a very clear procedure for that delegation, the whole protocol would be signed as breaking privacy (and I think it can probably be the case). Having written and implemented a delegated authorization profile for SAML, I can tell preserving privacy is not easy at all in the moment you allow delegations to be stacked, and other solutions, like the external services depicted by ProtectServe do scalemuch better. Be goode, -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Red.es - RedIRIS The Spanish NREN e-mail: diego.lopez@rediris.es jid: diego.lopez@rediris.es Tel: +34 955 056 621 Mobile: +34 669 898 094 ----------------------------------------- From rbarnes@bbn.com Wed Jul 29 03:34: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 D58A23A6EAC for ; Wed, 29 Jul 2009 03:34:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.642 X-Spam-Level: X-Spam-Status: No, score=-2.642 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EREKzzqP5to7 for ; Wed, 29 Jul 2009 03:34:05 -0700 (PDT) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 142B23A6F10 for ; Wed, 29 Jul 2009 03:34:00 -0700 (PDT) Received: from [128.89.254.3] (helo=dhcp-14e6.meeting.ietf.org) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1MW6Tt-0004Gg-Bu; Wed, 29 Jul 2009 06:33:58 -0400 Message-ID: <4A702593.5060308@bbn.com> Date: Wed, 29 Jul 2009 12:33:55 +0200 From: Richard Barnes User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: "Diego R. Lopez" References: <4A70004E.3000000@bbn.com> <4A70127F.8090009@stpeter.im> <4A70159A.5040206@bbn.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] What is 4-legged OAuth? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 10:34:06 -0000 Diego, Having a well-defined procedure for delegation was the point of OAuth in the first place! I'm just not clear on what risks you introduce by re-using it to sub-delegate; none are immediately clear to me. --Richard Diego R. Lopez wrote: > > On 29 Jul 2009, at 11:25, Richard Barnes wrote: > >> That of course raises another point that I'm not clear on: Why is the >> 3-legged case not composable? Once an authorization has been >> delegated to the Client, it seems like the Client could in principle >> act as a Resource Owner for that authorization, so that he could >> delegate to the next tier. >> >> There may be a desire for the RO to be able to flag that the Client >> can sub-delegate his delegated authorization, but that would seem to >> be an issue of the scope of the authorization, which has been outside >> the scope of the protocol. > > > I'm afraid that, unless you define a very clear procedure for that > delegation, the whole protocol would > be signed as breaking privacy (and I think it can probably be the case). > Having written and implemented > a delegated authorization profile for SAML, I can tell preserving > privacy is not easy at all in the moment > you allow delegations to be stacked, and other solutions, like the > external services depicted by > ProtectServe do scalemuch better. > > Be goode, > > -- > "Esta vez no fallaremos, Doctor Infierno" > > Dr Diego R. Lopez > > Red.es - RedIRIS > The Spanish NREN > > e-mail: diego.lopez@rediris.es > jid: diego.lopez@rediris.es > Tel: +34 955 056 621 > Mobile: +34 669 898 094 > ----------------------------------------- > > > > From diego.lopez@rediris.es Wed Jul 29 04:25: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 2D77C3A6FF6 for ; Wed, 29 Jul 2009 04:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s1qgzQ8+JenZ for ; Wed, 29 Jul 2009 04:25:31 -0700 (PDT) Received: from irisout1.rediris.es (irisout1.rediris.es [130.206.24.3]) by core3.amsl.com (Postfix) with ESMTP id B5F573A6FF2 for ; Wed, 29 Jul 2009 04:25:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.43,289,1246831200"; d="scan'208";a="9343318" Received: from unknown (HELO [130.206.16.166]) ([130.206.16.166]) by abel.rediris.es with ESMTP/TLS/AES128-SHA; 29 Jul 2009 13:25:36 +0200 Message-Id: <97CC5190-E828-48DD-A3F5-659F59681F3F@rediris.es> From: "Diego R. Lopez" To: Richard Barnes In-Reply-To: <4A702593.5060308@bbn.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 29 Jul 2009 13:25:10 +0200 References: <4A70004E.3000000@bbn.com> <4A70127F.8090009@stpeter.im> <4A70159A.5040206@bbn.com> <4A702593.5060308@bbn.com> X-Mailer: Apple Mail (2.935.3) Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] What is 4-legged OAuth? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 11:25:32 -0000 Richard, On 29 Jul 2009, at 12:33, Richard Barnes wrote: > Having a well-defined procedure for delegation was the point of > OAuth in the first place! I'm just not clear on what risks you > introduce by re-using it to sub-delegate; none are immediately clear > to me. If I have understood you well, what you proposed is to allow clients to forward their authorization tokens to other potential clients. To do so, you can make it with or without user explicit consent. In the first case, unless you send back the user to the SP (what would be exactly the same as the three-legged case with just a shorter path in user interactions) you are allowing a third party to ask the user to take decisions on access to the SP, and this seems to me a clear path for phishing. In the second case, you are simply transmitting the authotization without the explicit user consent, and that would break several privacy protecting laws (at least, here in the EU) Furthermore, since traceability is a essential requirement for any access control infrastructure, the unconstrained delegation would require a strict control of the potential clients that can share a token at the SP, including a detailed check of who is using the token and from whom it was generated, and this requires as well the ability of tracing the delegation path up to the original client, implying that tokens must be augmented with traces of the delegations, and you'll agree in that this won't scale. Be goode, -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Red.es - RedIRIS The Spanish NREN e-mail: diego.lopez@rediris.es jid: diego.lopez@rediris.es Tel: +34 955 056 621 Mobile: +34 669 898 094 ----------------------------------------- From rbarnes@bbn.com Wed Jul 29 05:07: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 420B13A703E for ; Wed, 29 Jul 2009 05:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.639 X-Spam-Level: X-Spam-Status: No, score=-2.639 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5t+a3+oAZXOI for ; Wed, 29 Jul 2009 05:07:21 -0700 (PDT) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 14D533A6D3B for ; Wed, 29 Jul 2009 05:07:21 -0700 (PDT) Received: from [128.89.254.2] (helo=dhcp-14e6.meeting.ietf.org) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1MW7wD-00053s-BU; Wed, 29 Jul 2009 08:07:17 -0400 Message-ID: <4A703B74.9010504@bbn.com> Date: Wed, 29 Jul 2009 14:07:16 +0200 From: Richard Barnes User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: "Diego R. Lopez" References: <4A70004E.3000000@bbn.com> <4A70127F.8090009@stpeter.im> <4A70159A.5040206@bbn.com> <4A702593.5060308@bbn.com> <97CC5190-E828-48DD-A3F5-659F59681F3F@rediris.es> In-Reply-To: <97CC5190-E828-48DD-A3F5-659F59681F3F@rediris.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] What is 4-legged OAuth? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 12:07:22 -0000 You're misunderstanding what I'm proposing. Let me try to state what I'm thinking more clearly. For consistency, I'll use terms from draft-barnes-oauth-model. I'm not proposing that one client simply pass its access token to some other potential client -- you're absolutely correct that that doesn't provide the user approval or traceability that you would want. What I'm talking about is doing the *entire* OAuth delegation procedure twice: First with the User as RO and Client1 as Client, then again with Client1 as RO and Client2 as Client (the Server being the same the whole time). In graphic form: +----------+ --+ | Resource | | | Owner 1 | | +----------+ | ^| | OAuth 1 || | req-tk-1||ver-tk-1 | |V | +----------+----------+ | +-----------req-tk-1----->| Client = Resource | --+ | +---------acc-tk-1----->| 1 Owner 2 | --+ | | +----------+----------+ | +----------+ ^| | | Server | || | | | req-tk-2||ver-tk-2 | OAuth 2 +----------+ |V | | | +----------+ | | +---------req-tk-2----->| Client | | +-----------acc-tk 2----->| 2 | | +----------+ --+ Doing this would enable accountable sub-delegation, since all the delegations are made through the Server. The one thing that's not immediately clear is how you fit user consent for the sub-delegation into this picture. But there's an easy answer there too: Permission to sub-delegate is just another permission that can be delegated via OAuth. In the above example, Client1 would have to receive permission to sub-delegate to Client2 in his initial transaction. You could also imagine a three-OAuth model, where: 1. OAuth1: RO grants Client1 permission to access resources 2. Client1 requests permission to sub-delegate to Client2 3. OAuth2: RO grants Client1 permission to sub-delegate to Client2 4. OAuth3: Client 1 grants Client2 permission to access resources Either way, these are just concatenations of OAuth transactions. What's missing, besides an informational document to describe how this works? --Richard Diego R. Lopez wrote: > Richard, > > On 29 Jul 2009, at 12:33, Richard Barnes wrote: >> Having a well-defined procedure for delegation was the point of OAuth >> in the first place! I'm just not clear on what risks you introduce by >> re-using it to sub-delegate; none are immediately clear to me. > > If I have understood you well, what you proposed is to allow clients to > forward their authorization tokens > to other potential clients. To do so, you can make it with or without > user explicit consent. In the first case, > unless you send back the user to the SP (what would be exactly the same > as the three-legged case with just > a shorter path in user interactions) you are allowing a third party to > ask the user to take decisions on > access to the SP, and this seems to me a clear path for phishing. In the > second case, you are simply > transmitting the authotization without the explicit user consent, and > that would break several privacy > protecting laws (at least, here in the EU) > > Furthermore, since traceability is a essential requirement for any > access control infrastructure, > the unconstrained delegation would require a strict control of the > potential clients that can share > a token at the SP, including a detailed check of who is using the token > and from whom it was generated, > and this requires as well the ability of tracing the delegation path up > to the original client, implying > that tokens must be augmented with traces of the delegations, and you'll > agree in that this won't scale. > > Be goode, > -- > "Esta vez no fallaremos, Doctor Infierno" > > Dr Diego R. Lopez > > Red.es - RedIRIS > The Spanish NREN > > e-mail: diego.lopez@rediris.es > jid: diego.lopez@rediris.es > Tel: +34 955 056 621 > Mobile: +34 669 898 094 > ----------------------------------------- > > > > From leifj@mnt.se Wed Jul 29 06:31: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 A38C73A7011 for ; Wed, 29 Jul 2009 06:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mFWYg8DAnyk7 for ; Wed, 29 Jul 2009 06:31:52 -0700 (PDT) Received: from mail-bw0-f221.google.com (mail-bw0-f221.google.com [209.85.218.221]) by core3.amsl.com (Postfix) with ESMTP id 853B23A6912 for ; Wed, 29 Jul 2009 06:31:52 -0700 (PDT) Received: by bwz21 with SMTP id 21so689257bwz.37 for ; Wed, 29 Jul 2009 06:31:52 -0700 (PDT) Received: by 10.103.225.15 with SMTP id c15mr4584846mur.115.1248874312028; Wed, 29 Jul 2009 06:31:52 -0700 (PDT) Received: from klapautius.localnet (dhcp-16e2.meeting.ietf.org [130.129.22.226]) by mx.google.com with ESMTPS id n10sm5259118mue.49.2009.07.29.06.31.51 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 29 Jul 2009 06:31:51 -0700 (PDT) From: Leif Johansson Organization: mnt.se To: oauth@ietf.org Date: Wed, 29 Jul 2009 15:31:48 +0200 User-Agent: KMail/1.11.2 (Linux/2.6.28-13-generic; KDE/4.2.2; i686; ; ) MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200907291531.49092.leifj@mnt.se> Subject: [OAUTH-WG] oauth saml bindings X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: leifj@mnt.se List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 13:31:53 -0000 Another topic that came up at the bar-BOF this morning was extensions (and use-cases) for sending attributes along with an OAuth authentication. After some discussion the room agreed that if such a thing was going to be attempted it should probably use existing attribute infrastructure, eg SAML. Hence the subject - SAML bindings for OAuth, that is a specification of how to send (certain types of) SAML protocol messages "over", or along side, OAuth. I'll provide a very simple use-case to show that this at least isn't just an academic exercise. Imagine using OAuth for some type of virtual worlds (aka grid) service where the user is first authenticated using a browser-based SSO (eg SAML WebSSO or OpenID 2.0) that supports asserting attributes about the user from the IdP to the relying party (application). The virtual worlds protocol runs over HTTP and the virtual world client application (which isn't the browser!) uses OAuth to authenticate to the virtual world server in order to operate on the protected resources that are the users objects in the world. During initial authentication (the WebSSO bit) the identity provider issues a SAML attribute assertion encrypted to the (key of the) virtual worlds server containing information about the user known to the IdP but not (a priori) known to the virtual worlds server (it can even be protected from the user). The browser doesn't communicate with the virtual worlds server, only the virtual worlds client does that but we need a way for the assertion to reach the virtual worlds server tied to the resource authentication. Cheers Leif From Eve.Maler@Sun.COM Wed Jul 29 07:22: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 0C4993A70EA for ; Wed, 29 Jul 2009 07:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.64 X-Spam-Level: X-Spam-Status: No, score=-4.64 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_MED=-4, 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 e3GsXqw6Zucz for ; Wed, 29 Jul 2009 07:22:29 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id 4710C3A70DA for ; Wed, 29 Jul 2009 07:22:29 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6TEMSqw008361 for ; Wed, 29 Jul 2009 14:22:28 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; delsp=yes; format=flowed Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KNJ00G00RRTHM00@mail-amer.sun.com> for oauth@ietf.org; Wed, 29 Jul 2009 08:22:28 -0600 (MDT) Received: from [172.28.169.79] ([unknown] [12.235.16.2]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KNJ004Z6RXFH2A0@mail-amer.sun.com>; Wed, 29 Jul 2009 08:22:28 -0600 (MDT) Date: Wed, 29 Jul 2009 07:22:27 -0700 From: Eve Maler In-reply-to: <4A703B74.9010504@bbn.com> Sender: Eve.Maler@Sun.COM To: Richard Barnes Message-id: X-Mailer: Apple Mail (2.935.3) References: <4A70004E.3000000@bbn.com> <4A70127F.8090009@stpeter.im> <4A70159A.5040206@bbn.com> <4A702593.5060308@bbn.com> <97CC5190-E828-48DD-A3F5-659F59681F3F@rediris.es> <4A703B74.9010504@bbn.com> Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] What is 4-legged OAuth? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 14:22:31 -0000 Hi folks-- I'm attending a conference in a different time zone, and so just saw this thread. Richard's idea of composing multiple instances of OAuth to get higher-order effects is great. It's not more legs, it's more instances of "three-legged" OAuth. Generating new solutions out of the same pieces is valuable. Regarding the discussion of "four-legged" OAuth, there are quite a few ways to add a true fourth party/entity (that's better than talking about "legs", I think), and it all depends on use cases. Lucy, thanks for mentioning ProtectServe! The idea here is to externalize the authorization decision itself into a fourth entity called an "authorization manager", which helps the user globally manage a complicated authz picture. ProtectServe *uses* OAuth in a couple of places but adds functionality, such as letting the user impose "contract terms" on the Consumer in accepting data and accessing services. We have found that OAuth isn't directly suitable for use in one of the two places because of a correlation/privacy issue, so that's one piece of feedback we can provide in terms of leveraging OAuth for new purposes -- we had to veer away from OAuth compliance. I've just started a group called "user-managed access" (UMA) to incubate a ProtectServe spec and implementations, with a goal of contributing the work to IETF. Interested folks are welcome to come on in. Regarding the list of potential new use cases etc. discussed at the breakfast BOF: A lot of these are interesting and timely. I ran a Project Concordia workshop on Monday where authorization was the big theme of the day, and a lot of "hybrid" scenarios involving OAuth subsequently came up. Maybe the OAuth and Concordia communities can work together where there's interest. Current best source of info about ProtectServe: http://www.xmlgrrl.com/blog/categories/protectserve/ A post that may help illustrate the entities I'm talking about: http://www.xmlgrrl.com/blog/archives/2009/04/05/relationship-authorization-make-up-your-mind/ Info on new UMA group: http://kantarainitiative.org/confluence/display/uma/Home Concordia post-workshop telecon notes: http://lists.projectconcordia.org/pipermail/community/2009-July/002074.html Thanks, Eve On 29 Jul 2009, at 5:07 AM, Richard Barnes wrote: > You're misunderstanding what I'm proposing. Let me try to state > what I'm thinking more clearly. For consistency, I'll use terms > from draft-barnes-oauth-model. > > I'm not proposing that one client simply pass its access token to > some other potential client -- you're absolutely correct that that > doesn't provide the user approval or traceability that you would want. > > What I'm talking about is doing the *entire* OAuth delegation > procedure twice: First with the User as RO and Client1 as Client, > then again with Client1 as RO and Client2 as Client (the Server > being the same the whole time). In graphic form: > > +----------+ --+ > | Resource | | > | Owner 1 | | > +----------+ | > ^| | OAuth 1 > || | > req-tk-1||ver-tk-1 | > |V | > +----------+----------+ | > +-----------req-tk-1----->| Client = Resource | --+ > | +---------acc-tk-1----->| 1 Owner 2 | --+ > | | +----------+----------+ | > +----------+ ^| | > | Server | || | > | | req-tk-2||ver-tk-2 | OAuth 2 > +----------+ |V | > | | +----------+ | > | +---------req-tk-2----->| Client | | > +-----------acc-tk 2----->| 2 | | > +----------+ --+ > > Doing this would enable accountable sub-delegation, since all the > delegations are made through the Server. > > The one thing that's not immediately clear is how you fit user > consent for the sub-delegation into this picture. But there's an > easy answer there too: Permission to sub-delegate is just another > permission that can be delegated via OAuth. In the above example, > Client1 would have to receive permission to sub-delegate to Client2 > in his initial transaction. You could also imagine a three-OAuth > model, where: > 1. OAuth1: RO grants Client1 permission to access resources > 2. Client1 requests permission to sub-delegate to Client2 > 3. OAuth2: RO grants Client1 permission to sub-delegate to Client2 > 4. OAuth3: Client 1 grants Client2 permission to access resources > > Either way, these are just concatenations of OAuth transactions. > What's missing, besides an informational document to describe how > this works? > > --Richard > > > > Diego R. Lopez wrote: >> Richard, >> On 29 Jul 2009, at 12:33, Richard Barnes wrote: >>> Having a well-defined procedure for delegation was the point of >>> OAuth in the first place! I'm just not clear on what risks you >>> introduce by re-using it to sub-delegate; none are immediately >>> clear to me. >> If I have understood you well, what you proposed is to allow >> clients to forward their authorization tokens >> to other potential clients. To do so, you can make it with or >> without user explicit consent. In the first case, >> unless you send back the user to the SP (what would be exactly the >> same as the three-legged case with just >> a shorter path in user interactions) you are allowing a third party >> to ask the user to take decisions on >> access to the SP, and this seems to me a clear path for phishing. >> In the second case, you are simply >> transmitting the authotization without the explicit user consent, >> and that would break several privacy >> protecting laws (at least, here in the EU) >> Furthermore, since traceability is a essential requirement for any >> access control infrastructure, >> the unconstrained delegation would require a strict control of the >> potential clients that can share >> a token at the SP, including a detailed check of who is using the >> token and from whom it was generated, >> and this requires as well the ability of tracing the delegation >> path up to the original client, implying >> that tokens must be augmented with traces of the delegations, and >> you'll agree in that this won't scale. >> Be goode, >> -- >> "Esta vez no fallaremos, Doctor Infierno" >> Dr Diego R. Lopez >> Red.es - RedIRIS >> The Spanish NREN >> e-mail: diego.lopez@rediris.es >> jid: diego.lopez@rediris.es >> Tel: +34 955 056 621 >> Mobile: +34 669 898 094 >> ----------------------------------------- > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth Eve Maler eve.maler @ sun.com Emerging Technologies Director cell +1 425 345 6756 Sun Microsystems Identity Software www.xmlgrrl.com/blog From jmeyer@linkedin.com Wed Jul 29 10:04: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 7C4923A6909 for ; Wed, 29 Jul 2009 10:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[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 C1bdijxTWvTo for ; Wed, 29 Jul 2009 10:04:29 -0700 (PDT) Received: from esv4-mav03.corp.linkedin.com (esv4-mav03.corp.linkedin.com [69.28.149.25]) by core3.amsl.com (Postfix) with ESMTP id B6CB03A6A00 for ; Wed, 29 Jul 2009 10:04:26 -0700 (PDT) DomainKey-Signature: s=prod; d=linkedin.com; c=nofws; q=dns; h=X-IronPort-AV:Received:X-Virus-Scanned:Received:Received: Cc:Message-Id:From:To:In-Reply-To:Content-Type: Content-Transfer-Encoding:Mime-Version:Subject:Date: References:X-Mailer; b=gsj78NhUf6AC04T9/vj4FTWC8HQn22i6Gt6WW84eaDkgyVwrpZC5hBc0 AmYEHqyZwPFd8HuzG8VuhQ2qlQRNHAVF87kHOyQp/oS6JsUf1/m2iXnkB mgrwbx/VkXuzVw6; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=linkedin.com; i=jmeyer@linkedin.com; q=dns/txt; s=proddkim; t=1248887068; x=1280423068; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Jim=20Meyer=20|Subject:=20R e:=20[OAUTH-WG]=20What=20is=204-legged=20OAuth?|Date:=20W ed,=2029=20Jul=202009=2010:04:25=20-0700|Message-Id:=20<3 CCB56E8-B859-497E-BE6A-90E2C7C3E1AF@linkedin.com>|To:=20E ve=20Maler=20|Cc:=20Richard=20Barnes =20,=0D=0A=20oauth@ietf.org |Mime-Version:=201.0=20(Apple=20Message=20framework=20v93 5.3)|Content-Transfer-Encoding:=207bit|In-Reply-To:=20|References: =20<4A70004E.3000000@bbn.com>=20<4A70127F.8090009@stpeter .im>=20<4A70159A.5040206@bbn.com>=20=20<4A702593.5060308@bbn.com> =20<97CC5190-E828-48DD-A3F5-659F59681F3F@rediris.es>=20<4 A703B74.9010504@bbn.com>=20; bh=ctEuBnGA4XOmayQo50eT6JP1udvqByXNS/lJefE3OPY=; b=Ipvu1AGlKZSOhiN+AyGU+esVZLXmEe8RGzskGgk8lr50XVCHRDI45+0d YZKqfwKgJ5aqlldsaRhL1Sj0occD8oANYq8C822dSN0h/RcZEQ1Xu3j2r RHFXhdHF3JxIm3/; X-IronPort-AV: E=Sophos;i="4.43,289,1246863600"; d="scan'208";a="7903726" Received: from localhost (localhost.localdomain [127.0.0.1]) by zpilot.corp.linkedin.com (Postfix) with ESMTP id EABFB1725C82; Wed, 29 Jul 2009 10:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at zpilot.corp.linkedin.com Received: from zpilot.corp.linkedin.com ([127.0.0.1]) by localhost (zpilot.corp.linkedin.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OA4FkJMeFZh8; Wed, 29 Jul 2009 10:03:48 -0700 (PDT) Received: from [10.16.18.228] (unknown [172.16.23.135]) by zpilot.corp.linkedin.com (Postfix) with ESMTP id C697D1725C81; Wed, 29 Jul 2009 10:03:48 -0700 (PDT) Message-Id: <3CCB56E8-B859-497E-BE6A-90E2C7C3E1AF@linkedin.com> From: Jim Meyer To: Eve Maler 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 v935.3) Date: Wed, 29 Jul 2009 10:04:25 -0700 References: <4A70004E.3000000@bbn.com> <4A70127F.8090009@stpeter.im> <4A70159A.5040206@bbn.com> <4A702593.5060308@bbn.com> <97CC5190-E828-48DD-A3F5-659F59681F3F@rediris.es> <4A703B74.9010504@bbn.com> X-Mailer: Apple Mail (2.935.3) Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] What is 4-legged OAuth? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 17:04:30 -0000 +1 for discussing these as "two-party", "three-party", etc. rather than "*-legged" or the number of delegations involved. It seems to lead directly to the question, "Who are the parties and what are their roles?" which lends focus and clarity to the explanation. --j On Jul 29, 2009, at 2:12 AM, Peter Saint-Andre wrote: > One thing we discussed this morning was that all this talk of legs is > confusing. I think we had rough consensus on something like the > following terminology... > > "two-legged" = authentication > > "three-legged" = single-layer delegation > > "four-legged" (and more) = multi-layer delegation On Jul 29, 2009, at 7:22 AM, Eve Maler wrote: > Regarding the discussion of "four-legged" OAuth, there are quite a > few ways to add a true fourth party/entity (that's better than > talking about "legs", I think), From diego.lopez@rediris.es Wed Jul 29 14:05: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 E4DDC3A6B43 for ; Wed, 29 Jul 2009 14:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.555 X-Spam-Level: X-Spam-Status: No, score=-6.555 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, 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 rIqxcszAAHgM for ; Wed, 29 Jul 2009 14:05:46 -0700 (PDT) Received: from irisout1.rediris.es (irisout1.rediris.es [130.206.24.3]) by core3.amsl.com (Postfix) with ESMTP id 5646C3A6BB4 for ; Wed, 29 Jul 2009 14:05:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.43,290,1246831200"; d="scan'208";a="9371447" Received: from 85.137.215.13.dyn.user.ono.com (HELO incal.lan) ([85.137.215.13]) by abel.rediris.es with ESMTP/TLS/AES128-SHA; 29 Jul 2009 23:05:51 +0200 Message-Id: From: "Diego R. Lopez" To: Richard Barnes In-Reply-To: <4A703B74.9010504@bbn.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 29 Jul 2009 18:34:15 +0200 References: <4A70004E.3000000@bbn.com> <4A70127F.8090009@stpeter.im> <4A70159A.5040206@bbn.com> <4A702593.5060308@bbn.com> <97CC5190-E828-48DD-A3F5-659F59681F3F@rediris.es> <4A703B74.9010504@bbn.com> X-Mailer: Apple Mail (2.935.3) Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] What is 4-legged OAuth? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 21:05:48 -0000 Hi Richard, On 29 Jul 2009, at 14:07, Richard Barnes wrote: > You're misunderstanding what I'm proposing. Let me try to state > what I'm thinking more clearly. For consistency, I'll use terms > from draft-barnes-oauth-model. > > I'm not proposing that one client simply pass its access token to > some other potential client -- you're absolutely correct that that > doesn't provide the user approval or traceability that you would want. > > What I'm talking about is doing the *entire* OAuth delegation > procedure twice: First with the User as RO and Client1 as Client, > then again with Client1 as RO and Client2 as Client (the Server > being the same the whole time). In graphic form: . . . Agreed. I totally misunderstood your first statement, probably because the fourth leg idea misled me. Looking at it now, it totally makes sense, though I'd say is more a chained- three-legged than a four-legged model... > Doing this would enable accountable sub-delegation, since all the > delegations are made through the Server. Indeed. > The one thing that's not immediately clear is how you fit user > consent for the sub-delegation into this picture. But there's an > easy answer there too: Permission to sub-delegate is just another > permission that can be delegated via OAuth. In the above example, > Client1 would have to receive permission to sub-delegate to Client2 > in his initial transaction. You could also imagine a three-OAuth > model, where: > 1. OAuth1: RO grants Client1 permission to access resources > 2. Client1 requests permission to sub-delegate to Client2 > 3. OAuth2: RO grants Client1 permission to sub-delegate to Client2 > 4. OAuth3: Client 1 grants Client2 permission to access resources Or a fourth or a fitfth or... That's why I think that calling it "chained" would be better. > Either way, these are just concatenations of OAuth transactions. > What's missing, besides an informational document to describe how > this works? Nothing, I'd say... Anyway, I still have a couple of concerns about usability and transitivity. Usability in this context is very much connected to practical security and to the requirement for informed consent: I think that the way in which confirmation for delegation and its limits are presented to the user is a key aspect, and should be stressed in the discussion of security aspects. Second, I assume that the permission for delegation can only be granted by the first transaction, so further delegations in delegated transactions should be explicitly prohibited. Be goode, -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Red.es - RedIRIS The Spanish NREN e-mail: diego.lopez@rediris.es jid: diego.lopez@rediris.es Tel: +34 955 056 621 Mobile: +34 669 898 094 ----------------------------------------- From eran@hueniverse.com Wed Jul 29 23:07: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 715433A6AA0 for ; Wed, 29 Jul 2009 23:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pf2352sspZxQ for ; Wed, 29 Jul 2009 23:07:27 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 7EE0F3A693F for ; Wed, 29 Jul 2009 23:07:27 -0700 (PDT) Received: (qmail 31949 invoked from network); 30 Jul 2009 06:07:29 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 30 Jul 2009 06:07:29 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 29 Jul 2009 23:07:28 -0700 From: Eran Hammer-Lahav To: "oauth@ietf.org" Date: Wed, 29 Jul 2009 23:07:21 -0700 Thread-Topic: [OAUTH-WG] Breakfast BoF minutes Thread-Index: AcoQGNOIenEe2UtBR2yoPlvwkgkjowAwDOXw Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234378356288A@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4A6FF11A.40208@stpeter.im> In-Reply-To: <4A6FF11A.40208@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] Breakfast BoF minutes X-BeenThere: oauth@ietf.org X-Mailman-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, 30 Jul 2009 06:07:28 -0000 Thanks Peter for great and speedy notes. It is somewhat disappointing that the majority of these items are outside t= he scope of the WG and seem to distract us from making progress on the core= protocol... I'd like to remind everyone that we are not here to invent a n= ew delegation protocol from scratch, and at the same time, OAuth is not a c= odename for 'a popular protocol I can change as I see fit for my own needs,= and still call it OAuth'. Comments inline. > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Peter Saint-Andre > Sent: Tuesday, July 28, 2009 11:50 PM >=20 > 1. OAuth for delegation. Currently the spec addresses only single-layer > delegation ("three-legged") and is silent about multi-layer delegation. > If we don't define this in a standard way, different people will find > different, non-standard ways to do it. We need to gather use cases and > work on specifying it. This has been raised many times over the past 2 years and no one has actual= ly offered real world use cases. =20 > 2. Non-WWW use cases. Let's gather these (shared calendaring, XMPP > chatroom ownership, exchange of app-level blobs, etc.). What does non-www mean? Non-HTTP? =20 > 3. OAuth for authentication. In this case, OAuth could be used to > replace DIGEST for authn. It's possible that SCRAM could be used as a > signing method. The group also talked about defining various related > SASL mechanisms (SAML, OpenID, OAuth). We need to keep separate authentication of protected resources requests and= authentication of end users (for granting access). OAuth authentication ha= s nothing to do with SAML or OpenID. How the end user is authenticated is s= trictly out of scope for OAuth (the user is redirected, magic happens, user= redirected back). As for supplementing Digest with a new authentication methods, that is part= of our charter. Also, I think Alexey has an action item to write a review = of using SCRAM in OAuth... was any progress made on this front? =20 > 4. Channel bindings. There are similarities here to HTTPS/DIGEST (Leif > Johansson mentioned an expired I-D about this and volunteered to post to > the list). This is a bit outside my personal area of expertise, but it does look relev= ant in the discussion of a new 2617-based authentication method. =20 > 5. Attribute extensions. Could we use OAuth for transporting existing > SAML formats? I would ask for use cases but would rather just keep this discussion out of= scope for now given the need to focus on getting chartered work done. =20 > 6. Split off the header signing aspects of OAuth, or at least call that > out more clearly in the spec? Someone at the BoF likened this to "DKIM > for the Web". Split off from what? =20 > 7. The spec is not designed to be profiled and extended. Is this OK? Nor does it really prevent it as the many extensions prove. We do need to a= ddress this to make it easier and clearer. As for profiling, this is what w= e are trying to do to the community spec in the WG, and as we make progress= , I think we will see how easy/hard it is. =20 > 8. Do callbacks need to be forward-ported to the I-D? Huh? =20 > 9. Discussion redirects. Currently most folks still take their items to > the googlegroups list. That's fine, but going forward we would like to > use the WG list for topics related to the core specifications. Nope. The existing list is the right home for 1.0 and 1.0a support issues, = including all code related topics (libraries, etc.). I have yet to see thre= ads posted to the Google group that should have been posted to the WG list. EHL From leifj@mnt.se Thu Jul 30 02:14: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 EF8DE3A6F24 for ; Thu, 30 Jul 2009 02:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DOqXQVmYiYI6 for ; Thu, 30 Jul 2009 02:14:45 -0700 (PDT) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by core3.amsl.com (Postfix) with ESMTP id 9D3423A6FE5 for ; Thu, 30 Jul 2009 02:14:45 -0700 (PDT) Received: by bwz19 with SMTP id 19so456931bwz.37 for ; Thu, 30 Jul 2009 02:14:45 -0700 (PDT) Received: by 10.103.6.18 with SMTP id j18mr516310mui.117.1248945285239; Thu, 30 Jul 2009 02:14:45 -0700 (PDT) Received: from klapautius.localnet (dhcp-16e2.meeting.ietf.org [130.129.22.226]) by mx.google.com with ESMTPS id j2sm17016mue.20.2009.07.30.02.14.44 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 30 Jul 2009 02:14:44 -0700 (PDT) To: oauth@ietf.org Content-Disposition: inline From: Leif Johansson Organization: mnt.se Date: Thu, 30 Jul 2009 11:14:41 +0200 MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200907301114.42106.leifj@mnt.se> Subject: Re: [OAUTH-WG] Breakfast BoF minutes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: leifj@mnt.se List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 09:14:47 -0000 On Thursday 30 July 2009 08.07.21 Eran Hammer-Lahav wrote: > Thanks Peter for great and speedy notes. > > It is somewhat disappointing that the majority of these items are outside > the scope of the WG and seem to distract us from making progress on the > core protocol... I'd like to remind everyone that we are not here to invent > a new delegation protocol from scratch, and at the same time, OAuth is not > a codename for 'a popular protocol I can change as I see fit for my own > needs, and still call it OAuth'. > Could you be more specific in your criticism? Which of the suggestions do you think is out of scope and why (given our charter)? Note that change-control for the WG charter ultimately resides with the IESG. Cheers Leif From eran@hueniverse.com Thu Jul 30 10:41: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 9748828C304 for ; Thu, 30 Jul 2009 10:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 56zZDVjYaAz4 for ; Thu, 30 Jul 2009 10:41:49 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 6FE5928C30C for ; Thu, 30 Jul 2009 10:41:49 -0700 (PDT) Received: (qmail 7830 invoked from network); 30 Jul 2009 17:41:51 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 30 Jul 2009 17:41:51 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 30 Jul 2009 10:41:47 -0700 From: Eran Hammer-Lahav To: Leif Johansson , "oauth@ietf.org" Date: Thu, 30 Jul 2009 10:41:42 -0700 Thread-Topic: [OAUTH-WG] Breakfast BoF minutes Thread-Index: AcoQ47XRksU7Ic6VR8ONUodLTwlPWAAWSRhg Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234378356290A@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4A6FF11A.40208@stpeter.im> <90C41DD21FB7C64BB94121FBBC2E7234378356288A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <200907300902.27929.leifj@sunet.se> In-Reply-To: <200907300902.27929.leifj@sunet.se> 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] Breakfast BoF minutes X-BeenThere: oauth@ietf.org X-Mailman-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, 30 Jul 2009 17:41:50 -0000 First, my issue with scope isn't about technical changes, but about being p= roductive. We have made no progress so far and to start branching out at th= is point will make it even worse. As for individual points, I did comment on each item... EHL > -----Original Message----- > From: Leif Johansson [mailto:leifj@sunet.se] > Sent: Thursday, July 30, 2009 12:02 AM > To: oauth@ietf.org > Cc: Eran Hammer-Lahav > Subject: Re: [OAUTH-WG] Breakfast BoF minutes >=20 > On Thursday 30 July 2009 08.07.21 Eran Hammer-Lahav wrote: > > Thanks Peter for great and speedy notes. > > > > It is somewhat disappointing that the majority of these items are > outside > > the scope of the WG and seem to distract us from making progress on > the > > core protocol... I'd like to remind everyone that we are not here to > invent > > a new delegation protocol from scratch, and at the same time, OAuth > is not > > a codename for 'a popular protocol I can change as I see fit for my > own > > needs, and still call it OAuth'. > > >=20 > Could you be more specific in your criticism? Which of the suggestions > do you > think is out of scope and why (given our charter)? Note that change- > control > for the WG charter ultimately resides with the IESG. >=20 > Cheers Leif From leifj@mnt.se Fri Jul 31 04:05: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 3493D3A6A3B for ; Fri, 31 Jul 2009 04:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.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 BXQbfqd3tMCV for ; Fri, 31 Jul 2009 04:05:32 -0700 (PDT) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by core3.amsl.com (Postfix) with ESMTP id 45E5B3A68E8 for ; Fri, 31 Jul 2009 04:05:31 -0700 (PDT) Received: by bwz19 with SMTP id 19so1122766bwz.37 for ; Fri, 31 Jul 2009 04:05:31 -0700 (PDT) Received: by 10.103.229.12 with SMTP id g12mr120042mur.12.1249038331188; Fri, 31 Jul 2009 04:05:31 -0700 (PDT) Received: from klapautius.localnet (dhcp-16e2.meeting.ietf.org [130.129.22.226]) by mx.google.com with ESMTPS id 14sm18519027muo.3.2009.07.31.04.05.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 31 Jul 2009 04:05:30 -0700 (PDT) To: oauth@ietf.org Content-Disposition: inline From: Leif Johansson Organization: mnt.se Date: Fri, 31 Jul 2009 13:05:27 +0200 MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200907311305.27957.leifj@mnt.se> Subject: Re: [OAUTH-WG] Breakfast BoF minutes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: leifj@mnt.se List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 11:05:33 -0000 On Thursday 30 July 2009 19.41.42 Eran Hammer-Lahav wrote: > First, my issue with scope isn't about technical changes, but about being > productive. We have made no progress so far and to start branching out at > this point will make it even worse. I agree that progress is needed on the core specifications but that doesn't preclude thinking and talking about what comes next. If you say "Lets not add documents to our charter before we finish what we already have on our plate" then I fully agree. I don't agree that _discussions_ on the list need to get shut down just because they aren't part of the charter - how could we ever decide on new charter items otherwise? Cheers Leif From leifj@mnt.se Fri Jul 31 04:06: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 BD92D3A6C4D for ; Fri, 31 Jul 2009 04:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xw4hpjZYHM4e for ; Fri, 31 Jul 2009 04:06:35 -0700 (PDT) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by core3.amsl.com (Postfix) with ESMTP id D46413A6825 for ; Fri, 31 Jul 2009 04:06:34 -0700 (PDT) Received: by bwz19 with SMTP id 19so1123208bwz.37 for ; Fri, 31 Jul 2009 04:06:34 -0700 (PDT) Received: by 10.103.220.18 with SMTP id x18mr1401753muq.67.1249038394106; Fri, 31 Jul 2009 04:06:34 -0700 (PDT) Received: from klapautius.localnet (dhcp-16e2.meeting.ietf.org [130.129.22.226]) by mx.google.com with ESMTPS id 23sm8417957mum.35.2009.07.31.04.06.33 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 31 Jul 2009 04:06:33 -0700 (PDT) To: oauth@ietf.org Content-Disposition: inline From: Leif Johansson Organization: mnt.se Date: Fri, 31 Jul 2009 13:06:31 +0200 MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200907311306.31382.leifj@mnt.se> Subject: Re: [OAUTH-WG] Breakfast BoF minutes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: leifj@mnt.se List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 11:06:35 -0000 > > 5. Attribute extensions. Could we use OAuth for transporting existing > > SAML formats? > > I would ask for use cases but would rather just keep this discussion out of > scope for now given the need to focus on getting chartered work done. > I sent those in a separate message to the list. > > 6. Split off the header signing aspects of OAuth, or at least call that > > out more clearly in the spec? Someone at the BoF likened this to "DKIM > > for the Web". > > Split off from what? The idea was to describe header signing independent of oauth (and have oauth reference that specification) which uses header signing as a way to define an http authentication mechanism. Cheers Leif From eran@hueniverse.com Fri Jul 31 09:57: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 E46D53A6B7D for ; Fri, 31 Jul 2009 09:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 uGhfNjzB-Zpt for ; Fri, 31 Jul 2009 09:57:19 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 367DA3A6EAC for ; Fri, 31 Jul 2009 09:57:19 -0700 (PDT) Received: (qmail 3547 invoked from network); 31 Jul 2009 16:57:21 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 31 Jul 2009 16:57:21 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Fri, 31 Jul 2009 09:57:18 -0700 From: Eran Hammer-Lahav To: Leif Johansson , "oauth@ietf.org" Date: Fri, 31 Jul 2009 09:57:16 -0700 Thread-Topic: [OAUTH-WG] Breakfast BoF minutes Thread-Index: AcoRzrvO617B/QIeQLyPQsTfr/eoxQAMNj8Q Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343783562A33@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4A6FF11A.40208@stpeter.im> <200907300902.27929.leifj@sunet.se> <90C41DD21FB7C64BB94121FBBC2E7234378356290A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <200907311304.49847.leifj@sunet.se> In-Reply-To: <200907311304.49847.leifj@sunet.se> 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] Breakfast BoF minutes X-BeenThere: oauth@ietf.org X-Mailman-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, 31 Jul 2009 16:57:20 -0000 It would be nice to have *any* discussion at this point about what's in sco= pe. Really, anything at all... Or maybe everyone is just happy with the two= draft and we should sent them to last call? Not likely. I opened a couple = of issues and have seen no response. We are in agreement but I would *prefer* that we let the chartered work at = least begin before we start taking attention off and on to other (related) = matters. EHL > -----Original Message----- > From: Leif Johansson [mailto:leifj@sunet.se] > Sent: Friday, July 31, 2009 4:05 AM > To: oauth@ietf.org > Cc: Eran Hammer-Lahav > Subject: Re: [OAUTH-WG] Breakfast BoF minutes >=20 > On Thursday 30 July 2009 19.41.42 Eran Hammer-Lahav wrote: > > First, my issue with scope isn't about technical changes, but about > being > > productive. We have made no progress so far and to start branching > out at > > this point will make it even worse. >=20 > I agree that progress is needed on the core specifications but that > doesn't > preclude thinking and talking about what comes next. >=20 > If you say "Lets not add documents to our charter before we finish what > we > already have on our plate" then I fully agree. >=20 > I don't agree that _discussions_ on the list need to get shut down just > because they aren't part of the charter - how could we ever decide on > new > charter items otherwise? >=20 > Cheers Leif From eran@hueniverse.com Fri Jul 31 09:59: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 56A5E3A6AAB for ; Fri, 31 Jul 2009 09:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DvEw-ccGhAUO for ; Fri, 31 Jul 2009 09:59:39 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 4F1C83A6EEF for ; Fri, 31 Jul 2009 09:59:08 -0700 (PDT) Received: (qmail 19196 invoked from network); 31 Jul 2009 16:59:10 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 31 Jul 2009 16:59:10 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Fri, 31 Jul 2009 09:59:06 -0700 From: Eran Hammer-Lahav To: Leif Johansson , "oauth@ietf.org" Date: Fri, 31 Jul 2009 09:59:04 -0700 Thread-Topic: [OAUTH-WG] Breakfast BoF minutes Thread-Index: AcoRzkg4XFOK3FebTF+hrkgAUuZ2lgAMcEMQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343783562A36@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4A6FF11A.40208@stpeter.im> <90C41DD21FB7C64BB94121FBBC2E7234378356288A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <200907311301.36266.leifj@sunet.se> In-Reply-To: <200907311301.36266.leifj@sunet.se> 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] Breakfast BoF minutes X-BeenThere: oauth@ietf.org X-Mailman-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, 31 Jul 2009 16:59:40 -0000 > -----Original Message----- > From: Leif Johansson [mailto:leifj@sunet.se] > Sent: Friday, July 31, 2009 4:02 AM > To: oauth@ietf.org > Cc: Eran Hammer-Lahav > Subject: Re: [OAUTH-WG] Breakfast BoF minutes > > > 6. Split off the header signing aspects of OAuth, or at least call > that > > > out more clearly in the spec? Someone at the BoF likened this to > "DKIM > > > for the Web". > > > > Split off from what? >=20 > The idea was to describe header signing independent of oauth (and have > oauth reference that specification) which uses header signing as a way > to > define an http authentication mechanism. When you say 'header signing' do you mean signing an HTTP header? OAuth doe= s not provide that today. EHL From esjewett@gmail.com Fri Jul 31 10:16: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 9A3923A6AAB for ; Fri, 31 Jul 2009 10:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ej02--tWhYzo for ; Fri, 31 Jul 2009 10:16:31 -0700 (PDT) Received: from mail-fx0-f217.google.com (mail-fx0-f217.google.com [209.85.220.217]) by core3.amsl.com (Postfix) with ESMTP id 54DD03A6924 for ; Fri, 31 Jul 2009 10:16:31 -0700 (PDT) Received: by fxm17 with SMTP id 17so1493303fxm.37 for ; Fri, 31 Jul 2009 10:16:31 -0700 (PDT) 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=UxqOZN3eOfz4ku4Z7ejfMpr5WOE+I2Lnb/JbAc9tJIA=; b=VRg4IHFCU0wr5euHtzFEg0t08zFZR18yKPFSMb7F+C2U8KD3FX6In8ajSRTWqVGsvO Cgwox08+Cb0X0okpXMrgRYLdJzRxgHvIlpGK0tuYFU8+4cG442ZgeZMReB2vxoPN45Mp td8t4eTeKCtp3MPVGb4U4C87IpJ3jSqlUq2XE= 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=f/c607JsvggdTl8DKX/eIkeZdHTxaCw/z9Jg/RnoBmUlLO/PKrjJwAHf9SnIC6+ie4 WVthIsd6K5cwAaQPHhdPuoo3M/2liuw+PJghvUVoSfOa30u3jl/idfIei1h+j8StbvEx IQInbH1KMqB3vIKGvGgStd0EAk/Z9vI/EABTQ= MIME-Version: 1.0 Received: by 10.239.175.140 with SMTP id n12mr273466hbf.164.1249060590827; Fri, 31 Jul 2009 10:16:30 -0700 (PDT) In-Reply-To: <059.36f227d7f81e520e6c5fec0b2a5faab4@tools.ietf.org> References: <059.36f227d7f81e520e6c5fec0b2a5faab4@tools.ietf.org> Date: Fri, 31 Jul 2009 13:16:30 -0400 Message-ID: <68f4a0e80907311016mfd6b31cm7009af214d15b423@mail.gmail.com> From: Ethan Jewett To: oauth@ietf.org Content-Type: multipart/alternative; boundary=0016363b9c5ad1b74104700394fa Subject: Re: [OAUTH-WG] [oauth] #4: Error Codes X-BeenThere: oauth@ietf.org X-Mailman-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, 31 Jul 2009 17:16:32 -0000 --0016363b9c5ad1b74104700394fa Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Is the proposal to consider including the basic approach of the problem reporting extension linked below into the authentication portion of the spec? I think this would be a good approach. I think it would also be beneficial to consider including similar (or preferably the same) error reporting functionality in the web-delegation portion of the spec, since post-rev1.0a oauth requires signing of the token requests and signing is where implementors and library authors seem to run into a lot of problems. Perhaps this issue should be categorized under both components? Ethan On Tue, Jul 21, 2009 at 6:35 PM, oauth issue tracker wrote: > #4: Error Codes > > ---------------------------------+------------------------------------------ > Reporter: eran@hueniverse.com | Owner: > > Section 8 poorly defines the HTTP response status codes (400 and 401), and > does not provide for any mechanism to convey the actual protocol errors > preventing the client from successfully authenticating. > > A proposed 'problem reporting' extension has been proposed for the Core > 1.0 protocol: > > http://wiki.oauth.net/ProblemReporting > > --0016363b9c5ad1b74104700394fa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Is the proposal to consider including the basic approach of the problem rep= orting extension linked below into the authentication portion of the spec? = I think this would be a good approach.

I think it would = also be beneficial to consider including similar (or preferably the same) e= rror reporting functionality in the web-delegation portion of the spec, sin= ce post-rev1.0a oauth requires signing of the token requests and signing is= where implementors and library authors seem to run into a lot of problems.=

Perhaps this issue should be categorized under both com= ponents?

Ethan
--0016363b9c5ad1b74104700394fa-- From trac@tools.ietf.org Fri Jul 31 10:26: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 955363A6E8D for ; Fri, 31 Jul 2009 10:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FV74fwJw-ZVm for ; Fri, 31 Jul 2009 10:26:25 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id E35D03A6B7D for ; Fri, 31 Jul 2009 10:26:25 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1MWvsB-0000ys-UD; Fri, 31 Jul 2009 10:26:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="ascii" Content-Transfer-Encoding: 7bit From: "oauth issue tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: esjewett@gmail.com X-Trac-Project: oauth Date: Fri, 31 Jul 2009 17:26:27 -0000 X-URL: http://tools.ietf.org/oauth/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/oauth/trac/ticket/2#comment:1 Message-ID: <068.937e1ea2cd33a7caf30101640b3ebfed@tools.ietf.org> References: <059.448e0b5ce4a5c1783037fbe21d9531fa@tools.ietf.org> X-Trac-Ticket-ID: 2 In-Reply-To: <059.448e0b5ce4a5c1783037fbe21d9531fa@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: esjewett@gmail.com, oauth@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] [oauth] #2: No Required Signature Method X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 17:26:26 -0000 #2: No Required Signature Method ---------------------------------+------------------------------------------ Reporter: eran@hueniverse.com | Owner: Type: defect | Status: new Priority: major | Milestone: Component: authentication | Version: Severity: Active WG Document | Resolution: Keywords: | ---------------------------------+------------------------------------------ Comment(by esjewett@gmail.com): It seems that there must be use-cases for each of the three signature methods in which it makes sense for a provider/server to support only that signature method and neither of the other two. Plaintext: Communication only allowed over SSL HMAC-SHA1: Communication over SSL not available, payload not sensitive RSA-SHA1: ??? Perhaps we can mandate HMAC-SHA1, which could also be used with SSL or TLS and providers can support the PLAINTEXT at their discretion. It would depend on the requirements that led to RSA-SHA1 and the processing overhead of HMAC-SH1 on mobile devices, neither of which are areas I am familiar with. -- Ticket URL: oauth From eran@hueniverse.com Fri Jul 31 10:27: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 A09F13A6B7D for ; Fri, 31 Jul 2009 10:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, 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 PwpvSjim7Rqr for ; Fri, 31 Jul 2009 10:27:47 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 6715C3A6B36 for ; Fri, 31 Jul 2009 10:27:47 -0700 (PDT) Received: (qmail 27338 invoked from network); 31 Jul 2009 17:27:49 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 31 Jul 2009 17:27:49 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Fri, 31 Jul 2009 10:27:49 -0700 From: Eran Hammer-Lahav To: Ethan Jewett , "oauth@ietf.org" Date: Fri, 31 Jul 2009 10:27:47 -0700 Thread-Topic: [OAUTH-WG] [oauth] #4: Error Codes Thread-Index: AcoSAqlrOlZU2aQrSmK/M/EjeiJlJQAAWl+Q Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343783562A58@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <059.36f227d7f81e520e6c5fec0b2a5faab4@tools.ietf.org> <68f4a0e80907311016mfd6b31cm7009af214d15b423@mail.gmail.com> In-Reply-To: <68f4a0e80907311016mfd6b31cm7009af214d15b423@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_90C41DD21FB7C64BB94121FBBC2E72343783562A58P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] [oauth] #4: Error Codes X-BeenThere: oauth@ietf.org X-Mailman-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, 31 Jul 2009 17:27:48 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343783562A58P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think if you solve it in the authentication part, the delegation parts si= mply inherits it. However, it might need to extend it with some delegation = specific codes. The main problem with the problem reporting extension today is that it is t= oo rich and complex without adding value. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= than Jewett Sent: Friday, July 31, 2009 10:17 AM To: oauth@ietf.org Subject: Re: [OAUTH-WG] [oauth] #4: Error Codes Is the proposal to consider including the basic approach of the problem rep= orting extension linked below into the authentication portion of the spec? = I think this would be a good approach. I think it would also be beneficial to consider including similar (or prefe= rably the same) error reporting functionality in the web-delegation portion= of the spec, since post-rev1.0a oauth requires signing of the token reques= ts and signing is where implementors and library authors seem to run into a= lot of problems. Perhaps this issue should be categorized under both components? Ethan On Tue, Jul 21, 2009 at 6:35 PM, oauth issue tracker > wrote: #4: Error Codes ---------------------------------+-----------------------------------------= - Reporter: eran@hueniverse.com | Owner: Section 8 poorly defines the HTTP response status codes (400 and 401), and does not provide for any mechanism to convey the actual protocol errors preventing the client from successfully authenticating. A proposed 'problem reporting' extension has been proposed for the Core 1.0 protocol: http://wiki.oauth.net/ProblemReporting --_000_90C41DD21FB7C64BB94121FBBC2E72343783562A58P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I think if you solve it in the authentication part, the delegation parts simply inherits it. However, it might need to extend it wi= th some delegation specific codes.

 

The main problem with the problem reporting extension today = is that it is too rich and complex without adding value.

 

EHL

 

From: oauth-bounces= @ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Ethan Jewett
Sent: Friday, July 31, 2009 10:17 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] [oauth] #4: Error Codes

 

Is the proposal to consider including the basic approa= ch of the problem reporting extension linked below into the authentication portio= n of the spec? I think this would be a good approach.

 

I think it would also be beneficial to consider includ= ing similar (or preferably the same) error reporting functionality in the web-delegation portion of the spec, since post-rev1.0a oauth requires signi= ng of the token requests and signing is where implementors and library authors seem to run into a lot of problems.

 

Perhaps this issue should be categorized under both components?

 

Ethan

 

On Tue, Jul 21, 2009 at 6:35 PM, oauth issue tracker &= lt;trac@tools.ietf.org> wrote:=

#4: Error Codes
---------------------------------+-----------------------------------------= -
 Reporter:  eran@huenivers= e.com  |       Owner:

 Section 8 poorly defines the HTTP response status codes (400 and 401)= , and
 does not provide for any mechanism to convey the actual protocol erro= rs
 preventing the client from successfully authenticating.

 A proposed 'problem reporting' extension has been proposed for the Co= re
 1.0 protocol:

 = http://wiki.oauth.net/ProblemReporting

 

--_000_90C41DD21FB7C64BB94121FBBC2E72343783562A58P3PW5EX1MB01E_-- From trac@tools.ietf.org Fri Jul 31 10:34: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 858903A6DB9 for ; Fri, 31 Jul 2009 10:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GU1Psuug17Lp for ; Fri, 31 Jul 2009 10:34:50 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id D1B923A6D9F for ; Fri, 31 Jul 2009 10:34:50 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1MWw0K-0007qw-UX; Fri, 31 Jul 2009 10:34:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="ascii" Content-Transfer-Encoding: 7bit From: "oauth issue tracker" X-Trac-Version: 0.11.1 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.1, by Edgewall Software To: esjewett@gmail.com X-Trac-Project: oauth Date: Fri, 31 Jul 2009 17:34:52 -0000 X-URL: http://tools.ietf.org/oauth/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/oauth/trac/ticket/3#comment:1 Message-ID: <068.9cdfe35c4d230d2864f377d4915301c1@tools.ietf.org> References: <059.93566784ff77fdb326fb5f22b11c9b17@tools.ietf.org> X-Trac-Ticket-ID: 3 In-Reply-To: <059.93566784ff77fdb326fb5f22b11c9b17@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: esjewett@gmail.com, oauth@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] [oauth] #3: Discovery Outline / Boundries X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 17:34:51 -0000 #3: Discovery Outline / Boundries ---------------------------------+------------------------------------------ Reporter: eran@hueniverse.com | Owner: Type: task | Status: new Priority: major | Milestone: Component: web-delegation | Version: Severity: Active WG Document | Resolution: Keywords: | ---------------------------------+------------------------------------------ Comment(by esjewett@gmail.com): Barring other concerns, it seems that it would be helpful to define at least optional parameters in the response to the get_request_token request that fully define the request_auth and get_token URLs. Would this be a problem in any scenarios? I don't see the way to discovery of the initial get_request_token URL without a more full-featured discovery mechanism, which I guess is out of scope, but also seems somewhat unnecessary. Possibly we could define a parameter in whatever problem reporting approach we decide to adopt in response to https://trac.tools.ietf.org/wg/oauth/trac/ticket/4 that would provide the get_request_token URL to the client. -- Ticket URL: oauth From eran@hueniverse.com Fri Jul 31 10:45: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 636273A6942 for ; Fri, 31 Jul 2009 10:45:17 -0700 (PDT) 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, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XUhMAaTpe6n6 for ; Fri, 31 Jul 2009 10:45:16 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 87BE43A6828 for ; Fri, 31 Jul 2009 10:45:16 -0700 (PDT) Received: (qmail 308 invoked from network); 31 Jul 2009 17:45:18 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 31 Jul 2009 17:45:17 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 31 Jul 2009 10:45:16 -0700 From: Eran Hammer-Lahav To: "trac@localhost.amsl.com" , "esjewett@gmail.com" Date: Fri, 31 Jul 2009 10:45:13 -0700 Thread-Topic: [OAUTH-WG] [oauth] #3: Discovery Outline / Boundries Thread-Index: AcoSBThhQzyAMfcxRX+FbPLb62XkkAAAVu4Q Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343783562A60@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <059.93566784ff77fdb326fb5f22b11c9b17@tools.ietf.org> <068.9cdfe35c4d230d2864f377d4915301c1@tools.ietf.org> In-Reply-To: <068.9cdfe35c4d230d2864f377d4915301c1@tools.ietf.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] [oauth] #3: Discovery Outline / Boundries X-BeenThere: oauth@ietf.org X-Mailman-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, 31 Jul 2009 17:45:17 -0000 (I think it would be best to use the list for discussing this issues, and n= ot the issue tracker system...) EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of oauth issue tracker > Sent: Friday, July 31, 2009 10:35 AM > To: esjewett@gmail.com > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] [oauth] #3: Discovery Outline / Boundries >=20 > #3: Discovery Outline / Boundries > ---------------------------------+------------------------------------- > ----- > Reporter: eran@hueniverse.com | Owner: > Type: task | Status: new > Priority: major | Milestone: > Component: web-delegation | Version: > Severity: Active WG Document | Resolution: > Keywords: | > ---------------------------------+------------------------------------- > ----- >=20 > Comment(by esjewett@gmail.com): >=20 > Barring other concerns, it seems that it would be helpful to define at > least optional parameters in the response to the get_request_token > request > that fully define the request_auth and get_token URLs. Would this be a > problem in any scenarios? >=20 > I don't see the way to discovery of the initial get_request_token URL > without a more full-featured discovery mechanism, which I guess is out > of > scope, but also seems somewhat unnecessary. Possibly we could define a > parameter in whatever problem reporting approach we decide to adopt in > response to https://trac.tools.ietf.org/wg/oauth/trac/ticket/4 that > would > provide the get_request_token URL to the client. >=20 > -- > Ticket URL: > > oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth