From oauth-bounces@ietf.org Sun Feb 1 16:10:01 2009 Return-Path: X-Original-To: oauth-archive@ietf.org Delivered-To: ietfarch-oauth-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25A1E28C1DF; Sun, 1 Feb 2009 16:10:01 -0800 (PST) X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E05FB28C1D4 for ; Sun, 1 Feb 2009 16:09:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, WHOIS_DMNBYPROXY=0.478] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MPBJyLyqiPpq for ; Sun, 1 Feb 2009 16:09:58 -0800 (PST) Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.185]) by core3.amsl.com (Postfix) with ESMTP id 836F13A6864 for ; Sun, 1 Feb 2009 16:09:57 -0800 (PST) Received: by rn-out-0910.google.com with SMTP id j66so854165rne.18 for ; Sun, 01 Feb 2009 16:09:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=bKQaJod0kxrRaJwfLueEeCbw+0nhiD6gVgATxpEBiCw=; b=v2gjRyAc+Do3pYQMQbfpDDeygfjGgWEPKzPeXloPUpfc0gPkUhXQe2JULLdsgX+EHF R1/jRYM18JCsdg/Rp8rgrA5xrpekx8UbkUdOBtZ625M+A8WEdLRRwV6UjkFfiEoc2T/D yDe1/inW5LOmrJWHqVEA/pZW4Eu2qieEgVfz4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=bDVdxI9Z3MXbR/eS/A5CMpM84cAKLzMMCMRguVjgkiEoqIZ8w0e6izlfyf+eIkxZbQ 00hpr/JHkH9Wosvdv94uT62kwQ4nYu2SpOz5DDtcZmP+Cb5UMgso1VLyN4XaHWpICE9I HB8EKre3K6XEy5oTUq1xLGww9HOzsBZ8g/ajo= MIME-Version: 1.0 Received: by 10.65.51.16 with SMTP id d16mr2309782qbk.41.1233533377126; Sun, 01 Feb 2009 16:09:37 -0800 (PST) In-Reply-To: <498508D1.5010706@gte.net> References: <4983D6C7.8070201@gte.net> <044801c98398$34fd6860$0201a8c0@nsnintra.net> <49849DFD.4020607@gte.net> <045601c983ec$1e919e30$0201a8c0@nsnintra.net> <498508D1.5010706@gte.net> Date: Sun, 1 Feb 2009 16:09:36 -0800 Message-ID: <1bc4603e0902011609h1c9a370cr369be297f6ef5d97@mail.gmail.com> From: Chris Messina To: Krishna Sankar Cc: Hannes Tschofenig , oauth@ietf.org Subject: Re: [oauth] OAUTH Charter Proposal X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0207660887==" Sender: oauth-bounces@ietf.org Errors-To: oauth-bounces@ietf.org --===============0207660887== Content-Type: multipart/alternative; boundary=00c09f8a51eec324780461e45ee0 --00c09f8a51eec324780461e45ee0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Had two quick things... First, small typo: "OAuth consist of:" should be "OAuth consists of:" Second, w/r/t to this: Furthermore, Oauth 1.0 defines three signature methods used to protect requests, > namely PLAINTEXT, HMAC-SHA1, and RSA-SHA1. The group will work on new > signature methods in case the existing mechanisms do not fulfill > the security requirements. Where are the "security requirements" coming from? Are these defined separately? Whose are they? Chris On Sat, Jan 31, 2009 at 6:28 PM, Krishna Sankar wrote: > Hannes, > Thank you. Agreed on all. > Cheers & have a nice weekend > > > Hannes Tschofenig wrote: > >> Hi Krishna, >> Thanks for your quick response. >> >> >>> Three vectors: >>> >>> a) While we cannot legislate extensibility, an extensibility guideline >>> document need to be part of the deliverables. When the main OAuth >>> discussions occur, there will be things we will say "this is not core but >>> belongs to extensions" or we might make certain assumptions that we need to >>> explicitly state or we might have certain insights. This document can >>> systemically capture all these artifacts. We also might need to add security >>> considerations as well as interoperability and conformance for extensions. >>> >>> >> >> A description on how OAUTH can (or should) be extended is certainly useful >> (better explicit than implicit). This could, for example, be part of the >> main specification. I have also seen separate documents that illustrate >> how >> a protocol (or a set of protocols) can be extended. Example: Design >> Guidelines for RADIUS >> http://www.ietf.org/internet-drafts/draft-ietf-radext-design-05.txt >> This document has been written some time after the deployment happened and >> provides a sort of best current practice on how to build RADIUS >> extensions. >> I believe it is a bit early for these type of documents. >> So, my proposal would be to capture the most important extensibility >> aspects >> within the main specification itself. Later, when some expertise can be >> gained with OAUTH extensions one can start thinking about capturing the >> design experience in a document. >> I guess we are doing fine with the security considerations as every IETF >> document needs to contain a section describing them. >> In any case, if you already have some ideas for text (or already a text >> proposal) for the OAUTH draft feel free to post something to the list >> (even >> though it is not directly related to the charter discussion itself). >> >> >>> b) As a part of the charter we should add : >>> >>> * Promote interoperability >>> * Provide guidelines for extensibility >>> >>> The group should think about extensibility & document the results of the >>> deliberations >>> >>> >> >> Explicitly stating extensibility in the charter sounds useful to me. I >> added it to the charter text. >> >>> c) While I like an extensibility framework, it might prove to be too >>> much and might not be practical. So am happy at the level of guidelines, >>> insights and suggestions. >>> >>> >> >> Ok. >> >> Ciao >> Hannes >> >> >> >>> Cheers >>> >>> Hannes Tschofenig wrote: >>> >>> >>>> >Should we mention anything about extensions or any >>>> >>>> >>>>> extensibility framework ? >>>>> >>>>> Cheers >>>>> >>>>> >>>>> >>>> What specifically do you have in mind? A document that describes an >>>> extensibility framework? >>>> Highlighting in the charter what extension points >>>> >>> could/should be used? >>> >>> >>>> Ciao >>>> Hannes >>>> >>>> >>>> >>>> >>> >> >> >> > > _______________________________________________ > oauth mailing list > oauth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Chris Messina Citizen-Participant & Open Web Advocate-at-Large factoryjoe.com # diso-project.org citizenagency.com # vidoop.com This email is: [ ] bloggable [X] ask first [ ] private --00c09f8a51eec324780461e45ee0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Had two quick things...

First, small typo: "OAuth consi= st of:OAuth consists of:"

Second, w/r/t to this:

Furthermore, Oauth 1.0 defines three signature methods used to protect = ;req= uests, namely PLAINTEXT, HMAC-SHA1, and RSA-SHA1. The group will work on&nb= sp;new signature methods in case the existing mechanisms do not fulfill the=  security requirements. 

Where are the "security requirements" coming = from? Are these defined separately? Whose are they?

Chris 

On Sat, Jan 31, 2009 at 6= :28 PM, Krishna Sankar <ksankar@gte.net> wrote:
Hannes,
  Thank you. Agreed on all.
Cheers & have a nice weekend
<k/>

Hannes Tschofenig wrote:
Hi Krishna,
Thanks for your quick response.
 
Three vectors:

a)   While we cannot legislate extensibility, an extensibility guideli= ne document need to be part of the deliverables. When the main OAuth discus= sions occur, there will be things we will say "this is not core but be= longs to extensions" or we might make certain assumptions that we need= to explicitly state or we might have certain insights. This document can s= ystemically capture all these artifacts. We also might need to add security= considerations as well as interoperability and conformance for extensions.=
   

A description on how OAUTH can (or should) be extended is certainly useful<= br> (better explicit than implicit). This could, for example, be part of the main specification. I have also seen separate documents that illustrate how=
a protocol (or a set of protocols) can be extended. Example: Design
Guidelines for RADIUS
http://www.ietf.org/internet-drafts/draft-ietf-radex= t-design-05.txt
This document has been written some time after the deployment happened and<= br> provides a sort of best current practice on how to build RADIUS extensions.=
I believe it is a bit early for these type of documents.
So, my proposal would be to capture the most important extensibility aspect= s
within the main specification itself. Later, when some expertise can be
gained with OAUTH extensions one can start thinking about capturing the
design experience in a document.
I guess we are doing fine with the security considerations as every IETF document needs to contain a section describing them.
In any case, if you already have some ideas for text (or already a text
proposal) for the OAUTH draft feel free to post something to the list (even=
though it is not directly related to the charter discussion itself).
 
b) As a part of the charter we should add :

* Promote interoperability
* Provide guidelines for extensibility

The group should think about extensibility & document the results of th= e deliberations
   

Explicitly stating extensibility in the charter sounds useful to me. I adde= d it to the charter text.    
c)   While I like an extensibility framework, it might prove to be too= much and might not be practical. So am happy at the level of guidelines, i= nsights and suggestions.
   

Ok.

Ciao
Hannes

 
Cheers
<k/>
Hannes Tschofenig wrote:
   
 >Should we mention anything about extensions or any
       
extensibility framework ?

Cheers
<k/>
           
What specifically do you have in mind? A document that describes an extensi= bility framework?
Highlighting in the charter what extension points      
could/should be used?
   
Ciao
Hannes


       


 

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



--
Chris Messi= na
Citizen-Participant &
 Open Web Advocate-at-Large
factoryjoe.com # diso-project.org
citizenagency.com # vidoop.com
This email is:   [ ] bloggable  = ;  [X] ask first   [ ] private
--00c09f8a51eec324780461e45ee0-- --===============0207660887== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ oauth mailing list oauth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --===============0207660887==-- From oauth-bounces@ietf.org Sun Feb 1 23:00:21 2009 Return-Path: X-Original-To: oauth-archive@ietf.org Delivered-To: ietfarch-oauth-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A7EA3A6870; Sun, 1 Feb 2009 23:00:21 -0800 (PST) X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4CFF3A6870 for ; Sun, 1 Feb 2009 23:00:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.614 X-Spam-Level: X-Spam-Status: No, score=-3.614 tagged_above=-999 required=5 tests=[AWL=-1.015, 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 f67qSs5njUXC for ; Sun, 1 Feb 2009 23:00:19 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id CE5713A63D2 for ; Sun, 1 Feb 2009 23:00:15 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n126xt0g011498 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 2 Feb 2009 07:59:55 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n126xt8h013568 for ; Mon, 2 Feb 2009 07:59:55 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Feb 2009 07:59:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 2 Feb 2009 09:00:39 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45FFEE62@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [oauth] OAUTH Charter Proposal Thread-Index: AcmFA/TGyhpZcEERTZ2O37rALUIGkw== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 02 Feb 2009 06:59:54.0832 (UTC) FILETIME=[DA298500:01C98503] Subject: Re: [oauth] OAUTH Charter Proposal X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: oauth-bounces@ietf.org Errors-To: oauth-bounces@ietf.org Hi Chris, First, small typo: "OAuth consist of:" should be "OAuth consists of:" [hannes] Thanks. Fixed. Second, w/r/t to this: Furthermore, Oauth 1.0 defines three signature methods used to protect requests, namely PLAINTEXT, HMAC-SHA1, and RSA-SHA1. The group will work on new signature methods in case the existing mechanisms do not fulfill the security requirements. Where are the "security requirements" coming from? Are these defined separately? Whose are they? [hannes] I think a pragmatic approach is sensible here: a document that describes a new mechanism might want to say what requirements guided the solution and thereby provide some motivation. I was not thinking of an independent requirements document. I don't think that it is well spent time. Ciao Hannes Chris _______________________________________________ oauth mailing list oauth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From oauth-bounces@ietf.org Sun Feb 1 23:54:22 2009 Return-Path: X-Original-To: oauth-archive@ietf.org Delivered-To: ietfarch-oauth-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 580EB3A6936; Sun, 1 Feb 2009 23:54:22 -0800 (PST) X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B2793A688F for ; Sun, 1 Feb 2009 23:54:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.604 X-Spam-Level: X-Spam-Status: No, score=-5.604 tagged_above=-999 required=5 tests=[AWL=0.995, 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 kzLL-SjQHqqb for ; Sun, 1 Feb 2009 23:54:19 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 1910A3A6936 for ; Sun, 1 Feb 2009 23:54:18 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n127rvRo030361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 2 Feb 2009 08:53:57 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n127rqBi010001 for ; Mon, 2 Feb 2009 08:53:57 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Feb 2009 08:53:55 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 2 Feb 2009 09:54:40 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45FFEF34@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Charter Proposal v2 Thread-Index: AcmFC4CX6YsJ6CC8SsmUmVmVKEashQ== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 02 Feb 2009 07:53:55.0109 (UTC) FILETIME=[65848D50:01C9850B] Subject: [oauth] Charter Proposal v2 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: oauth-bounces@ietf.org Errors-To: oauth-bounces@ietf.org Based on the feedback I have updated the charter text proposal ---------- Open Authentication Protocol (oauth) Last Modified: 2009-01-30 Chair(s): TBD Applications Area Director(s): Chris Newman Lisa Dusseault Applications Area Advisor: TBD Mailing Lists: https://www.ietf.org/mailman/listinfo/oauth Description of Working Group: OAuth allows a user to grant a third-party Web site or application access to their resources, without revealing their credentials, or even their identity. For example, a photo-sharing site that supports OAuth would allow its users to use a third-party printing Web site to access their private pictures, without gaining full control of the user account. OAuth consists of: * A mechanism for exchanging a user's credentials for a token-secret pair which can be used by a third party to access resources on their behalf * A mechanism for signing HTTP requests with the token-secret pair The Working Group will produce one or more documents suitable for consideration as Proposed Standard, based upon the OAuth I-D, that will: * Align OAuth with the Internet and Web architectures, best practices and terminology * Assure good security practice, or document gaps in its capabilities * Promote interoperability * Provide guidelines for extensibility This specifically means that as a starting point for the working group the OAuth 1.0 specification is used and the available extension points are going to be utilized. It seems desireable to profile OAuth 1.0 in a way that produces a specification that is a backwards compatible profile, i.e. any OAUTH 1.0 and the specification produced by this group must support a basic set of features to guarantee interoperability. Furthermore, Oauth 1.0 defines three signature methods used to protect requests, namely PLAINTEXT, HMAC-SHA1, and RSA-SHA1. The group will work on new signature methods in case the existing mechanisms do not fulfill the security requirements. Existing signature methods will not be modified but may be dropped as part of the backwards compatible profiling activity. In doing so, it should consider: * Implementer experience * Existing uses of OAuth * Ability to achieve broad impementation * Ability to address broader use cases than may be contemplated by the original authors * Impact on the Internet and Web The Working Group is not tasked with defining a generally applicable HTTP Authentication mechanism (i.e., browser-based "2-leg" scenerio), and should consider this work out of scope in its discussions. However, if the deliverables are able to be factored in such a way that this is a byproduct, or such a scenario could be addressed by additional future work, the Working Group may choose to do so. After delivering OAuth, the Working Group may consider defining additional functions and/or extensions, for example (but not limited to): * Discovery of authentication configuration * Message integrity * Recommendations regarding the structure of the token Goals and Milestones: 12/2009 Submit document(s) suitable for publication as standards-track RFCs. _______________________________________________ oauth mailing list oauth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From oauth-bounces@ietf.org Mon Feb 2 00:21:55 2009 Return-Path: X-Original-To: oauth-archive@ietf.org Delivered-To: ietfarch-oauth-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9227A3A6927; Mon, 2 Feb 2009 00:21:55 -0800 (PST) X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDB283A69AB for ; Mon, 2 Feb 2009 00:20:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.489 X-Spam-Level: X-Spam-Status: No, score=-5.489 tagged_above=-999 required=5 tests=[AWL=1.110, 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 ncNqQ+VLKnMD for ; Mon, 2 Feb 2009 00:19:59 -0800 (PST) Received: from atreus.tartarus.org (atreus.tartarus.org [80.252.125.10]) by core3.amsl.com (Postfix) with ESMTP id 97BE73A69CD for ; Mon, 2 Feb 2009 00:19:59 -0800 (PST) Received: from james by atreus.tartarus.org with local (Exim 4.63) (envelope-from ) id 1LTu1r-0006Pp-8A for oauth@ietf.org; Mon, 02 Feb 2009 08:19:39 +0000 Date: Mon, 2 Feb 2009 08:19:39 +0000 From: James Aylett To: oauth@ietf.org Message-ID: <20090202081939.GD20152@tartarus.org> References: <3D3C75174CB95F42AD6BCC56E5555B45FFEE62@FIESEXC015.nsn-intra.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B45FFEE62@FIESEXC015.nsn-intra.net> User-Agent: Mutt/1.5.13 (2006-08-11) Subject: Re: [oauth] OAUTH Charter Proposal X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: oauth-bounces@ietf.org Errors-To: oauth-bounces@ietf.org On Mon, Feb 02, 2009 at 09:00:39AM +0200, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > > > Furthermore, Oauth 1.0 defines three signature methods used to > > > protect requests, namely PLAINTEXT, HMAC-SHA1, and RSA-SHA1. The > > > group will work on new signature methods in case the existing > > > mechanisms do not fulfill the security requirements. > > > Where are the "security requirements" coming from? Are these defined > > separately? Whose are they? > > I think a pragmatic approach is sensible here: a document that > describes a new mechanism might want to say what requirements guided > the solution and thereby provide some motivation. I assumed that this would cover normal security review as per IETF process: any and all valid security concerns raised by the community in the process of writing or reviewing the security considerations section, or the use of security elements in other parts of the document. The latter is more likely to be the area where algorithm choices may be challenged on the basis of insufficient strength or suitability. James -- James Aylett talktorex.co.uk - xapian.org - uncertaintydivision.org _______________________________________________ oauth mailing list oauth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From oauth-bounces@ietf.org Mon Feb 2 00:24:38 2009 Return-Path: X-Original-To: oauth-archive@ietf.org Delivered-To: ietfarch-oauth-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C02403A6927; Mon, 2 Feb 2009 00:24:38 -0800 (PST) X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 145B93A6896 for ; Mon, 2 Feb 2009 00:24:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, WHOIS_DMNBYPROXY=0.478] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZnYQHCxTGdQ for ; Mon, 2 Feb 2009 00:24:36 -0800 (PST) Received: from mail-gx0-f21.google.com (mail-gx0-f21.google.com [209.85.217.21]) by core3.amsl.com (Postfix) with ESMTP id CBE323A6927 for ; Mon, 2 Feb 2009 00:24:35 -0800 (PST) Received: by gxk14 with SMTP id 14so1092481gxk.13 for ; Mon, 02 Feb 2009 00:24:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=fw858ZeRb3p7zlIS+8M1lw4q0s6JST9ONdofs0yuGVA=; b=r/LOt4CgWs64MZtrrN/XJ1S0+WO0K1pSn4/Q25i7ZFzSVcxsZCUTtURSjZy6X80g6+ aQe/Fc+VX7zvkeFkYmsL86CQmo8xNLxdZq4y84fDawOyJc7Ke0psn94llNxbkE55G2ma DBvVUkkhmH5rbZLi17sPixd6Tqxsf0ctm4Zq4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=M4mQd8vtEM4HIy//gzYJsaZuShsrQXH4xcdhLtL114TnC744HF/a9/FVkb9+q/QIcw BzbldgNZPszdZ0z3i9VK74tY05cG/swf+ipVOn2l7HxB+LqdooJ0057vsetexEDV/4M1 Z5jJ9Pu/ESdfHh0VHvzyuaYUJgXzwo4LuvrPY= MIME-Version: 1.0 Received: by 10.65.51.16 with SMTP id d16mr2530243qbk.41.1233563055964; Mon, 02 Feb 2009 00:24:15 -0800 (PST) In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B45FFEE62@FIESEXC015.nsn-intra.net> References: <3D3C75174CB95F42AD6BCC56E5555B45FFEE62@FIESEXC015.nsn-intra.net> Date: Mon, 2 Feb 2009 00:24:15 -0800 Message-ID: <1bc4603e0902020024j71230bbr47b0b2c65b58b2b4@mail.gmail.com> From: Chris Messina To: "Tschofenig, Hannes (NSN - FI/Espoo)" Cc: oauth@ietf.org Subject: Re: [oauth] OAUTH Charter Proposal X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0314708699==" Sender: oauth-bounces@ietf.org Errors-To: oauth-bounces@ietf.org --===============0314708699== Content-Type: multipart/alternative; boundary=00c09f8a51eec241550461eb47c7 --00c09f8a51eec241550461eb47c7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Sun, Feb 1, 2009 at 11:00 PM, Tschofenig, Hannes (NSN - FI/Espoo) < hannes.tschofenig@nsn.com> wrote: > > Second, w/r/t to this: > > > Furthermore, Oauth 1.0 defines three signature methods used to > protect requests, namely PLAINTEXT, HMAC-SHA1, and RSA-SHA1. The group > will work on new signature methods in case the existing mechanisms do > not fulfill the security requirements. > > > Where are the "security requirements" coming from? Are these defined > separately? Whose are they? > > [hannes] I think a pragmatic approach is sensible here: a document that > describes a new mechanism might want to say what requirements guided the > solution and thereby provide some motivation. > > I was not thinking of an independent requirements document. I don't > think that it is well spent time. > I agree. Maybe it was just the wording -- it sounded like there were some definitive "security requirements" (or else you wouldn't be able to tell if they were fulfilled!) but perhaps that's not what's intended there. I think I understand now: if you propose new security methods or signing mechanisms, the document will describe why to use them in situations with different security requirements. Ok. Thanks, Chris -- Chris Messina Citizen-Participant & Open Web Advocate-at-Large factoryjoe.com # diso-project.org citizenagency.com # vidoop.com This email is: [ ] bloggable [X] ask first [ ] private --00c09f8a51eec241550461eb47c7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sun, Feb 1, 2009 at 11:00 PM, Tschofenig, Han= nes (NSN - FI/Espoo) <hannes.tschofenig@nsn.com> wrote:

Second, w/r/t to this:


       Furthermore, Oauth 1.0 defines three signature = methods used to
protect requests, namely PLAINTEXT, HMAC-SHA1, and RSA-SHA1. The group
will work on new signature methods in case the existing mechanisms do
not fulfill the security requirements.


Where are the "security requirements" coming from? Are these defi= ned
separately? Whose are they?

[hannes] I think a pragmatic approach is sensible here: a document th= at
describes a new mechanism might want to say what requirements guided the solution and thereby provide some motivation.

I was not thinking of an independent requirements document. I don't
think that it is well spent time.

I agree.

Maybe it= was just the wording -- it sounded like there were some definitive "s= ecurity requirements" (or else you wouldn't be able to tell if the= y were fulfilled!) but perhaps that's not what's intended there.

I think I understand now: if you propose new security m= ethods or signing mechanisms, the document will describe why to use them in= situations with different security requirements. Ok.

Thanks,

Chris 

--
Chr= is Messina
Citizen-Participant &
 Open Web Advocate-at-Larg= e

factoryjoe.com # diso-project.org
citizenagency.com # vidoop.com
This email is:   [ ] bloggable  = ;  [X] ask first   [ ] private
--00c09f8a51eec241550461eb47c7-- --===============0314708699== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ oauth mailing list oauth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --===============0314708699==-- From oauth-bounces@ietf.org Mon Feb 2 00:37:24 2009 Return-Path: X-Original-To: oauth-archive@ietf.org Delivered-To: ietfarch-oauth-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CA983A6935; Mon, 2 Feb 2009 00:37:24 -0800 (PST) X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 485803A6927 for ; Mon, 2 Feb 2009 00:37:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.375 X-Spam-Level: X-Spam-Status: No, score=-3.375 tagged_above=-999 required=5 tests=[AWL=-1.254, BAYES_00=-2.599, WHOIS_DMNBYPROXY=0.478] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1ukDesoVjvZ for ; Mon, 2 Feb 2009 00:37:22 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id E789F3A6816 for ; Mon, 2 Feb 2009 00:37:21 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n128axB9018882 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 2 Feb 2009 09:36:59 +0100 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n128axNX020861; Mon, 2 Feb 2009 09:36:59 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Feb 2009 09:36:59 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 2 Feb 2009 10:37:44 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45FFEFDE@FIESEXC015.nsn-intra.net> In-Reply-To: <1bc4603e0902020024j71230bbr47b0b2c65b58b2b4@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [oauth] OAUTH Charter Proposal Thread-Index: AcmFD6dr5d66USasRc2MM/+CQiYoOwAAKExQ References: <3D3C75174CB95F42AD6BCC56E5555B45FFEE62@FIESEXC015.nsn-intra.net> <1bc4603e0902020024j71230bbr47b0b2c65b58b2b4@mail.gmail.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Chris Messina" X-OriginalArrivalTime: 02 Feb 2009 08:36:59.0400 (UTC) FILETIME=[69E01080:01C98511] Cc: oauth@ietf.org Subject: Re: [oauth] OAUTH Charter Proposal X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: oauth-bounces@ietf.org Errors-To: oauth-bounces@ietf.org What about the following text: " Furthermore, OAuth 1.0 defines three signature methods used to protect requests, namely PLAINTEXT, HMAC-SHA1, and RSA-SHA1. The group will work on new signature methods and will describe the environments where additional security requirements justify their usage. Existing signature methods will not be modified but may be dropped as part of the backwards compatible profiling activity. " Ciao Hannes PS: There are lots of people out there who have a strong opinion about different algorithms and usage modes. I wouldn't be surprised to spend some time discussing different algorithms. ________________________________ From: ext Chris Messina [mailto:chris.messina@gmail.com] Sent: 02 February, 2009 10:24 To: Tschofenig, Hannes (NSN - FI/Espoo) Cc: oauth@ietf.org Subject: Re: [oauth] OAUTH Charter Proposal On Sun, Feb 1, 2009 at 11:00 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: Second, w/r/t to this: Furthermore, Oauth 1.0 defines three signature methods used to protect requests, namely PLAINTEXT, HMAC-SHA1, and RSA-SHA1. The group will work on new signature methods in case the existing mechanisms do not fulfill the security requirements. Where are the "security requirements" coming from? Are these defined separately? Whose are they? [hannes] I think a pragmatic approach is sensible here: a document that describes a new mechanism might want to say what requirements guided the solution and thereby provide some motivation. I was not thinking of an independent requirements document. I don't think that it is well spent time. I agree. Maybe it was just the wording -- it sounded like there were some definitive "security requirements" (or else you wouldn't be able to tell if they were fulfilled!) but perhaps that's not what's intended there. I think I understand now: if you propose new security methods or signing mechanisms, the document will describe why to use them in situations with different security requirements. Ok. Thanks, Chris -- Chris Messina Citizen-Participant & Open Web Advocate-at-Large factoryjoe.com # diso-project.org citizenagency.com # vidoop.com This email is: [ ] bloggable [X] ask first [ ] private _______________________________________________ oauth mailing list oauth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From oauth-bounces@ietf.org Mon Feb 2 05:47:45 2009 Return-Path: X-Original-To: oauth-archive@ietf.org Delivered-To: ietfarch-oauth-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FC5528C215; Mon, 2 Feb 2009 05:47:45 -0800 (PST) X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7459128C215 for ; Mon, 2 Feb 2009 05:47:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-ArOi0LsYk0 for ; Mon, 2 Feb 2009 05:47:43 -0800 (PST) Received: from imo-d05.mx.aol.com (imo-d05.mx.aol.com [205.188.157.37]) by core3.amsl.com (Postfix) with ESMTP id 60BB128C1EF for ; Mon, 2 Feb 2009 05:47:42 -0800 (PST) Received: from GFFletch@aol.com by imo-d05.mx.aol.com (mail_out_v39.1.) id j.cb5.4d963fc8 (37583); Mon, 2 Feb 2009 08:47:13 -0500 (EST) Received: from C0A80169.tipt.aol.com ([10.172.1.80]) by cia-mb05.mx.aol.com (v121_r5.5) with ESMTP id MAILCIAMB058-92cf4986f95521c; Mon, 02 Feb 2009 08:47:02 -0500 Message-ID: <4986F954.1090001@aol.com> Date: Mon, 02 Feb 2009 08:47:00 -0500 From: George Fletcher Organization: AOL LLC User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Hannes Tschofenig References: <033101c98303$e6fde7f0$0201a8c0@nsnintra.net> In-Reply-To: <033101c98303$e6fde7f0$0201a8c0@nsnintra.net> X-AOL-IP: 10.172.1.80 X-Mailer: Unknown (No Version) Cc: oauth@ietf.org Subject: Re: [oauth] OAUTH Charter Proposal X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: oauth-bounces@ietf.org Errors-To: oauth-bounces@ietf.org Not wanting to start a huge debate... but within the OAuth community we've made the distinction between Authentication and Authorization, with OAuth being an API Authorization protocol and leaving Authentication out of scope. Is this charter planning to tackle authentication as well as authorization? The statement... > OAuth consist of: > * A mechanism for exchanging a user's credentials for a token-secret pair > has me a little confused. I would word this as... * A mechanism that allows a user to authorize API access via a token-secret pair Thanks, George Hannes Tschofenig wrote: > Hi all, > > After a chat with Lisa I got in touch with Eran to slightly revise the > charter text that Sam and Mark put together for the last IETF meeting. > > It should addresses some of the comments provided during the BOF. Your > feedback is welcome. > > Ciao > Hannes > > ------------------------------------- > > Open Authentication Protocol (oauth) > > Last Modified: 2009-01-30 > > Chair(s): > > TBD > > Applications Area Director(s): > > Chris Newman > Lisa Dusseault > > Applications Area Advisor: > > TBD > > Mailing Lists: > > https://www.ietf.org/mailman/listinfo/oauth > > Description of Working Group: > > OAuth allows a user to grant a third-party Web site or application access to > their resources, without revealing their credentials, or even their > identity. For example, a photo-sharing site that supports OAuth would allow > its users to use a third-party printing Web site to access their private > pictures, without gaining full control of the user account. > > OAuth consist of: > * A mechanism for exchanging a user's credentials for a token-secret pair > which can be used by a third party to access resources on their behalf > * A mechanism for signing HTTP requests with the token-secret pair > > The Working Group will produce one or more documents suitable for > consideration as Proposed Standard, based upon the OAuth I-D, that will: > * Align OAuth with the Internet and Web architectures, best practices and > terminology > * Assure good security practice, or document gaps in its capabilities > * Promote interoperability > > This specifically means that as a starting point for the working group the > OAuth 1.0 specification is used and the > available extension points are going to be utilized. It seems desireable to > profile OAuth 1.0 in a way that produces a specification that is a backwards > compatible profile, i.e. any OAUTH 1.0 and the specification produced by > this group must support a basic set of features to guarantee > interoperability. > > Furthermore, Oauth 1.0 defines three signature methods used to protect > requests, namely PLAINTEXT, HMAC-SHA1, and RSA-SHA1. The group will work on > new signature methods in case the existing mechanisms do not fulfill the > security requirements. Existing signature methods will not be modified but > may be dropped as part of the backwards compatible profiling activity. > > In doing so, it should consider: > * Implementer experience > * Existing uses of OAuth > * Ability to achieve broad impementation > * Ability to address broader use cases than may be contemplated by the > original authors > * Impact on the Internet and Web > > The Working Group is not tasked with defining a generally applicable HTTP > Authentication mechanism (i.e., browser-based "2-leg" scenerio), and should > consider this work out of scope in its discussions. However, if the > deliverables are able to be factored in such a way that this is a byproduct, > or such a scenario could be addressed by additional future work, the Working > Group may choose to do so. > > After delivering OAuth, the Working Group MAY consider defining additional > functions and/or extensions, for example > (but not limited to): > * Discovery of authentication configuration > * Message integrity > * Recommendations regarding the structure of the token > > Goals and Milestones: > > 12/2009 Submit document(s) suitable for publication as standards-track > RFCs. > > _______________________________________________ > oauth mailing 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 oauth-bounces@ietf.org Mon Feb 2 06:24:50 2009 Return-Path: X-Original-To: oauth-archive@ietf.org Delivered-To: ietfarch-oauth-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 127753A6B48; Mon, 2 Feb 2009 06:24:50 -0800 (PST) X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 653513A6B48 for ; Mon, 2 Feb 2009 06:24:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 BNpC2c8XbrMT for ; Mon, 2 Feb 2009 06:24:48 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by core3.amsl.com (Postfix) with ESMTP id 358F03A6B36 for ; Mon, 2 Feb 2009 06:24:48 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 3so581251qwe.31 for ; Mon, 02 Feb 2009 06:24:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=Zl2A5PLsPUGEnyxzKxu7riQ2GoZJ8WbU6l+fhtY1E/w=; b=nQ66jMKbyBu0v/cTaQF2fxvEw2REiXkXUjtUm3zGMUCV+57oL84B6XTTzGCia25lUj ewajKMAHRwngAI+249B7+Y0ptvCOIhdogmSRZBKS4jytitU7rELJqrw7eYuIC9/Q4k2i FIFt9piVqUEZbNJbi30ByA3p+g8amzoY/OeEI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=UmX6LNjrLc/UgHY+H2JKbzKGqGqFyWph6fJ0PXsyOTPcduwtoJc/a+xujKFFUxowi3 0/7Q1lrGfLTOQBxB/lzAZxmj40EtOh+LFmdp2iU+sp9mK0mIuDSivZYfURtbTsQwfMzT 1j5dih9XmLR0pqQnDl3OM8gHZATJ7jDeRxtSE= MIME-Version: 1.0 Received: by 10.214.79.11 with SMTP id c11mr3602064qab.350.1233584667849; Mon, 02 Feb 2009 06:24:27 -0800 (PST) In-Reply-To: <033101c98303$e6fde7f0$0201a8c0@nsnintra.net> References: <033101c98303$e6fde7f0$0201a8c0@nsnintra.net> Date: Mon, 2 Feb 2009 15:24:27 +0100 Message-ID: <6c0fd2bc0902020624s221cfc34x7af1de770d34d4ee@mail.gmail.com> From: Hubert Le Van Gong To: Hannes Tschofenig , oauth@ietf.org Subject: Re: [oauth] OAUTH Charter Proposal X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: oauth-bounces@ietf.org Errors-To: oauth-bounces@ietf.org Hi Hannes, Thanks for updating the charter. Some comments below. "It seems desireable to profile OAuth 1.0 in a way that produces a specification that is a backwards compatible profile, i.e. any OAUTH 1.0 and the specification produced by this group must support a basic set of features to guarantee interoperability." - Profiling usually means to constrain further an existing specification. This seems to contradict the part of the charter that talks of supporting broader use cases beyond the original scope...? What did you mean there? - I would argue that there is no guaranteed interoperability in the current OAuth 1.0 spec. We need to address this. The security report Sam (Hartman) created highlights a few things that should be done: (1) mandatory-to-implement algorithm(s) for security (2) interoperable way to find the lifetime of a request or access-token (3) description of how a service uses OAuth I had the same comment as George just sent on AuthZ vs. AuthN Cheers, Hubert On Fri, Jan 30, 2009 at 6:55 PM, Hannes Tschofenig wrote: > Hi all, > > After a chat with Lisa I got in touch with Eran to slightly revise the > charter text that Sam and Mark put together for the last IETF meeting. > > It should addresses some of the comments provided during the BOF. Your > feedback is welcome. > > Ciao > Hannes > > ------------------------------------- > > Open Authentication Protocol (oauth) > > Last Modified: 2009-01-30 > > Chair(s): > > TBD > > Applications Area Director(s): > > Chris Newman > Lisa Dusseault > > Applications Area Advisor: > > TBD > > Mailing Lists: > > https://www.ietf.org/mailman/listinfo/oauth > > Description of Working Group: > > OAuth allows a user to grant a third-party Web site or application access to > their resources, without revealing their credentials, or even their > identity. For example, a photo-sharing site that supports OAuth would allow > its users to use a third-party printing Web site to access their private > pictures, without gaining full control of the user account. > > OAuth consist of: > * A mechanism for exchanging a user's credentials for a token-secret pair > which can be used by a third party to access resources on their behalf > * A mechanism for signing HTTP requests with the token-secret pair > > The Working Group will produce one or more documents suitable for > consideration as Proposed Standard, based upon the OAuth I-D, that will: > * Align OAuth with the Internet and Web architectures, best practices and > terminology > * Assure good security practice, or document gaps in its capabilities > * Promote interoperability > > This specifically means that as a starting point for the working group the > OAuth 1.0 specification is used and the > available extension points are going to be utilized. It seems desireable to > profile OAuth 1.0 in a way that produces a specification that is a backwards > compatible profile, i.e. any OAUTH 1.0 and the specification produced by > this group must support a basic set of features to guarantee > interoperability. > > Furthermore, Oauth 1.0 defines three signature methods used to protect > requests, namely PLAINTEXT, HMAC-SHA1, and RSA-SHA1. The group will work on > new signature methods in case the existing mechanisms do not fulfill the > security requirements. Existing signature methods will not be modified but > may be dropped as part of the backwards compatible profiling activity. > > In doing so, it should consider: > * Implementer experience > * Existing uses of OAuth > * Ability to achieve broad impementation > * Ability to address broader use cases than may be contemplated by the > original authors > * Impact on the Internet and Web > > The Working Group is not tasked with defining a generally applicable HTTP > Authentication mechanism (i.e., browser-based "2-leg" scenerio), and should > consider this work out of scope in its discussions. However, if the > deliverables are able to be factored in such a way that this is a byproduct, > or such a scenario could be addressed by additional future work, the Working > Group may choose to do so. > > After delivering OAuth, the Working Group MAY consider defining additional > functions and/or extensions, for example > (but not limited to): > * Discovery of authentication configuration > * Message integrity > * Recommendations regarding the structure of the token > > Goals and Milestones: > > 12/2009 Submit document(s) suitable for publication as standards-track > RFCs. > > _______________________________________________ > oauth mailing 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 oauth-bounces@ietf.org Mon Feb 2 06:33:26 2009 Return-Path: X-Original-To: oauth-archive@ietf.org Delivered-To: ietfarch-oauth-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 447D828C217; Mon, 2 Feb 2009 06:33:26 -0800 (PST) X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AB5528C21C for ; Mon, 2 Feb 2009 06:33:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.344 X-Spam-Level: X-Spam-Status: No, score=-2.344 tagged_above=-999 required=5 tests=[AWL=0.255, 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 OykbDfQw75tI for ; Mon, 2 Feb 2009 06:33:24 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 71DCB28C217 for ; Mon, 2 Feb 2009 06:33:16 -0800 (PST) Received: (qmail invoked by alias); 02 Feb 2009 14:32:55 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp023) with SMTP; 02 Feb 2009 15:32:55 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+1AVUoIvC1SfYb1PBQxtExIQwlP/9xxRcbBMrsfN 1QyZNq5e+Uz5xO From: "Hannes Tschofenig" To: "'George Fletcher'" References: <033101c98303$e6fde7f0$0201a8c0@nsnintra.net> <4986F954.1090001@aol.com> Date: Mon, 2 Feb 2009 16:33:41 +0200 Message-ID: <006301c98543$3f1df240$e846a20a@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <4986F954.1090001@aol.com> Thread-Index: AcmFPMXP+fDI6IjpRvyC04itr8TLogABm+aw X-Y-GMX-Trusted: 0 X-FuHaFi: 0.54 Cc: oauth@ietf.org Subject: Re: [oauth] OAUTH Charter Proposal X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: oauth-bounces@ietf.org Errors-To: oauth-bounces@ietf.org Sounds good to me. Thanks, George. >-----Original Message----- >From: George Fletcher [mailto:gffletch@aol.com] >Sent: 02 February, 2009 15:47 >To: Hannes Tschofenig >Cc: oauth@ietf.org >Subject: Re: [oauth] OAUTH Charter Proposal > >Not wanting to start a huge debate... but within the OAuth >community we've made the distinction between Authentication >and Authorization, with OAuth being an API Authorization >protocol and leaving Authentication out of scope. > >Is this charter planning to tackle authentication as well as >authorization? The statement... >> OAuth consist of: >> * A mechanism for exchanging a user's credentials for a >token-secret >> pair >> >has me a little confused. I would word this as... > >* A mechanism that allows a user to authorize API access via a >token-secret pair > >Thanks, >George > > >Hannes Tschofenig wrote: >> Hi all, >> >> After a chat with Lisa I got in touch with Eran to slightly >revise the >> charter text that Sam and Mark put together for the last >IETF meeting. >> >> It should addresses some of the comments provided during the >BOF. Your >> feedback is welcome. >> >> Ciao >> Hannes >> >> ------------------------------------- >> >> Open Authentication Protocol (oauth) >> >> Last Modified: 2009-01-30 >> >> Chair(s): >> >> TBD >> >> Applications Area Director(s): >> >> Chris Newman >> Lisa Dusseault >> >> Applications Area Advisor: >> >> TBD >> >> Mailing Lists: >> >> https://www.ietf.org/mailman/listinfo/oauth >> >> Description of Working Group: >> >> OAuth allows a user to grant a third-party Web site or application >> access to their resources, without revealing their credentials, or >> even their identity. For example, a photo-sharing site that supports >> OAuth would allow its users to use a third-party printing >Web site to >> access their private pictures, without gaining full control >of the user account. >> >> OAuth consist of: >> * A mechanism for exchanging a user's credentials for a >token-secret >> pair which can be used by a third party to access resources >on their behalf >> * A mechanism for signing HTTP requests with the token-secret pair >> >> The Working Group will produce one or more documents suitable for >> consideration as Proposed Standard, based upon the OAuth >I-D, that will: >> * Align OAuth with the Internet and Web architectures, best >> practices and terminology >> * Assure good security practice, or document gaps in its >capabilities >> * Promote interoperability >> >> This specifically means that as a starting point for the >working group >> the OAuth 1.0 specification is used and the available >extension points >> are going to be utilized. It seems desireable to profile >OAuth 1.0 in >> a way that produces a specification that is a backwards compatible >> profile, i.e. any OAUTH 1.0 and the specification produced by this >> group must support a basic set of features to guarantee >> interoperability. >> >> Furthermore, Oauth 1.0 defines three signature methods used >to protect >> requests, namely PLAINTEXT, HMAC-SHA1, and RSA-SHA1. The group will >> work on new signature methods in case the existing mechanisms do not >> fulfill the security requirements. Existing signature >methods will not >> be modified but may be dropped as part of the backwards >compatible profiling activity. >> >> In doing so, it should consider: >> * Implementer experience >> * Existing uses of OAuth >> * Ability to achieve broad impementation >> * Ability to address broader use cases than may be contemplated by >> the original authors >> * Impact on the Internet and Web >> >> The Working Group is not tasked with defining a generally applicable >> HTTP Authentication mechanism (i.e., browser-based "2-leg" >scenerio), >> and should consider this work out of scope in its discussions. >> However, if the deliverables are able to be factored in such a way >> that this is a byproduct, or such a scenario could be addressed by >> additional future work, the Working Group may choose to do so. >> >> After delivering OAuth, the Working Group MAY consider defining >> additional functions and/or extensions, for example (but not limited >> to): >> * Discovery of authentication configuration >> * Message integrity >> * Recommendations regarding the structure of the token >> >> Goals and Milestones: >> >> 12/2009 Submit document(s) suitable for publication as >standards-track >> RFCs. >> >> _______________________________________________ >> oauth mailing 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 oauth-bounces@ietf.org Mon Feb 2 06:50:26 2009 Return-Path: X-Original-To: oauth-archive@ietf.org Delivered-To: ietfarch-oauth-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A278B3A6A1A; Mon, 2 Feb 2009 06:50:26 -0800 (PST) X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB6CC28C1F0 for ; Mon, 2 Feb 2009 06:50:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.346 X-Spam-Level: X-Spam-Status: No, score=-2.346 tagged_above=-999 required=5 tests=[AWL=0.253, 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 H2cEZshUR9Yz for ; Mon, 2 Feb 2009 06:50:24 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id A729F3A6A0C for ; Mon, 2 Feb 2009 06:50:23 -0800 (PST) Received: (qmail invoked by alias); 02 Feb 2009 14:50:03 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp027) with SMTP; 02 Feb 2009 15:50:03 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+f0ogt9rafQkW04SgM02uWAOL6BsWcRKbEqfV/5t nMwMFdsYIHftch From: "Hannes Tschofenig" To: "'Hubert Le Van Gong'" , References: <033101c98303$e6fde7f0$0201a8c0@nsnintra.net> <6c0fd2bc0902020624s221cfc34x7af1de770d34d4ee@mail.gmail.com> Date: Mon, 2 Feb 2009 16:50:50 +0200 Message-ID: <006401c98545$a41f6b90$e846a20a@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <6c0fd2bc0902020624s221cfc34x7af1de770d34d4ee@mail.gmail.com> Thread-Index: AcmFQfSbipaAN9I2S+qbr69dtEvPowAAVnhg X-Y-GMX-Trusted: 0 X-FuHaFi: 0.54 Subject: Re: [oauth] OAUTH Charter Proposal X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: oauth-bounces@ietf.org Errors-To: oauth-bounces@ietf.org Hi Hubert, >Hi Hannes, > >Thanks for updating the charter. Some comments below. > >"It seems desireable to profile OAuth 1.0 in a way that >produces a specification that is a backwards compatible >profile, i.e. any OAUTH 1.0 and the specification produced by >this group must support a basic set of features to guarantee >interoperability." > >- Profiling usually means to constrain further an existing >specification. > This seems to contradict the part of the charter that talks of > supporting broader use cases beyond the original scope...? > What did you mean there? When multiple options are provided then indicating which onces are mandatory to implement is something that I call profiling. When the profiled version is run against Oauth 1.0 it would still interoperate (in some sense; if that particular Oauth 1.0 implementation had implemented all options). You mention this aspect of improving interoperability in your next paragraph below as well. The sentence about "Ability to address broader use cases than may be contemplated by the original authors" can be more seen as a "we leave room for extensions that offer additional use cases" phrase. >- I would argue that there is no guaranteed interoperability in the > current OAuth 1.0 spec. We need to address this. The security report > Sam (Hartman) created highlights a few things that should > be done: > (1) mandatory-to-implement algorithm(s) for security > (2) interoperable way to find the lifetime of a request or > access-token > (3) description of how a service uses OAuth These things sound good to me. I guess you don't want to list them in the charter itself, right? Ciao Hannes > >I had the same comment as George just sent on AuthZ vs. AuthN > >Cheers, >Hubert > > > >On Fri, Jan 30, 2009 at 6:55 PM, Hannes Tschofenig > wrote: >> Hi all, >> >> After a chat with Lisa I got in touch with Eran to slightly >revise the >> charter text that Sam and Mark put together for the last >IETF meeting. >> >> It should addresses some of the comments provided during the >BOF. Your >> feedback is welcome. >> >> Ciao >> Hannes >> >> ------------------------------------- >> >> Open Authentication Protocol (oauth) >> >> Last Modified: 2009-01-30 >> >> Chair(s): >> >> TBD >> >> Applications Area Director(s): >> >> Chris Newman >> Lisa Dusseault >> >> Applications Area Advisor: >> >> TBD >> >> Mailing Lists: >> >> https://www.ietf.org/mailman/listinfo/oauth >> >> Description of Working Group: >> >> OAuth allows a user to grant a third-party Web site or application >> access to their resources, without revealing their credentials, or >> even their identity. For example, a photo-sharing site that supports >> OAuth would allow its users to use a third-party printing >Web site to >> access their private pictures, without gaining full control >of the user account. >> >> OAuth consist of: >> * A mechanism for exchanging a user's credentials for a >token-secret >> pair which can be used by a third party to access resources on their >> behalf >> * A mechanism for signing HTTP requests with the token-secret pair >> >> The Working Group will produce one or more documents suitable for >> consideration as Proposed Standard, based upon the OAuth >I-D, that will: >> * Align OAuth with the Internet and Web architectures, best >practices >> and terminology >> * Assure good security practice, or document gaps in its >capabilities >> * Promote interoperability >> >> This specifically means that as a starting point for the >working group >> the OAuth 1.0 specification is used and the available >extension points >> are going to be utilized. It seems desireable to profile >OAuth 1.0 in >> a way that produces a specification that is a backwards compatible >> profile, i.e. any OAUTH 1.0 and the specification produced by this >> group must support a basic set of features to guarantee >> interoperability. >> >> Furthermore, Oauth 1.0 defines three signature methods used >to protect >> requests, namely PLAINTEXT, HMAC-SHA1, and RSA-SHA1. The group will >> work on new signature methods in case the existing mechanisms do not >> fulfill the security requirements. Existing signature >methods will not >> be modified but may be dropped as part of the backwards >compatible profiling activity. >> >> In doing so, it should consider: >> * Implementer experience >> * Existing uses of OAuth >> * Ability to achieve broad impementation >> * Ability to address broader use cases than may be contemplated by >> the original authors >> * Impact on the Internet and Web >> >> The Working Group is not tasked with defining a generally applicable >> HTTP Authentication mechanism (i.e., browser-based "2-leg" >scenerio), >> and should consider this work out of scope in its discussions. >> However, if the deliverables are able to be factored in such a way >> that this is a byproduct, or such a scenario could be addressed by >> additional future work, the Working Group may choose to do so. >> >> After delivering OAuth, the Working Group MAY consider defining >> additional functions and/or extensions, for example (but not limited >> to): >> * Discovery of authentication configuration >> * Message integrity >> * Recommendations regarding the structure of the token >> >> Goals and Milestones: >> >> 12/2009 Submit document(s) suitable for publication as >standards-track >> RFCs. >> >> _______________________________________________ >> oauth mailing 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 oauth-bounces@ietf.org Mon Feb 2 07:11:09 2009 Return-Path: X-Original-To: oauth-archive@ietf.org Delivered-To: ietfarch-oauth-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5783C3A68CE; Mon, 2 Feb 2009 07:11:09 -0800 (PST) X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBC603A6A1A for ; Mon, 2 Feb 2009 06:51:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YvZD1mq62VH4 for ; Mon, 2 Feb 2009 06:51:27 -0800 (PST) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with SMTP id 8ACF33A6A0C for ; Mon, 2 Feb 2009 06:51:27 -0800 (PST) Received: from source ([209.85.221.20]) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKSYcIV3d7Q4xPocFlrtePcpSKiM3iUk90@postini.com; Mon, 02 Feb 2009 06:51:09 PST Received: by qyk13 with SMTP id 13so1851880qyk.23 for ; Mon, 02 Feb 2009 06:51:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.214.182.9 with SMTP id e9mr189503qaf.98.1233586262969; Mon, 02 Feb 2009 06:51:02 -0800 (PST) Date: Mon, 2 Feb 2009 09:51:02 -0500 Message-ID: From: Brett McDowell To: oauth@ietf.org Subject: [oauth] pointer to latest charter? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: oauth-bounces@ietf.org Errors-To: oauth-bounces@ietf.org Hello everyone. I'm new to the mailing list. It was recommended to me that I join the discussion to review and comment on the latest charter. I wasn't able to find it on the ietf web site. Could someone point me to that document? Many thanks, Brett McDowell _______________________________________________ oauth mailing list oauth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From oauth-bounces@ietf.org Mon Feb 2 07:14:42 2009 Return-Path: X-Original-To: oauth-archive@ietf.org Delivered-To: ietfarch-oauth-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8BC13A6A0C; Mon, 2 Feb 2009 07:14:42 -0800 (PST) X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 718403A693C for ; Mon, 2 Feb 2009 07:14:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.073, 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 dWNj9TzWb8cN for ; Mon, 2 Feb 2009 07:14:35 -0800 (PST) Received: from mail-qy0-f11.google.com (mail-qy0-f11.google.com [209.85.221.11]) by core3.amsl.com (Postfix) with ESMTP id 6FE5B3A65A5 for ; Mon, 2 Feb 2009 07:14:35 -0800 (PST) Received: by qyk4 with SMTP id 4so1940024qyk.13 for ; Mon, 02 Feb 2009 07:14:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=P1MsBvV8FPDdy9745kFAsuV7yuzfd4+uqEyUra2HNpE=; b=LsuKRuro2hAoq97NbEGqR9I+8rsWJngaMthZ3Gts2iee2wF+f/q0hXSuh4wkGsM+d1 0I5NiRc/Jc40Mn4lO7f8IgODs0QSwOx+lXewDap0qtS8uKWhRHUv+aWZz7QDL1Js1MbV vm8S4vr/ikttjF3tBAwV8fL/Zg3CUqVlFnGIQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=RxP1bCQTqdDH7N6Qw6nTO7goEDQmnxspnzFdApBCxuzDMspeEpb2GjnrpHT46C2Wiy UDFUTCG5qY6XlrNW/opiUGOLgw+NR22P3vo3EyhNu12ltOyLDn1rIEJtDmZU5A9irYcU cJlnywuRcJXxZgq31msdPIpwFqeJ3LDlRKUjw= MIME-Version: 1.0 Received: by 10.214.216.2 with SMTP id o2mr6320892qag.385.1233587647625; Mon, 02 Feb 2009 07:14:07 -0800 (PST) In-Reply-To: <006401c98545$a41f6b90$e846a20a@nsnintra.net> References: <033101c98303$e6fde7f0$0201a8c0@nsnintra.net> <6c0fd2bc0902020624s221cfc34x7af1de770d34d4ee@mail.gmail.com> <006401c98545$a41f6b90$e846a20a@nsnintra.net> Date: Mon, 2 Feb 2009 16:14:07 +0100 Message-ID: <6c0fd2bc0902020714v30130802t2090f8d737953010@mail.gmail.com> From: Hubert Le Van Gong To: Hannes Tschofenig Cc: oauth@ietf.org Subject: Re: [oauth] OAUTH Charter Proposal X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: oauth-bounces@ietf.org Errors-To: oauth-bounces@ietf.org Hi Hannes, Thanks for the clarification; I understand what was meant. I would note however that this paragraph mixes 2 distinct issues: backward compatibility and interoperability. We want to promote both but not necessarily at the expense of one of them (and security as well). For instance, it is recommended that at least one security algorithm is made mandatory. If we mandate backward compatibility then that algorithm can only be one of the algorithms already defined in OAuth 1.0 which, as noted in older email threads, is not a good idea. IMHO ensuring interoperability & good security of the to-be IETF spec is, in fine, paramount to ensuring 100% backward compatibility (of course a solution could be to mandate at least 2 security algos, one from the 1.0 spec and another more future-proof). These considerations may not need to appear in the charter but I think it is important to be as clear as possible on the intent of the charter. Cheers, Hubert >>"It seems desireable to profile OAuth 1.0 in a way that >>produces a specification that is a backwards compatible >>profile, i.e. any OAUTH 1.0 and the specification produced by >>this group must support a basic set of features to guarantee >>interoperability." >> >>- Profiling usually means to constrain further an existing >>specification. >> This seems to contradict the part of the charter that talks of >> supporting broader use cases beyond the original scope...? >> What did you mean there? > > When multiple options are provided then indicating which onces are mandatory > to implement is something that I call profiling. When the profiled version > is run against Oauth 1.0 it would still interoperate (in some sense; if that > particular Oauth 1.0 implementation had implemented all options). You > mention this aspect of improving interoperability in your next paragraph > below as well. > > The sentence about "Ability to address broader use cases than may be > contemplated by the original authors" can be more seen as a "we leave room > for extensions that offer additional use cases" phrase. > >>- I would argue that there is no guaranteed interoperability in the >> current OAuth 1.0 spec. We need to address this. The security report >> Sam (Hartman) created highlights a few things that should >> be done: >> (1) mandatory-to-implement algorithm(s) for security >> (2) interoperable way to find the lifetime of a request or >> access-token >> (3) description of how a service uses OAuth > > These things sound good to me. I guess you don't want to list them in the > charter itself, right? > > Ciao > Hannes > >> >>I had the same comment as George just sent on AuthZ vs. AuthN >> >>Cheers, >>Hubert >> >> >> >>On Fri, Jan 30, 2009 at 6:55 PM, Hannes Tschofenig >> wrote: >>> Hi all, >>> >>> After a chat with Lisa I got in touch with Eran to slightly >>revise the >>> charter text that Sam and Mark put together for the last >>IETF meeting. >>> >>> It should addresses some of the comments provided during the >>BOF. Your >>> feedback is welcome. >>> >>> Ciao >>> Hannes >>> >>> ------------------------------------- >>> >>> Open Authentication Protocol (oauth) >>> >>> Last Modified: 2009-01-30 >>> >>> Chair(s): >>> >>> TBD >>> >>> Applications Area Director(s): >>> >>> Chris Newman >>> Lisa Dusseault >>> >>> Applications Area Advisor: >>> >>> TBD >>> >>> Mailing Lists: >>> >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> Description of Working Group: >>> >>> OAuth allows a user to grant a third-party Web site or application >>> access to their resources, without revealing their credentials, or >>> even their identity. For example, a photo-sharing site that supports >>> OAuth would allow its users to use a third-party printing >>Web site to >>> access their private pictures, without gaining full control >>of the user account. >>> >>> OAuth consist of: >>> * A mechanism for exchanging a user's credentials for a >>token-secret >>> pair which can be used by a third party to access resources on their >>> behalf >>> * A mechanism for signing HTTP requests with the token-secret pair >>> >>> The Working Group will produce one or more documents suitable for >>> consideration as Proposed Standard, based upon the OAuth >>I-D, that will: >>> * Align OAuth with the Internet and Web architectures, best >>practices >>> and terminology >>> * Assure good security practice, or document gaps in its >>capabilities >>> * Promote interoperability >>> >>> This specifically means that as a starting point for the >>working group >>> the OAuth 1.0 specification is used and the available >>extension points >>> are going to be utilized. It seems desireable to profile >>OAuth 1.0 in >>> a way that produces a specification that is a backwards compatible >>> profile, i.e. any OAUTH 1.0 and the specification produced by this >>> group must support a basic set of features to guarantee >>> interoperability. >>> >>> Furthermore, Oauth 1.0 defines three signature methods used >>to protect >>> requests, namely PLAINTEXT, HMAC-SHA1, and RSA-SHA1. The group will >>> work on new signature methods in case the existing mechanisms do not >>> fulfill the security requirements. Existing signature >>methods will not >>> be modified but may be dropped as part of the backwards >>compatible profiling activity. >>> >>> In doing so, it should consider: >>> * Implementer experience >>> * Existing uses of OAuth >>> * Ability to achieve broad impementation >>> * Ability to address broader use cases than may be contemplated by >>> the original authors >>> * Impact on the Internet and Web >>> >>> The Working Group is not tasked with defining a generally applicable >>> HTTP Authentication mechanism (i.e., browser-based "2-leg" >>scenerio), >>> and should consider this work out of scope in its discussions. >>> However, if the deliverables are able to be factored in such a way >>> that this is a byproduct, or such a scenario could be addressed by >>> additional future work, the Working Group may choose to do so. >>> >>> After delivering OAuth, the Working Group MAY consider defining >>> additional functions and/or extensions, for example (but not limited >>> to): >>> * Discovery of authentication configuration >>> * Message integrity >>> * Recommendations regarding the structure of the token >>> >>> Goals and Milestones: >>> >>> 12/2009 Submit document(s) suitable for publication as >>standards-track >>> RFCs. >>> >>> _______________________________________________ >>> oauth mailing 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 oauth-bounces@ietf.org Mon Feb 2 07:17:15 2009 Return-Path: X-Original-To: oauth-archive@ietf.org Delivered-To: ietfarch-oauth-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB9523A6A0C; Mon, 2 Feb 2009 07:17:15 -0800 (PST) X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F357D3A6A0C for ; Mon, 2 Feb 2009 07:17:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.061, 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 aPwN0yuXiOaV for ; Mon, 2 Feb 2009 07:17:14 -0800 (PST) Received: from mail-qy0-f11.google.com (mail-qy0-f11.google.com [209.85.221.11]) by core3.amsl.com (Postfix) with ESMTP id C408F3A6983 for ; Mon, 2 Feb 2009 07:17:13 -0800 (PST) Received: by qyk4 with SMTP id 4so1942052qyk.13 for ; Mon, 02 Feb 2009 07:16:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=WxI4gEqVKl/gAMdlgpMe2GRUZEIvYumiqN1pNPFPHjU=; b=dMEm8Fbkfe5CWwuD3krs/Q4Iz2DFKyhLTFUcqAVLtc/DywL4VeH/J3VTPC15xPqPY9 /M/SaORJI10YS70B13FIDLLzkxxT9zBvLT2qpJumzhy+1qyLWuSAL/JqnMu7IZTyAkl5 xEZsIUIn/H7+Tm5KUWRx59y6BUSVZLlU3Nz8s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=hvZBrs21aycdeK1Pf3fDVaC8KXF57Mf3viwuyOGX50qLdJKwVsUcfzbpnLwTOPqylY v8SunQ7e6v4mjTubRyPNyoYtGbOoT5Un4wI+SVryMAWa/ATvWo/5MRDZxd0In27+C6K7 Krk2mmVGN93lBce9g5RpGvoXH8g0Z4X4Z+DnE= MIME-Version: 1.0 Received: by 10.214.11.9 with SMTP id 9mr6345678qak.269.1233587808288; Mon, 02 Feb 2009 07:16:48 -0800 (PST) In-Reply-To: References: Date: Mon, 2 Feb 2009 16:16:47 +0100 Message-ID: <6c0fd2bc0902020716s1b207f4bi1c1c47410d4c609@mail.gmail.com> From: Hubert Le Van Gong To: Brett McDowell Cc: oauth@ietf.org Subject: Re: [oauth] pointer to latest charter? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: oauth-bounces@ietf.org Errors-To: oauth-bounces@ietf.org Hi Brett, Below is a copy of the latest draft. ============================= Hi all, After a chat with Lisa I got in touch with Eran to slightly revise the charter text that Sam and Mark put together for the last IETF meeting. It should addresses some of the comments provided during the BOF. Your feedback is welcome. Ciao Hannes ------------------------------------- Open Authentication Protocol (oauth) Last Modified: 2009-01-30 Chair(s): TBD Applications Area Director(s): Chris Newman Lisa Dusseault Applications Area Advisor: TBD Mailing Lists: https://www.ietf.org/mailman/listinfo/oauth Description of Working Group: OAuth allows a user to grant a third-party Web site or application access to their resources, without revealing their credentials, or even their identity. For example, a photo-sharing site that supports OAuth would allow its users to use a third-party printing Web site to access their private pictures, without gaining full control of the user account. OAuth consist of: * A mechanism for exchanging a user's credentials for a token-secret pair which can be used by a third party to access resources on their behalf * A mechanism for signing HTTP requests with the token-secret pair The Working Group will produce one or more documents suitable for consideration as Proposed Standard, based upon the OAuth I-D, that will: * Align OAuth with the Internet and Web architectures, best practices and terminology * Assure good security practice, or document gaps in its capabilities * Promote interoperability This specifically means that as a starting point for the working group the OAuth 1.0 specification is used and the available extension points are going to be utilized. It seems desireable to profile OAuth 1.0 in a way that produces a specification that is a backwards compatible profile, i.e. any OAUTH 1.0 and the specification produced by this group must support a basic set of features to guarantee interoperability. Furthermore, Oauth 1.0 defines three signature methods used to protect requests, namely PLAINTEXT, HMAC-SHA1, and RSA-SHA1. The group will work on new signature methods in case the existing mechanisms do not fulfill the security requirements. Existing signature methods will not be modified but may be dropped as part of the backwards compatible profiling activity. In doing so, it should consider: * Implementer experience * Existing uses of OAuth * Ability to achieve broad impementation * Ability to address broader use cases than may be contemplated by the original authors * Impact on the Internet and Web The Working Group is not tasked with defining a generally applicable HTTP Authentication mechanism (i.e., browser-based "2-leg" scenerio), and should consider this work out of scope in its discussions. However, if the deliverables are able to be factored in such a way that this is a byproduct, or such a scenario could be addressed by additional future work, the Working Group may choose to do so. After delivering OAuth, the Working Group MAY consider defining additional functions and/or extensions, for example (but not limited to): * Discovery of authentication configuration * Message integrity * Recommendations regarding the structure of the token Goals and Milestones: 12/2009 Submit document(s) suitable for publication as standards-track RFCs. _______________________________________________ On Mon, Feb 2, 2009 at 3:51 PM, Brett McDowell wrote: > Hello everyone. I'm new to the mailing list. It was recommended to > me that I join the discussion to review and comment on the latest > charter. I wasn't able to find it on the ietf web site. Could > someone point me to that document? > > Many thanks, > > Brett McDowell > _______________________________________________ > oauth mailing 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 oauth-bounces@ietf.org Mon Feb 2 08:15:41 2009 Return-Path: X-Original-To: oauth-archive@ietf.org Delivered-To: ietfarch-oauth-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73F1E3A6B99; Mon, 2 Feb 2009 08:15:41 -0800 (PST) X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AEB33A6B98 for ; Mon, 2 Feb 2009 08:15:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.479 X-Spam-Level: X-Spam-Status: No, score=-4.479 tagged_above=-999 required=5 tests=[AWL=-1.880, 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 utTZo1o5Rm6H for ; Mon, 2 Feb 2009 08:15:39 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 70B343A6B99 for ; Mon, 2 Feb 2009 08:15:37 -0800 (PST) Received: (qmail 9590 invoked from network); 2 Feb 2009 16:15:18 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 2 Feb 2009 16:15:15 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Mon, 2 Feb 2009 09:15:15 -0700 From: Eran Hammer-Lahav To: George Fletcher , Hannes Tschofenig Date: Mon, 2 Feb 2009 09:15:05 -0700 Thread-Topic: [oauth] OAUTH Charter Proposal Thread-Index: AcmFPMnQ+u9fM6vaQ7OGPzxOJRDv7AAE+zSQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234127C939A08@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <033101c98303$e6fde7f0$0201a8c0@nsnintra.net> <4986F954.1090001@aol.com> In-Reply-To: <4986F954.1090001@aol.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [oauth] OAUTH Charter Proposal X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: oauth-bounces@ietf.org Errors-To: oauth-bounces@ietf.org How is exchanging credentials equal to authentication? I would not want to use the term API in the charter. While this is the current use case, I view OAuth as part of the 2617 family, and can be used for any HTTP request. I do not think most people consider every HTTP request an API call. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of George Fletcher > Sent: Monday, February 02, 2009 5:47 AM > To: Hannes Tschofenig > Cc: oauth@ietf.org > Subject: Re: [oauth] OAUTH Charter Proposal > > Not wanting to start a huge debate... but within the OAuth community > we've made the distinction between Authentication and Authorization, > with OAuth being an API Authorization protocol and leaving > Authentication out of scope. > > Is this charter planning to tackle authentication as well as > authorization? The statement... > > OAuth consist of: > > * A mechanism for exchanging a user's credentials for a token- > secret pair > > > has me a little confused. I would word this as... > > * A mechanism that allows a user to authorize API access via a > token-secret pair > > Thanks, > George > > > Hannes Tschofenig wrote: > > Hi all, > > > > After a chat with Lisa I got in touch with Eran to slightly revise > the > > charter text that Sam and Mark put together for the last IETF > meeting. > > > > It should addresses some of the comments provided during the BOF. > Your > > feedback is welcome. > > > > Ciao > > Hannes > > > > ------------------------------------- > > > > Open Authentication Protocol (oauth) > > > > Last Modified: 2009-01-30 > > > > Chair(s): > > > > TBD > > > > Applications Area Director(s): > > > > Chris Newman > > Lisa Dusseault > > > > Applications Area Advisor: > > > > TBD > > > > Mailing Lists: > > > > https://www.ietf.org/mailman/listinfo/oauth > > > > Description of Working Group: > > > > OAuth allows a user to grant a third-party Web site or application > access to > > their resources, without revealing their credentials, or even their > > identity. For example, a photo-sharing site that supports OAuth would > allow > > its users to use a third-party printing Web site to access their > private > > pictures, without gaining full control of the user account. > > > > OAuth consist of: > > * A mechanism for exchanging a user's credentials for a token- > secret pair > > which can be used by a third party to access resources on their > behalf > > * A mechanism for signing HTTP requests with the token-secret pair > > > > The Working Group will produce one or more documents suitable for > > consideration as Proposed Standard, based upon the OAuth I-D, that > will: > > * Align OAuth with the Internet and Web architectures, best > practices and > > terminology > > * Assure good security practice, or document gaps in its > capabilities > > * Promote interoperability > > > > This specifically means that as a starting point for the working > group the > > OAuth 1.0 specification is used and the > > available extension points are going to be utilized. It seems > desireable to > > profile OAuth 1.0 in a way that produces a specification that is a > backwards > > compatible profile, i.e. any OAUTH 1.0 and the specification produced > by > > this group must support a basic set of features to guarantee > > interoperability. > > > > Furthermore, Oauth 1.0 defines three signature methods used to > protect > > requests, namely PLAINTEXT, HMAC-SHA1, and RSA-SHA1. The group will > work on > > new signature methods in case the existing mechanisms do not fulfill > the > > security requirements. Existing signature methods will not be > modified but > > may be dropped as part of the backwards compatible profiling > activity. > > > > In doing so, it should consider: > > * Implementer experience > > * Existing uses of OAuth > > * Ability to achieve broad impementation > > * Ability to address broader use cases than may be contemplated by > the > > original authors > > * Impact on the Internet and Web > > > > The Working Group is not tasked with defining a generally applicable > HTTP > > Authentication mechanism (i.e., browser-based "2-leg" scenerio), and > should > > consider this work out of scope in its discussions. However, if the > > deliverables are able to be factored in such a way that this is a > byproduct, > > or such a scenario could be addressed by additional future work, the > Working > > Group may choose to do so. > > > > After delivering OAuth, the Working Group MAY consider defining > additional > > functions and/or extensions, for example > > (but not limited to): > > * Discovery of authentication configuration > > * Message integrity > > * Recommendations regarding the structure of the token > > > > Goals and Milestones: > > > > 12/2009 Submit document(s) suitable for publication as standards- > track > > RFCs. > > > > _______________________________________________ > > oauth mailing list > > oauth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > oauth mailing list > oauth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ oauth mailing list oauth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From oauth-bounces@ietf.org Mon Feb 2 08:43:00 2009 Return-Path: X-Original-To: oauth-archive@ietf.org Delivered-To: ietfarch-oauth-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D42228C154; Mon, 2 Feb 2009 08:43:00 -0800 (PST) X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B5B03A6B88 for ; Mon, 2 Feb 2009 08:42:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 uDPimDB1h3KA for ; Mon, 2 Feb 2009 08:42:57 -0800 (PST) Received: from mail-ew0-f21.google.com (mail-ew0-f21.google.com [209.85.219.21]) by core3.amsl.com (Postfix) with ESMTP id 2C8563A68AC for ; Mon, 2 Feb 2009 08:42:57 -0800 (PST) Received: by ewy14 with SMTP id 14so1949453ewy.13 for ; Mon, 02 Feb 2009 08:42:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=wM0r9gBiPQWwfe8/pRycLf/WjvQ0V9ja6BJm4CJWvik=; b=DUJJsY35LXfHHoezFWBKLrfkH7RJpqDVcJra4Y8QuoaKyqNlPNt1ufsQx6UZBs8FW3 8kQ0YDV/Fs7cjDjkx1rQBjHs5ygDamqVuUfUje65/Zoeaxmo4/OMhK3JAcWGowrf/3MQ djivDHJKkYNgd5B4xqvl5IoGMHRAlPoUB9W5Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=AQHuc/Zo9YKcYH4AirCZ3YvEG4jgIBO0pi2rDTPNjrpW2rMcHVw87GVSxUVidKy5PA ASfHxzyeemfHPLtfm7l56jX5gqejeqL28iMlK13hTRAoqeXznATQmtmN1m1B+zp0vHyG Z8tXypg5xMfpds68WXcB9PNGJFO8bXGLbpQME= MIME-Version: 1.0 Received: by 10.210.111.4 with SMTP id j4mr1089514ebc.1.1233592956968; Mon, 02 Feb 2009 08:42:36 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234127C939A08@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <033101c98303$e6fde7f0$0201a8c0@nsnintra.net> <4986F954.1090001@aol.com> <90C41DD21FB7C64BB94121FBBC2E7234127C939A08@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 2 Feb 2009 16:42:36 +0000 Message-ID: From: Blaine Cook To: Eran Hammer-Lahav Cc: "oauth@ietf.org" Subject: Re: [oauth] OAUTH Charter Proposal X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: oauth-bounces@ietf.org Errors-To: oauth-bounces@ietf.org On Mon, Feb 2, 2009 at 4:15 PM, Eran Hammer-Lahav wrote: > How is exchanging credentials equal to authentication? By exchanging the credentials in a verifiable way (i.e., with secrets & signing), you're authenticating the consumer as acting on behalf of the user. If we weren't trying to do *authenticated* requests, then there wouldn't be any point in hiding (or having) secrets. > I would not want to use the term API in the charter. While this is the current use case, I view OAuth as part of the 2617 family, and can be used for any HTTP request. I do not think most people consider every HTTP request an API call. +1 - perhaps the more general "Interface" makes sense? I think OAuth is actually a bit more general than 2617, in that it's possible to use it across transport protocols (though in general we should be targeting HTTP first). b. _______________________________________________ oauth mailing list oauth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From oauth-bounces@ietf.org Mon Feb 2 09:01:50 2009 Return-Path: X-Original-To: oauth-archive@ietf.org Delivered-To: ietfarch-oauth-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9B1C3A6BB9; Mon, 2 Feb 2009 09:01:50 -0800 (PST) X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 067DE3A6BB9 for ; Mon, 2 Feb 2009 09:01:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.436 X-Spam-Level: X-Spam-Status: No, score=-4.436 tagged_above=-999 required=5 tests=[AWL=-1.837, 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 dyThh3gmAKuO for ; Mon, 2 Feb 2009 09:01:49 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 2CBC83A6973 for ; Mon, 2 Feb 2009 09:01:49 -0800 (PST) Received: (qmail 20624 invoked from network); 2 Feb 2009 17:01:30 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 2 Feb 2009 17:01:30 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 2 Feb 2009 10:01:29 -0700 From: Eran Hammer-Lahav To: Blaine Cook Date: Mon, 2 Feb 2009 10:01:19 -0700 Thread-Topic: [oauth] OAUTH Charter Proposal Thread-Index: AcmFVUHsc7cPFW4aTomFcNYNSksrKAAAaycg Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234127C939A14@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <033101c98303$e6fde7f0$0201a8c0@nsnintra.net> <4986F954.1090001@aol.com> <90C41DD21FB7C64BB94121FBBC2E7234127C939A08@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [oauth] OAUTH Charter Proposal X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: oauth-bounces@ietf.org Errors-To: oauth-bounces@ietf.org Of course you are authenticating the credentials, but the spec does not tell you how to do it. Following this logic, every spec in the world with dependency on authentication will fall under this category... OAuth says "go get yourself authenticated and come back with something useful". The method in which the user authenticate against the Service Provider is completely out of scope. But obviously OAuth includes authentication in other areas such as authenticating tokens and potentially the identity of the Consumer and Service Provider (see Sam's review). This continues debate regarding authz/n is silly. OAuth currently does not specify how to authenticate the end user. But it might (not likely in core) in the future, for example, if it supports structured tokens with self signing capabilities (the user can produce tokens and hand them over to the Consumer without SP involvement, but the ability to authenticate them). In this case the user technically authenticate itself via a certificate and the verification is delegated on from the Consumer to the Service Provider. We need to separate the marketing from the technical architecture. EHL > -----Original Message----- > From: Blaine Cook [mailto:romeda@gmail.com] > Sent: Monday, February 02, 2009 8:43 AM > To: Eran Hammer-Lahav > Cc: oauth@ietf.org > Subject: Re: [oauth] OAUTH Charter Proposal > > On Mon, Feb 2, 2009 at 4:15 PM, Eran Hammer-Lahav > wrote: > > How is exchanging credentials equal to authentication? > > By exchanging the credentials in a verifiable way (i.e., with secrets > & signing), you're authenticating the consumer as acting on behalf of > the user. If we weren't trying to do *authenticated* requests, then > there wouldn't be any point in hiding (or having) secrets. > > > I would not want to use the term API in the charter. While this is > the current use case, I view OAuth as part of the 2617 family, and can > be used for any HTTP request. I do not think most people consider every > HTTP request an API call. > > +1 - perhaps the more general "Interface" makes sense? I think OAuth > is actually a bit more general than 2617, in that it's possible to use > it across transport protocols (though in general we should be > targeting HTTP first). > > b. _______________________________________________ oauth mailing list oauth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From oauth-bounces@ietf.org Mon Feb 2 09:02:55 2009 Return-Path: X-Original-To: oauth-archive@ietf.org Delivered-To: ietfarch-oauth-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70FC53A6BBD; Mon, 2 Feb 2009 09:02:55 -0800 (PST) X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA6F73A6973 for ; Mon, 2 Feb 2009 09:02:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[AWL=0.043, 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 6CH-13QifAFk for ; Mon, 2 Feb 2009 09:02:53 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by core3.amsl.com (Postfix) with ESMTP id EF0CB3A6817 for ; Mon, 2 Feb 2009 09:02:52 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so1771419wfd.31 for ; Mon, 02 Feb 2009 09:02:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=T0E12eEh+UheLCwv5ZtsKDh09T0rVysrfUhktYf0EMQ=; b=X1TfT+g6CDsGy2DrGduOAHBJ3ZdaosMPhC3W9AyS6pJVei2OXO4UGuHjwniA5CBS50 NVjjGnonK5mEa5+RNaa11vbX43OtbYar+Z5hAQ6ZAdDe/+X32ddqiVwdBGambuIl72hp 9OEN3OJflLX1xXPgGfiwaRvG9bzbOuGCNGI3g= 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=gib7Fiwwc9T+ogCqnRgMIsGLF8ADQCGdNckvWCb05SqHxS4YonHsdPiiCDr1nnpzWF mNXfPJNnIFfG1XE0R9KGDjchPb9VHlbpHrYSRzgl5FTAgfG58WpZClMlD9NNAj+NToeX R7TuYFZ0ZIZv1J5tx8ELOPg+NINVv1cn3l0vs= MIME-Version: 1.0 Received: by 10.142.125.4 with SMTP id x4mr1930455wfc.75.1233594152268; Mon, 02 Feb 2009 09:02:32 -0800 (PST) In-Reply-To: <033101c98303$e6fde7f0$0201a8c0@nsnintra.net> References: <033101c98303$e6fde7f0$0201a8c0@nsnintra.net> Date: Mon, 2 Feb 2009 12:02:32 -0500 X-Google-Sender-Auth: eca8a07b477277fe Message-ID: <422b9b380902020902w5f10c01fx619f9da78613f967@mail.gmail.com> From: kellan To: Hannes Tschofenig Cc: oauth@ietf.org Subject: Re: [oauth] OAUTH Charter Proposal X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: oauth-bounces@ietf.org Errors-To: oauth-bounces@ietf.org George's concern that we not position ourselves as an AuthN specification mirrors my own. Also, when we talk about extensibility points we're talking about the If-Not-Forbidden pattern, yes? Lastly, and I'll admit this is a dumb question, is the inconsistent capitalization to convey information, or are we still just in an early draft? -kellan On Fri, Jan 30, 2009 at 12:55 PM, Hannes Tschofenig wrote: > Hi all, > > After a chat with Lisa I got in touch with Eran to slightly revise the > charter text that Sam and Mark put together for the last IETF meeting. > > It should addresses some of the comments provided during the BOF. Your > feedback is welcome. > > Ciao > Hannes > > ------------------------------------- > > Open Authentication Protocol (oauth) > > Last Modified: 2009-01-30 > > Chair(s): > > TBD > > Applications Area Director(s): > > Chris Newman > Lisa Dusseault > > Applications Area Advisor: > > TBD > > Mailing Lists: > > https://www.ietf.org/mailman/listinfo/oauth > > Description of Working Group: > > OAuth allows a user to grant a third-party Web site or application access to > their resources, without revealing their credentials, or even their > identity. For example, a photo-sharing site that supports OAuth would allow > its users to use a third-party printing Web site to access their private > pictures, without gaining full control of the user account. > > OAuth consist of: > * A mechanism for exchanging a user's credentials for a token-secret pair > which can be used by a third party to access resources on their behalf > * A mechanism for signing HTTP requests with the token-secret pair > > The Working Group will produce one or more documents suitable for > consideration as Proposed Standard, based upon the OAuth I-D, that will: > * Align OAuth with the Internet and Web architectures, best practices and > terminology > * Assure good security practice, or document gaps in its capabilities > * Promote interoperability > > This specifically means that as a starting point for the working group the > OAuth 1.0 specification is used and the > available extension points are going to be utilized. It seems desireable to > profile OAuth 1.0 in a way that produces a specification that is a backwards > compatible profile, i.e. any OAUTH 1.0 and the specification produced by > this group must support a basic set of features to guarantee > interoperability. > > Furthermore, Oauth 1.0 defines three signature methods used to protect > requests, namely PLAINTEXT, HMAC-SHA1, and RSA-SHA1. The group will work on > new signature methods in case the existing mechanisms do not fulfill the > security requirements. Existing signature methods will not be modified but > may be dropped as part of the backwards compatible profiling activity. > > In doing so, it should consider: > * Implementer experience > * Existing uses of OAuth > * Ability to achieve broad impementation > * Ability to address broader use cases than may be contemplated by the > original authors > * Impact on the Internet and Web > > The Working Group is not tasked with defining a generally applicable HTTP > Authentication mechanism (i.e., browser-based "2-leg" scenerio), and should > consider this work out of scope in its discussions. However, if the > deliverables are able to be factored in such a way that this is a byproduct, > or such a scenario could be addressed by additional future work, the Working > Group may choose to do so. > > After delivering OAuth, the Working Group MAY consider defining additional > functions and/or extensions, for example > (but not limited to): > * Discovery of authentication configuration > * Message integrity > * Recommendations regarding the structure of the token > > Goals and Milestones: > > 12/2009 Submit document(s) suitable for publication as standards-track > RFCs. > > _______________________________________________ > oauth mailing 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 oauth-bounces@ietf.org Mon Feb 2 09:09:29 2009 Return-Path: X-Original-To: oauth-archive@ietf.org Delivered-To: ietfarch-oauth-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E128828C249; Mon, 2 Feb 2009 09:09:29 -0800 (PST) X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 018FF28C23F for ; Mon, 2 Feb 2009 09:09:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.348 X-Spam-Level: X-Spam-Status: No, score=-4.348 tagged_above=-999 required=5 tests=[AWL=-2.083, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cv+mZUTsrQlS for ; Mon, 2 Feb 2009 09:09:28 -0800 (PST) Received: from outbound-mail-139.bluehost.com (outbound-mail-139.bluehost.com [67.222.39.29]) by core3.amsl.com (Postfix) with SMTP id EFB0728C249 for ; Mon, 2 Feb 2009 09:09:27 -0800 (PST) Received: (qmail 19054 invoked by uid 0); 2 Feb 2009 17:09:11 -0000 Received: from unknown (HELO box320.bluehost.com) (69.89.31.120) by outboundproxy4.bluehost.com with SMTP; 2 Feb 2009 17:09:11 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=jkemp.net; h=Received:Cc:Message-Id:From:To:In-Reply-To:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:References:X-Mailer:X-Identified-User; b=IA+pVfDGfCp80DRDF8QqKFsLCIcjzfJGV/dDFU0TY0ab122pUh+9vH1uFgPDiQwDVjdxvrXVryhGXEKnTRxn/9q8Dq30AqMDdaqdxJ3sp9XeR8IbHOE2QTvgjpz3VbSg; Received: from c-75-69-14-217.hsd1.vt.comcast.net ([75.69.14.217] helo=[192.168.0.50]) by box320.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1LU2II-0002AL-OA; Mon, 02 Feb 2009 10:09:11 -0700 Message-Id: <8AC53A6C-A264-42ED-BBFA-2581DFB107E2@jkemp.net> From: John Kemp To: Blaine Cook In-Reply-To: Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 2 Feb 2009 12:09:06 -0500 References: <033101c98303$e6fde7f0$0201a8c0@nsnintra.net> <4986F954.1090001@aol.com> <90C41DD21FB7C64BB94121FBBC2E7234127C939A08@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-Mailer: Apple Mail (2.930.3) X-Identified-User: {1122:box320.bluehost.com:jkempnet:jkemp.net} {sentby:smtp auth 75.69.14.217 authed with john+jkemp.net} Cc: "oauth@ietf.org" Subject: Re: [oauth] OAUTH Charter Proposal X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: oauth-bounces@ietf.org Errors-To: oauth-bounces@ietf.org On Feb 2, 2009, at 11:42 AM, Blaine Cook wrote: > On Mon, Feb 2, 2009 at 4:15 PM, Eran Hammer-Lahav > wrote: >> How is exchanging credentials equal to authentication? > > By exchanging the credentials in a verifiable way (i.e., with secrets > & signing), you're authenticating the consumer as acting on behalf of > the user. If we weren't trying to do *authenticated* requests, then > there wouldn't be any point in hiding (or having) secrets. Right - we specify, for example, HMAC signing methods, used to ensure that the consumer and SP know the same key. The interesting discussion perhaps is about who is being authenticated, and by whom, at each point. > > >> I would not want to use the term API in the charter. While this is >> the current use case, I view OAuth as part of the 2617 family, and >> can be used for any HTTP request. I do not think most people >> consider every HTTP request an API call. > > +1 - perhaps the more general "Interface" makes sense? I think OAuth > is actually a bit more general than 2617, in that it's possible to use > it across transport protocols (though in general we should be > targeting HTTP first). I agree, and would add that the RFC 2617-compatible mechanism we specified in OAuth 1.0 conveys more information than that pertaining only to the authentication of the user (behind the user-agent). For now, it might be wise to be clear that we are unclear when describing this work ;) - johnk > > > b. > _______________________________________________ > oauth mailing 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 oauth-bounces@ietf.org Mon Feb 2 09:49:19 2009 Return-Path: X-Original-To: oauth-archive@ietf.org Delivered-To: ietfarch-oauth-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AB1F28C169; Mon, 2 Feb 2009 09:49:19 -0800 (PST) X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CF533A6A32 for ; Mon, 2 Feb 2009 09:49:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQAj1if4jOpL for ; Mon, 2 Feb 2009 09:49:17 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id 2209D3A69FB for ; Mon, 2 Feb 2009 09:49:16 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 25so266692eya.31 for ; Mon, 02 Feb 2009 09:48:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=XkeNrxIZ+xb6tY82J9YJv2wbnQqiXi3VlRXugpqcqrw=; b=ZXXTCl8AQgtzOhj4XuOqVUGJxLvICz82e7iEPq5CPRi3VdjbTz9wgBfmbpm9zPAFgV PBcRiAUKzewE1+9cPi1LjPORbU0QWMag+grVsGyPMWK+SK1EszBAVFqNDoWGbJbdoIy4 5olL8DwSNDrvm9JQKEHMD5Py7CZXtcWclKAhw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=NWgbONqNTwgWHm46liCibEdfipwsaToxBQNaAVqdQjRdbjN52mUSg0pBZ6TuVsRopd rwJOWt48/rNjvKEUIMwqYVwCSvt9EzuzMCb2vPFeIpEe6QAzGewMgWdReD49mImx9ySZ L8CkYzMpL8sx3sW8y+yHzJrZDYZ/bSKWCWJuU= MIME-Version: 1.0 Received: by 10.210.35.17 with SMTP id i17mr1923149ebi.70.1233596936168; Mon, 02 Feb 2009 09:48:56 -0800 (PST) In-Reply-To: <8AC53A6C-A264-42ED-BBFA-2581DFB107E2@jkemp.net> References: <033101c98303$e6fde7f0$0201a8c0@nsnintra.net> <4986F954.1090001@aol.com> <90C41DD21FB7C64BB94121FBBC2E7234127C939A08@P3PW5EX1MB01.EX1.SECURESERVER.NET> <8AC53A6C-A264-42ED-BBFA-2581DFB107E2@jkemp.net> Date: Mon, 2 Feb 2009 17:48:56 +0000 Message-ID: From: Blaine Cook To: John Kemp Cc: "oauth@ietf.org" Subject: Re: [oauth] OAUTH Charter Proposal X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: oauth-bounces@ietf.org Errors-To: oauth-bounces@ietf.org On Mon, Feb 2, 2009 at 5:09 PM, John Kemp wrote: > Right - we specify, for example, HMAC signing methods, used to ensure that > the consumer and SP know the same key. The interesting discussion perhaps is > about who is being authenticated, and by whom, at each point. Having discussed this with a couple of people off-list, it seems to me like the words "authentication" and "authorization" have too much baggage associated with them to be of use in clearly defining what OAuth is. I'm sure there are words for this stuff, but I like Eran's comment the best: "OAuth is a goddamn delegation protocol" I'm happy using whatever terminology, and fully agree with John that we should be clear that we are unclear on this. Which is totally fine, and ultimately we know what we're trying to do, so nit-picking the language isn't useful. < concerns rescinded > b. _______________________________________________ oauth mailing list oauth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From oauth-bounces@ietf.org Mon Feb 2 10:39:58 2009 Return-Path: X-Original-To: oauth-archive@ietf.org Delivered-To: ietfarch-oauth-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CAD23A6ABD; Mon, 2 Feb 2009 10:39:58 -0800 (PST) X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F8093A68CC for ; Mon, 2 Feb 2009 10:39:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CfoRs7UTM71d for ; Mon, 2 Feb 2009 10:39:56 -0800 (PST) Received: from imo-m12.mail.aol.com (imo-m12.mx.aol.com [64.12.143.100]) by core3.amsl.com (Postfix) with ESMTP id ACF183A6B28 for ; Mon, 2 Feb 2009 10:39:52 -0800 (PST) Received: from GFFletch@aol.com by imo-m12.mx.aol.com (mail_out_v39.1.) id 7.cb6.4749e300 (37688); Mon, 2 Feb 2009 13:39:03 -0500 (EST) Received: from palantir.local ([10.181.87.202]) by cia-mb08.mx.aol.com (v121_r5.5) with ESMTP id MAILCIAMB084-9338498735d03e4; Mon, 02 Feb 2009 13:05:05 -0500 Message-ID: <498735D0.3060304@aol.com> Date: Mon, 02 Feb 2009 13:05:04 -0500 From: George Fletcher Organization: AOL LLC User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Eran Hammer-Lahav References: <033101c98303$e6fde7f0$0201a8c0@nsnintra.net> <4986F954.1090001@aol.com> <90C41DD21FB7C64BB94121FBBC2E7234127C939A08@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234127C939A14@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234127C939A14@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-AOL-IP: 10.181.87.202 X-Mailer: Unknown (No Version) Cc: "oauth@ietf.org" Subject: Re: [oauth] OAUTH Charter Proposal X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: oauth-bounces@ietf.org Errors-To: oauth-bounces@ietf.org Eran Hammer-Lahav wrote: > Of course you are authenticating the credentials, but the spec does not tell you how to do it. Following this logic, every spec in the world with dependency on authentication will fall under this category... > > OAuth says "go get yourself authenticated and come back with something useful". The method in which the user authenticate against the Service Provider is completely out of scope. But obviously OAuth includes authentication in other areas such as authenticating tokens and potentially the identity of the Consumer and Service Provider (see Sam's review). > > This continues debate regarding authz/n is silly. OAuth currently does not specify how to authenticate the end user. But it might (not likely in core) in the future, for example, if it supports structured tokens with self signing capabilities (the user can produce tokens and hand them over to the Consumer without SP involvement, but the ability to authenticate them). In this case the user technically authenticate itself via a certificate and the verification is delegated on from the Consumer to the Service Provider. > +1 to structured tokens Does this need to get called out in the charter as a specific desire? Or do we just ensure it isn't precluded in the work that's done? Thanks, George > We need to separate the marketing from the technical architecture. > > EHL > > > >> -----Original Message----- >> From: Blaine Cook [mailto:romeda@gmail.com] >> Sent: Monday, February 02, 2009 8:43 AM >> To: Eran Hammer-Lahav >> Cc: oauth@ietf.org >> Subject: Re: [oauth] OAUTH Charter Proposal >> >> On Mon, Feb 2, 2009 at 4:15 PM, Eran Hammer-Lahav >> wrote: >> >>> How is exchanging credentials equal to authentication? >>> >> By exchanging the credentials in a verifiable way (i.e., with secrets >> & signing), you're authenticating the consumer as acting on behalf of >> the user. If we weren't trying to do *authenticated* requests, then >> there wouldn't be any point in hiding (or having) secrets. >> >> >>> I would not want to use the term API in the charter. While this is >>> >> the current use case, I view OAuth as part of the 2617 family, and can >> be used for any HTTP request. I do not think most people consider every >> HTTP request an API call. >> >> +1 - perhaps the more general "Interface" makes sense? I think OAuth >> is actually a bit more general than 2617, in that it's possible to use >> it across transport protocols (though in general we should be >> targeting HTTP first). >> >> b. >> > _______________________________________________ > oauth mailing 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 oauth-bounces@ietf.org Mon Feb 2 10:44:27 2009 Return-Path: X-Original-To: oauth-archive@ietf.org Delivered-To: ietfarch-oauth-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 491773A6AC8; Mon, 2 Feb 2009 10:44:27 -0800 (PST) X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE0D23A6AC8 for ; Mon, 2 Feb 2009 10:44:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.818 X-Spam-Level: X-Spam-Status: No, score=-2.818 tagged_above=-999 required=5 tests=[AWL=-0.220, 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 LQuHzNcotd24 for ; Mon, 2 Feb 2009 10:44:25 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.228]) by core3.amsl.com (Postfix) with ESMTP id 174063A68CC for ; Mon, 2 Feb 2009 10:44:25 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so1500139rvf.49 for ; Mon, 02 Feb 2009 10:44:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=UGg40AVpa/BEpYpMLPVGJ+BhTIsREt55XFWCpT4Smok=; b=FReisaRaDJ1tIFgRP8mTdkKJz76BwWvzb+kAdU2TkQ9wGuuJ9Dw8sNkOq/VP2w7V7u x9mVTJ4oMq2KKpVFTPcL0Ubk8VEF++aDWbDh1a0K6jkcTF0XCRXCB1z8Vz51Wm+H8obH Jf5kUbFjhTHBHJk0T1E51zbJa/Ntxx5h6ImxI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=oL1sCdbizyfSmknw1SlUH0XLW9VR2+dgxBvy1csI6pgEo+3kWUwkCx8O6EjUANmZi7 jbyU75/uceXl6Rba3R7ehL03uYlT5u2DrlrCbwbl50Csb32GUyVsL/Mq4vjRcDRW1/GK IRY6YmTmanUZH5XE1wBYVgMEFTp+bGPXTzSw4= MIME-Version: 1.0 Received: by 10.141.19.9 with SMTP id w9mr1068775rvi.252.1233600245524; Mon, 02 Feb 2009 10:44:05 -0800 (PST) In-Reply-To: <1bc4603e0902020024j71230bbr47b0b2c65b58b2b4@mail.gmail.com> References: <3D3C75174CB95F42AD6BCC56E5555B45FFEE62@FIESEXC015.nsn-intra.net> <1bc4603e0902020024j71230bbr47b0b2c65b58b2b4@mail.gmail.com> Date: Mon, 2 Feb 2009 10:44:05 -0800 Message-ID: From: Lisa Dusseault To: Chris Messina Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , oauth@ietf.org Subject: Re: [oauth] OAUTH Charter Proposal X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1674887523==" Sender: oauth-bounces@ietf.org Errors-To: oauth-bounces@ietf.org --===============1674887523== Content-Type: multipart/alternative; boundary=000e0cd151946de7c80461f3f0d6 --000e0cd151946de7c80461f3f0d6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Mon, Feb 2, 2009 at 12:24 AM, Chris Messina wrote: > > ... > it sounded like there were some definitive "security requirements" (or > else you wouldn't be able to tell if they were fulfilled!) but perhaps > that's not what's intended there. > There are. The main ones are: BCP 61, "*Strong Security Requirements for Internet Engineering Task Force Standard Protocols* " BCP 72, "*Guidelines for Writing RFC Text on Security Considerations* ", < http://tools.ietf.org/html/rfc3552> The IETF is not stellar at documenting everything that has come to be a security requirement through popular demand, but we do have the above. Lisa --000e0cd151946de7c80461f3f0d6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Feb 2, 2009 at 12:24 AM, Chris M= essina <chr= is.messina@gmail.com> wrote:

...
 it= sounded like there were some definitive "security requirements" = (or else you wouldn't be able to tell if they were fulfilled!) but perh= aps that's not what's intended there.

There are. The main ones are:
BCP= 61, "Strong Security Requirements for Internet Engineering Task Fo= rce Standard Protocols " <http://tools.ietf.org/html/rfc3365>
BCP 72, "Guidelines for Writing RFC Text on Security Considerations= ", <http://tool= s.ietf.org/html/rfc3552>

The IETF is not stellar at documenti= ng everything that has come to be a security requirement through popular de= mand, but we do have the above.

Lisa
--000e0cd151946de7c80461f3f0d6-- --===============1674887523== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ oauth mailing list oauth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --===============1674887523==-- From oauth-bounces@ietf.org Mon Feb 2 10:50:21 2009 Return-Path: X-Original-To: oauth-archive@ietf.org Delivered-To: ietfarch-oauth-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6200A3A6AC8; Mon, 2 Feb 2009 10:50:21 -0800 (PST) X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 116193A6AEE for ; Mon, 2 Feb 2009 10:50:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.395 X-Spam-Level: X-Spam-Status: No, score=-4.395 tagged_above=-999 required=5 tests=[AWL=-1.797, 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 9CPDMPVz4X9P for ; Mon, 2 Feb 2009 10:50:16 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 80C4C3A6AC8 for ; Mon, 2 Feb 2009 10:50:16 -0800 (PST) Received: (qmail 10422 invoked from network); 2 Feb 2009 18:49:57 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 2 Feb 2009 18:49:57 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 2 Feb 2009 11:49:57 -0700 From: Eran Hammer-Lahav To: "oauth@ietf.org" Date: Mon, 2 Feb 2009 11:49:45 -0700 Thread-Topic: [oauth] OAUTH Charter Proposal Thread-Index: AcmFZjvnlaUDAynyQ0KLfQyCsucB4QAAB3fw Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234127C939A2B@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <3D3C75174CB95F42AD6BCC56E5555B45FFEE62@FIESEXC015.nsn-intra.net> <1bc4603e0902020024j71230bbr47b0b2c65b58b2b4@mail.gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [oauth] OAUTH Charter Proposal X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1856291084==" Sender: oauth-bounces@ietf.org Errors-To: oauth-bounces@ietf.org --===============1856291084== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E7234127C939A2BP3PW5EX1MB01E_" --_000_90C41DD21FB7C64BB94121FBBC2E7234127C939A2BP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Of course, even 'delegation' is a problematic term. HTTP Basic auth is not = considered a delegation protocol but it really is. The End User gives the U= ser Agent some credentials to access resources on its behalf on the Web Ser= ver. There is no restriction in Basic auth about the number of credentials = used, so there could be a special one to give the browser. Hmm. I guess that makes OAuth a 'goddamn goddamn protocol', if we replace a= ll the problematic words... of course that does not help us at all. I would not waste too much time trying to find a one liner to describe the = protocol. And when in doubt, the Core 1.0 spec defines a framework for us t= o work with, and can always be used to draw the lines of what we are trying= to solve. EHL --_000_90C41DD21FB7C64BB94121FBBC2E7234127C939A2BP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Of course, even ‘delegation’ is a problematic te= rm. HTTP Basic auth is not considered a delegation protocol but it really is. T= he End User gives the User Agent some credentials to access resources on its behalf on the Web Server. There is no restriction in Basic auth about the number of credentials used, so there could be a special one to give the browser.

 

Hmm. I guess that makes OAuth a ‘goddamn goddamn proto= col’, if we replace all the problematic words… of course that does not help= us at all.

 

I would not waste too much time trying to find a one liner t= o describe the protocol. And when in doubt, the Core 1.0 spec defines a frame= work for us to work with, and can always be used to draw the lines of what we ar= e trying to solve.

 

EHL

 

--_000_90C41DD21FB7C64BB94121FBBC2E7234127C939A2BP3PW5EX1MB01E_-- --===============1856291084== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ oauth mailing list oauth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --===============1856291084==-- From oauth-bounces@ietf.org Mon Feb 2 11:58:25 2009 Return-Path: X-Original-To: oauth-archive@ietf.org Delivered-To: ietfarch-oauth-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFC1A28C11D; Mon, 2 Feb 2009 11:58:25 -0800 (PST) X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A8963A696D for ; Mon, 2 Feb 2009 11:58:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.424 X-Spam-Level: X-Spam-Status: No, score=-5.424 tagged_above=-999 required=5 tests=[AWL=-0.222, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 dqD1dirf1y3Z for ; Mon, 2 Feb 2009 11:58:19 -0800 (PST) Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by core3.amsl.com (Postfix) with ESMTP id 9AF363A68C2 for ; Mon, 2 Feb 2009 11:58:16 -0800 (PST) Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id n12JvrRe004409; Mon, 2 Feb 2009 11:57:53 -0800 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Feb 2009 11:57:53 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 2 Feb 2009 11:57:52 -0800 Message-ID: <2788466ED3E31C418E9ACC5C3166155768B24D@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [oauth] OAUTH Charter Proposal Thread-Index: AcmFPMm3btexUrcIR8KMhSEYbNI68wALYfkh References: <033101c98303$e6fde7f0$0201a8c0@nsnintra.net> <4986F954.1090001@aol.com> From: "Hallam-Baker, Phillip" To: "George Fletcher" , "Hannes Tschofenig" X-OriginalArrivalTime: 02 Feb 2009 19:57:53.0030 (UTC) FILETIME=[88894A60:01C98570] Cc: oauth@ietf.org Subject: Re: [oauth] OAUTH Charter Proposal X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1348646680==" Sender: oauth-bounces@ietf.org Errors-To: oauth-bounces@ietf.org This is a multi-part message in MIME format. --===============1348646680== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C98570.884A26F9" This is a multi-part message in MIME format. ------_=_NextPart_001_01C98570.884A26F9 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think it is imnportant to discuss the charter here because the hardest = part of this whole problem is working out what we are actually trying to = achieve and arriving at consensus that we are all talking about the same = thing. =20 We do not have to develop an authentication protocol for OAuth but we do = need to understand what an authentication protocol does and what is = meant by an authorization protocol. =20 =20 Another feature of the discussion is that there are parts of OAUTH that = people now want to use simply as platform and that has implications. = Lots of people are talking about the need to sign pieces of http = headers. =20 =20 =20 I don't think we need yet another Internet authentication protocol.=20 =20 What we do however need, and in particular I think OAuth requires to be = explicable to lay people, is a uniform identifier to represent the party = being authenticated and a standard human-readable presentation thereof. =20 Otherwise I fear that we will end up with yet more middle-ware that does = not quite meet up at either end. =20 =20 So let the user be authenticated by SAML, WS-Trust, HTTP-Auth, OpenID or = whatever. But there has to be a clearly defined mental model of what = that means. =20 Lets take SAML as a starting point since it has a consistent = nomenclature that has considerable consensus. =20 =20 We have an authentication protocol, that delivers a SAML assertion. =20 Regardless of what the specification might say, the actual semantics of = a SAML authentication assertion (and indeed any delegated mechanism) are = 'here is a partywhich I have authenticated as X by reference to = mechanism Y which you can verifty by reference to credential Z." =20 In other words, the use of delegated authentication does not in fact = remove the need for authentication, it merely changes the type of = credential that the relying party is going to use. =20 =20 Now one problem we punted on in SAML, that I now regret is the question = of what the user identifier would be. This was left to the individual = authentication federation. Which I view as a mistake because it means = that we lack two critical pieces that are necessary to make the system = work. =20 The first is discovery, say Alice is identfied by = SSQW:eurtu.org/20/alice@example.com =20 That is a perfectly legal SAML identifier. Which is a problem. We left = far too many options which would not have been so bad if we had made it = very clear that there was a very strong preference for one particular = form when we are dealling with users in an internet context. =20 user@idp.example.org Now if we had only said use email addresses, and only email addresses we = would have been only one step away from universal log-in. =20 =20 All SAML is missing is an SRV identifier for locating an authentication = server for a given identifier. If that is in place alice can use = alice@example.com as her login identifier on any site whatsoever and the = site can then go out and find that there is a SAML authentication = assertion service at idp.example.com. =20 So if we simply say to all the authentication protocols out there that = they can work with OAuth, if and only if they =20 1) Use an email address format identifier 2) Specify an SRV based discovery mechanism =20 That would of course mean that the group might well have to write a = document describing the SRV bindings for a number of existing protocols = that are out there, or rather for subsets of such protocols. But that is = the general requirement for a new group. =20 =20 We can argue about the precise shape of the box (i.e. the discovery = mechanism, the identifier to be used) but I don't think we should argue = about the need for such a box or the need to leave stuff out. =20 There are at least 4 different general purpose authentication frameworks = out there and because they are all designed to be meta and all designed = to be interoperable you can actually create cycles within cycles just = like there are folk who run VMWare Linux in a VM Ware Windows in a = VMWare Linux.=20 =20 =20 After that, we can get down to the much harder problem of working out = what an OAuth token should be called. Contrary to discussion in the = group, I do not think it maps cleanly onto any concept in the existing = nomenclature. Whch is probably why the discussion turns circular. =20 Moreover, folk should remember that this is a concept that was botched = in pretty much every operating system design, especially UNIX. I don't = know of any O/S which allows a user to easily and cleanly set up an = access rule of the form 'Sendmail can manage mail on behalf of Fred' = without granting more access than is necessary for the limited task. = These schemes inevitably use the big hammer of root privilege which does = not exist on the net. The problem is not that hard, it is unsolved = because it was not necessary to solve it earlier. =20 What we are talking about here is a limited delegation of authority. =20 There are different ways of implementing a delegation of authority. One = is to establish a new user account with the specified authentication = access and privileges, the second is to add an ACL to the resource in = question allowing a specified party to gain access. =20 Depending on which method of implementaion you chose, the OAuth = statement will appear to be authorization or Authentication. But it is = neither, it is a delegation of authority. If we try to call it = authorization we end up having to find a new name for ACLs. =20 =20 . ________________________________ From: oauth-bounces@ietf.org on behalf of George Fletcher Sent: Mon 2/2/2009 8:47 AM To: Hannes Tschofenig Cc: oauth@ietf.org Subject: Re: [oauth] OAUTH Charter Proposal Not wanting to start a huge debate... but within the OAuth community we've made the distinction between Authentication and Authorization, with OAuth being an API Authorization protocol and leaving Authentication out of scope. Is this charter planning to tackle authentication as well as authorization? The statement... > OAuth consist of: > * A mechanism for exchanging a user's credentials for a token-secret = pair > =20 has me a little confused. I would word this as... * A mechanism that allows a user to authorize API access via a token-secret pair Thanks, George Hannes Tschofenig wrote: > Hi all, > > After a chat with Lisa I got in touch with Eran to slightly revise the > charter text that Sam and Mark put together for the last IETF meeting. > > It should addresses some of the comments provided during the BOF. Your > feedback is welcome. > > Ciao > Hannes > > ------------------------------------- > > Open Authentication Protocol (oauth) > > Last Modified: 2009-01-30 > > Chair(s): > > TBD > > Applications Area Director(s): > > Chris Newman > Lisa Dusseault > > Applications Area Advisor: > > TBD > > Mailing Lists: > > https://www.ietf.org/mailman/listinfo/oauth > > Description of Working Group: > > OAuth allows a user to grant a third-party Web site or application = access to > their resources, without revealing their credentials, or even their > identity. For example, a photo-sharing site that supports OAuth would = allow > its users to use a third-party printing Web site to access their = private > pictures, without gaining full control of the user account. > > OAuth consist of: > * A mechanism for exchanging a user's credentials for a token-secret = pair > which can be used by a third party to access resources on their behalf > * A mechanism for signing HTTP requests with the token-secret pair > > The Working Group will produce one or more documents suitable for > consideration as Proposed Standard, based upon the OAuth I-D, that = will: > * Align OAuth with the Internet and Web architectures, best = practices and > terminology > * Assure good security practice, or document gaps in its = capabilities > * Promote interoperability > > This specifically means that as a starting point for the working group = the > OAuth 1.0 specification is used and the=20 > available extension points are going to be utilized. It seems = desireable to > profile OAuth 1.0 in a way that produces a specification that is a = backwards > compatible profile, i.e. any OAUTH 1.0 and the specification produced = by > this group must support a basic set of features to guarantee > interoperability. > > Furthermore, Oauth 1.0 defines three signature methods used to protect > requests, namely PLAINTEXT, HMAC-SHA1, and RSA-SHA1. The group will = work on > new signature methods in case the existing mechanisms do not fulfill = the > security requirements. Existing signature methods will not be modified = but > may be dropped as part of the backwards compatible profiling activity. > > In doing so, it should consider: > * Implementer experience > * Existing uses of OAuth > * Ability to achieve broad impementation > * Ability to address broader use cases than may be contemplated by = the > original authors > * Impact on the Internet and Web > > The Working Group is not tasked with defining a generally applicable = HTTP > Authentication mechanism (i.e., browser-based "2-leg" scenerio), and = should > consider this work out of scope in its discussions. However, if the > deliverables are able to be factored in such a way that this is a = byproduct, > or such a scenario could be addressed by additional future work, the = Working > Group may choose to do so. > > After delivering OAuth, the Working Group MAY consider defining = additional > functions and/or extensions, for example > (but not limited to): > * Discovery of authentication configuration > * Message integrity > * Recommendations regarding the structure of the token > > Goals and Milestones: > > 12/2009 Submit document(s) suitable for publication as = standards-track > RFCs. > > _______________________________________________ > oauth mailing list > oauth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > =20 _______________________________________________ oauth mailing list oauth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ------_=_NextPart_001_01C98570.884A26F9 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [oauth] OAUTH Charter Proposal=0A= =0A= =0A= =0A=
=0A=
I think it is = imnportant to discuss the charter here because the hardest part of this = whole problem is working out what we are actually trying to achieve and = arriving at consensus that we are all talking about the same = thing.
=0A=
 
=0A=
We do not have to develop an = authentication protocol for OAuth but we do need to understand what an = authentication protocol does and what is meant by an authorization = protocol.
=0A=
 
=0A=
 
=0A=
Another feature of the = discussion is that there are parts of OAUTH that people now want to use = simply as platform and that has implications. Lots of people are talking = about the need to sign pieces of http headers.
=0A=
 
=0A=
 
=0A=
 
=0A=
I don't think = we need yet another Internet authentication protocol.
=0A=
 
=0A=
What we do however need, and = in particular I think OAuth requires to be explicable to lay people, is = a uniform identifier to represent the party being authenticated and a = standard human-readable presentation thereof.
=0A=
 
=0A=
Otherwise I fear that we will = end up with yet more middle-ware that does not quite meet up at either = end.
=0A=
 
=0A=
 
=0A=
So let the user be = authenticated by SAML, WS-Trust, HTTP-Auth, OpenID or whatever. But = there has to be a clearly defined mental model of what that = means.
=0A=
 
=0A=
Lets take SAML as a starting = point since it has a consistent nomenclature that has considerable = consensus.
=0A=
 
=0A=
 
=0A=
We have an authentication = protocol, that delivers a SAML assertion.
=0A=
 
=0A=
Regardless of what the = specification might say, the actual semantics of a SAML authentication = assertion (and indeed any delegated mechanism) are 'here is a partywhich = I have authenticated as X by reference to mechanism Y which you can = verifty by reference to credential Z."
=0A=
 
=0A=
In other words, the use of = delegated authentication does not in fact remove the need for = authentication, it merely changes the type of credential that the = relying party is going to use.
=0A=
 
=0A=
 
=0A=
Now one problem we punted on = in SAML, that I now regret is the question of what the user identifier = would be. This was left to the individual authentication federation. = Which I view as a mistake because it means that we lack two critical = pieces that are necessary to make the system work.
=0A=
 
=0A=
The first is discovery, say = Alice is identfied by SSQW:eurtu.org/20/alice@example.com
=0A=
 
=0A=
That is a perfectly legal = SAML identifier. Which is a problem. We left far too many options which = would not have been so bad if we had made it very clear that there was a = very strong preference for one particular form when we are dealling with = users in an internet context.
=0A=
 
=0A=
       = <saml:NameIdentifier
       &nbs= p; = Format=3D"urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
=          = user@idp.example.org
       = </saml:NameIdentifier>
=0A=
Now if we had only said use = email addresses, and only email addresses we would have been only one = step away from universal log-in.
=0A=
 
=0A=
 
=0A=
All SAML is missing is an SRV = identifier for locating an authentication server for a given identifier. = If that is in place alice can use alice@example.com as her login = identifier on any site whatsoever and the site can then go out and find = that there is a SAML authentication assertion service at = idp.example.com.
=0A=
 
=0A=
So if we simply say to all = the authentication protocols out there that they can work with OAuth, if = and only if they
=0A=
 
=0A=
1) Use an email address = format identifier
=0A=
2) Specify an SRV based = discovery mechanism
=0A=
 
=0A=
That would of course mean = that the group might well have to write a document describing the SRV = bindings for a number of existing protocols that are out there, or = rather for subsets of such protocols. But that is the general = requirement for a new group.
=0A=
 
=0A=
 
=0A=
We can argue about the = precise shape of the box (i.e. the discovery mechanism, the identifier = to be used) but I don't think we should argue about the need for such a = box or the need to leave stuff out.
=0A=
 
=0A=
There are at least 4 = different general purpose authentication frameworks out there and = because they are all designed to be meta and all designed to be = interoperable you can actually create cycles within cycles just like = there are folk who run VMWare Linux in a VM Ware Windows in a VMWare = Linux.
=0A=
 
=0A=
 
=0A=
After that, we can get down = to the much harder problem of working out what an OAuth token should be = called. Contrary to discussion in the group, I do not think it maps = cleanly onto any concept in the existing nomenclature. Whch is probably = why the discussion turns circular.
=0A=
 
=0A=
Moreover, folk should = remember that this is a concept that was botched in pretty much every = operating system design, especially UNIX. I don't know of any O/S which = allows a user to easily and cleanly set up an access rule of the form = 'Sendmail can manage mail on behalf of Fred' without granting more = access than is necessary for the limited task. These schemes inevitably = use the big hammer of root privilege which does not exist on the net. = The problem is not that hard, it is unsolved because it was not = necessary to solve it earlier.
=0A=
 
=0A=
What we are talking about = here is a limited delegation of authority.
=0A=
 
=0A=
There are different ways of = implementing a delegation of authority. One is to establish a new user = account with the specified authentication access and privileges, the = second is to add an ACL to the resource in question allowing a specified = party to gain access.
=0A=
 
=0A=
Depending on which method of = implementaion you chose, the OAuth statement will appear to be = authorization or Authentication. But it is neither, it is a delegation = of authority. If we try to call it authorization we end up having to = find a new name for ACLs.
=0A=
 
=0A=
 
=0A=
.
=0A=

=0A=
=0A= From: oauth-bounces@ietf.org on = behalf of George Fletcher
Sent: Mon 2/2/2009 8:47 = AM
To: Hannes Tschofenig
Cc: = oauth@ietf.org
Subject: Re: [oauth] OAUTH Charter = Proposal

=0A=
=0A=

Not wanting to start a huge debate... but within the = OAuth community
we've made the distinction between Authentication and = Authorization,
with OAuth being an API Authorization protocol and = leaving
Authentication out of scope.

Is this charter planning = to tackle authentication as well as
authorization? The = statement...
> OAuth consist of:
>   * A mechanism = for exchanging a user's credentials for a token-secret = pair
>  
has me a little confused.  I would word = this as...

* A mechanism that allows a user to authorize API = access via a
token-secret = pair

Thanks,
George


Hannes Tschofenig = wrote:
> Hi all,
>
> After a chat with Lisa I got in = touch with Eran to slightly revise the
> charter text that Sam and = Mark put together for the last IETF meeting.
>
> It should = addresses some of the comments provided during the BOF. Your
> = feedback is welcome.
>
> Ciao
> Hannes
>
> = -------------------------------------
>
> Open = Authentication Protocol (oauth)
>
> Last Modified: = 2009-01-30
>
> Chair(s):
>
> TBD
>
> = Applications Area Director(s):
>
> Chris Newman = <chris.newman@sun.com>
> Lisa Dusseault = <lisa@osafoundation.org>
>
> Applications Area = Advisor:
>
> TBD
>
> Mailing = Lists:
>
> https://www.ietf.org= /mailman/listinfo/oauth
>
> Description of Working = Group:
>
> OAuth allows a user to grant a third-party Web = site or application access to
> their resources, without revealing = their credentials, or even their
> identity. For example, a = photo-sharing site that supports OAuth would allow
> its users to = use a third-party printing Web site to access their private
> = pictures, without gaining full control of the user = account.
>
> OAuth consist of:
>   * A = mechanism for exchanging a user's credentials for a token-secret = pair
> which can be used by a third party to access resources on = their behalf
>   * A mechanism for signing HTTP requests = with the token-secret pair
>
> The Working Group will = produce one or more documents suitable for
> consideration as = Proposed Standard, based upon the OAuth I-D, that = will:
>   * Align OAuth with the Internet and Web = architectures, best practices and
> = terminology
>   * Assure good security practice, or = document gaps in its capabilities
>   * Promote = interoperability
>
> This specifically means that as a = starting point for the working group the
> OAuth 1.0 specification = is used and the 
> available extension points are going to be = utilized. It seems desireable to
> profile OAuth 1.0 in a way that = produces a specification that is a backwards
> compatible profile, = i.e. any OAUTH 1.0 and the specification produced by
> this group = must support a basic set of features to guarantee
> = interoperability.
>
> Furthermore, Oauth 1.0 defines three = signature methods used to protect
> requests, namely PLAINTEXT, = HMAC-SHA1, and RSA-SHA1. The group will work on
> new signature = methods in case the existing mechanisms do not fulfill the
> = security requirements. Existing signature methods will not be modified = but
> may be dropped as part of the backwards compatible profiling = activity.
>
> In doing so, it should = consider:
>   * Implementer = experience
>   * Existing uses of = OAuth
>   * Ability to achieve broad = impementation
>   * Ability to address broader use cases = than may be contemplated by the
> original = authors
>   * Impact on the Internet and = Web
>
> The Working Group is not tasked with defining a = generally applicable HTTP
> Authentication mechanism (i.e., = browser-based "2-leg" scenerio), and should
> consider this work = out of scope in its discussions. However, if the
> deliverables = are able to be factored in such a way that this is a byproduct,
> = or such a scenario could be addressed by additional future work, the = Working
> Group may choose to do so.
>
> After = delivering OAuth, the Working Group MAY consider defining = additional
> functions and/or extensions, for example
> (but = not limited to):
>   * Discovery of authentication = configuration
>   * Message = integrity
>   * Recommendations regarding the structure = of the token
>
> Goals and Milestones:
>
> = 12/2009     Submit document(s) suitable for = publication as standards-track
> RFCs.
>
> = _______________________________________________
> oauth mailing = list
> oauth@ietf.org
> https://www.ietf.org= /mailman/listinfo/oauth
>
>  
______________= _________________________________
oauth mailing = list
oauth@ietf.org
https://www.ietf.org= /mailman/listinfo/oauth

------_=_NextPart_001_01C98570.884A26F9-- --===============1348646680== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ oauth mailing list oauth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --===============1348646680==-- From oauth-bounces@ietf.org Mon Feb 2 15:01:56 2009 Return-Path: X-Original-To: oauth-archive@ietf.org Delivered-To: ietfarch-oauth-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA8743A6B1B; Mon, 2 Feb 2009 15:01:56 -0800 (PST) X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B28983A6823 for ; Mon, 2 Feb 2009 15:01:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[AWL=0.700, 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 5ue9s7D2XUtJ for ; Mon, 2 Feb 2009 15:01:55 -0800 (PST) Received: from chilco.textdrive.com (chilco.textdrive.com [207.7.108.242]) by core3.amsl.com (Postfix) with ESMTP id 13A203A67B5 for ; Mon, 2 Feb 2009 15:01:54 -0800 (PST) Received: from [192.168.3.166] (83-70-234-252-dynamic.b-ras1.prp.dublin.eircom.net [83.70.234.252]) by chilco.textdrive.com (Postfix) with ESMTP id E4D45DD628 for ; Mon, 2 Feb 2009 23:01:34 +0000 (UTC) Message-ID: <49877B4C.8020107@dehora.net> Date: Mon, 02 Feb 2009 23:01:32 +0000 From: Bill de hOra User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: oauth@ietf.org References: <033101c98303$e6fde7f0$0201a8c0@nsnintra.net> In-Reply-To: <033101c98303$e6fde7f0$0201a8c0@nsnintra.net> Subject: Re: [oauth] OAUTH Charter Proposal X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: oauth-bounces@ietf.org Errors-To: oauth-bounces@ietf.org Hannes Tschofenig wrote: > Hi all, > > After a chat with Lisa I got in touch with Eran to slightly revise the > charter text that Sam and Mark put together for the last IETF meeting. > > It should addresses some of the comments provided during the BOF. Your > feedback is welcome. +1. My only concern is interop around the signing methods. Usually this requires a MUST for at least one signing mechanism. Bill _______________________________________________ oauth mailing list oauth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From oauth-bounces@ietf.org Mon Feb 2 15:30:34 2009 Return-Path: X-Original-To: oauth-archive@ietf.org Delivered-To: ietfarch-oauth-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D6E43A6B1B; Mon, 2 Feb 2009 15:30:34 -0800 (PST) X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C04E43A67B5 for ; Mon, 2 Feb 2009 15:28:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.611 X-Spam-Level: X-Spam-Status: No, score=-1.611 tagged_above=-999 required=5 tests=[AWL=0.988, 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 nHPdotByxaVr for ; Mon, 2 Feb 2009 15:28:22 -0800 (PST) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.185]) by core3.amsl.com (Postfix) with ESMTP id 5A99528C11D for ; Mon, 2 Feb 2009 15:28:22 -0800 (PST) Received: by nf-out-0910.google.com with SMTP id b11so266585nfh.39 for ; Mon, 02 Feb 2009 15:28:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:in-reply-to:references :mime-version:content-type:message-id:cc:content-transfer-encoding :from:subject:date:to:x-pgp-agent:x-mailer; bh=O/MFWHf0EbeYUz7WRDhw2Hx5tPRUJ7Tj2uOLuIyd/2E=; b=MFeKMvR6Mgq2PUv1iAaPw+0Zi1PjcmcjaX+nK7uRT603G8ul2oCz5gqiCp076KOyNn mbv+Jnwf6pfAp3jcCmp4k9ZLRES3ejWAMwQ8gh/amtCVGjYkLf1Yv+3qjwfgLWi6PsV0 YW508yiUuNPNlkYiPsh0kNRqyVhst07lXT31A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:in-reply-to:references:mime-version:content-type:message-id :cc:content-transfer-encoding:from:subject:date:to:x-pgp-agent :x-mailer; b=Ljf7w71FGQwKzqL2/PzvhIAZfWpSW/poSlnzqPT3JIZFWjH/Uvi4HK+GLfUdeT3zgK z0DuIn9VdGc9JzEV431Us5bkx84HrpeTpwCBBDNFpq7vo92qVu7CUNO00Raj4Csd/Xz5 7q5XmuTAVUN5174Xx4ENSlBO/t+/sxCniD2Vc= Received: by 10.210.34.5 with SMTP id h5mr1972121ebh.161.1233617282224; Mon, 02 Feb 2009 15:28:02 -0800 (PST) Received: from ?10.168.106.46? (ip68-0-70-106.tu.ok.cox.net [68.0.70.106]) by mx.google.com with ESMTPS id 7sm304800eyg.57.2009.02.02.15.28.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 02 Feb 2009 15:28:01 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234127C939A2B@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <3D3C75174CB95F42AD6BCC56E5555B45FFEE62@FIESEXC015.nsn-intra.net> <1bc4603e0902020024j71230bbr47b0b2c65b58b2b4@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E7234127C939A2B@P3PW5EX1MB01.EX1.SECURESERVER.NET> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: <5AB18178-6A4B-4080-AB10-E7D6E933CFB1@josephholsten.com> From: Joseph A Holsten Date: Mon, 2 Feb 2009 17:27:41 -0600 To: Eran Hammer-Lahav X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.753.1) Cc: "oauth@ietf.org" Subject: Re: [oauth] OAUTH Charter Proposal X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-2022-jp"; Format="flowed"; DelSp="yes" Sender: oauth-bounces@ietf.org Errors-To: oauth-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OAuth has two compontents. The authorization component is a very lightweight capabilities system which is mostly left up to the SP to define. It defines the requirements of the access token (capability) and how to access the resource. It does not currently provide the fine grained control that an authz protocol usually provides (see c- lists, acls). It doesn't need it, but is the right place for it if such control were necessary. The key is that this capability grants access to a resource, therefore it is authz. The other part is very similar to Kerberos ticket granting, which you might call token negotiation, brokered authentication, or delegation. This is about requesting the access token. It is completely optional, and may be left out (see thmbnl implementation), or replaced (see hybrid protocol). While this used to be a service provided by authentication protocols, clearly OAuth proves that ticket granting and authentication may be separate protocols. OAuth could become authn by stating what credentials could be sent directly to the Authorization endpoint. If this was defined, then OAuth would be functionally equivalent to a Kerberos TGS or WS-Trust STS. Normally these protocols do not necessarily grant access to any resource, clearly putting them outside the realm of authz. Since OAuth does grant access, it is unique among protocols. No I don't think they belong in separate specs, but it is useful to look at this in terms of traditional security protocols. But what matters is not so much the terms, as matters the formalization of the protocol. I suggest we create a mailing list oauth-authz-authn- flamewar to continue this discussion. http://josephholsten.com On Feb 2, 2009, at 12:49 PM, Eran Hammer-Lahav wrote: > Of course, even $B!F(Bdelegation$B!G(B is a problematic term. HTTP Basic auth > is not considered a delegation protocol but it really is. The End > User gives the User Agent some credentials to access resources on > its behalf on the Web Server. There is no restriction in Basic auth > about the number of credentials used, so there could be a special > one to give the browser. > > > > Hmm. I guess that makes OAuth a $B!F(Bgoddamn goddamn protocol$B!G(B, if we > replace all the problematic words$B!D(B of course that does not help us > at all. > > > > I would not waste too much time trying to find a one liner to > describe the protocol. And when in doubt, the Core 1.0 spec defines > a framework for us to work with, and can always be used to draw the > lines of what we are trying to solve. > > > > EHL > > > > _______________________________________________ > oauth mailing list > oauth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth http://josephholsten.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkmHgW4ACgkQrPgSa0qMrmGmvQCfSgEOykkwMUmnfId1X8+K01AR FbcAni93Rq91mtuYCHlQBFiFwuOwJokz =6H9y -----END PGP SIGNATURE----- _______________________________________________ oauth mailing list oauth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From stephen.farrell@cs.tcd.ie Thu Feb 5 08:56:44 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D57928C15D for ; Thu, 5 Feb 2009 08:56:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.243 X-Spam-Level: X-Spam-Status: No, score=-0.243 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id epLIYk1AJLwj for ; Thu, 5 Feb 2009 08:56:43 -0800 (PST) Received: from mail.newbay.com (87-198-172-198.ptr.magnet.ie [87.198.172.198]) by core3.amsl.com (Postfix) with ESMTP id D85973A6840 for ; Thu, 5 Feb 2009 08:56:42 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.newbay.com (Postfix) with ESMTP id AC524100415A6; Thu, 5 Feb 2009 16:56:21 +0000 (GMT) X-Virus-Scanned: amavisd-new at newbay.com Received: from mail.newbay.com ([127.0.0.1]) by localhost (mail.newbay.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UJFNXgiAJuue; Thu, 5 Feb 2009 16:56:20 +0000 (GMT) Received: from [192.168.3.55] (unknown [192.168.3.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.newbay.com (Postfix) with ESMTP id 68BF01004073D; Thu, 5 Feb 2009 16:56:20 +0000 (GMT) Message-ID: <498B1AC9.6020600@cs.tcd.ie> Date: Thu, 05 Feb 2009 16:58:49 +0000 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.16 (X11/20080707) MIME-Version: 1.0 To: "Tschofenig, Hannes (NSN - FI/Espoo)" References: <3D3C75174CB95F42AD6BCC56E5555B45FFEF34@FIESEXC015.nsn-intra.net> In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B45FFEF34@FIESEXC015.nsn-intra.net> 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] Charter Proposal v2 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 16:56:44 -0000 Hi Hannes, That's pretty good. A bunch of nits below. Stephen. Tschofenig, Hannes (NSN - FI/Espoo) wrote: > Based on the feedback I have updated the charter text proposal > > ---------- > > Open Authentication Protocol (oauth) > > Last Modified: 2009-01-30 > > Chair(s): > > TBD > > Applications Area Director(s): > > Chris Newman > Lisa Dusseault > > Applications Area Advisor: > > TBD > > Mailing Lists: > > https://www.ietf.org/mailman/listinfo/oauth > > Description of Working Group: > > OAuth allows a user to grant a third-party Web site or application > access to their resources, without revealing their credentials, or even s/without/without necessarily/ esp. wrt identity, which may be apparent from the URLs or lower-layer addresses involved. > their identity. For example, a photo-sharing site that supports OAuth > would allow its users to use a third-party printing Web site to access > their private pictures, without gaining full control of the user > account. > > OAuth consists of: > * A mechanism for exchanging a user's credentials for a token-secret > pair which can be used by a third party to access resources on their > behalf > * A mechanism for signing HTTP requests with the token-secret pair > > The Working Group will produce one or more documents suitable for > consideration as Proposed Standard, based upon the OAuth I-D, that will: I think referring by name to draft-hammer-oauth would be better there, so folks on the IETF list can more easily check it out later. > * Align OAuth with the Internet and Web architectures, best practices > and terminology Hmmm...that's very open-ended. I'd fear that this leaves a WG open to people constantly carping that such-and-such isn't best practice. Minimally, I think there is work on the terminology needed, but I'm not sure what else you had in mind here. I'd suggest deleting this bullet and adding one along the lines of: * Improve the terminology used > * Assure good security practice, or document gaps in its capabilities s/Assure/Embody/ as-is, it claims we'll make sure that running systems are "secure" which we can't do > * Promote interoperability > * Provide guidelines for extensibility > > This specifically means that as a starting point for the working group > the OAuth 1.0 specification is used and the available extension points > are going to be utilized. It seems desireable to profile OAuth 1.0 in a s/It seems desirable to/The WG will/ I think there was a clear consensus on that at the BoF. > way that produces a specification that is a backwards compatible > profile, i.e. any OAUTH 1.0 and the specification produced by this group > must support a basic set of features to guarantee interoperability. > > Furthermore, Oauth 1.0 defines three signature methods used to protect > requests, namely PLAINTEXT, HMAC-SHA1, and RSA-SHA1. The group will work > on new signature methods in case the existing mechanisms do not fulfill > the security requirements. Existing signature methods will not be > modified but may be dropped as part of the backwards compatible > profiling activity. > > In doing so, it should consider: > * Implementer experience > * Existing uses of OAuth > * Ability to achieve broad impementation > * Ability to address broader use cases than may be contemplated by the > original authors > * Impact on the Internet and Web I'd argue to delete the last bullet above since that's implicit in all IETF WGs and if specifically called out is yet another place where people could quibble endlessly. > > The Working Group is not tasked with defining a generally applicable > HTTP Authentication mechanism (i.e., browser-based "2-leg" scenerio), > and should consider this work out of scope in its discussions. However, > if the deliverables are able to be factored in such a way that this is a > byproduct, or such a scenario could be addressed by additional future > work, the Working Group may choose to do so. > > After delivering OAuth, the Working Group may consider defining > additional functions and/or extensions, for example (but not limited > to): > * Discovery of authentication configuration > * Message integrity > * Recommendations regarding the structure of the token > > Goals and Milestones: > > 12/2009 Submit document(s) suitable for publication as > standards-track RFCs. > _______________________________________________ > oauth mailing list > oauth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From onyxraven@gmail.com Thu Feb 5 09:12:59 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60E163A6A56 for ; Thu, 5 Feb 2009 09:12:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7DBLzTUtOZpH for ; Thu, 5 Feb 2009 09:12:58 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by core3.amsl.com (Postfix) with ESMTP id 5BCC73A6826 for ; Thu, 5 Feb 2009 09:12:58 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 3so146110qwe.31 for ; Thu, 05 Feb 2009 09:12:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=qmX/AkDDYGdVaZnkxgcZ+so4uPNfpGzH9h/dg63z0cw=; b=PbG2NfH0o+d8iYuV2KtAhCSGUPx5EiC6P+ClFz6MH5KYjBwWdMl8dcyoc1fM27cBc5 4KsXJ7v31G42vVE84Tr3ElcpvudYsTaT7JJAHbCfvMerfkx0HU4gYtcv9HHZbaHht87i Wyt0/yyhUCDnpWtfLvoZySdBGbHqI9/Xzheks= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=tse3K4yxY6KOZ+sGK31hwwgxoQGcjUsYg4YQFM/zOueuYY8VdkklutFjIGoGv1FQkQ 2N6nzHrOAPn1FAFyNVRcOYO8IPiwii+d6908UVOm9XS2eFcLIryAq0hpNqUkf7NoACYh 5SFUyk5IJWBsrCNaUsA6ctWo+LKMluabX/lHM= MIME-Version: 1.0 Received: by 10.229.74.77 with SMTP id t13mr253313qcj.58.1233853956978; Thu, 05 Feb 2009 09:12:36 -0800 (PST) Date: Thu, 5 Feb 2009 10:12:36 -0700 Message-ID: From: Onyx Raven To: oauth@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [oauth] OAuth only for HTTP request signing? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 17:12:59 -0000 I see the following line in the ITEF charter: * A mechanism for signing HTTP requests with the token-secret pair Is the 'core' OAuth specification going to be limited only to HTTP, or is there opportunity and reason to make it a general method of signing method, resource and parameters of a programmatic request for the purpose of consumer authorization and user credential delegation? It seems like other protocols could use the same signing and delegation methodology (probably with some hybrid using HTTP), but may not be 'traditional' HTTP (eg, XMPP http://xmpp.org/extensions/xep-0235.html) during requests. Or, would the 'extensions' go the other way, defining how other protocols might use the same methods, or in a generic sense? I guess I wonder if defining only HTTP and not calling out generic usage could make using OAuth in other areas somewhat more difficult from a standards perspective. From Hannes.Tschofenig@gmx.net Thu Feb 5 11:49: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 C154B3A687A for ; Thu, 5 Feb 2009 11:49:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.364 X-Spam-Level: X-Spam-Status: No, score=-2.364 tagged_above=-999 required=5 tests=[AWL=0.235, 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 2r1czByddn7y for ; Thu, 5 Feb 2009 11:49:49 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id D07F03A6806 for ; Thu, 5 Feb 2009 11:49:44 -0800 (PST) Received: (qmail invoked by alias); 05 Feb 2009 19:49:42 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp033) with SMTP; 05 Feb 2009 20:49:42 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18Nbs5iLZENjokRVYRQrJZaOGjR8E933yZVQo7vBW 5tW52M7gx0zYbJ From: "Hannes Tschofenig" To: "'ext Hallam-Baker, Phillip'" , "George Fletcher" , "Hannes Tschofenig" References: <033101c98303$e6fde7f0$0201a8c0@nsnintra.net><4986F954.1090001@aol.com> <2788466ED3E31C418E9ACC5C3166155768B24D@mou1wnexmb09.vcorp.ad.vrsn.com> Date: Thu, 5 Feb 2009 21:50:28 +0200 Message-ID: <009801c987cb$00683530$0201a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <2788466ED3E31C418E9ACC5C3166155768B24D@mou1wnexmb09.vcorp.ad.vrsn.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcmFPMm3btexUrcIR8KMhSEYbNI68wALYfkhAIJiWlA= X-Y-GMX-Trusted: 0 X-FuHaFi: 0.78 Cc: oauth@ietf.org Subject: Re: [oauth] OAUTH Charter Proposal X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 19:49:53 -0000 Hi Phillip, your mail has a lot of interesting thoughts about the history of SAML. To make my work easier, do you think we can improve the charter text somehow? Ciao Hannes ________________________________ From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of ext Hallam-Baker, Phillip Sent: 02 February, 2009 21:58 To: George Fletcher; Hannes Tschofenig Cc: oauth@ietf.org Subject: Re: [oauth] OAUTH Charter Proposal I think it is imnportant to discuss the charter here because the hardest part of this whole problem is working out what we are actually trying to achieve and arriving at consensus that we are all talking about the same thing. We do not have to develop an authentication protocol for OAuth but we do need to understand what an authentication protocol does and what is meant by an authorization protocol. Another feature of the discussion is that there are parts of OAUTH that people now want to use simply as platform and that has implications. Lots of people are talking about the need to sign pieces of http headers. I don't think we need yet another Internet authentication protocol. What we do however need, and in particular I think OAuth requires to be explicable to lay people, is a uniform identifier to represent the party being authenticated and a standard human-readable presentation thereof. Otherwise I fear that we will end up with yet more middle-ware that does not quite meet up at either end. So let the user be authenticated by SAML, WS-Trust, HTTP-Auth, OpenID or whatever. But there has to be a clearly defined mental model of what that means. Lets take SAML as a starting point since it has a consistent nomenclature that has considerable consensus. We have an authentication protocol, that delivers a SAML assertion. Regardless of what the specification might say, the actual semantics of a SAML authentication assertion (and indeed any delegated mechanism) are 'here is a partywhich I have authenticated as X by reference to mechanism Y which you can verifty by reference to credential Z." In other words, the use of delegated authentication does not in fact remove the need for authentication, it merely changes the type of credential that the relying party is going to use. Now one problem we punted on in SAML, that I now regret is the question of what the user identifier would be. This was left to the individual authentication federation. Which I view as a mistake because it means that we lack two critical pieces that are necessary to make the system work. The first is discovery, say Alice is identfied by SSQW:eurtu.org/20/alice@example.com That is a perfectly legal SAML identifier. Which is a problem. We left far too many options which would not have been so bad if we had made it very clear that there was a very strong preference for one particular form when we are dealling with users in an internet context. user@idp.example.org Now if we had only said use email addresses, and only email addresses we would have been only one step away from universal log-in. All SAML is missing is an SRV identifier for locating an authentication server for a given identifier. If that is in place alice can use alice@example.com as her login identifier on any site whatsoever and the site can then go out and find that there is a SAML authentication assertion service at idp.example.com. So if we simply say to all the authentication protocols out there that they can work with OAuth, if and only if they 1) Use an email address format identifier 2) Specify an SRV based discovery mechanism That would of course mean that the group might well have to write a document describing the SRV bindings for a number of existing protocols that are out there, or rather for subsets of such protocols. But that is the general requirement for a new group. We can argue about the precise shape of the box (i.e. the discovery mechanism, the identifier to be used) but I don't think we should argue about the need for such a box or the need to leave stuff out. There are at least 4 different general purpose authentication frameworks out there and because they are all designed to be meta and all designed to be interoperable you can actually create cycles within cycles just like there are folk who run VMWare Linux in a VM Ware Windows in a VMWare Linux. After that, we can get down to the much harder problem of working out what an OAuth token should be called. Contrary to discussion in the group, I do not think it maps cleanly onto any concept in the existing nomenclature. Whch is probably why the discussion turns circular. Moreover, folk should remember that this is a concept that was botched in pretty much every operating system design, especially UNIX. I don't know of any O/S which allows a user to easily and cleanly set up an access rule of the form 'Sendmail can manage mail on behalf of Fred' without granting more access than is necessary for the limited task. These schemes inevitably use the big hammer of root privilege which does not exist on the net. The problem is not that hard, it is unsolved because it was not necessary to solve it earlier. What we are talking about here is a limited delegation of authority. There are different ways of implementing a delegation of authority. One is to establish a new user account with the specified authentication access and privileges, the second is to add an ACL to the resource in question allowing a specified party to gain access. Depending on which method of implementaion you chose, the OAuth statement will appear to be authorization or Authentication. But it is neither, it is a delegation of authority. If we try to call it authorization we end up having to find a new name for ACLs. . ________________________________ From: oauth-bounces@ietf.org on behalf of George Fletcher Sent: Mon 2/2/2009 8:47 AM To: Hannes Tschofenig Cc: oauth@ietf.org Subject: Re: [oauth] OAUTH Charter Proposal Not wanting to start a huge debate... but within the OAuth community we've made the distinction between Authentication and Authorization, with OAuth being an API Authorization protocol and leaving Authentication out of scope. Is this charter planning to tackle authentication as well as authorization? The statement... > OAuth consist of: > * A mechanism for exchanging a user's credentials for a token-secret pair > has me a little confused. I would word this as... * A mechanism that allows a user to authorize API access via a token-secret pair Thanks, George Hannes Tschofenig wrote: > Hi all, > > After a chat with Lisa I got in touch with Eran to slightly revise the > charter text that Sam and Mark put together for the last IETF meeting. > > It should addresses some of the comments provided during the BOF. Your > feedback is welcome. > > Ciao > Hannes > > ------------------------------------- > > Open Authentication Protocol (oauth) > > Last Modified: 2009-01-30 > > Chair(s): > > TBD > > Applications Area Director(s): > > Chris Newman > Lisa Dusseault > > Applications Area Advisor: > > TBD > > Mailing Lists: > > https://www.ietf.org/mailman/listinfo/oauth > > Description of Working Group: > > OAuth allows a user to grant a third-party Web site or application access to > their resources, without revealing their credentials, or even their > identity. For example, a photo-sharing site that supports OAuth would allow > its users to use a third-party printing Web site to access their private > pictures, without gaining full control of the user account. > > OAuth consist of: > * A mechanism for exchanging a user's credentials for a token-secret pair > which can be used by a third party to access resources on their behalf > * A mechanism for signing HTTP requests with the token-secret pair > > The Working Group will produce one or more documents suitable for > consideration as Proposed Standard, based upon the OAuth I-D, that will: > * Align OAuth with the Internet and Web architectures, best practices and > terminology > * Assure good security practice, or document gaps in its capabilities > * Promote interoperability > > This specifically means that as a starting point for the working group the > OAuth 1.0 specification is used and the > available extension points are going to be utilized. It seems desireable to > profile OAuth 1.0 in a way that produces a specification that is a backwards > compatible profile, i.e. any OAUTH 1.0 and the specification produced by > this group must support a basic set of features to guarantee > interoperability. > > Furthermore, Oauth 1.0 defines three signature methods used to protect > requests, namely PLAINTEXT, HMAC-SHA1, and RSA-SHA1. The group will work on > new signature methods in case the existing mechanisms do not fulfill the > security requirements. Existing signature methods will not be modified but > may be dropped as part of the backwards compatible profiling activity. > > In doing so, it should consider: > * Implementer experience > * Existing uses of OAuth > * Ability to achieve broad impementation > * Ability to address broader use cases than may be contemplated by the > original authors > * Impact on the Internet and Web > > The Working Group is not tasked with defining a generally applicable HTTP > Authentication mechanism (i.e., browser-based "2-leg" scenerio), and should > consider this work out of scope in its discussions. However, if the > deliverables are able to be factored in such a way that this is a byproduct, > or such a scenario could be addressed by additional future work, the Working > Group may choose to do so. > > After delivering OAuth, the Working Group MAY consider defining additional > functions and/or extensions, for example > (but not limited to): > * Discovery of authentication configuration > * Message integrity > * Recommendations regarding the structure of the token > > Goals and Milestones: > > 12/2009 Submit document(s) suitable for publication as standards-track > RFCs. > > _______________________________________________ > oauth mailing list > oauth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ oauth mailing list oauth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Thu Feb 5 12:08:57 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BDC03A6806 for ; Thu, 5 Feb 2009 12:08:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.356 X-Spam-Level: X-Spam-Status: No, score=-4.356 tagged_above=-999 required=5 tests=[AWL=-1.757, 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 92epy6-VFNrh for ; Thu, 5 Feb 2009 12:08:56 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id AB7E03A6781 for ; Thu, 5 Feb 2009 12:08:07 -0800 (PST) Received: (qmail 16209 invoked from network); 5 Feb 2009 20:08:09 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 5 Feb 2009 20:08:08 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 5 Feb 2009 13:08:08 -0700 From: Eran Hammer-Lahav To: Onyx Raven , "oauth@ietf.org" Date: Thu, 5 Feb 2009 13:08:07 -0700 Thread-Topic: [oauth] OAuth only for HTTP request signing? Thread-Index: AcmHtPRVBi5zOmwHRcGZoCskvofIvwAGIFla Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [oauth] OAuth only for HTTP request signing? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 20:08:57 -0000 While I can certainly appreciate the usefulness of making OAuth protocol-agnostic, this must stay outside the scope of this WG. The OAuth signature workflow is completely HTTP based. The HTTP method, host, and dereferenced URI are used to build the base string. The token exchange workflow defines an HTTP interaction. My main objection to even considering this, is the fact that without fully understanding the security context of the protocol, we will not be able to address it. Trying to apply the principals of OAuth to other protocols is simply not practical. This suggests that for XMPP to use an OAuth-like protocol, it needs to define its own binding. The only useful aspect of OAuth to other protocols is allowing them to use access tokens (and secrets) for accessing resources. There is nothing in th= e current spec to prevent that. It would be impractical for us to address that. EHL On 2/5/09 9:12 AM, "Onyx Raven" wrote: > I see the following line in the ITEF charter: > > * A mechanism for signing HTTP requests with the token-secret pair > > Is the 'core' OAuth specification going to be limited only to HTTP, or > is there opportunity and reason to make it a general method of signing > method, resource and parameters of a programmatic request for the > purpose of consumer authorization and user credential delegation? > > It seems like other protocols could use the same signing and > delegation methodology (probably with some hybrid using HTTP), but may > not be 'traditional' HTTP (eg, XMPP > http://xmpp.org/extensions/xep-0235.html) during requests. Or, would > the 'extensions' go the other way, defining how other protocols might > use the same methods, or in a generic sense? > > I guess I wonder if defining only HTTP and not calling out generic > usage could make using OAuth in other areas somewhat more difficult > from a standards perspective. From trscavo@gmail.com Thu Feb 5 12:19: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 A8EED3A6A0E for ; Thu, 5 Feb 2009 12:19:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 MQY4kVtmqcIR for ; Thu, 5 Feb 2009 12:19:53 -0800 (PST) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by core3.amsl.com (Postfix) with ESMTP id D0B953A69FB for ; Thu, 5 Feb 2009 12:19:52 -0800 (PST) Received: by yw-out-2324.google.com with SMTP id 3so386493ywj.49 for ; Thu, 05 Feb 2009 12:19:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=wBjVpiM4DLw/vUr6X1qaRu4k3osVfew6l3WA/Oni+68=; b=cJL/uQlkUXIW1w1AvsEbpt8oDHKsTqibuJ0BTs+KOzHxIb/3E62TSVTesTNEzzRzR1 Us+aAcYirqwko8uQ53EbN8/c1sxbUFI7id7toAaZtyXj3K+Zi/HbDAu+UYoU9hzmZPO2 /LEYtKDAIsXy1T6mA2Tw4GO9iqqZ4cQlbEgd4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=P5y/ajnIYfqr0b/Qbs1OtjrFeRB6XA6Px8//iLgJiHGaCHc4Q1zqVs1+cIkgG984k8 qLBWLtIdq9pQRdK6+RCchUpLOn6iWvFJUQDjmCLNZUDGkjIwrnD5wAiwBaXlkN9lNHYd EnWt5QqzhElv4OWYZL3wR8bWo+m8EWacivtzA= MIME-Version: 1.0 Received: by 10.151.27.15 with SMTP id e15mr866368ybj.66.1233865192607; Thu, 05 Feb 2009 12:19:52 -0800 (PST) In-Reply-To: References: Date: Thu, 5 Feb 2009 14:19:52 -0600 Message-ID: From: Tom Scavo To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Onyx Raven , "oauth@ietf.org" Subject: Re: [oauth] OAuth only for HTTP request signing? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 20:19:53 -0000 On Thu, Feb 5, 2009 at 2:08 PM, Eran Hammer-Lahav wrote: > > Trying to apply the principals of OAuth to other protocols is > simply not practical. This suggests that for XMPP to use an OAuth-like > protocol, it needs to define its own binding. Indeed, SAML has profiled the "SimpleSign" binding: http://wiki.oasis-open.org/security/SimpleSignBinding SimpleSign is similar to OAuth, if only in spirit. Tom From seth@mojodna.net Thu Feb 5 12:52:11 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1461A28C103 for ; Thu, 5 Feb 2009 12:52:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zixJaX1Bisg0 for ; Thu, 5 Feb 2009 12:52:10 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by core3.amsl.com (Postfix) with ESMTP id EDE4428C0F8 for ; Thu, 5 Feb 2009 12:52:09 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so464732wfd.31 for ; Thu, 05 Feb 2009 12:52:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.143.39.16 with SMTP id r16mr496600wfj.249.1233867130567; Thu, 05 Feb 2009 12:52:10 -0800 (PST) In-Reply-To: References: Date: Thu, 5 Feb 2009 12:52:10 -0800 Message-ID: <1d7d37050902051252h3eb088a9rc48758a99825372@mail.gmail.com> From: Seth Fitzsimmons To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Onyx Raven , "oauth@ietf.org" Subject: Re: [oauth] OAuth only for HTTP request signing? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 20:52:11 -0000 > The OAuth signature workflow is completely HTTP based. The HTTP method, > host, and dereferenced URI are used to build the base string. The token > exchange workflow defines an HTTP interaction. I beg to differ on the signature workflow. The base string is constructed of *a* method (e.g. 'iq') and something standing in for a URI (either an actual URI or something resembling 'from@jabber.org&to@jabber.org'). Beyond those substitutions, the rest of the signature generation is exactly the same. XMPP (XEP-0235) assumes that tokens are exchanged out of band, leaving that mechanism in HTTP. > My main objection to even considering this, is the fact that without fully > understanding the security context of the protocol, we will not be able to > address it. Trying to apply the principals of OAuth to other protocols is > simply not practical. This suggests that for XMPP to use an OAuth-like > protocol, it needs to define its own binding. How do you mean 'binding'? > The only useful aspect of OAuth to other protocols is allowing them to use > access tokens (and secrets) for accessing resources. There is nothing in the > current spec to prevent that. It would be impractical for us to address > that. To me, the most useful aspect of OAuth when applied to other protocols is a clearly defined way to generate signatures given constituent components. seth From lisa.dusseault@messagingarchitects.com Thu Feb 5 12:08:52 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABF353A6A0E for ; Thu, 5 Feb 2009 12:08:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[AWL=0.288, 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 TuP5jlkPGxfw for ; Thu, 5 Feb 2009 12:08:51 -0800 (PST) Received: from mplus1.messagingarchitects.com (bastille.gwtools.com [216.94.112.120]) by core3.amsl.com (Postfix) with ESMTP id E5FAC3A6AB8 for ; Thu, 5 Feb 2009 12:07:11 -0800 (PST) Received: from [192.168.1.100] lisad@messagingarchitects.com [74.95.2.169] by mplus1.messagingarchitects.com with M+ Extreme Email Engine 2008.4.debug; Thu, 05 Feb 2009 15:07:16 -0500 X-MailFrom: lisa.dusseault@messagingarchitects.com Message-Id: <3AFEE04B-C4FD-46CD-92F1-FC44CD52A161@messagingarchitects.com> From: Lisa Dusseault To: oauth@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 5 Feb 2009 12:07:09 -0800 X-Mailer: Apple Mail (2.930.3) X-Mplus-Virus-Scanned: mplusversion: 2008.4.debug ; timestamp: Thu, 05 Feb 2009 15:07:17 -0500 engine: XCFAntiVirus1 Engine; version: 3830 (20090205)/1080 (20090204)/1087 (20090205)/1.009 (20070910) result: 0 ; ref: none; status: success; error: none engine: XCFAntiVirus2 Engine; version: 5.1.00/5516 result: 0 ; ref: none; status: success; error: none engine: XCFAntiVirus3 Engine; version: 5.07.0001 result: 0 ; ref: str=0001.0A010202.498B46EF.0145,ss=1,fgs=0; status: success; error: none X-Mplus-Spam-Scanned: mplusversion: 2008.4.debug ; timestamp: Thu, 05 Feb 2009 15:07:17 -0500 engine: XCFSPAM1 Engine ; version: Not Available ; level: 0 ref: 0-0-0-2162-c status: success ;error: none engine: XCFSPAM4 Engine ; version: 5.1.2/2009.02.05.02.01.32/2005.02.11.04.44.13/0/0/2007.01.28.16.09.00/2007.02.13.01.23.26/0/0/2009.01.22.21.42.10/2009.02.05.19.01.00/2009.02.05.02.40.00/2009.02.05.19.37.04/0/0/2009.01.21.21.18.19/; level: 2 ref: status: success ;error: none X-Mailman-Approved-At: Thu, 05 Feb 2009 13:03:10 -0800 Subject: [oauth] OAuth BOF approved X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 20:08:53 -0000 The BOF request was approved. I have asked Hannes Tschofenig and Blaine Cook to co-chair the next BOF -- Mark and Sam are both extremely busy :) As always, please familiarize yourself with the agenda (once posted) and read the drafts listed on it before attending this BOF. We'll need to keep focused as it's the 2nd BOF and should be able to come to consensus on forming a WG. Progress made on charter consensus before the BOF is always welcome. Lisa --- Scanned by M+ Guardian Messaging Firewall --- Messaging Architects sponsors The Spamhaus Project. From john@jkemp.net Thu Feb 5 13:21: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 B9C5C28C10A for ; Thu, 5 Feb 2009 13:21:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.808 X-Spam-Level: X-Spam-Status: No, score=-1.808 tagged_above=-999 required=5 tests=[AWL=0.457, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AGtUU1OUP8AY for ; Thu, 5 Feb 2009 13:21:52 -0800 (PST) Received: from outbound-mail-20.bluehost.com (outbound-mail-20.bluehost.com [69.89.20.235]) by core3.amsl.com (Postfix) with SMTP id A744728C0F8 for ; Thu, 5 Feb 2009 13:21:52 -0800 (PST) Received: (qmail 18641 invoked by uid 0); 5 Feb 2009 21:21:09 -0000 Received: from unknown (HELO box320.bluehost.com) (69.89.31.120) by outboundproxy1.bluehost.com with SMTP; 5 Feb 2009 21:21:09 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=jkemp.net; h=Received:Cc:Message-Id:From:To:In-Reply-To:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:References:X-Mailer:X-Identified-User; b=WfRezYEczlqyl1SwV9TkkQZpKRWYSsbon18MP+ZSASVlKQNyMBPvFSRKd1CSUIAC32c+wJdCKiB0Eq7kT1mMLhhUsQd/m22CF4vVjmwBZ5f/3dTIYaww6mPl8ogZ5fD/; Received: from cpe-69-205-56-47.nycap.res.rr.com ([69.205.56.47] helo=[192.168.1.118]) by box320.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1LVBfU-0005SP-Bd; Thu, 05 Feb 2009 14:21:52 -0700 Message-Id: From: John Kemp To: Seth Fitzsimmons In-Reply-To: <1d7d37050902051252h3eb088a9rc48758a99825372@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 5 Feb 2009 16:21:50 -0500 References: <1d7d37050902051252h3eb088a9rc48758a99825372@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) X-Identified-User: {1122:box320.bluehost.com:jkempnet:jkemp.net} {sentby:smtp auth 69.205.56.47 authed with john+jkemp.net} Cc: Onyx Raven , "oauth@ietf.org" Subject: Re: [oauth] OAuth only for HTTP request signing? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 21:21:53 -0000 On Feb 5, 2009, at 3:52 PM, Seth Fitzsimmons wrote: > > XMPP (XEP-0235) assumes that tokens are exchanged out of band, leaving > that mechanism in HTTP. Right. The point being that there are at least two potentially- independent parts to OAuth - a set of signature mechanisms (RSA-SHA1, HMAC-SHA1, PLAINTEXT), and an HTTP-based protocol for token exchange. [...] > > To me, the most useful aspect of OAuth when applied to other protocols > is a clearly defined way to generate signatures given constituent > components. I think it's certainly reasonable to suggest that the signature mechanisms be defined so as to be useful in contexts other than HTTP. Which apparently already worked well-enough for XMPP with OAuth 1.0. - johnk From eran@hueniverse.com Thu Feb 5 13:32: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 817853A6827 for ; Thu, 5 Feb 2009 13:32:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.318 X-Spam-Level: X-Spam-Status: No, score=-4.318 tagged_above=-999 required=5 tests=[AWL=-1.720, 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 6TXazYFlb+xm for ; Thu, 5 Feb 2009 13:32:45 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 79B1C3A68E5 for ; Thu, 5 Feb 2009 13:32:45 -0800 (PST) Received: (qmail 16322 invoked from network); 5 Feb 2009 21:32:46 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 5 Feb 2009 21:32:18 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 5 Feb 2009 14:32:18 -0700 From: Eran Hammer-Lahav To: Lisa Dusseault , "oauth@ietf.org" Date: Thu, 5 Feb 2009 14:32:16 -0700 Thread-Topic: [oauth] OAuth BOF approved Thread-Index: AcmH1SjZQkQAYwE/Q0OKvJ4KaCWE6AABA5TJ Message-ID: In-Reply-To: <3AFEE04B-C4FD-46CD-92F1-FC44CD52A161@messagingarchitects.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C5B09AE0122C6eranhueniversecom_" MIME-Version: 1.0 Subject: Re: [oauth] OAuth BOF approved X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 21:32:46 -0000 --_000_C5B09AE0122C6eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable For all you new to the IETF: This is about the upcoming IETF Meeting #74: http://www.ietf.org/meetings/7= 4/ March 22-27, 2009 in San Francisco. You need to register to attend. There is also a new RFC about running a successful BoF: http://tools.ietf.org/html/rfc5434 EHL On 2/5/09 12:07 PM, "Lisa Dusseault" wrote: The BOF request was approved. I have asked Hannes Tschofenig and Blaine Cook to co-chair the next BOF -- Mark and Sam are both extremely busy :) As always, please familiarize yourself with the agenda (once posted) and read the drafts listed on it before attending this BOF. We'll need to keep focused as it's the 2nd BOF and should be able to come to consensus on forming a WG. Progress made on charter consensus before the BOF is always welcome. Lisa --- Scanned by M+ Guardian Messaging Firewall --- Messaging Architects sponsors The Spamhaus Project. _______________________________________________ oauth mailing list oauth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_C5B09AE0122C6eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [oauth] OAuth BOF approved For all you new to the IETF:

This is about the upcoming IETF Meeting #74: http://www.ietf.org/meetings/74/
 March 22-27, 2009 in San Francisco. You need to register to attend.
There is also a new RFC about running a successful BoF:
http://tools.ietf.org/html/r= fc5434

EHL


On 2/5/09 12:07 PM, "Lisa Dusseault" <lisa.dusseault@messagingarchitects.com> w= rote:



The BOF request was approved.  I have asked Hannes Tschofenig and
Blaine Cook to co-chair the next BOF -- Mark and Sam are both
extremely busy :)

As always, please familiarize yourself with the agenda (once posted)
and read the drafts listed on it before attending this BOF.  We'll
need to keep focused as it's the 2nd BOF and should be able to come to
consensus on forming a WG.  Progress made on charter consensus before<= BR> the BOF is always welcome.

Lisa

--- Scanned by M+ Guardian Messaging Firewall ---
Messaging Architects sponsors The Spamhaus Project.

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

--_000_C5B09AE0122C6eranhueniversecom_-- From onyxraven@gmail.com Thu Feb 5 13:37: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 421023A6AC8 for ; Thu, 5 Feb 2009 13:37:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uljaq9Bkwi-K for ; Thu, 5 Feb 2009 13:37:47 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by core3.amsl.com (Postfix) with ESMTP id 513BA3A6A16 for ; Thu, 5 Feb 2009 13:37:47 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 3so202840qwe.31 for ; Thu, 05 Feb 2009 13:37:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=uRPeNipOOW9y6wtwVEnNvzuYm5xtsxHIefpjIXuQZXU=; b=BH8tyQ6LYc5dNou2HYvBAJxBxYv3ALmptc5T9e3r04SguEDnZxidrneAK4A9bpcRBJ X00q9xSSgpcKFgJiLZXmRn0vFKbVNS0WcdIKBinxPOoj89KlzwRf7AmFGQaSBsoyiKzS zuOmgNiJkv81LHHa3+8RmAiPWOoSNvgqKzMDA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=f5cMItTiwvtf9YmInaID/XgeN8HHafoS8QRcBGgBn1uWnEbrA1W4xYqceAp3ytbTaV T3QhxCsC21lCkRsL+FwcNcjIE/45mBfEciLKkyD1pF1/l6qiqfqLXzeo8cV1RI10FhNK hm7ho7QL/mtuaRoVf0BdEpn9M2azaQVmZM688= MIME-Version: 1.0 Received: by 10.229.73.194 with SMTP id r2mr491595qcj.29.1233869867573; Thu, 05 Feb 2009 13:37:47 -0800 (PST) In-Reply-To: References: <1d7d37050902051252h3eb088a9rc48758a99825372@mail.gmail.com> Date: Thu, 5 Feb 2009 14:37:47 -0700 Message-ID: From: Onyx Raven To: John Kemp Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org" Subject: Re: [oauth] OAuth only for HTTP request signing? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 21:37:48 -0000 So, thats what I was trying to get at. I agree that the excepted token consumer-request -> sp-auth -> consumer-access process should be HTTP based as it is defined now. It was really more about the consumer -> sp request signing (with delegated access), which like below, could be XMPP, IRC, proprietary game protocols, etc. At a basic level, signature signing is defined as METHOD&RESOURCE&PARAMETERS (where parameters are key/value pairs structured in www-form-urlencoded style). But like I said before, as long as the core standard has acceptable wording for other consumer -> sp request protocols to hook into, thats what matters there. I just wanted to be sure we didn't get locked into something we might want alternatives to in the future. On Thu, Feb 5, 2009 at 2:21 PM, John Kemp wrote: > On Feb 5, 2009, at 3:52 PM, Seth Fitzsimmons wrote: > >> >> XMPP (XEP-0235) assumes that tokens are exchanged out of band, leaving >> that mechanism in HTTP. > > Right. The point being that there are at least two potentially-independent > parts to OAuth - a set of signature mechanisms (RSA-SHA1, HMAC-SHA1, > PLAINTEXT), and an HTTP-based protocol for token exchange. > > [...] > >> >> To me, the most useful aspect of OAuth when applied to other protocols >> is a clearly defined way to generate signatures given constituent >> components. > > I think it's certainly reasonable to suggest that the signature mechanisms > be defined so as to be useful in contexts other than HTTP. Which apparently > already worked well-enough for XMPP with OAuth 1.0. > > - johnk > From onyxraven@gmail.com Thu Feb 5 13:39:57 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3B3C3A69B7 for ; Thu, 5 Feb 2009 13:39:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dEJg0xJyjsD1 for ; Thu, 5 Feb 2009 13:39:57 -0800 (PST) Received: from mail-qy0-f11.google.com (mail-qy0-f11.google.com [209.85.221.11]) by core3.amsl.com (Postfix) with ESMTP id BF20E3A6827 for ; Thu, 5 Feb 2009 13:39:56 -0800 (PST) Received: by qyk4 with SMTP id 4so744190qyk.13 for ; Thu, 05 Feb 2009 13:39:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=5S0ErYa3O5TzCwEj6FAQOpHO1ud8LrzUE42QZ21VTn4=; b=VtF58MpiJOh230VhNUJliejia04VdalftQbG7ISw8pIS/yh9qGloJMlOHXVtxbk8HP Vk+FAFwKBB5l1/m6zIyTTgdrjVWbQL7urbiJdQZarC3PvNUb/3EgFBqmNlQYSSQOEcSj wFHU1BqHEdg0x6NFHXTkOnUJ5o6i+JP59XmDk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=uBbsdkid0Kk7hP/FLsMjK0FtgSZNQfivnhIwZtWye+oLSpoj3wrdfW9Z/MWu9yVVz6 YiW6qt+ZVU/5E+9QlGW3scTxRlknq0Ur1Y7Zln0BMVOOe9g1cyrI9L7KCss4akdWyNqi lrhzAZmJuBREmbsOSTuc/BDhTVcwUqmJl3oV8= MIME-Version: 1.0 Received: by 10.229.110.13 with SMTP id l13mr494544qcp.4.1233869996773; Thu, 05 Feb 2009 13:39:56 -0800 (PST) In-Reply-To: References: <1d7d37050902051252h3eb088a9rc48758a99825372@mail.gmail.com> Date: Thu, 5 Feb 2009 14:39:56 -0700 Message-ID: From: Onyx Raven To: John Kemp Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org" Subject: Re: [oauth] OAuth only for HTTP request signing? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 21:39:57 -0000 Sorry, I got ahead of myself about the signature/signing - METHOD&RESOURCE&PARAMETERS, hashed with one of the accepted methods (RSA-SHA1, HMAC-SHA1, PLAINTEXT). On Thu, Feb 5, 2009 at 2:37 PM, Onyx Raven wrote: > So, thats what I was trying to get at. I agree that the excepted > token consumer-request -> sp-auth -> consumer-access process should be > HTTP based as it is defined now. It was really more about the > consumer -> sp request signing (with delegated access), which like > below, could be XMPP, IRC, proprietary game protocols, etc. At a > basic level, signature signing is defined as > METHOD&RESOURCE&PARAMETERS (where parameters are key/value pairs > structured in www-form-urlencoded style). > > But like I said before, as long as the core standard has acceptable > wording for other consumer -> sp request protocols to hook into, thats > what matters there. I just wanted to be sure we didn't get locked > into something we might want alternatives to in the future. > > On Thu, Feb 5, 2009 at 2:21 PM, John Kemp wrote: >> On Feb 5, 2009, at 3:52 PM, Seth Fitzsimmons wrote: >> >>> >>> XMPP (XEP-0235) assumes that tokens are exchanged out of band, leaving >>> that mechanism in HTTP. >> >> Right. The point being that there are at least two potentially-independent >> parts to OAuth - a set of signature mechanisms (RSA-SHA1, HMAC-SHA1, >> PLAINTEXT), and an HTTP-based protocol for token exchange. >> >> [...] >> >>> >>> To me, the most useful aspect of OAuth when applied to other protocols >>> is a clearly defined way to generate signatures given constituent >>> components. >> >> I think it's certainly reasonable to suggest that the signature mechanisms >> be defined so as to be useful in contexts other than HTTP. Which apparently >> already worked well-enough for XMPP with OAuth 1.0. >> >> - johnk >> > From eran@hueniverse.com Thu Feb 5 13:44:13 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E73F93A6AC8 for ; Thu, 5 Feb 2009 13:44:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.283 X-Spam-Level: X-Spam-Status: No, score=-4.283 tagged_above=-999 required=5 tests=[AWL=-1.684, 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 Noqc3tM1mvQM for ; Thu, 5 Feb 2009 13:44:13 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 1B2C03A6A16 for ; Thu, 5 Feb 2009 13:44:13 -0800 (PST) Received: (qmail 18300 invoked from network); 5 Feb 2009 21:44:14 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 5 Feb 2009 21:44:14 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 5 Feb 2009 14:44:14 -0700 From: Eran Hammer-Lahav To: Seth Fitzsimmons Date: Thu, 5 Feb 2009 14:44:13 -0700 Thread-Topic: [oauth] OAuth only for HTTP request signing? Thread-Index: AcmH053ttbp7ieyxTB6ygZ5LFk/1BwAB0Saw Message-ID: In-Reply-To: <1d7d37050902051252h3eb088a9rc48758a99825372@mail.gmail.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Onyx Raven , "oauth@ietf.org" Subject: Re: [oauth] OAuth only for HTTP request signing? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 21:44:14 -0000 On 2/5/09 12:52 PM, "Seth Fitzsimmons" wrote: >> My main objection to even considering this, is the fact that without ful= ly >> understanding the security context of the protocol, we will not be able = to >> address it. Trying to apply the principals of OAuth to other protocols i= s >> simply not practical. This suggests that for XMPP to use an OAuth-like >> protocol, it needs to define its own binding. > > How do you mean 'binding'? What to put in the each of the string components, how to send the signature and parameters, etc. The SBS 'method' in Core 1.0 is well defined to be an HTTP method, uppercase, etc. Does XMPP uses HTTP methods? My objection is purely from security perspective. If the security experts i= n the room want to take a different position, I'll defer to them. But my assumption is that we are looking specifically at HTTP and how HTTP request= s can be made securely (under the conditions defined by this use case). I know little of XMPP, as one example, to say that its characteristics are similar enough to HTTP to have the same security considerations. In addition, it is unclear to me that OAuth is the appropriate approach to delegation in XMPP and other protocols. It *was not* developed with such us= e cases in mind. EHL From eran@hueniverse.com Thu Feb 5 13:50: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 773C33A68B8 for ; Thu, 5 Feb 2009 13:50:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.248 X-Spam-Level: X-Spam-Status: No, score=-4.248 tagged_above=-999 required=5 tests=[AWL=-1.650, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4GHJZWrn1lpB for ; Thu, 5 Feb 2009 13:50:50 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id AC7513A67F6 for ; Thu, 5 Feb 2009 13:50:50 -0800 (PST) Received: (qmail 19349 invoked from network); 5 Feb 2009 21:50:52 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 5 Feb 2009 21:50:52 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 5 Feb 2009 14:50:48 -0700 From: Eran Hammer-Lahav To: Onyx Raven , John Kemp Date: Thu, 5 Feb 2009 14:50:47 -0700 Thread-Topic: [oauth] OAuth only for HTTP request signing? Thread-Index: AcmH2f1RJWanljK4SmWwDxZK4TdK2AAAdAMH Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C5B09F37122D5eranhueniversecom_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [oauth] OAuth only for HTTP request signing? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 21:50:56 -0000 --_000_C5B09F37122D5eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The fact the signature base string today is compatible with XMPP (but takin= g a liberal view of the workflow), is mostly luck. It just happened that a = solution that was optimized for HTTP seems to work well for XMPP with some = clarifications. It is very likely that we will be defining a new signature method. If non-H= TTP considerations will make it any more complex than it has to be, I will = find it problematic. If it doesn't, great. I am happy to allow the charter = to "review the applicability of existing and new signature methods to proto= cols other than HTTP", but that is where I think we should draw a line. The charter should allow a signature method that does not support XMPP, if = it makes HTTP better. In other words, I am against putting any other protoc= ol at equal consideration as HTTP. EHL On 2/5/09 1:37 PM, "Onyx Raven" wrote: So, thats what I was trying to get at. I agree that the excepted token consumer-request -> sp-auth -> consumer-access process should be HTTP based as it is defined now. It was really more about the consumer -> sp request signing (with delegated access), which like below, could be XMPP, IRC, proprietary game protocols, etc. At a basic level, signature signing is defined as METHOD&RESOURCE&PARAMETERS (where parameters are key/value pairs structured in www-form-urlencoded style). But like I said before, as long as the core standard has acceptable wording for other consumer -> sp request protocols to hook into, thats what matters there. I just wanted to be sure we didn't get locked into something we might want alternatives to in the future. On Thu, Feb 5, 2009 at 2:21 PM, John Kemp wrote: > On Feb 5, 2009, at 3:52 PM, Seth Fitzsimmons wrote: > >> >> XMPP (XEP-0235) assumes that tokens are exchanged out of band, leaving >> that mechanism in HTTP. > > Right. The point being that there are at least two potentially-independen= t > parts to OAuth - a set of signature mechanisms (RSA-SHA1, HMAC-SHA1, > PLAINTEXT), and an HTTP-based protocol for token exchange. > > [...] > >> >> To me, the most useful aspect of OAuth when applied to other protocols >> is a clearly defined way to generate signatures given constituent >> components. > > I think it's certainly reasonable to suggest that the signature mechanism= s > be defined so as to be useful in contexts other than HTTP. Which apparent= ly > already worked well-enough for XMPP with OAuth 1.0. > > - johnk > --_000_C5B09F37122D5eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [oauth] OAuth only for HTTP request signing? The fact the signature base string today is compatible with XMPP (but= taking a liberal view of the workflow), is mostly luck. It just happened t= hat a solution that was optimized for HTTP seems to work well for XMPP with= some clarifications.

It is very likely that we will be defining a new signature method. If non-H= TTP considerations will make it any more complex than it has to be, I will = find it problematic. If it doesn’t, great. I am happy to allow the ch= arter to “review the applicability of existing and new signature meth= ods to protocols other than HTTP”, but that is where I think we shoul= d draw a line.

The charter should allow a signature method that does not support XMPP, if = it makes HTTP better. In other words, I am against putting any other protoc= ol at equal consideration as HTTP.

EHL


On 2/5/09 1:37 PM, "Onyx Raven" <onyxraven@gmail.com> wrote:

So, thats what I was trying to get at. &nbs= p;I agree that the excepted
token consumer-request -> sp-auth -> consumer-access process should b= e
HTTP based as it is defined now.  It was really more about the
consumer -> sp request signing (with delegated access), which like
below, could be XMPP, IRC, proprietary game protocols, etc.  At a
basic level, signature signing is defined as
METHOD&RESOURCE&PARAMETERS (where parameters are key/value pairs structured in www-form-urlencoded style).

But like I said before, as long as the core standard has acceptable
wording for other consumer -> sp request protocols to hook into, thats what matters there.  I just wanted to be sure we didn't get locked
into something we might want alternatives to in the future.

On Thu, Feb 5, 2009 at 2:21 PM, John Kemp <jo= hn@jkemp.net> wrote:
> On Feb 5, 2009, at 3:52 PM, Seth Fitzsimmons wrote:
>
>>
>> XMPP (XEP-0235) assumes that tokens are exchanged out of band, lea= ving
>> that mechanism in HTTP.
>
> Right. The point being that there are at least two potentially-indepen= dent
> parts to OAuth - a set of signature mechanisms (RSA-SHA1, HMAC-SHA1, > PLAINTEXT), and an HTTP-based protocol for token exchange.
>
> [...]
>
>>
>> To me, the most useful aspect of OAuth when applied to other proto= cols
>> is a clearly defined way to generate signatures given constituent<= BR> >> components.
>
> I think it's certainly reasonable to suggest that the signature mechan= isms
> be defined so as to be useful in contexts other than HTTP. Which appar= ently
> already worked well-enough for XMPP with OAuth 1.0.
>
> - johnk
>

--_000_C5B09F37122D5eranhueniversecom_-- From will@willnorris.com Thu Feb 5 13:58: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 97A0D3A6AB8 for ; Thu, 5 Feb 2009 13:58:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n1Vv6CnyZhyE for ; Thu, 5 Feb 2009 13:58:31 -0800 (PST) Received: from mho-01-bos.mailhop.org (mho-01-bos.mailhop.org [63.208.196.178]) by core3.amsl.com (Postfix) with ESMTP id AB65D3A6AD1 for ; Thu, 5 Feb 2009 13:58:31 -0800 (PST) Received: from c-24-5-85-216.hsd1.ca.comcast.net ([24.5.85.216] helo=[10.0.1.7]) by mho-01-bos.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1LVCEx-0002Rn-D2; Thu, 05 Feb 2009 21:58:31 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 24.5.85.216 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18tUnniJ9SV+p1lVM7wTZNGbrDbeCk4GmA= Message-Id: From: Will Norris To: Eran Hammer-Lahav 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 v930.3) Date: Thu, 5 Feb 2009 13:58:28 -0800 References: X-Mailer: Apple Mail (2.930.3) Cc: Onyx Raven , "oauth@ietf.org" Subject: Re: [oauth] OAuth only for HTTP request signing? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 21:58:32 -0000 Eran, Is the plan to put the existing SBS stuff in IETF OAuth Core or in a separate HTTP binding? Perhaps that would be a reasonable compromise, leaving OAuth Core protocol agnostic. Of course, the WG could only be responsible for creating the HTTP binding, not any other protocol. But it would leave OAuth Core flexible enough to support future protocol bindings in the future without modification. Or am I missing something? -will On Feb 5, 2009, at 1:50 PM, Eran Hammer-Lahav wrote: > The fact the signature base string today is compatible with XMPP > (but taking a liberal view of the workflow), is mostly luck. It just > happened that a solution that was optimized for HTTP seems to work > well for XMPP with some clarifications. > > It is very likely that we will be defining a new signature method. > If non-HTTP considerations will make it any more complex than it has > to be, I will find it problematic. If it doesn't, great. I am happy > to allow the charter to "review the applicability of existing and > new signature methods to protocols other than HTTP", but that is > where I think we should draw a line. > > The charter should allow a signature method that does not support > XMPP, if it makes HTTP better. In other words, I am against putting > any other protocol at equal consideration as HTTP. > > EHL > > > On 2/5/09 1:37 PM, "Onyx Raven" wrote: > > So, thats what I was trying to get at. I agree that the excepted > token consumer-request -> sp-auth -> consumer-access process should be > HTTP based as it is defined now. It was really more about the > consumer -> sp request signing (with delegated access), which like > below, could be XMPP, IRC, proprietary game protocols, etc. At a > basic level, signature signing is defined as > METHOD&RESOURCE&PARAMETERS (where parameters are key/value pairs > structured in www-form-urlencoded style). > > But like I said before, as long as the core standard has acceptable > wording for other consumer -> sp request protocols to hook into, thats > what matters there. I just wanted to be sure we didn't get locked > into something we might want alternatives to in the future. > > On Thu, Feb 5, 2009 at 2:21 PM, John Kemp wrote: >> On Feb 5, 2009, at 3:52 PM, Seth Fitzsimmons wrote: >> >>> >>> XMPP (XEP-0235) assumes that tokens are exchanged out of band, >>> leaving >>> that mechanism in HTTP. >> >> Right. The point being that there are at least two potentially- >> independent >> parts to OAuth - a set of signature mechanisms (RSA-SHA1, HMAC-SHA1, >> PLAINTEXT), and an HTTP-based protocol for token exchange. >> >> [...] >> >>> >>> To me, the most useful aspect of OAuth when applied to other >>> protocols >>> is a clearly defined way to generate signatures given constituent >>> components. >> >> I think it's certainly reasonable to suggest that the signature >> mechanisms >> be defined so as to be useful in contexts other than HTTP. Which >> apparently >> already worked well-enough for XMPP with OAuth 1.0. >> >> - johnk >> > > _______________________________________________ > oauth mailing list > oauth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Thu Feb 5 14:08: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 DAEAA28C0D9 for ; Thu, 5 Feb 2009 14:08:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.216 X-Spam-Level: X-Spam-Status: No, score=-4.216 tagged_above=-999 required=5 tests=[AWL=-1.617, 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 LVaqmZW35yRX for ; Thu, 5 Feb 2009 14:08:52 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id BF7B03A6AB8 for ; Thu, 5 Feb 2009 14:08:52 -0800 (PST) Received: (qmail 6131 invoked from network); 5 Feb 2009 22:08:54 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 5 Feb 2009 22:08:54 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 5 Feb 2009 15:08:54 -0700 From: Eran Hammer-Lahav To: Will Norris Date: Thu, 5 Feb 2009 15:08:52 -0700 Thread-Topic: [oauth] OAuth only for HTTP request signing? Thread-Index: AcmH3OSyDb2d/bSWQ9G4kM7LScRsiAAAW9ly Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Onyx Raven , "oauth@ietf.org" Subject: Re: [oauth] OAuth only for HTTP request signing? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 22:08:54 -0000 The proposal is to the OAuth Core 1.0, bring it to IETF security standards, make interop better defined, and be done. The closer we stay to Core 1.0 th= e better (as long as security and interop are not compromised). That is the general idea, at least my reasons for starting this effort. It seems silly to me to try and separate the transport from the protocol, given this protocol was explicitly created to address shortcomings in the HTTP transport. Security and interop dictates a tightly defined relationship to the transport layer. EHL On 2/5/09 1:58 PM, "Will Norris" wrote: > Eran, > > Is the plan to put the existing SBS stuff in IETF OAuth Core or in a > separate HTTP binding? Perhaps that would be a reasonable compromise, > leaving OAuth Core protocol agnostic. Of course, the WG could only be > responsible for creating the HTTP binding, not any other protocol. > But it would leave OAuth Core flexible enough to support future > protocol bindings in the future without modification. > > Or am I missing something? > > -will > > > On Feb 5, 2009, at 1:50 PM, Eran Hammer-Lahav wrote: > >> The fact the signature base string today is compatible with XMPP >> (but taking a liberal view of the workflow), is mostly luck. It just >> happened that a solution that was optimized for HTTP seems to work >> well for XMPP with some clarifications. >> >> It is very likely that we will be defining a new signature method. >> If non-HTTP considerations will make it any more complex than it has >> to be, I will find it problematic. If it doesn't, great. I am happy >> to allow the charter to "review the applicability of existing and >> new signature methods to protocols other than HTTP", but that is >> where I think we should draw a line. >> >> The charter should allow a signature method that does not support >> XMPP, if it makes HTTP better. In other words, I am against putting >> any other protocol at equal consideration as HTTP. >> >> EHL >> >> >> On 2/5/09 1:37 PM, "Onyx Raven" wrote: >> >> So, thats what I was trying to get at. I agree that the excepted >> token consumer-request -> sp-auth -> consumer-access process should be >> HTTP based as it is defined now. It was really more about the >> consumer -> sp request signing (with delegated access), which like >> below, could be XMPP, IRC, proprietary game protocols, etc. At a >> basic level, signature signing is defined as >> METHOD&RESOURCE&PARAMETERS (where parameters are key/value pairs >> structured in www-form-urlencoded style). >> >> But like I said before, as long as the core standard has acceptable >> wording for other consumer -> sp request protocols to hook into, thats >> what matters there. I just wanted to be sure we didn't get locked >> into something we might want alternatives to in the future. >> >> On Thu, Feb 5, 2009 at 2:21 PM, John Kemp wrote: >>> On Feb 5, 2009, at 3:52 PM, Seth Fitzsimmons wrote: >>> >>>> >>>> XMPP (XEP-0235) assumes that tokens are exchanged out of band, >>>> leaving >>>> that mechanism in HTTP. >>> >>> Right. The point being that there are at least two potentially- >>> independent >>> parts to OAuth - a set of signature mechanisms (RSA-SHA1, HMAC-SHA1, >>> PLAINTEXT), and an HTTP-based protocol for token exchange. >>> >>> [...] >>> >>>> >>>> To me, the most useful aspect of OAuth when applied to other >>>> protocols >>>> is a clearly defined way to generate signatures given constituent >>>> components. >>> >>> I think it's certainly reasonable to suggest that the signature >>> mechanisms >>> be defined so as to be useful in contexts other than HTTP. Which >>> apparently >>> already worked well-enough for XMPP with OAuth 1.0. >>> >>> - johnk >>> >> >> _______________________________________________ >> oauth mailing list >> oauth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > From seth@mojodna.net Thu Feb 5 14:22: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 173D43A67CF for ; Thu, 5 Feb 2009 14:22:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ME2-LdlMak8 for ; Thu, 5 Feb 2009 14:22:21 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.173]) by core3.amsl.com (Postfix) with ESMTP id 598D93A69B7 for ; Thu, 5 Feb 2009 14:22:21 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so501687wfd.31 for ; Thu, 05 Feb 2009 14:22:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.142.185.13 with SMTP id i13mr567497wff.36.1233872542519; Thu, 05 Feb 2009 14:22:22 -0800 (PST) In-Reply-To: References: <1d7d37050902051252h3eb088a9rc48758a99825372@mail.gmail.com> Date: Thu, 5 Feb 2009 14:22:22 -0800 Message-ID: <1d7d37050902051422w299c3af4g8d11a9fe647c65f6@mail.gmail.com> From: Seth Fitzsimmons To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Onyx Raven , "oauth@ietf.org" Subject: Re: [oauth] OAuth only for HTTP request signing? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 22:22:22 -0000 >> How do you mean 'binding'? > > What to put in the each of the string components, how to send the signature > and parameters, etc. The SBS 'method' in Core 1.0 is well defined to be an > HTTP method, uppercase, etc. Does XMPP uses HTTP methods? No, but the XEP slots in message types in its place (iq / message). We were looking at method as "verb" or "action". HTTP methods are typically uppercase, hence that particular normalization. Any chance we could aim to create a generic SBS (e.g. verb&context¶meters) and define a binding for HTTP only (leaving bindings to other protocols up to them)? > My objection is purely from security perspective. If the security experts in > the room want to take a different position, I'll defer to them. But my > assumption is that we are looking specifically at HTTP and how HTTP requests > can be made securely (under the conditions defined by this use case). > > I know little of XMPP, as one example, to say that its characteristics are > similar enough to HTTP to have the same security considerations. Leaving "parameters" open allows other protocols to designate which core parameters are necessary (e.g. nonce/timestamp aren't necessary assuming TLS for XMPP, but they're in there because that assumption can't be made). Certainly security considerations will define the binding, but needn't be part of the core. > In addition, it is unclear to me that OAuth is the appropriate approach to > delegation in XMPP and other protocols. It *was not* developed with such use > cases in mind. Sure, it was coincidental, but that it was possible was due to the perceived flexibility of the signature base string. Do you consider the definition of the signing process part of the protocol, the transport, or something else? seth From eran@hueniverse.com Thu Feb 5 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 1DA073A69C1 for ; Thu, 5 Feb 2009 15:31:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.184 X-Spam-Level: X-Spam-Status: No, score=-4.184 tagged_above=-999 required=5 tests=[AWL=-1.585, 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 CCOzsmbrUzSi for ; Thu, 5 Feb 2009 15:31:25 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 154343A69B4 for ; Thu, 5 Feb 2009 15:31:25 -0800 (PST) Received: (qmail 18834 invoked from network); 5 Feb 2009 23:31:25 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 5 Feb 2009 23:31:25 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 5 Feb 2009 16:31:25 -0700 From: Eran Hammer-Lahav To: Seth Fitzsimmons Date: Thu, 5 Feb 2009 16:31:23 -0700 Thread-Topic: [oauth] OAuth only for HTTP request signing? Thread-Index: AcmH4Df8uBwbrl5jSG6V6SMLKxwROgACaMjk Message-ID: In-Reply-To: <1d7d37050902051422w299c3af4g8d11a9fe647c65f6@mail.gmail.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Onyx Raven , "oauth@ietf.org" Subject: Re: [oauth] OAuth only for HTTP request signing? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 23:31:28 -0000 On 2/5/09 2:22 PM, "Seth Fitzsimmons" wrote: > Any chance we could aim to create a generic SBS (e.g. > verb&context¶meters) and define a binding for HTTP only (leaving > bindings to other protocols up to them)? Aim, sure. Define it as a goal or requirement of the WG in the charter... I rather not. If we do, it should be a non-binding goal to allow other transport binding for using OAuth token-secret pairs in other protocols. If someone wants to offer a language for the charter with regard to such non-binding approach, I would be happy to consider. > Do you consider the definition of the signing process part of the > protocol, the transport, or something else? Well, I consider it as a replacement/addition to RFC 2617. If you consider 2617 part of HTTP, than I consider OAuth part of the transport. If you consider 2617 closer to the application layer, I'm ok with that too. In other words, I consider OAuth as an HTTP specific protocol. So I don't really need to define it in a modular with respect to other transports. Within the HTTP use case, I still consider it modular where the way you obtain an Access Token is separate from how to authenticate using that token. EHL From hubertlvg@gmail.com Fri Feb 6 00:39:03 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EE8C3A6B68 for ; Fri, 6 Feb 2009 00:39:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.397 X-Spam-Level: X-Spam-Status: No, score=-1.397 tagged_above=-999 required=5 tests=[AWL=-1.098, BAYES_00=-2.599, MANGLED_AVOID=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jRTJbPpcfS5z for ; Fri, 6 Feb 2009 00:39:02 -0800 (PST) Received: from mail-qy0-f11.google.com (mail-qy0-f11.google.com [209.85.221.11]) by core3.amsl.com (Postfix) with ESMTP id E6A853A67B6 for ; Fri, 6 Feb 2009 00:39:01 -0800 (PST) Received: by qyk4 with SMTP id 4so1051698qyk.13 for ; Fri, 06 Feb 2009 00:39:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=izAqkXrnyq1fYXrlln/obPciHB9kBu29aUxDM1IjLK4=; b=jgfCtSQ8M4f1GwbnDJ4I1bgCf52BhxHQ6xJyFScw1rzo1U7hKTBstV6j5xFeiUkS9y AvYvxvXUFEQlzFAQ6i+izHcCMHAsZP5k8gT2X+PX92IdW5QliBdkBuNbVgSoELt3w6XK 13jBXmCQ0J62hdIITDEpac8NYHPl6Ck7L91ls= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=BgMe4S69bHVXw5XZCGxH1u9ycLe3BlTVN6EI5+u9D+BD8TbiWFYjwr1GzQkV/WQdW4 SlaVGuB5NtqDz3mIwLONcTYj23jSZWYgHxIdP9JBpDZlFj18C4RgAO6dLY0ixZfuKhcC iGWNhCjJrw8hVzG2z1h4NmXFTNV1a6yXZj27c= MIME-Version: 1.0 Received: by 10.215.38.1 with SMTP id q1mr2209139qaj.310.1233909543088; Fri, 06 Feb 2009 00:39:03 -0800 (PST) In-Reply-To: References: Date: Fri, 6 Feb 2009 09:39:03 +0100 Message-ID: <6c0fd2bc0902060039t4c4e81ccn77ad873b7b91afa3@mail.gmail.com> From: Hubert Le Van Gong To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Onyx Raven , "oauth@ietf.org" Subject: Re: [oauth] OAuth only for HTTP request signing? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 08:39:03 -0000 Although it could be interesting to have the signature mechanism made protocol agnostic, I agree with your approach. However as mentioned previously, the OAuth Core 1.0 is composed of 2 independent components (the protocol and the signature mechanism). I would propose to target 2 separate documents, one being the OAuth protocol and the other one addressing security mechanisms (i.e. the signature mech). There are several initiatives out there that either contemplate or have already chosen to adopt the OAuth signature mechanism since it fulfills a void in the current HTTP world. Does this seem reasonable? Cheers, Hubert On Thu, Feb 5, 2009 at 11:08 PM, Eran Hammer-Lahav wrote: > The proposal is to the OAuth Core 1.0, bring it to IETF security standards, > make interop better defined, and be done. The closer we stay to Core 1.0 the > better (as long as security and interop are not compromised). That is the > general idea, at least my reasons for starting this effort. > > It seems silly to me to try and separate the transport from the protocol, > given this protocol was explicitly created to address shortcomings in the > HTTP transport. > > Security and interop dictates a tightly defined relationship to the > transport layer. > > EHL > > > On 2/5/09 1:58 PM, "Will Norris" wrote: > >> Eran, >> >> Is the plan to put the existing SBS stuff in IETF OAuth Core or in a >> separate HTTP binding? Perhaps that would be a reasonable compromise, >> leaving OAuth Core protocol agnostic. Of course, the WG could only be >> responsible for creating the HTTP binding, not any other protocol. >> But it would leave OAuth Core flexible enough to support future >> protocol bindings in the future without modification. >> >> Or am I missing something? >> >> -will >> >> >> On Feb 5, 2009, at 1:50 PM, Eran Hammer-Lahav wrote: >> >>> The fact the signature base string today is compatible with XMPP >>> (but taking a liberal view of the workflow), is mostly luck. It just >>> happened that a solution that was optimized for HTTP seems to work >>> well for XMPP with some clarifications. >>> >>> It is very likely that we will be defining a new signature method. >>> If non-HTTP considerations will make it any more complex than it has >>> to be, I will find it problematic. If it doesn't, great. I am happy >>> to allow the charter to "review the applicability of existing and >>> new signature methods to protocols other than HTTP", but that is >>> where I think we should draw a line. >>> >>> The charter should allow a signature method that does not support >>> XMPP, if it makes HTTP better. In other words, I am against putting >>> any other protocol at equal consideration as HTTP. >>> >>> EHL >>> >>> >>> On 2/5/09 1:37 PM, "Onyx Raven" wrote: >>> >>> So, thats what I was trying to get at. I agree that the excepted >>> token consumer-request -> sp-auth -> consumer-access process should be >>> HTTP based as it is defined now. It was really more about the >>> consumer -> sp request signing (with delegated access), which like >>> below, could be XMPP, IRC, proprietary game protocols, etc. At a >>> basic level, signature signing is defined as >>> METHOD&RESOURCE&PARAMETERS (where parameters are key/value pairs >>> structured in www-form-urlencoded style). >>> >>> But like I said before, as long as the core standard has acceptable >>> wording for other consumer -> sp request protocols to hook into, thats >>> what matters there. I just wanted to be sure we didn't get locked >>> into something we might want alternatives to in the future. >>> >>> On Thu, Feb 5, 2009 at 2:21 PM, John Kemp wrote: >>>> On Feb 5, 2009, at 3:52 PM, Seth Fitzsimmons wrote: >>>> >>>>> >>>>> XMPP (XEP-0235) assumes that tokens are exchanged out of band, >>>>> leaving >>>>> that mechanism in HTTP. >>>> >>>> Right. The point being that there are at least two potentially- >>>> independent >>>> parts to OAuth - a set of signature mechanisms (RSA-SHA1, HMAC-SHA1, >>>> PLAINTEXT), and an HTTP-based protocol for token exchange. >>>> >>>> [...] >>>> >>>>> >>>>> To me, the most useful aspect of OAuth when applied to other >>>>> protocols >>>>> is a clearly defined way to generate signatures given constituent >>>>> components. >>>> >>>> I think it's certainly reasonable to suggest that the signature >>>> mechanisms >>>> be defined so as to be useful in contexts other than HTTP. Which >>>> apparently >>>> already worked well-enough for XMPP with OAuth 1.0. >>>> >>>> - johnk >>>> >>> >>> _______________________________________________ >>> oauth mailing list >>> oauth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> >> > > _______________________________________________ > oauth mailing list > oauth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From eran@hueniverse.com Fri Feb 6 08:43:23 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F40B28C0DF for ; Fri, 6 Feb 2009 08:43:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.003 X-Spam-Level: X-Spam-Status: No, score=-3.003 tagged_above=-999 required=5 tests=[AWL=-2.704, BAYES_00=-2.599, MANGLED_AVOID=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mgVGlPmJS5CU for ; Fri, 6 Feb 2009 08:43:22 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 8CF5A3A67D6 for ; Fri, 6 Feb 2009 08:43:22 -0800 (PST) Received: (qmail 18317 invoked from network); 6 Feb 2009 16:43:24 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 6 Feb 2009 16:43:24 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Fri, 6 Feb 2009 09:43:15 -0700 From: Eran Hammer-Lahav To: Hubert Le Van Gong Date: Fri, 6 Feb 2009 09:43:13 -0700 Thread-Topic: [oauth] OAuth only for HTTP request signing? Thread-Index: AcmINl3Nh6TTdQ9eQ9e+UML5LXWRwAAQembg Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234127C939B7A@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <6c0fd2bc0902060039t4c4e81ccn77ad873b7b91afa3@mail.gmail.com> In-Reply-To: <6c0fd2bc0902060039t4c4e81ccn77ad873b7b91afa3@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Onyx Raven , "oauth@ietf.org" Subject: Re: [oauth] OAuth only for HTTP request signing? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 16:43:23 -0000 I am extremely hesitant to make this an official charter request but this w= as exactly my plan when I submitted draft-hammer-oauth. At the time I assum= ed this will be an Informational track individual submission. The thing is, if you break the spec into two documents, what you are end up= creating is: 1. An alternative to RFC 2617 2. An extension to 2617 for delegation If you bundle them into a single document, #1 becomes less official as a di= rect alternative to 2617, even though some people may choose to use it that= way (which is currently the case with deployment of 2-legged OAuth). The fear is that if we charter this work to produce two documents, we posit= ion OAuth as a replacement to 2617. If we charter this work to produce one = document, we position OAuth as an extension of 2617 that is use-case specif= ic. While this might sound like silly semantic games, it is actually very i= mportant. Replacement of 2617 has a much wider scope than the current OAuth charter. = It brings in a lot more requirements, and at the same time, opens the door = to a much greater deviation from Core 1.0. If we focus on the delegation us= e case, we may or may not come up with a 2-legged solution that will be acc= eptable to the security community as a replacement of 2617. But it will be = acceptable for this specific use case. If we focus on first replacing 2617, we will have to accept the likelihood = of further breaking away from Core 1.0 - something a majority of people her= e strongly objected to. This was also the general agreement at the OAuth Bo= F (not replacing 2617, but that competition is not necessarily a bad thing)= . EHL > -----Original Message----- > From: Hubert Le Van Gong [mailto:hubertlvg@gmail.com] > Sent: Friday, February 06, 2009 12:39 AM > To: Eran Hammer-Lahav > Cc: Will Norris; Onyx Raven; oauth@ietf.org > Subject: Re: [oauth] OAuth only for HTTP request signing? > > Although it could be interesting to have the signature mechanism made > protocol > agnostic, I agree with your approach. However as mentioned previously, > the > OAuth Core 1.0 is composed of 2 independent components (the protocol > and the signature mechanism). > > I would propose to target 2 separate documents, one being the OAuth > protocol > and the other one addressing security mechanisms (i.e. the signature > mech). > > There are several initiatives out there that either contemplate or have > already > chosen to adopt the OAuth signature mechanism since it fulfills a void > in the > current HTTP world. > > Does this seem reasonable? > > Cheers, > Hubert > > > On Thu, Feb 5, 2009 at 11:08 PM, Eran Hammer-Lahav > wrote: > > The proposal is to the OAuth Core 1.0, bring it to IETF security > standards, > > make interop better defined, and be done. The closer we stay to Core > 1.0 the > > better (as long as security and interop are not compromised). That is > the > > general idea, at least my reasons for starting this effort. > > > > It seems silly to me to try and separate the transport from the > protocol, > > given this protocol was explicitly created to address shortcomings in > the > > HTTP transport. > > > > Security and interop dictates a tightly defined relationship to the > > transport layer. > > > > EHL > > > > > > On 2/5/09 1:58 PM, "Will Norris" wrote: > > > >> Eran, > >> > >> Is the plan to put the existing SBS stuff in IETF OAuth Core or in a > >> separate HTTP binding? Perhaps that would be a reasonable > compromise, > >> leaving OAuth Core protocol agnostic. Of course, the WG could only > be > >> responsible for creating the HTTP binding, not any other protocol. > >> But it would leave OAuth Core flexible enough to support future > >> protocol bindings in the future without modification. > >> > >> Or am I missing something? > >> > >> -will > >> > >> > >> On Feb 5, 2009, at 1:50 PM, Eran Hammer-Lahav wrote: > >> > >>> The fact the signature base string today is compatible with XMPP > >>> (but taking a liberal view of the workflow), is mostly luck. It > just > >>> happened that a solution that was optimized for HTTP seems to work > >>> well for XMPP with some clarifications. > >>> > >>> It is very likely that we will be defining a new signature method. > >>> If non-HTTP considerations will make it any more complex than it > has > >>> to be, I will find it problematic. If it doesn't, great. I am happy > >>> to allow the charter to "review the applicability of existing and > >>> new signature methods to protocols other than HTTP", but that is > >>> where I think we should draw a line. > >>> > >>> The charter should allow a signature method that does not support > >>> XMPP, if it makes HTTP better. In other words, I am against putting > >>> any other protocol at equal consideration as HTTP. > >>> > >>> EHL > >>> > >>> > >>> On 2/5/09 1:37 PM, "Onyx Raven" wrote: > >>> > >>> So, thats what I was trying to get at. I agree that the excepted > >>> token consumer-request -> sp-auth -> consumer-access process should > be > >>> HTTP based as it is defined now. It was really more about the > >>> consumer -> sp request signing (with delegated access), which like > >>> below, could be XMPP, IRC, proprietary game protocols, etc. At a > >>> basic level, signature signing is defined as > >>> METHOD&RESOURCE&PARAMETERS (where parameters are key/value pairs > >>> structured in www-form-urlencoded style). > >>> > >>> But like I said before, as long as the core standard has acceptable > >>> wording for other consumer -> sp request protocols to hook into, > thats > >>> what matters there. I just wanted to be sure we didn't get locked > >>> into something we might want alternatives to in the future. > >>> > >>> On Thu, Feb 5, 2009 at 2:21 PM, John Kemp wrote: > >>>> On Feb 5, 2009, at 3:52 PM, Seth Fitzsimmons wrote: > >>>> > >>>>> > >>>>> XMPP (XEP-0235) assumes that tokens are exchanged out of band, > >>>>> leaving > >>>>> that mechanism in HTTP. > >>>> > >>>> Right. The point being that there are at least two potentially- > >>>> independent > >>>> parts to OAuth - a set of signature mechanisms (RSA-SHA1, HMAC- > SHA1, > >>>> PLAINTEXT), and an HTTP-based protocol for token exchange. > >>>> > >>>> [...] > >>>> > >>>>> > >>>>> To me, the most useful aspect of OAuth when applied to other > >>>>> protocols > >>>>> is a clearly defined way to generate signatures given constituent > >>>>> components. > >>>> > >>>> I think it's certainly reasonable to suggest that the signature > >>>> mechanisms > >>>> be defined so as to be useful in contexts other than HTTP. Which > >>>> apparently > >>>> already worked well-enough for XMPP with OAuth 1.0. > >>>> > >>>> - johnk > >>>> > >>> > >>> _______________________________________________ > >>> oauth mailing 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 lisa.dusseault@gmail.com Fri Feb 6 11:04: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 743063A6BE0 for ; Fri, 6 Feb 2009 11:04:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.872 X-Spam-Level: X-Spam-Status: No, score=-2.872 tagged_above=-999 required=5 tests=[AWL=-0.274, 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 BQSBV93D0AUE for ; Fri, 6 Feb 2009 11:04:43 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.239]) by core3.amsl.com (Postfix) with ESMTP id 901AF3A6BDE for ; Fri, 6 Feb 2009 11:04:43 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so875773rvf.49 for ; Fri, 06 Feb 2009 11:04:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=wvYfB77uk7O40BXC6QhPE+GhPd/YVBAYaj2GPgz7kCc=; b=W5B+PpoomCyzJqI1CoM4wb3mTzTbsRkP5aO5D6lqpe/WjP6e2Bnf/XNYuNVsUX7GUc VVNa0tNoGLbIVug/EAV0mx1uVNGgW7TaUUdYU+BPPIc98jwUo+zaRWrSzvReZgtjduJk Fr9PryMPTG8RAAoFA0J4r8jP38NaW+Q+EYlqs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=tMsMPUkEB0i71kpWnHwYVrXDpyYgy/JuvZwe2DBSnxVqjIeoe0OX2B6a0R6R47wQgH qTUb8VGcAChDjHB/I1fdg82U4SCd6ok+TkIrR8EzbD1cMKYac/NStHwi5NhtkwT1sW8+ Pfr6mjELnwrGYBJFjwjqHStJ749c2NGaHQeTs= MIME-Version: 1.0 Received: by 10.140.186.20 with SMTP id j20mr1502147rvf.272.1233947085328; Fri, 06 Feb 2009 11:04:45 -0800 (PST) Date: Fri, 6 Feb 2009 11:04:45 -0800 Message-ID: From: Lisa Dusseault To: oauth@ietf.org Content-Type: multipart/alternative; boundary=000e0cd14e7cb15301046244b11e Cc: gregory.ietf@gmail.com Subject: [oauth] Comment on charter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 19:04:44 -0000 --000e0cd14e7cb15301046244b11e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Here's a comment on the charter, Greg told me this in person but I asked him to follow up on the list. He's not on the list, so please keep him on the cc' for this discussion: Oauth team, I think the work you are doing is meaningful and I hope to see it transition to WG soon. Here is a comment to your charter that I made from the mic at the last BoF, and which I hope to see included in the next version of the charter. >From the charter: "The Working Group will produce one or more documents suitable for consideration as Proposed Standard, based upon the OAuth I-D, that will: * Align OAuth with the Internet and Web architectures, best practices and terminology * Assure good security practice, or document gaps in its capabilities * Promote interoperability" Change second bullet to: "* Assure good security practice, or document gaps in its capabilities, and propose a path forward for addressing the gap." The reason: we have experienced in other places in IETF where documents with less-than-perfect security get hung up in Security Area review, and for good reason. We want secure protocols that use modern, best-practice secruity mechanisms. However, sometimes getting from today to that state of best-practice security mechanism is non-trivial, and will take standard and implementation work. We are learning over time that (1) documenting security gaps, combined with (2) a clear path to addressing gaps, and (3) work in progress to addressing gaps goes a long way to making less-than-best-security-practice specifications more acceptable. I.e. The charter change I propose is geared toward helping Oauth see the light of day more quickly, and have an incremental path toward best-practice security. Let me know what you think, Gregorry. --000e0cd14e7cb15301046244b11e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Here's a comment on the charter, Greg told me this in person but I aske= d him to follow up on the list.  He's not on the list, so please k= eep him on the cc' for this discussion:

Oauth team,
I think the work you are doing is meaningful and I hope to see it transition to WG soon.

Here is a comment to your charter that I made from the mic at the last BoF, and which I hope to see included in the next version of the charter.

From the charter:

"The Working Group will produce one or more = documents suitable
for
consideration as Proposed Standard, based upon= the OAuth I-D, that will:
  * Align OAuth with the Internet and We= b architectures, best
practices and
terminology
  * Assure good security practice, or = document gaps in its
capabilities
  * Promote interoperability&q= uot;

Change second bullet to:
"* Assure good security practi= ce, or document gaps in its
capabilities, and propose a path forward for addressing the gap."
<= br>The reason:  we have experienced in other places in IETF where
d= ocuments with less-than-perfect security get hung up in Security Area
re= view, and for good reason. We want secure protocols that use modern,
best-practice secruity mechanisms. However, sometimes getting from todayto that state of best-practice security mechanism is non-trivial, and
w= ill take standard and implementation work. We are learning over time
that (1) documenting security gaps, combined with (2) a clear path to
ad= dressing gaps, and (3) work in progress to addressing gaps goes a long
w= ay to making less-than-best-security-practice specifications more
accept= able.

I.e. The charter change I propose is geared toward helping Oauth see th= e
light of day more quickly, and have an incremental path toward
best= -practice security.

Let me know what you think,
Gregorry.



--000e0cd14e7cb15301046244b11e-- From romeda@gmail.com Sun Feb 8 05:59:14 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60CDF3A6A7C for ; Sun, 8 Feb 2009 05:59:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, SARE_WEOFFER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id izDfb0jfxNnr for ; Sun, 8 Feb 2009 05:59:13 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id 068393A6A65 for ; Sun, 8 Feb 2009 05:59:12 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 25so293995eya.31 for ; Sun, 08 Feb 2009 05:59:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=F5/yHXNuaNET0yqNS2CtVVHuE0NrDF+DW8gfJu12Hww=; b=XIkDIII5kSu7CSFeW9W6jSCTcb+W4YJC21Vs1D6j/1TKhDvAlhknJrHgx192ejUv+O 9lCmA08447vmUbRzURrLwoFn3SbN3+slMTszGrurhlIYjlHef+ILQH0XzX5fLiHYSI4o KzgiDgsfN6n2eky5mmxQepvuo72QlORtn4ctA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=YFrW2xaoFBn3UvAYNsQHrktI3DZ5NTa6q6sjejdp4NiNAfVrRQKIIFjXu4rJi7jJ1k s63P2c1fLrAWhzmWbtw15tmULZ3L61fP3NRmCa6TYl+siYIv+1zN9RYtGi1+SVhJiH23 GZj8y0sSJOTmM0HlH0YNFUiN01W6xVv9KnmO8= MIME-Version: 1.0 Received: by 10.210.120.7 with SMTP id s7mr3037286ebc.78.1234101555496; Sun, 08 Feb 2009 05:59:15 -0800 (PST) In-Reply-To: References: Date: Sun, 8 Feb 2009 14:59:15 +0100 Message-ID: From: Blaine Cook To: Lisa Dusseault Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: gregory.ietf@gmail.com, oauth@ietf.org Subject: Re: [oauth] Comment on charter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2009 13:59:14 -0000 On Fri, Feb 6, 2009 at 8:04 PM, Lisa Dusseault wrote: > * Assure good security practice, or document gaps in its > capabilities > > ... > > Change second bullet to: > "* Assure good security practice, or document gaps in its > capabilities, and propose a path forward for addressing the gap." > > ... We are learning over time > that (1) documenting security gaps, combined with (2) a clear path to > addressing gaps, and (3) work in progress to addressing gaps goes a long > way to making less-than-best-security-practice specifications more > acceptable. > > I.e. The charter change I propose is geared toward helping Oauth see the > light of day more quickly, and have an incremental path toward > best-practice security. I fully agree. My approach to security, and I think this is true for others involved with OAuth, is to strive for the best security that will actually work. That is to say that if OAuth wasn't adopted because the security introduced a too-high barrier to adoption, then the reality is that everyone has less security overall since they're using Basic auth or whatever other (less secure) alternative. By pushing forward OAuth, we've educated people and informed discussions around security, enabling people to think about even better approaches, and as those conversations mature, we (as the web community in general) should absolutely be active in ensuring that we offer the best usable solutions possible. b. From Hannes.Tschofenig@gmx.net Mon Feb 16 12:48:00 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BFBA3A6BCB for ; Mon, 16 Feb 2009 12:48:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.454 X-Spam-Level: X-Spam-Status: No, score=-1.454 tagged_above=-999 required=5 tests=[AWL=-0.714, 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 P1GmIzsvWGwO for ; Mon, 16 Feb 2009 12:47:59 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 93A6A3A6954 for ; Mon, 16 Feb 2009 12:47:50 -0800 (PST) Received: (qmail invoked by alias); 16 Feb 2009 19:51:17 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp069) with SMTP; 16 Feb 2009 20:51:17 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/Vy3gx2HLVq9w5WaRBrHT1XmYcU30/dgG8R9vJ6Z Nfhv5Fv79t+2oN From: "Hannes Tschofenig" To: Date: Mon, 16 Feb 2009 21:52:10 +0200 Message-ID: <009e01c99070$11d33100$0201a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcmQcA387rU+CCmsTHyQ0lQ7pueWAw== X-Y-GMX-Trusted: 0 X-FuHaFi: 0.58 Subject: [oauth] draft-dehora-farrell-oauth-accesstoken-creds-00.txt and OAUTH Extensions in the Charter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 20:48:00 -0000 Stephen ask me how their document draft-dehora-farrell-oauth-accesstoken-creds-00.txt is reflected in the charter text. Independent of this particular document, I believe that we should focus our initial efforts on the Base OAUTH specification rather than working on extensions. As such, I would say that (depending on the progress of the work with the main specification) we should discuss extensions in the summer timeframe. Regarding this specific extension: I read through draft-dehora-farrell-oauth-accesstoken-creds-00.txt and wanted to make sure that I understood the extension correctly. Here is a message flow that Jeff created some time ago. This document suggests to skip the message exchanges marked as (2.*). This means that the redirect from the Service Provider to the Customer and the subsequent steps of user authentication and authorization are replaced with the ability to carry some username/password in the Access token when the Consumer sends the request to the Service Provider. photos.example.net +----------+ | | | OAuth | printer.example.com | Service | +--------+ | Provider | | | | | | OAuth | |[protected| |Consumer| |resources]| +----+ | | | | | UA | | [RP] | | [SP] | +-+--+ +---+----+ +----+-----+ | | | | 1.0. User Agent inter-| | | acts with Consumer | | | site [optional] | | |<--------------------->| | | | | | | | | | | | 1.1. UA informs/directs | | Consumer to do something | | with a resource (photo) | | at SP | | |---------------------->| | | | | | | | | | | | | 1.2. Consumer attempts | | accessing photo at SP| | |--------------------->| | | | | | | | | 1.3. SP replies with | | | a HTTP 401 containing| | | a "OAuth" www-authn | | | header field | | |<---------------------| | | | | | | | | 1.4. Consumer replies| | | with a request for | | | "unauthorized Request| | | Token" (uRT) via POST| | | to SP's "request token | | URL" | | |--------------------->| | | | | | | | | 1.5. SP issues uRT & | | | token secret to | | | Consumer. | | |<---------------------| | | | | | | | | | | 2.0. Consumer redirects | | UA to SP "User Author-| | | ization URL" including| | | the uRT. | | +<- - - - - - - - - - - - | | . | (indirected via UA) | | . | | | +-------------------------+--------------------->| | | | | | | | | | | | | | 2.2. User authenticates with the Service | | Provider (optional methods vary, realization | | is out of scope) | |<============================================>| | 2.3. User grants or declines permission | | for the Service Provider allow Consumer | | access to the resource (photo). | | | | | | | | | | | | | | 2.4. If permision granted, UA redirected back| | to Consumer's "Callback URL", conveying the | | uRT. | | +<- - - - - - - - - - - - - - - - - - - - - - - -| . | (indirected via UA) | | . | | | . | | | +------------------------>| | | | | | | | | |3.0. Consumer requests| | |Access token, supplies| | |uRT. | | |--------------------->| | | | | | | | | | | |3.1. SP grants Access | | | Token. | | |<---------------------| | | | | | | | |4.x. Consumer uses the| | |Access Token, Access | | |Token Secret, Consumer| | |Key, and Consumer Secret | |to make authenticated | | |request(s) to the Service | |Provider. | | |=====================>| | | . | | | . | | | . | | | | My personal view is that this goes a bit against the OAUTH idea. Unless the username/password is again created using some other mechanism (which the document does not describe) then there are vulnerability that OAUTH was initially meant to deal with. Additionally, the result is less likely to be easy to deploy. As a justification for the work the following argument is provided: "HTTP redirection to a browser is unavailable or unsuitable, such as intermediary aggregators and mobile or settop devices." I wonder whether this is really a problem in today's mobile devices to justify this optimization. Maybe I just didn't capture the idea properly. Ciao Hannes From hannes.tschofenig@nsn.com Tue Feb 17 00:36:01 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51B5F3A6899 for ; Tue, 17 Feb 2009 00:36:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.71 X-Spam-Level: X-Spam-Status: No, score=-5.71 tagged_above=-999 required=5 tests=[AWL=0.889, 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 Fv533tT1zAvL for ; Tue, 17 Feb 2009 00:36:00 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 0238D3A65A5 for ; Tue, 17 Feb 2009 00:35:59 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n1H8a6Mh005366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 17 Feb 2009 09:36:06 +0100 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n1H8a6HZ029801; Tue, 17 Feb 2009 09:36:06 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Feb 2009 09:36:05 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Feb 2009 10:37:00 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45010DB8C4@FIESEXC015.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [oauth] Comment on charter Thread-Index: AcmIjcuRbKyD2uB/TZWgYv1TFsGjFAITPYdA References: From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Lisa Dusseault" , X-OriginalArrivalTime: 17 Feb 2009 08:36:05.0592 (UTC) FILETIME=[C5FFDD80:01C990DA] Cc: gregory.ietf@gmail.com Subject: Re: [oauth] Comment on charter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 08:36:01 -0000 Thank you Greg for your input. I incorporated your comment into the charter text as it sounds good to me.=20 =20 Ciao Hannes ________________________________ From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of ext Lisa Dusseault Sent: 06 February, 2009 21:05 To: oauth@ietf.org Cc: gregory.ietf@gmail.com Subject: [oauth] Comment on charter =09 =09 Here's a comment on the charter, Greg told me this in person but I asked him to follow up on the list. He's not on the list, so please keep him on the cc' for this discussion: =09 Oauth team, I think the work you are doing is meaningful and I hope to see it transition to WG soon.=20 =09 Here is a comment to your charter that I made from the mic at the last BoF, and which I hope to see included in the next version of the charter. =09 From the charter: =09 "The Working Group will produce one or more documents suitable for consideration as Proposed Standard, based upon the OAuth I-D, that will: * Align OAuth with the Internet and Web architectures, best practices and terminology * Assure good security practice, or document gaps in its capabilities * Promote interoperability" =09 Change second bullet to: "* Assure good security practice, or document gaps in its capabilities, and propose a path forward for addressing the gap." =09 The reason: we have experienced in other places in IETF where documents with less-than-perfect security get hung up in Security Area review, and for good reason. We want secure protocols that use modern, best-practice secruity mechanisms. However, sometimes getting from today to that state of best-practice security mechanism is non-trivial, and will take standard and implementation work. We are learning over time that (1) documenting security gaps, combined with (2) a clear path to addressing gaps, and (3) work in progress to addressing gaps goes a long way to making less-than-best-security-practice specifications more acceptable.=20 =09 I.e. The charter change I propose is geared toward helping Oauth see the light of day more quickly, and have an incremental path toward best-practice security. =09 Let me know what you think, Gregorry. =09 =09 =09 =09 =09 From hannes.tschofenig@nsn.com Tue Feb 17 00:47: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 A5D5D3A68BB for ; Tue, 17 Feb 2009 00:47:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.799 X-Spam-Level: X-Spam-Status: No, score=-3.799 tagged_above=-999 required=5 tests=[AWL=-1.200, 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 zZb+qrDtApcl for ; Tue, 17 Feb 2009 00:47:25 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 736033A68B2 for ; Tue, 17 Feb 2009 00:47:25 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n1H8lUbO004352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 17 Feb 2009 09:47:30 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n1H8lTmK019673; Tue, 17 Feb 2009 09:47:30 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Feb 2009 09:47:29 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Feb 2009 10:48:23 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45010DB8E1@FIESEXC015.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [oauth] OAuth only for HTTP request signing? Thread-Index: AcmH2f1RJWanljK4SmWwDxZK4TdK2AAAdAMHAj/5YvA= References: From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Eran Hammer-Lahav" , "Onyx Raven" , "John Kemp" X-OriginalArrivalTime: 17 Feb 2009 08:47:29.0205 (UTC) FILETIME=[5D76EE50:01C990DC] Cc: oauth@ietf.org Subject: Re: [oauth] OAuth only for HTTP request signing? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 08:47:26 -0000 I am happy to add text that says something like "The applicability of existing and new signature methods to protocols other than HTTP will be investigated." However, I am reluctant to extend the current charter text to potentially unknown protocols. Even new XMPP extensions regarding OAuth cannot be developed within this group.=20 I think that the statement above is the best we can do. If someone has the time and the energy to look at various other protocols where OAuth could be used with then I am sure the group would be happy about any feedback of potential problems, which can then be dealt with.=20 Ciao Hannes ________________________________ From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of ext Eran Hammer-Lahav Sent: 05 February, 2009 23:51 To: Onyx Raven; John Kemp Cc: oauth@ietf.org Subject: Re: [oauth] OAuth only for HTTP request signing? =09 =09 The fact the signature base string today is compatible with XMPP (but taking a liberal view of the workflow), is mostly luck. It just happened that a solution that was optimized for HTTP seems to work well for XMPP with some clarifications. =09 It is very likely that we will be defining a new signature method. If non-HTTP considerations will make it any more complex than it has to be, I will find it problematic. If it doesn't, great. I am happy to allow the charter to "review the applicability of existing and new signature methods to protocols other than HTTP", but that is where I think we should draw a line. =09 The charter should allow a signature method that does not support XMPP, if it makes HTTP better. In other words, I am against putting any other protocol at equal consideration as HTTP. =09 EHL =09 =09 On 2/5/09 1:37 PM, "Onyx Raven" wrote: =09 =09 So, thats what I was trying to get at. I agree that the excepted token consumer-request -> sp-auth -> consumer-access process should be HTTP based as it is defined now. It was really more about the consumer -> sp request signing (with delegated access), which like below, could be XMPP, IRC, proprietary game protocols, etc. At a basic level, signature signing is defined as METHOD&RESOURCE&PARAMETERS (where parameters are key/value pairs structured in www-form-urlencoded style). =09 But like I said before, as long as the core standard has acceptable wording for other consumer -> sp request protocols to hook into, thats what matters there. I just wanted to be sure we didn't get locked into something we might want alternatives to in the future. =09 On Thu, Feb 5, 2009 at 2:21 PM, John Kemp wrote: > On Feb 5, 2009, at 3:52 PM, Seth Fitzsimmons wrote: > >> >> XMPP (XEP-0235) assumes that tokens are exchanged out of band, leaving >> that mechanism in HTTP. > > Right. The point being that there are at least two potentially-independent > parts to OAuth - a set of signature mechanisms (RSA-SHA1, HMAC-SHA1, > PLAINTEXT), and an HTTP-based protocol for token exchange. > > [...] > >> >> To me, the most useful aspect of OAuth when applied to other protocols >> is a clearly defined way to generate signatures given constituent >> components. > > I think it's certainly reasonable to suggest that the signature mechanisms > be defined so as to be useful in contexts other than HTTP. Which apparently > already worked well-enough for XMPP with OAuth 1.0. > > - johnk > =09 =09 From hannes.tschofenig@nsn.com Tue Feb 17 00:53:58 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62CF43A6BEB for ; Tue, 17 Feb 2009 00:53:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.69 X-Spam-Level: X-Spam-Status: No, score=-3.69 tagged_above=-999 required=5 tests=[AWL=-1.091, 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 HkycrDipeG2b for ; Tue, 17 Feb 2009 00:53:57 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 2A7C93A6B91 for ; Tue, 17 Feb 2009 00:53:56 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n1H8s5Gi022526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 17 Feb 2009 09:54:06 +0100 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n1H8s4JK021848 for ; Tue, 17 Feb 2009 09:54:05 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Feb 2009 09:54:04 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Feb 2009 10:54:59 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45010DB8F0@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last Call for Comments: OAuth Charter Text Thread-Index: AcmQ3WoAZgwvy53AT+C/dYe/RSZZuw== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 17 Feb 2009 08:54:04.0824 (UTC) FILETIME=[49459980:01C990DD] Subject: [oauth] Last Call for Comments: OAuth Charter Text X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 08:53:58 -0000 Hi all,=20 we have now discussed the charter text for some time and we got good feedback. I have tried to reflect it in an appropriate way.=20 I think it is about time to finish this part of the story. Please review the current charter text and make a judgement whether we can move forward with it.=20 Ciao Hannes ------------------------------------------------------------------------ ------------- Open Authentication Protocol (oauth) Last Modified: 2009-01-30 Chair(s): TBD Applications Area Director(s): Chris Newman Lisa Dusseault =20 Applications Area Advisor: TBD Mailing Lists: https://www.ietf.org/mailman/listinfo/oauth Description of Working Group: OAuth allows a user to grant a third-party Web site or application access to their resources, without revealing their credentials, or even their identity. For example, a photo-sharing site that supports OAuth would allow its users to use a third-party printing Web site to access their private pictures, without gaining full control of the user account. OAuth consists of: * A mechanism for exchanging a user's credentials for a token-secret pair that can be used by a third party to access resources on their behalf. * A mechanism for signing HTTP requests with the token-secret pair. The Working Group will produce one or more documents suitable for consideration as Proposed Standard, based upon the OAuth I-D, that will: * Align OAuth with the Internet and Web architectures, best practices and terminology. * Assure good security practice, or document gaps in its capabilities, and propose a path forward for addressing the gap. * Promote interoperability. * Provide guidelines for extensibility. This specifically means that as a starting point for the working group the OAuth 1.0 specification is used and the available extension points are going to be utilized. It seems desireable to profile OAuth 1.0 in a way that produces a specification that is a backwards compatible profile, i.e. an OAuth 1.0 implementation and the specification produced by this group must support a basic set of features to guarantee interoperability.=20 Furthermore, OAuth 1.0 defines three signature methods used to protect requests, namely PLAINTEXT, HMAC-SHA1, and RSA-SHA1. The group will work on new signature methods and will describe the environments where new security requirements justify their usage. Existing signature methods will not be modified but may be dropped as part of the backwards compatible profiling activity. The applicability of existing and new signature methods to protocols other than HTTP will be investigated. In doing so, it should consider: * Implementer experience. * Existing uses of OAuth. * Ability to achieve broad impementation. * Ability to address broader use cases than may be contemplated by the original authors. * Impact on the Internet and Web. The Working Group is not tasked with defining a generally applicable HTTP Authentication mechanism (i.e., browser-based "2-leg" scenerio), and should consider this work out of scope in its discussions. However, if the deliverables are able to be factored in such a way that this is a byproduct, or such a scenario could be addressed by additional future work, the Working Group may choose to do so. After delivering OAuth, the Working Group may consider defining additional functions and/or extensions, for example (but not limited to): * Discovery of authentication configuration. * Message integrity. * Recommendations regarding the structure of the token. Goals and Milestones: Apr 2009 Submit 'OAuth: HTTP Authorization Delegation Protocol' as working group item (draft-hammer-oauth will be used as a starting point for further work.) Sep 2009 Start Working Group Last Call on 'OAuth: HTTP Authorization Delegation Protocol' Sep 2009 Discusion about OAUTH extensions the group should work on Nov 2009 Submit 'OAuth: HTTP Authorization Delegation Protocol' to the IESG for consideration as a Proposed Standard=20 Nov 2009 Prepare milestone update to start new work within the scope of the charter From hannes.tschofenig@nsn.com Tue Feb 17 01:34: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 784B23A68A7 for ; Tue, 17 Feb 2009 01:34:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-1.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 xRQloCdspu3j for ; Tue, 17 Feb 2009 01:34:14 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id DCA7B3A69AD for ; Tue, 17 Feb 2009 01:34:13 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n1H9YNWM002975 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 17 Feb 2009 10:34:23 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n1H9YMVc022903 for ; Tue, 17 Feb 2009 10:34:23 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Feb 2009 10:34:22 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Feb 2009 11:35:17 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45010DB968@FIESEXC015.nsn-intra.net> In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B45010DB8F0@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [oauth] Last Call for Comments: OAuth Charter Text Thread-Index: AcmQ3WoAZgwvy53AT+C/dYe/RSZZuwABToaw References: <3D3C75174CB95F42AD6BCC56E5555B45010DB8F0@FIESEXC015.nsn-intra.net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "Tschofenig, Hannes (NSN - FI/Espoo)" , X-OriginalArrivalTime: 17 Feb 2009 09:34:22.0173 (UTC) FILETIME=[EA1FC8D0:01C990E2] Subject: Re: [oauth] Last Call for Comments: OAuth Charter Text X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 09:34:15 -0000 Btw, I should also indicate a deadline for providing comments.=20 Please have your comments in no later than February 27th.=20 Thanks.=20 Ciao Hannes >-----Original Message----- >From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]=20 >On Behalf Of ext Tschofenig, Hannes (NSN - FI/Espoo) >Sent: 17 February, 2009 10:55 >To: oauth@ietf.org >Subject: [oauth] Last Call for Comments: OAuth Charter Text > >Hi all,=20 > >we have now discussed the charter text for some time and we=20 >got good feedback. I have tried to reflect it in an appropriate way.=20 > >I think it is about time to finish this part of the story.=20 >Please review the current charter text and make a judgement=20 >whether we can move forward with it.=20 > >Ciao >Hannes > >--------------------------------------------------------------- >--------- >------------- > >Open Authentication Protocol (oauth) > >Last Modified: 2009-01-30 > >Chair(s): > >TBD > >Applications Area Director(s): > >Chris Newman >Lisa Dusseault =20 > >Applications Area Advisor: > >TBD > >Mailing Lists: > >https://www.ietf.org/mailman/listinfo/oauth > >Description of Working Group: > >OAuth allows a user to grant a third-party Web site or=20 >application access to their resources, without revealing their=20 >credentials, or even their identity. For example, a=20 >photo-sharing site that supports OAuth would allow its users=20 >to use a third-party printing Web site to access their private=20 >pictures, without gaining full control of the user account. > >OAuth consists of: > * A mechanism for exchanging a user's credentials for a=20 >token-secret pair that can be used by a third party to access=20 >resources on their behalf. > * A mechanism for signing HTTP requests with the token-secret pair. > >The Working Group will produce one or more documents suitable=20 >for consideration as Proposed Standard, based upon the OAuth=20 >I-D, that will: > * Align OAuth with the Internet and Web architectures, best=20 >practices and terminology. > * Assure good security practice, or document gaps in its=20 >capabilities, and propose a path forward for addressing the gap. > * Promote interoperability. > * Provide guidelines for extensibility. > >This specifically means that as a starting point for the=20 >working group the OAuth 1.0 specification is used and the=20 >available extension points are going to be utilized. It seems=20 >desireable to profile OAuth 1.0 in a way that produces a=20 >specification that is a backwards compatible profile, i.e. an=20 >OAuth 1.0 implementation and the specification produced by=20 >this group must support a basic set of features to guarantee=20 >interoperability.=20 > >Furthermore, OAuth 1.0 defines three signature methods used to=20 >protect requests, namely PLAINTEXT, HMAC-SHA1, and RSA-SHA1.=20 >The group will work on new signature methods and will describe=20 >the environments where new security requirements justify their=20 >usage. Existing signature methods will not be modified but may=20 >be dropped as part of the backwards compatible profiling=20 >activity. The applicability of existing and new signature=20 >methods to protocols other than HTTP will be investigated. > >In doing so, it should consider: > * Implementer experience. > * Existing uses of OAuth. > * Ability to achieve broad impementation. > * Ability to address broader use cases than may be=20 >contemplated by the original authors. > * Impact on the Internet and Web. > >The Working Group is not tasked with defining a generally=20 >applicable HTTP Authentication mechanism (i.e., browser-based=20 >"2-leg" scenerio), and should consider this work out of scope=20 >in its discussions. However, if the deliverables are able to=20 >be factored in such a way that this is a byproduct, or such a=20 >scenario could be addressed by additional future work, the=20 >Working Group may choose to do so. > >After delivering OAuth, the Working Group may consider=20 >defining additional functions and/or extensions, for example=20 >(but not limited >to): > * Discovery of authentication configuration. > * Message integrity. > * Recommendations regarding the structure of the token. > >Goals and Milestones: > >Apr 2009 Submit 'OAuth: HTTP Authorization Delegation Protocol' as >working group item > (draft-hammer-oauth will be used as a starting=20 >point for further work.) >Sep 2009 Start Working Group Last Call on 'OAuth: HTTP Authorization >Delegation Protocol' >Sep 2009 Discusion about OAUTH extensions the group should work on >Nov 2009 Submit 'OAuth: HTTP Authorization Delegation Protocol' to >the IESG for consideration as a Proposed Standard=20 >Nov 2009 Prepare milestone update to start new work within the scope >of the charter >_______________________________________________ >oauth mailing list >oauth@ietf.org >https://www.ietf.org/mailman/listinfo/oauth > From stephen.farrell@cs.tcd.ie Tue Feb 17 08:11:45 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5298E3A69C7 for ; Tue, 17 Feb 2009 08:11:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, 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 trZ5NzIUlmXN for ; Tue, 17 Feb 2009 08:11:44 -0800 (PST) Received: from SG2EHSOBE006.bigfish.com (outbound-sin.frontbridge.com [207.46.51.80]) by core3.amsl.com (Postfix) with ESMTP id B17EC3A684E for ; Tue, 17 Feb 2009 08:11:43 -0800 (PST) Received: from mail228-sin-R.bigfish.com (10.3.40.3) by SG2EHSOBE006.bigfish.com (10.3.40.26) with Microsoft SMTP Server id 8.1.340.0; Tue, 17 Feb 2009 16:11:53 +0000 Received: from mail228-sin (localhost.localdomain [127.0.0.1]) by mail228-sin-R.bigfish.com (Postfix) with ESMTP id 74F9D16E0115; Tue, 17 Feb 2009 16:11:53 +0000 (UTC) X-BigFish: VPS-46(zz1432R98dR14ffO936eQ1805M936fMzzzz1033ILz2dh6bh87il61h) X-Spam-TCS-SCL: 0:0 X-FB-SS: 5, X-FB-DOMAIN-IP-MATCH: fail Received: by mail228-sin (MessageSwitch) id 1234887108755421_6074; Tue, 17 Feb 2009 16:11:48 +0000 (UCT) Received: from imx1.tcd.ie (imx1.tcd.ie [134.226.17.160]) by mail228-sin.bigfish.com (Postfix) with ESMTP id 011A21E006D; Tue, 17 Feb 2009 16:11:48 +0000 (UTC) Received: from Vams.imx1 (imx1.tcd.ie [134.226.17.160]) by imx1.tcd.ie (Postfix) with SMTP id AE20B48ED; Tue, 17 Feb 2009 16:11:46 +0000 (GMT) Received: from imx1.tcd.ie ([134.226.17.160]) by imx1 ([127.0.0.1]) with SMTP (gateway) id A05C37A0950; Tue, 17 Feb 2009 16:11:46 +0000 Received: from [134.226.62.18] (cswireless62-18.cs.tcd.ie [134.226.62.18]) by imx1.tcd.ie (Postfix) with ESMTP id 71C0948ED; Tue, 17 Feb 2009 16:11:46 +0000 (GMT) Message-ID: <499AE278.6050405@cs.tcd.ie> Date: Tue, 17 Feb 2009 16:14:48 +0000 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.16 (X11/20080707) MIME-Version: 1.0 To: "Tschofenig, Hannes (NSN - FI/Espoo)" References: <3D3C75174CB95F42AD6BCC56E5555B45010DB8F0@FIESEXC015.nsn-intra.net> In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B45010DB8F0@FIESEXC015.nsn-intra.net> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-AntiVirus-Status: MessageID = A15C37A0950 X-AntiVirus-Status: Host: imx1.tcd.ie X-AntiVirus-Status: Action Taken: X-AntiVirus-Status: NONE X-AntiVirus-Status: Checked by TCD Vexira. (version=1.60.2 VDF=10.101.14) Cc: oauth@ietf.org Subject: Re: [oauth] Last Call for Comments: OAuth Charter Text X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 16:11:45 -0000 I made some comments before [1] that don't seem to have been included here - was that deliberate or did they get missed? S. [1] http://www.ietf.org/mail-archive/web/oauth/current/msg00061.html Tschofenig, Hannes (NSN - FI/Espoo) wrote: > Hi all, > > we have now discussed the charter text for some time and we got good > feedback. I have tried to reflect it in an appropriate way. > > I think it is about time to finish this part of the story. Please review > the current charter text and make a judgement whether we can move > forward with it. > > Ciao > Hannes > > ------------------------------------------------------------------------ > ------------- > > Open Authentication Protocol (oauth) > > Last Modified: 2009-01-30 > > Chair(s): > > TBD > > Applications Area Director(s): > > Chris Newman > Lisa Dusseault > > Applications Area Advisor: > > TBD > > Mailing Lists: > > https://www.ietf.org/mailman/listinfo/oauth > > Description of Working Group: > > OAuth allows a user to grant a third-party Web site or application > access to their resources, without revealing their credentials, or even > their identity. For example, a photo-sharing site that supports OAuth > would allow its users to use a third-party printing Web site to access > their private pictures, without gaining full control of the user > account. > > OAuth consists of: > * A mechanism for exchanging a user's credentials for a token-secret > pair that can be used by a third party to access resources on their > behalf. > * A mechanism for signing HTTP requests with the token-secret pair. > > The Working Group will produce one or more documents suitable for > consideration as Proposed Standard, based upon the OAuth I-D, that will: > * Align OAuth with the Internet and Web architectures, best practices > and terminology. > * Assure good security practice, or document gaps in its capabilities, > and propose a path forward for addressing the gap. > * Promote interoperability. > * Provide guidelines for extensibility. > > This specifically means that as a starting point for the working group > the OAuth 1.0 specification is used and the available extension points > are going to be utilized. It seems desireable to profile OAuth 1.0 in a > way that produces a specification that is a backwards compatible > profile, i.e. an OAuth 1.0 implementation and the specification produced > by this group must support a basic set of features to guarantee > interoperability. > > Furthermore, OAuth 1.0 defines three signature methods used to protect > requests, namely PLAINTEXT, HMAC-SHA1, and RSA-SHA1. The group will work > on new signature methods and will describe the environments where new > security requirements justify their usage. Existing signature methods > will not be modified but may be dropped as part of the backwards > compatible profiling activity. The applicability of existing and new > signature methods to protocols other than HTTP will be investigated. > > In doing so, it should consider: > * Implementer experience. > * Existing uses of OAuth. > * Ability to achieve broad impementation. > * Ability to address broader use cases than may be contemplated by the > original authors. > * Impact on the Internet and Web. > > The Working Group is not tasked with defining a generally applicable > HTTP Authentication mechanism (i.e., browser-based "2-leg" scenerio), > and should consider this work out of scope in its discussions. However, > if the deliverables are able to be factored in such a way that this is a > byproduct, or such a scenario could be addressed by additional future > work, the Working Group may choose to do so. > > After delivering OAuth, the Working Group may consider defining > additional functions and/or extensions, for example (but not limited > to): > * Discovery of authentication configuration. > * Message integrity. > * Recommendations regarding the structure of the token. > > Goals and Milestones: > > Apr 2009 Submit 'OAuth: HTTP Authorization Delegation Protocol' as > working group item > (draft-hammer-oauth will be used as a starting point for > further work.) > Sep 2009 Start Working Group Last Call on 'OAuth: HTTP Authorization > Delegation Protocol' > Sep 2009 Discusion about OAUTH extensions the group should work on > Nov 2009 Submit 'OAuth: HTTP Authorization Delegation Protocol' to > the IESG for consideration as a Proposed Standard > Nov 2009 Prepare milestone update to start new work within the scope > of the charter > _______________________________________________ > oauth mailing list > oauth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From stephen.farrell@cs.tcd.ie Tue Feb 17 08:11: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 2A6B73A6CAC for ; Tue, 17 Feb 2009 08:11:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-1.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 xcwSsgSJO9Ye for ; Tue, 17 Feb 2009 08:11:47 -0800 (PST) Received: from WA4EHSOBE002.bigfish.com (wa4ehsobe002.messaging.microsoft.com [216.32.181.12]) by core3.amsl.com (Postfix) with ESMTP id 8FCBC3A6CAA for ; Tue, 17 Feb 2009 08:11:47 -0800 (PST) Received: from mail155-wa4-R.bigfish.com (10.8.14.240) by WA4EHSOBE002.bigfish.com (10.8.40.22) with Microsoft SMTP Server id 8.1.340.0; Tue, 17 Feb 2009 16:11:59 +0000 Received: from mail155-wa4 (localhost.localdomain [127.0.0.1]) by mail155-wa4-R.bigfish.com (Postfix) with ESMTP id 7BA5F97823A; Tue, 17 Feb 2009 16:11:58 +0000 (UTC) X-BigFish: VPS0(zz98dR617Rzzzzz2dh6bh87il61h) X-Spam-TCS-SCL: 0:0 X-FB-SS: 5, X-FB-DOMAIN-IP-MATCH: fail Received: by mail155-wa4 (MessageSwitch) id 1234887115341212_13376; Tue, 17 Feb 2009 16:11:55 +0000 (UCT) Received: from imx1.tcd.ie (wpad.iss.tcd.ie [134.226.17.160]) by mail155-wa4.bigfish.com (Postfix) with ESMTP id A390812C00B3; Tue, 17 Feb 2009 16:11:42 +0000 (UTC) Received: from Vams.imx1 (imx1.tcd.ie [134.226.17.160]) by imx1.tcd.ie (Postfix) with SMTP id 0CFD448ED; Tue, 17 Feb 2009 16:11:42 +0000 (GMT) Received: from imx1.tcd.ie ([134.226.17.160]) by imx1 ([127.0.0.1]) with SMTP (gateway) id A05C230894B; Tue, 17 Feb 2009 16:11:42 +0000 Received: from [134.226.62.18] (cswireless62-18.cs.tcd.ie [134.226.62.18]) by imx1.tcd.ie (Postfix) with ESMTP id 5639D48ED; Tue, 17 Feb 2009 16:11:41 +0000 (GMT) Message-ID: <499AE273.1010609@cs.tcd.ie> Date: Tue, 17 Feb 2009 16:14:43 +0000 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.16 (X11/20080707) MIME-Version: 1.0 To: Hannes Tschofenig References: <009e01c99070$11d33100$0201a8c0@nsnintra.net> In-Reply-To: <009e01c99070$11d33100$0201a8c0@nsnintra.net> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-AntiVirus-Status: MessageID = A15C230894B X-AntiVirus-Status: Host: imx1.tcd.ie X-AntiVirus-Status: Action Taken: X-AntiVirus-Status: NONE X-AntiVirus-Status: Checked by TCD Vexira. (version=1.60.2 VDF=10.101.14) Cc: oauth@ietf.org Subject: Re: [oauth] draft-dehora-farrell-oauth-accesstoken-creds-00.txt and OAUTH Extensions in the Charter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 16:11:50 -0000 Hannes Tschofenig wrote: > Stephen ask me how their document > draft-dehora-farrell-oauth-accesstoken-creds-00.txt is reflected in the > charter text. Actually, I sent a mail to you and Blaine off list. I guess we should now discuss it on the list, now that you've gone ahead here instead of responding to the off list mail. Also I didn't ask how "its reflected" I suggested a way to include it, which is quite different. My suggestion is to add the following: "The WG will develop an oauth extension suited for use on challenged devices and by aggregators that allows for the client to directly acquire an access token from a set of credentials. One such scheme is defined in draft-dehora-farrell-oauth-accesstoken-creds" I'd still like to see that included and will certainly suggest it again in SF, as I did in MSP, and without anyone (that I recall) disagreeing with considering the use case. > Independent of this particular document, I believe that we should focus our > initial efforts on the Base OAUTH specification rather than working on > extensions. Agreed. I never asked that our use case be worked before the spec work is done and have no idea how you formed that impression. > As such, I would say that (depending on the progress of the work > with the main specification) we should discuss extensions in the summer > timeframe. I think its fair enough to mention the AFAIK only proposed extension that's documented as an I-D in the charter. I don't read your current charter proposal as encompassing our draft without rechartering. > Regarding this specific extension: I read through > draft-dehora-farrell-oauth-accesstoken-creds-00.txt and wanted to make sure > that I understood the extension correctly. Here is a message flow that Jeff > created some time ago. This document suggests to skip the message exchanges > marked as (2.*). This means that the redirect from the Service Provider to > the Customer and the subsequent steps of user authentication and > authorization are replaced with the ability to carry some username/password > in the Access token when the Consumer sends the request to the Service > Provider. Right. > My personal view is that this goes a bit against the OAUTH idea. Unless the > username/password is again created using some other mechanism (which the > document does not describe) then there are vulnerability that OAUTH was > initially meant to deal with. That's sort-of correct, however the point is that its necessary to deploy OAuth for existing mobile devices and some aggregation use cases. > Additionally, the result is less likely to be > easy to deploy. I think you're 100% wrong there...for the use cases we're considering. On what basis do you say that? Do you think that HTTP redirects on mobiles are just fine? > As a justification for the work the following argument is provided: "HTTP > redirection to a browser is unavailable or unsuitable, such as intermediary > aggregators and mobile or settop devices." I wonder whether this is really a > problem in today's mobile devices to justify this optimization. You can wonder, but it is. Stephen. From GFFletch@aol.com Tue Feb 17 09:19:58 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 448463A6B11 for ; Tue, 17 Feb 2009 09:19:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 AAtm+WEXQrIn for ; Tue, 17 Feb 2009 09:19:57 -0800 (PST) Received: from imo-m22.mail.aol.com (imo-m22.mx.aol.com [64.12.137.3]) by core3.amsl.com (Postfix) with ESMTP id 121C63A69C7 for ; Tue, 17 Feb 2009 09:19:56 -0800 (PST) Received: from GFFletch@aol.com by imo-m22.mx.aol.com (mail_out_v39.1.) id 2.d37.3e22e466 (37592); Tue, 17 Feb 2009 12:18:01 -0500 (EST) Received: from palantir.local ([10.181.74.97]) by cia-mb06.mx.aol.com (v123.3) with ESMTP id MAILCIAMB065-92d8499af1393a; Tue, 17 Feb 2009 12:17:45 -0500 Message-ID: <499AF139.3020706@aol.com> Date: Tue, 17 Feb 2009 12:17:45 -0500 From: George Fletcher Organization: AOL LLC User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: "Tschofenig, Hannes (NSN - FI/Espoo)" References: <3D3C75174CB95F42AD6BCC56E5555B45010DB8F0@FIESEXC015.nsn-intra.net> In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B45010DB8F0@FIESEXC015.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AOL-IP: 10.181.74.97 X-Mailer: Unknown (No Version) Cc: oauth@ietf.org Subject: Re: [oauth] Last Call for Comments: OAuth Charter Text X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 17:19:58 -0000 Just to clarify... does the following quote from the charter... "This specifically means that as a starting point for the working group the OAuth 1.0 specification is used and the available extension points are going to be utilized." .... mean that all extensions either checked in at oauth.pbwiki.com, the svn repository, or the draft-dehora-farrell-oauth-accesstoken-creds-00.txt that Stephen mentions will all be considered? Or will only certain extensions be considered for inclusion into the 1.0 version? Thanks, George Tschofenig, Hannes (NSN - FI/Espoo) wrote: > Hi all, > > we have now discussed the charter text for some time and we got good > feedback. I have tried to reflect it in an appropriate way. > > I think it is about time to finish this part of the story. Please review > the current charter text and make a judgement whether we can move > forward with it. > > Ciao > Hannes > > ------------------------------------------------------------------------ > ------------- > > Open Authentication Protocol (oauth) > > Last Modified: 2009-01-30 > > Chair(s): > > TBD > > Applications Area Director(s): > > Chris Newman > Lisa Dusseault > > Applications Area Advisor: > > TBD > > Mailing Lists: > > https://www.ietf.org/mailman/listinfo/oauth > > Description of Working Group: > > OAuth allows a user to grant a third-party Web site or application > access to their resources, without revealing their credentials, or even > their identity. For example, a photo-sharing site that supports OAuth > would allow its users to use a third-party printing Web site to access > their private pictures, without gaining full control of the user > account. > > OAuth consists of: > * A mechanism for exchanging a user's credentials for a token-secret > pair that can be used by a third party to access resources on their > behalf. > * A mechanism for signing HTTP requests with the token-secret pair. > > The Working Group will produce one or more documents suitable for > consideration as Proposed Standard, based upon the OAuth I-D, that will: > * Align OAuth with the Internet and Web architectures, best practices > and terminology. > * Assure good security practice, or document gaps in its capabilities, > and propose a path forward for addressing the gap. > * Promote interoperability. > * Provide guidelines for extensibility. > > This specifically means that as a starting point for the working group > the OAuth 1.0 specification is used and the available extension points > are going to be utilized. It seems desireable to profile OAuth 1.0 in a > way that produces a specification that is a backwards compatible > profile, i.e. an OAuth 1.0 implementation and the specification produced > by this group must support a basic set of features to guarantee > interoperability. > > Furthermore, OAuth 1.0 defines three signature methods used to protect > requests, namely PLAINTEXT, HMAC-SHA1, and RSA-SHA1. The group will work > on new signature methods and will describe the environments where new > security requirements justify their usage. Existing signature methods > will not be modified but may be dropped as part of the backwards > compatible profiling activity. The applicability of existing and new > signature methods to protocols other than HTTP will be investigated. > > In doing so, it should consider: > * Implementer experience. > * Existing uses of OAuth. > * Ability to achieve broad impementation. > * Ability to address broader use cases than may be contemplated by the > original authors. > * Impact on the Internet and Web. > > The Working Group is not tasked with defining a generally applicable > HTTP Authentication mechanism (i.e., browser-based "2-leg" scenerio), > and should consider this work out of scope in its discussions. However, > if the deliverables are able to be factored in such a way that this is a > byproduct, or such a scenario could be addressed by additional future > work, the Working Group may choose to do so. > > After delivering OAuth, the Working Group may consider defining > additional functions and/or extensions, for example (but not limited > to): > * Discovery of authentication configuration. > * Message integrity. > * Recommendations regarding the structure of the token. > > Goals and Milestones: > > Apr 2009 Submit 'OAuth: HTTP Authorization Delegation Protocol' as > working group item > (draft-hammer-oauth will be used as a starting point for > further work.) > Sep 2009 Start Working Group Last Call on 'OAuth: HTTP Authorization > Delegation Protocol' > Sep 2009 Discusion about OAUTH extensions the group should work on > Nov 2009 Submit 'OAuth: HTTP Authorization Delegation Protocol' to > the IESG for consideration as a Proposed Standard > Nov 2009 Prepare milestone update to start new work within the scope > of the charter > _______________________________________________ > oauth mailing list > oauth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From eran@hueniverse.com Tue Feb 17 09:38: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 674503A6A67 for ; Tue, 17 Feb 2009 09:38:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kvOs+I01rPzh for ; Tue, 17 Feb 2009 09:38:32 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 21A4B3A6A0B for ; Tue, 17 Feb 2009 09:38:32 -0800 (PST) Received: (qmail 27373 invoked from network); 17 Feb 2009 17:38:42 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 17 Feb 2009 17:38:42 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Tue, 17 Feb 2009 10:38:42 -0700 From: Eran Hammer-Lahav To: George Fletcher , "Tschofenig, Hannes (NSN - FI/Espoo)" Date: Tue, 17 Feb 2009 10:38:40 -0700 Thread-Topic: [oauth] Last Call for Comments: OAuth Charter Text Thread-Index: AcmRI/3S6ORTrwkARNySJoGCdaGeFgAAnAwA Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234127C939E62@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <3D3C75174CB95F42AD6BCC56E5555B45010DB8F0@FIESEXC015.nsn-intra.net> <499AF139.3020706@aol.com> In-Reply-To: <499AF139.3020706@aol.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [oauth] Last Call for Comments: OAuth Charter Text X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 17:38:33 -0000 No. 'extension points' mean the spec allowing new signature methods, parame= ter methods, etc. The ways in which the spec allows it to be extended. Not = extension proposals. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of George Fletcher > Sent: Tuesday, February 17, 2009 9:18 AM > To: Tschofenig, Hannes (NSN - FI/Espoo) > Cc: oauth@ietf.org > Subject: Re: [oauth] Last Call for Comments: OAuth Charter Text > > Just to clarify... does the following quote from the charter... > > "This specifically means that as a starting point for the working group > the OAuth 1.0 specification is used and the available extension points > are going to be utilized." > > .... mean that all extensions either checked in at oauth.pbwiki.com, > the > svn repository, or the > draft-dehora-farrell-oauth-accesstoken-creds-00.txt that Stephen > mentions will all be considered? > > Or will only certain extensions be considered for inclusion into the > 1.0 > version? > > Thanks, > George > > Tschofenig, Hannes (NSN - FI/Espoo) wrote: > > Hi all, > > > > we have now discussed the charter text for some time and we got good > > feedback. I have tried to reflect it in an appropriate way. > > > > I think it is about time to finish this part of the story. Please > review > > the current charter text and make a judgement whether we can move > > forward with it. > > > > Ciao > > Hannes > > > > --------------------------------------------------------------------- > --- > > ------------- > > > > Open Authentication Protocol (oauth) > > > > Last Modified: 2009-01-30 > > > > Chair(s): > > > > TBD > > > > Applications Area Director(s): > > > > Chris Newman > > Lisa Dusseault > > > > Applications Area Advisor: > > > > TBD > > > > Mailing Lists: > > > > https://www.ietf.org/mailman/listinfo/oauth > > > > Description of Working Group: > > > > OAuth allows a user to grant a third-party Web site or application > > access to their resources, without revealing their credentials, or > even > > their identity. For example, a photo-sharing site that supports OAuth > > would allow its users to use a third-party printing Web site to > access > > their private pictures, without gaining full control of the user > > account. > > > > OAuth consists of: > > * A mechanism for exchanging a user's credentials for a token- > secret > > pair that can be used by a third party to access resources on their > > behalf. > > * A mechanism for signing HTTP requests with the token-secret pair. > > > > The Working Group will produce one or more documents suitable for > > consideration as Proposed Standard, based upon the OAuth I-D, that > will: > > * Align OAuth with the Internet and Web architectures, best > practices > > and terminology. > > * Assure good security practice, or document gaps in its > capabilities, > > and propose a path forward for addressing the gap. > > * Promote interoperability. > > * Provide guidelines for extensibility. > > > > This specifically means that as a starting point for the working > group > > the OAuth 1.0 specification is used and the available extension > points > > are going to be utilized. It seems desireable to profile OAuth 1.0 in > a > > way that produces a specification that is a backwards compatible > > profile, i.e. an OAuth 1.0 implementation and the specification > produced > > by this group must support a basic set of features to guarantee > > interoperability. > > > > Furthermore, OAuth 1.0 defines three signature methods used to > protect > > requests, namely PLAINTEXT, HMAC-SHA1, and RSA-SHA1. The group will > work > > on new signature methods and will describe the environments where new > > security requirements justify their usage. Existing signature methods > > will not be modified but may be dropped as part of the backwards > > compatible profiling activity. The applicability of existing and new > > signature methods to protocols other than HTTP will be investigated. > > > > In doing so, it should consider: > > * Implementer experience. > > * Existing uses of OAuth. > > * Ability to achieve broad impementation. > > * Ability to address broader use cases than may be contemplated by > the > > original authors. > > * Impact on the Internet and Web. > > > > The Working Group is not tasked with defining a generally applicable > > HTTP Authentication mechanism (i.e., browser-based "2-leg" scenerio), > > and should consider this work out of scope in its discussions. > However, > > if the deliverables are able to be factored in such a way that this > is a > > byproduct, or such a scenario could be addressed by additional future > > work, the Working Group may choose to do so. > > > > After delivering OAuth, the Working Group may consider defining > > additional functions and/or extensions, for example (but not limited > > to): > > * Discovery of authentication configuration. > > * Message integrity. > > * Recommendations regarding the structure of the token. > > > > Goals and Milestones: > > > > Apr 2009 Submit 'OAuth: HTTP Authorization Delegation Protocol' as > > working group item > > (draft-hammer-oauth will be used as a starting point for > > further work.) > > Sep 2009 Start Working Group Last Call on 'OAuth: HTTP > Authorization > > Delegation Protocol' > > Sep 2009 Discusion about OAUTH extensions the group should work on > > Nov 2009 Submit 'OAuth: HTTP Authorization Delegation Protocol' to > > the IESG for consideration as a Proposed Standard > > Nov 2009 Prepare milestone update to start new work within the > scope > > of the charter > > _______________________________________________ > > oauth mailing list > > oauth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > oauth mailing list > oauth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From GFFletch@aol.com Tue Feb 17 09:46: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 666FE3A693C for ; Tue, 17 Feb 2009 09:46:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NsOxyGrbk+9c for ; Tue, 17 Feb 2009 09:46:47 -0800 (PST) Received: from imo-d05.mx.aol.com (imo-d05.mx.aol.com [205.188.157.37]) by core3.amsl.com (Postfix) with ESMTP id 09C563A69C7 for ; Tue, 17 Feb 2009 09:46:46 -0800 (PST) Received: from GFFletch@aol.com by imo-d05.mx.aol.com (mail_out_v39.1.) id 7.cc7.4c451a72 (37180); Tue, 17 Feb 2009 12:46:22 -0500 (EST) Received: from palantir.local ([10.181.74.97]) by cia-ma05.mx.aol.com (v123.3) with ESMTP id MAILCIAMA053-913c499af7e3394; Tue, 17 Feb 2009 12:46:11 -0500 Message-ID: <499AF7E3.7040007@aol.com> Date: Tue, 17 Feb 2009 12:46:11 -0500 From: George Fletcher Organization: AOL LLC User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Eran Hammer-Lahav References: <3D3C75174CB95F42AD6BCC56E5555B45010DB8F0@FIESEXC015.nsn-intra.net> <499AF139.3020706@aol.com> <90C41DD21FB7C64BB94121FBBC2E7234127C939E62@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234127C939E62@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AOL-IP: 10.181.74.97 X-Mailer: Unknown (No Version) Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , "oauth@ietf.org" Subject: Re: [oauth] Last Call for Comments: OAuth Charter Text X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 17:46:48 -0000 So what is the plan for existing extensions written against OAuth 1.0 core? Will they be supported? or will they need to be re-written? Should the charter take into consideration the extensions that are already deployed? (e.g. Scalable OAuth?) Thanks, George Eran Hammer-Lahav wrote: > No. 'extension points' mean the spec allowing new signature methods, parameter methods, etc. The ways in which the spec allows it to be extended. Not extension proposals. > > EHL > > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of George Fletcher >> Sent: Tuesday, February 17, 2009 9:18 AM >> To: Tschofenig, Hannes (NSN - FI/Espoo) >> Cc: oauth@ietf.org >> Subject: Re: [oauth] Last Call for Comments: OAuth Charter Text >> >> Just to clarify... does the following quote from the charter... >> >> "This specifically means that as a starting point for the working group >> the OAuth 1.0 specification is used and the available extension points >> are going to be utilized." >> >> .... mean that all extensions either checked in at oauth.pbwiki.com, >> the >> svn repository, or the >> draft-dehora-farrell-oauth-accesstoken-creds-00.txt that Stephen >> mentions will all be considered? >> >> Or will only certain extensions be considered for inclusion into the >> 1.0 >> version? >> >> Thanks, >> George >> >> Tschofenig, Hannes (NSN - FI/Espoo) wrote: >> >>> Hi all, >>> >>> we have now discussed the charter text for some time and we got good >>> feedback. I have tried to reflect it in an appropriate way. >>> >>> I think it is about time to finish this part of the story. Please >>> >> review >> >>> the current charter text and make a judgement whether we can move >>> forward with it. >>> >>> Ciao >>> Hannes >>> >>> --------------------------------------------------------------------- >>> >> --- >> >>> ------------- >>> >>> Open Authentication Protocol (oauth) >>> >>> Last Modified: 2009-01-30 >>> >>> Chair(s): >>> >>> TBD >>> >>> Applications Area Director(s): >>> >>> Chris Newman >>> Lisa Dusseault >>> >>> Applications Area Advisor: >>> >>> TBD >>> >>> Mailing Lists: >>> >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> Description of Working Group: >>> >>> OAuth allows a user to grant a third-party Web site or application >>> access to their resources, without revealing their credentials, or >>> >> even >> >>> their identity. For example, a photo-sharing site that supports OAuth >>> would allow its users to use a third-party printing Web site to >>> >> access >> >>> their private pictures, without gaining full control of the user >>> account. >>> >>> OAuth consists of: >>> * A mechanism for exchanging a user's credentials for a token- >>> >> secret >> >>> pair that can be used by a third party to access resources on their >>> behalf. >>> * A mechanism for signing HTTP requests with the token-secret pair. >>> >>> The Working Group will produce one or more documents suitable for >>> consideration as Proposed Standard, based upon the OAuth I-D, that >>> >> will: >> >>> * Align OAuth with the Internet and Web architectures, best >>> >> practices >> >>> and terminology. >>> * Assure good security practice, or document gaps in its >>> >> capabilities, >> >>> and propose a path forward for addressing the gap. >>> * Promote interoperability. >>> * Provide guidelines for extensibility. >>> >>> This specifically means that as a starting point for the working >>> >> group >> >>> the OAuth 1.0 specification is used and the available extension >>> >> points >> >>> are going to be utilized. It seems desireable to profile OAuth 1.0 in >>> >> a >> >>> way that produces a specification that is a backwards compatible >>> profile, i.e. an OAuth 1.0 implementation and the specification >>> >> produced >> >>> by this group must support a basic set of features to guarantee >>> interoperability. >>> >>> Furthermore, OAuth 1.0 defines three signature methods used to >>> >> protect >> >>> requests, namely PLAINTEXT, HMAC-SHA1, and RSA-SHA1. The group will >>> >> work >> >>> on new signature methods and will describe the environments where new >>> security requirements justify their usage. Existing signature methods >>> will not be modified but may be dropped as part of the backwards >>> compatible profiling activity. The applicability of existing and new >>> signature methods to protocols other than HTTP will be investigated. >>> >>> In doing so, it should consider: >>> * Implementer experience. >>> * Existing uses of OAuth. >>> * Ability to achieve broad impementation. >>> * Ability to address broader use cases than may be contemplated by >>> >> the >> >>> original authors. >>> * Impact on the Internet and Web. >>> >>> The Working Group is not tasked with defining a generally applicable >>> HTTP Authentication mechanism (i.e., browser-based "2-leg" scenerio), >>> and should consider this work out of scope in its discussions. >>> >> However, >> >>> if the deliverables are able to be factored in such a way that this >>> >> is a >> >>> byproduct, or such a scenario could be addressed by additional future >>> work, the Working Group may choose to do so. >>> >>> After delivering OAuth, the Working Group may consider defining >>> additional functions and/or extensions, for example (but not limited >>> to): >>> * Discovery of authentication configuration. >>> * Message integrity. >>> * Recommendations regarding the structure of the token. >>> >>> Goals and Milestones: >>> >>> Apr 2009 Submit 'OAuth: HTTP Authorization Delegation Protocol' as >>> working group item >>> (draft-hammer-oauth will be used as a starting point for >>> further work.) >>> Sep 2009 Start Working Group Last Call on 'OAuth: HTTP >>> >> Authorization >> >>> Delegation Protocol' >>> Sep 2009 Discusion about OAUTH extensions the group should work on >>> Nov 2009 Submit 'OAuth: HTTP Authorization Delegation Protocol' to >>> the IESG for consideration as a Proposed Standard >>> Nov 2009 Prepare milestone update to start new work within the >>> >> scope >> >>> of the charter >>> _______________________________________________ >>> oauth mailing list >>> oauth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >> _______________________________________________ >> oauth mailing list >> oauth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > From eran@hueniverse.com Tue Feb 17 09:51: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 B2CAF3A69C7 for ; Tue, 17 Feb 2009 09:51:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gIXEaLXg5rtA for ; Tue, 17 Feb 2009 09:51:52 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 451763A67A4 for ; Tue, 17 Feb 2009 09:51:52 -0800 (PST) Received: (qmail 21555 invoked from network); 17 Feb 2009 17:51:58 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 17 Feb 2009 17:51:58 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 17 Feb 2009 10:51:57 -0700 From: Eran Hammer-Lahav To: George Fletcher Date: Tue, 17 Feb 2009 10:51:57 -0700 Thread-Topic: [oauth] Last Call for Comments: OAuth Charter Text Thread-Index: AcmRJ7pOAq8yd/1AT6yrSgmsgM+VLQAAEjiw Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234127C939E63@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <3D3C75174CB95F42AD6BCC56E5555B45010DB8F0@FIESEXC015.nsn-intra.net> <499AF139.3020706@aol.com> <90C41DD21FB7C64BB94121FBBC2E7234127C939E62@P3PW5EX1MB01.EX1.SECURESERVER.NET> <499AF7E3.7040007@aol.com> In-Reply-To: <499AF7E3.7040007@aol.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , "oauth@ietf.org" Subject: Re: [oauth] Last Call for Comments: OAuth Charter Text X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 17:51:53 -0000 None of the extensions have been declared final. I expect the problem repor= ting to be incorporated (or replaced with something similar). Since this ne= w work is likely to break some things, it would be better to first get it d= one and then consider its impact on deployed extensions. There is nothing i= n the charter that will prevent us from re-chartering the wg to do more wor= k when this is done. But for now we should be focused on getting the core p= rotocol into a standard status. EHL > -----Original Message----- > From: George Fletcher [mailto:gffletch@aol.com] > Sent: Tuesday, February 17, 2009 9:46 AM > To: Eran Hammer-Lahav > Cc: Tschofenig, Hannes (NSN - FI/Espoo); oauth@ietf.org > Subject: Re: [oauth] Last Call for Comments: OAuth Charter Text > > So what is the plan for existing extensions written against OAuth 1.0 > core? Will they be supported? or will they need to be re-written? > Should > the charter take into consideration the extensions that are already > deployed? (e.g. Scalable OAuth?) > > Thanks, > George > > Eran Hammer-Lahav wrote: > > No. 'extension points' mean the spec allowing new signature methods, > parameter methods, etc. The ways in which the spec allows it to be > extended. Not extension proposals. > > > > EHL > > > > > >> -----Original Message----- > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > Behalf > >> Of George Fletcher > >> Sent: Tuesday, February 17, 2009 9:18 AM > >> To: Tschofenig, Hannes (NSN - FI/Espoo) > >> Cc: oauth@ietf.org > >> Subject: Re: [oauth] Last Call for Comments: OAuth Charter Text > >> > >> Just to clarify... does the following quote from the charter... > >> > >> "This specifically means that as a starting point for the working > group > >> the OAuth 1.0 specification is used and the available extension > points > >> are going to be utilized." > >> > >> .... mean that all extensions either checked in at oauth.pbwiki.com, > >> the > >> svn repository, or the > >> draft-dehora-farrell-oauth-accesstoken-creds-00.txt that Stephen > >> mentions will all be considered? > >> > >> Or will only certain extensions be considered for inclusion into the > >> 1.0 > >> version? > >> > >> Thanks, > >> George > >> > >> Tschofenig, Hannes (NSN - FI/Espoo) wrote: > >> > >>> Hi all, > >>> > >>> we have now discussed the charter text for some time and we got > good > >>> feedback. I have tried to reflect it in an appropriate way. > >>> > >>> I think it is about time to finish this part of the story. Please > >>> > >> review > >> > >>> the current charter text and make a judgement whether we can move > >>> forward with it. > >>> > >>> Ciao > >>> Hannes > >>> > >>> ------------------------------------------------------------------- > -- > >>> > >> --- > >> > >>> ------------- > >>> > >>> Open Authentication Protocol (oauth) > >>> > >>> Last Modified: 2009-01-30 > >>> > >>> Chair(s): > >>> > >>> TBD > >>> > >>> Applications Area Director(s): > >>> > >>> Chris Newman > >>> Lisa Dusseault > >>> > >>> Applications Area Advisor: > >>> > >>> TBD > >>> > >>> Mailing Lists: > >>> > >>> https://www.ietf.org/mailman/listinfo/oauth > >>> > >>> Description of Working Group: > >>> > >>> OAuth allows a user to grant a third-party Web site or application > >>> access to their resources, without revealing their credentials, or > >>> > >> even > >> > >>> their identity. For example, a photo-sharing site that supports > OAuth > >>> would allow its users to use a third-party printing Web site to > >>> > >> access > >> > >>> their private pictures, without gaining full control of the user > >>> account. > >>> > >>> OAuth consists of: > >>> * A mechanism for exchanging a user's credentials for a token- > >>> > >> secret > >> > >>> pair that can be used by a third party to access resources on their > >>> behalf. > >>> * A mechanism for signing HTTP requests with the token-secret > pair. > >>> > >>> The Working Group will produce one or more documents suitable for > >>> consideration as Proposed Standard, based upon the OAuth I-D, that > >>> > >> will: > >> > >>> * Align OAuth with the Internet and Web architectures, best > >>> > >> practices > >> > >>> and terminology. > >>> * Assure good security practice, or document gaps in its > >>> > >> capabilities, > >> > >>> and propose a path forward for addressing the gap. > >>> * Promote interoperability. > >>> * Provide guidelines for extensibility. > >>> > >>> This specifically means that as a starting point for the working > >>> > >> group > >> > >>> the OAuth 1.0 specification is used and the available extension > >>> > >> points > >> > >>> are going to be utilized. It seems desireable to profile OAuth 1.0 > in > >>> > >> a > >> > >>> way that produces a specification that is a backwards compatible > >>> profile, i.e. an OAuth 1.0 implementation and the specification > >>> > >> produced > >> > >>> by this group must support a basic set of features to guarantee > >>> interoperability. > >>> > >>> Furthermore, OAuth 1.0 defines three signature methods used to > >>> > >> protect > >> > >>> requests, namely PLAINTEXT, HMAC-SHA1, and RSA-SHA1. The group will > >>> > >> work > >> > >>> on new signature methods and will describe the environments where > new > >>> security requirements justify their usage. Existing signature > methods > >>> will not be modified but may be dropped as part of the backwards > >>> compatible profiling activity. The applicability of existing and > new > >>> signature methods to protocols other than HTTP will be > investigated. > >>> > >>> In doing so, it should consider: > >>> * Implementer experience. > >>> * Existing uses of OAuth. > >>> * Ability to achieve broad impementation. > >>> * Ability to address broader use cases than may be contemplated > by > >>> > >> the > >> > >>> original authors. > >>> * Impact on the Internet and Web. > >>> > >>> The Working Group is not tasked with defining a generally > applicable > >>> HTTP Authentication mechanism (i.e., browser-based "2-leg" > scenerio), > >>> and should consider this work out of scope in its discussions. > >>> > >> However, > >> > >>> if the deliverables are able to be factored in such a way that this > >>> > >> is a > >> > >>> byproduct, or such a scenario could be addressed by additional > future > >>> work, the Working Group may choose to do so. > >>> > >>> After delivering OAuth, the Working Group may consider defining > >>> additional functions and/or extensions, for example (but not > limited > >>> to): > >>> * Discovery of authentication configuration. > >>> * Message integrity. > >>> * Recommendations regarding the structure of the token. > >>> > >>> Goals and Milestones: > >>> > >>> Apr 2009 Submit 'OAuth: HTTP Authorization Delegation Protocol' > as > >>> working group item > >>> (draft-hammer-oauth will be used as a starting point > for > >>> further work.) > >>> Sep 2009 Start Working Group Last Call on 'OAuth: HTTP > >>> > >> Authorization > >> > >>> Delegation Protocol' > >>> Sep 2009 Discusion about OAUTH extensions the group should work > on > >>> Nov 2009 Submit 'OAuth: HTTP Authorization Delegation Protocol' > to > >>> the IESG for consideration as a Proposed Standard > >>> Nov 2009 Prepare milestone update to start new work within the > >>> > >> scope > >> > >>> of the charter > >>> _______________________________________________ > >>> oauth mailing 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 aaron@serendipity.cx Tue Feb 17 11:12:55 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1306D3A6B83 for ; Tue, 17 Feb 2009 11:12:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9aYh679ss4A for ; Tue, 17 Feb 2009 11:12:54 -0800 (PST) Received: from mail.serendipity.cx (serendipity.palo-alto.ca.us [66.92.2.87]) by core3.amsl.com (Postfix) with ESMTP id 1E4653A6B38 for ; Tue, 17 Feb 2009 11:12:54 -0800 (PST) Received: from serendipity.cx (unknown [10.10.10.34]) by mail.serendipity.cx (Postfix) with ESMTP id E55832936; Tue, 17 Feb 2009 11:18:52 -0800 (PST) MIME-Version: 1.0 Date: Tue, 17 Feb 2009 11:17:50 -0800 From: Aaron Stone To: "Tschofenig, Hannes (NSN - FI/Espoo)" In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B45010DB968@FIESEXC015.nsn-intra.net> References: <3D3C75174CB95F42AD6BCC56E5555B45010DB8F0@FIESEXC015.nsn-intra.net> <3D3C75174CB95F42AD6BCC56E5555B45010DB968@FIESEXC015.nsn-intra.net> Message-ID: <30e8c781d5bc33846cf3f69ff4478632@serendipity.cx> X-Sender: aaron@serendipity.cx User-Agent: RoundCube Webmail/0.2 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="UTF-8" Cc: oauth@ietf.org Subject: Re: [oauth] Last Call for Comments: OAuth Charter Text X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 19:12:55 -0000 Hi Hannes and WG, The middle paragraphs are pretty choppy and unclear to me. I think I get what's going on well enough not to complain (that is, "The Charter Looks Good Enough To Me (TM)"), but below are some suggested changes to clarify. Cheers, Aaron On Tue, 17 Feb 2009 11:35:17 +0200, "Tschofenig, Hannes (NSN - FI/Espoo)" wrote: > Btw, I should also indicate a deadline for providing comments. > > Please have your comments in no later than February 27th. > > Thanks. [snip] >>OAuth consists of: >> * A mechanism for exchanging a user's credentials for a >>token-secret pair that can be used by a third party to access >>resources on their behalf. >> * A mechanism for signing HTTP requests with the token-secret pair. >> >>The Working Group will produce one or more documents suitable >>for consideration as Proposed Standard, based upon the OAuth >>I-D, that will: Here we start with the OAuth I-D... Suggested replacement text: "The Working Group will produce one or more documents suitable for consideration as Proposed Standard. The Working Group will begin with the independently published OAuth 1.0 specification, and will:" >> * Align OAuth with the Internet and Web architectures, best >>practices and terminology. >> * Assure good security practice, or document gaps in its >>capabilities, and propose a path forward for addressing the gap. >> * Promote interoperability. >> * Provide guidelines for extensibility. >> >>This specifically means that as a starting point for the >>working group the OAuth 1.0 specification is used and the >>available extension points are going to be utilized. It seems What are "available extension points" ? >>desireable to profile OAuth 1.0 in a way that produces a >>specification that is a backwards compatible profile, i.e. an >>OAuth 1.0 implementation and the specification produced by >>this group must support a basic set of features to guarantee >>interoperability. ...here we talk about OAuth 1.0. What's the difference from the OAuth I-D in the previous paragraph? Suggested replacement paragraph: "As best as possible, the Working Group will produce a specification that is a backwards compatible profile of OAuth 1.0, i.e. an OAuth 1.0 implementation and the specification(s) produced by this group will support a basic set of features to assure interoperability. The Working Group will also consider existing OAuth 1.0 extensions for interoperability with the updated specification(s)." >>Furthermore, OAuth 1.0 defines three signature methods used to >>protect requests, namely PLAINTEXT, HMAC-SHA1, and RSA-SHA1. >>The group will work on new signature methods and will describe >>the environments where new security requirements justify their >>usage. Existing signature methods will not be modified but may >>be dropped as part of the backwards compatible profiling >>activity. The applicability of existing and new signature >>methods to protocols other than HTTP will be investigated. >> >>In doing so, it should consider: s/ it / the Working Group / For me, "In doing so" refers to signature methods and applicability of signature methods to protocols other than HTTP. Is that correct? If not, let's replace "In doing so" with what we'd be so doing ;) >> * Implementer experience. >> * Existing uses of OAuth. >> * Ability to achieve broad impementation. >> * Ability to address broader use cases than may be >>contemplated by the original authors. >> * Impact on the Internet and Web. >> [cut] From john@jkemp.net Tue Feb 17 11:22: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 A89C228C131 for ; Tue, 17 Feb 2009 11:22:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sDitkAx8w+rv for ; Tue, 17 Feb 2009 11:22:05 -0800 (PST) Received: from outbound-mail-03.bluehost.com (outbound-mail-03.bluehost.com [69.89.21.13]) by core3.amsl.com (Postfix) with SMTP id CDC3928C12E for ; Tue, 17 Feb 2009 11:22:05 -0800 (PST) Received: (qmail 5064 invoked by uid 0); 17 Feb 2009 19:21:13 -0000 Received: from unknown (HELO box320.bluehost.com) (69.89.31.120) by outboundproxy1.bluehost.com with SMTP; 17 Feb 2009 19:21:13 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=jkemp.net; h=Received:Message-Id:From:To:In-Reply-To:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:References:X-Mailer:X-Identified-User; b=hvAG4sDJzZR1vjU4VyYL22CyYyJ/6A+awmhxqotkQViFiG8VrHYWWGCO6Nxs9f7AurUI906xWZNczdcVGiR3vbJ16yKP8d1mrdtkIIUAo2XAdxunFiIN3dv+mJVW6u1e; Received: from cpe-69-205-56-47.nycap.res.rr.com ([69.205.56.47] helo=mztrcscn117.americas.nokia.com) by box320.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1LZVWK-0003x5-35 for oauth@ietf.org; Tue, 17 Feb 2009 12:22:16 -0700 Message-Id: <29A1D181-4EAF-435D-A5CE-CB67A5152DC2@jkemp.net> From: John Kemp To: oauth@ietf.org In-Reply-To: <499AE273.1010609@cs.tcd.ie> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 17 Feb 2009 14:22:14 -0500 References: <009e01c99070$11d33100$0201a8c0@nsnintra.net> <499AE273.1010609@cs.tcd.ie> X-Mailer: Apple Mail (2.930.3) X-Identified-User: {1122:box320.bluehost.com:jkempnet:jkemp.net} {sentby:smtp auth 69.205.56.47 authed with john+jkemp.net} Subject: Re: [oauth] draft-dehora-farrell-oauth-accesstoken-creds-00.txt and OAUTH Extensions in the Charter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 19:22:06 -0000 On Feb 17, 2009, at 11:14 AM, Stephen Farrell wrote: > My suggestion is to add the following: > > "The WG will develop an oauth extension suited for use > on challenged devices and by aggregators that allows for > the client to directly acquire an access token from > a set of credentials. One such scheme is defined in > draft-dehora-farrell-oauth-accesstoken-creds" > > I'd still like to see that included and will certainly > suggest it again in SF, as I did in MSP, and without > anyone (that I recall) disagreeing with considering > the use case. Personally I am in favour of working on such an extension, and if we need to update the charter to allow it, then I second Stephen's suggestion that we do so. . > >> Independent of this particular document, I believe that we should >> focus our >> initial efforts on the Base OAUTH specification rather than working >> on >> extensions. > > Agreed. I never asked that our use case be worked before > the spec work is done and have no idea how you formed that > impression. > >> As such, I would say that (depending on the progress of the work >> with the main specification) we should discuss extensions in the >> summer >> timeframe. > > I think its fair enough to mention the AFAIK only proposed extension > that's documented as an I-D in the charter. I don't read your current > charter proposal as encompassing our draft without rechartering. From the charter text in [1] > "After delivering OAuth, the Working Group may consider defining > additional functions and/or extensions, for example (but not limited > to): > * Discovery of authentication configuration. > * Message integrity. > * Recommendations regarding the structure of the token." Perhaps we might add this proposal to that list explicitly? Furthermore, is there a currently-known reason why we would wait to work on extensions until the OAuth specification itself is delivered, provided that there is the will and concrete support to create extensions? There are several OAuth extensions already in use (language preference and problem reporting, to name a couple) and I would expect that since they are already in use by some, those people might wish also to revise them in light of an IETF-approved OAuth. Should these also be added explicitly? > [...] > >> As a justification for the work the following argument is provided: >> "HTTP >> redirection to a browser is unavailable or unsuitable, such as >> intermediary >> aggregators and mobile or settop devices." I wonder whether this is >> really a >> problem in today's mobile devices to justify this optimization. > > You can wonder, but it is. I have to agree that multiple browser redirects in a mobile network are indeed still often a problem. - johnk [1] http://www.ietf.org/mail-archive/web/oauth/current/msg00085.html From Hannes.Tschofenig@gmx.net Tue Feb 17 12:11: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 6E5AE3A6882 for ; Tue, 17 Feb 2009 12:11:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.276 X-Spam-Level: X-Spam-Status: No, score=-2.276 tagged_above=-999 required=5 tests=[AWL=0.323, 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 avlCjC2YjNmA for ; Tue, 17 Feb 2009 12:11:20 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id D49B33A6C2A for ; Tue, 17 Feb 2009 12:11:19 -0800 (PST) Received: (qmail invoked by alias); 17 Feb 2009 20:11:29 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp065) with SMTP; 17 Feb 2009 21:11:29 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19nW3olRHtnw5po2brLemfzwzO4dROuBFZSC0pS1k bvVfv3o/zLIo/3 From: "Hannes Tschofenig" To: "'Stephen Farrell'" References: <009e01c99070$11d33100$0201a8c0@nsnintra.net> <499AE273.1010609@cs.tcd.ie> Date: Tue, 17 Feb 2009 22:12:29 +0200 Message-ID: <00ca01c9913c$1027aa30$0201a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcmRGnXm9uRbhr6fQRKNCai6yRdZ0QAICiEw In-Reply-To: <499AE273.1010609@cs.tcd.ie> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.58 Cc: oauth@ietf.org Subject: Re: [oauth] draft-dehora-farrell-oauth-accesstoken-creds-00.txt and OAUTH Extensions in the Charter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 20:11:21 -0000 Hi Stephen, adding the text as an example of possible extensions the group should work on is fine for me as we have already listed other possible extensions to the charter text. I got the impression that you wanted to have a milestone added already, which I believe would be premature given that the main focus of the initial work should be spent on the main spec. As I can read from your response you are agreeing with me on this issue. I still believe that the document needs to provide much more context about the usage scenarios you have in mind and what the implications regarding security area. The current version of the document is essentially only describing the bare minimum. Can you ship an update for the IETF#74 cutoff date? Ciao Hannes >Hannes Tschofenig wrote: >> Stephen ask me how their document >> draft-dehora-farrell-oauth-accesstoken-creds-00.txt is reflected in >> the charter text. > >Actually, I sent a mail to you and Blaine off list. I guess we >should now discuss it on the list, now that you've gone ahead >here instead of responding to the off list mail. > >Also I didn't ask how "its reflected" I suggested a way to >include it, which is quite different. > >My suggestion is to add the following: > >"The WG will develop an oauth extension suited for use on >challenged devices and by aggregators that allows for the >client to directly acquire an access token from a set of >credentials. One such scheme is defined in >draft-dehora-farrell-oauth-accesstoken-creds" > >I'd still like to see that included and will certainly suggest >it again in SF, as I did in MSP, and without anyone (that I >recall) disagreeing with considering the use case. > >> Independent of this particular document, I believe that we should >> focus our initial efforts on the Base OAUTH specification >rather than >> working on extensions. > >Agreed. I never asked that our use case be worked before the >spec work is done and have no idea how you formed that impression. > >> As such, I would say that (depending on the progress of the >work with >> the main specification) we should discuss extensions in the summer >> timeframe. > >I think its fair enough to mention the AFAIK only proposed >extension that's documented as an I-D in the charter. I don't >read your current charter proposal as encompassing our draft >without rechartering. > >> Regarding this specific extension: I read through >> draft-dehora-farrell-oauth-accesstoken-creds-00.txt and >wanted to make >> sure that I understood the extension correctly. Here is a >message flow >> that Jeff created some time ago. This document suggests to skip the >> message exchanges marked as (2.*). This means that the redirect from >> the Service Provider to the Customer and the subsequent >steps of user >> authentication and authorization are replaced with the ability to >> carry some username/password in the Access token when the Consumer >> sends the request to the Service Provider. > >Right. > >> My personal view is that this goes a bit against the OAUTH idea. >> Unless the username/password is again created using some other >> mechanism (which the document does not describe) then there are >> vulnerability that OAUTH was initially meant to deal with. > >That's sort-of correct, however the point is that its >necessary to deploy OAuth for existing mobile devices and some >aggregation use cases. > >> Additionally, the result is less likely to be easy to deploy. > >I think you're 100% wrong there...for the use cases we're >considering. On what basis do you say that? Do you think that >HTTP redirects on mobiles are just fine? > >> As a justification for the work the following argument is provided: >> "HTTP redirection to a browser is unavailable or unsuitable, such as >> intermediary aggregators and mobile or settop devices." I wonder >> whether this is really a problem in today's mobile devices >to justify this optimization. > >You can wonder, but it is. > >Stephen. > From Hannes.Tschofenig@gmx.net Tue Feb 17 12:33: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 870F33A69FF for ; Tue, 17 Feb 2009 12:33:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.291 X-Spam-Level: X-Spam-Status: No, score=-2.291 tagged_above=-999 required=5 tests=[AWL=0.308, 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 GBtDNld5fLsK for ; Tue, 17 Feb 2009 12:33:08 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 939123A6882 for ; Tue, 17 Feb 2009 12:33:03 -0800 (PST) Received: (qmail invoked by alias); 17 Feb 2009 20:03:55 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp071) with SMTP; 17 Feb 2009 21:03:55 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19q4IhKRtJq5LFru1dkDPnHBQntlHvpdDnZtRJoz2 Ngh/uN3YsGBgkd From: "Hannes Tschofenig" To: "'Stephen Farrell'" , "Tschofenig, Hannes \(NSN - FI/Espoo\)" References: <3D3C75174CB95F42AD6BCC56E5555B45010DB8F0@FIESEXC015.nsn-intra.net> <499AE278.6050405@cs.tcd.ie> Date: Tue, 17 Feb 2009 22:04:51 +0200 Message-ID: <00c901c9913b$056f0670$0201a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcmRGnhJIKg2ZYeFTFqTKpPsrKEE1AAIHBEw In-Reply-To: <499AE278.6050405@cs.tcd.ie> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.52 Cc: oauth@ietf.org Subject: Re: [oauth] Last Call for Comments: OAuth Charter Text X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 20:33:09 -0000 I missed them and I will incorporate them. Thanks for pointing me to them. Ciao Hannes >-----Original Message----- >From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] >On Behalf Of Stephen Farrell >Sent: 17 February, 2009 18:15 >To: Tschofenig, Hannes (NSN - FI/Espoo) >Cc: oauth@ietf.org >Subject: Re: [oauth] Last Call for Comments: OAuth Charter Text > > >I made some comments before [1] that don't seem to have been >included here - was that deliberate or did they get missed? > >S. > >[1] http://www.ietf.org/mail-archive/web/oauth/current/msg00061.html > >Tschofenig, Hannes (NSN - FI/Espoo) wrote: >> Hi all, >> >> we have now discussed the charter text for some time and we got good >> feedback. I have tried to reflect it in an appropriate way. >> >> I think it is about time to finish this part of the story. Please >> review the current charter text and make a judgement whether we can >> move forward with it. >> >> Ciao >> Hannes >> >> >---------------------------------------------------------------------- >> -- >> ------------- >> >> Open Authentication Protocol (oauth) >> >> Last Modified: 2009-01-30 >> >> Chair(s): >> >> TBD >> >> Applications Area Director(s): >> >> Chris Newman >> Lisa Dusseault >> >> Applications Area Advisor: >> >> TBD >> >> Mailing Lists: >> >> https://www.ietf.org/mailman/listinfo/oauth >> >> Description of Working Group: >> >> OAuth allows a user to grant a third-party Web site or application >> access to their resources, without revealing their credentials, or >> even their identity. For example, a photo-sharing site that supports >> OAuth would allow its users to use a third-party printing >Web site to >> access their private pictures, without gaining full control of the >> user account. >> >> OAuth consists of: >> * A mechanism for exchanging a user's credentials for a >token-secret >> pair that can be used by a third party to access resources on their >> behalf. >> * A mechanism for signing HTTP requests with the token-secret pair. >> >> The Working Group will produce one or more documents suitable for >> consideration as Proposed Standard, based upon the OAuth >I-D, that will: >> * Align OAuth with the Internet and Web architectures, best >> practices and terminology. >> * Assure good security practice, or document gaps in its >> capabilities, and propose a path forward for addressing the gap. >> * Promote interoperability. >> * Provide guidelines for extensibility. >> >> This specifically means that as a starting point for the >working group >> the OAuth 1.0 specification is used and the available >extension points >> are going to be utilized. It seems desireable to profile >OAuth 1.0 in >> a way that produces a specification that is a backwards compatible >> profile, i.e. an OAuth 1.0 implementation and the specification >> produced by this group must support a basic set of features to >> guarantee interoperability. >> >> Furthermore, OAuth 1.0 defines three signature methods used >to protect >> requests, namely PLAINTEXT, HMAC-SHA1, and RSA-SHA1. The group will >> work on new signature methods and will describe the >environments where >> new security requirements justify their usage. Existing signature >> methods will not be modified but may be dropped as part of the >> backwards compatible profiling activity. The applicability >of existing >> and new signature methods to protocols other than HTTP will >be investigated. >> >> In doing so, it should consider: >> * Implementer experience. >> * Existing uses of OAuth. >> * Ability to achieve broad impementation. >> * Ability to address broader use cases than may be contemplated by >> the original authors. >> * Impact on the Internet and Web. >> >> The Working Group is not tasked with defining a generally applicable >> HTTP Authentication mechanism (i.e., browser-based "2-leg" >scenerio), >> and should consider this work out of scope in its discussions. >> However, if the deliverables are able to be factored in such a way >> that this is a byproduct, or such a scenario could be addressed by >> additional future work, the Working Group may choose to do so. >> >> After delivering OAuth, the Working Group may consider defining >> additional functions and/or extensions, for example (but not limited >> to): >> * Discovery of authentication configuration. >> * Message integrity. >> * Recommendations regarding the structure of the token. >> >> Goals and Milestones: >> >> Apr 2009 Submit 'OAuth: HTTP Authorization Delegation Protocol' as >> working group item >> (draft-hammer-oauth will be used as a starting point for >> further work.) >> Sep 2009 Start Working Group Last Call on 'OAuth: HTTP >Authorization >> Delegation Protocol' >> Sep 2009 Discusion about OAUTH extensions the group should work on >> Nov 2009 Submit 'OAuth: HTTP Authorization Delegation Protocol' to >> the IESG for consideration as a Proposed Standard >> Nov 2009 Prepare milestone update to start new work >within the scope >> of the charter >> _______________________________________________ >> oauth mailing 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 Dorothy.Gellert@nokia.com Tue Feb 17 12:44:07 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAC233A68CF for ; Tue, 17 Feb 2009 12:44:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6P1gngC5YTYK for ; Tue, 17 Feb 2009 12:44:07 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 9C6BC3A67A5 for ; Tue, 17 Feb 2009 12:44:06 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n1HKi4U5026133; Tue, 17 Feb 2009 22:44:10 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Feb 2009 22:43:14 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Feb 2009 22:43:09 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Tue, 17 Feb 2009 21:43:09 +0100 From: To: , Date: Tue, 17 Feb 2009 21:43:07 +0100 Thread-Topic: [oauth] draft-dehora-farrell-oauth-accesstoken-creds-00.txt and OAUTH Extensions in the Charter Thread-Index: AcmRGpgtNrUn/IH9T5uk5JjrmOw72AAJKJ+g Message-ID: <26A704E322043948902DFFDD2CB493DB27E8CED2FE@NOK-EUMSG-01.mgdnok.nokia.com> References: <009e01c99070$11d33100$0201a8c0@nsnintra.net> <499AE273.1010609@cs.tcd.ie> In-Reply-To: <499AE273.1010609@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 17 Feb 2009 20:43:09.0588 (UTC) FILETIME=[57ED6540:01C99140] X-Nokia-AV: Clean Cc: oauth@ietf.org Subject: Re: [oauth] draft-dehora-farrell-oauth-accesstoken-creds-00.txt and OAUTH Extensions in the Charter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 20:44:08 -0000 I recall there was a lot of support in Minneapolis for extension targeted f= or devices as Stephen suggests. I would support adding the text proposed b= y Stephen to the OAUTH charter: "The WG will develop an oauth extension suited for use on challenged device= s and by aggregators that allows for the client to directly acquire an acce= ss token from a set of credentials. One such scheme is defined in draft-deh= ora-farrell-oauth-accesstoken-creds" I don't believe the last sentence precludes any other proposed drafts that = meet this goal, if there are other approaches that may be developing in the= WG. Best Regards, Dorothy -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of e= xt Stephen Farrell Sent: Tuesday, February 17, 2009 8:15 AM To: Hannes Tschofenig Cc: oauth@ietf.org Subject: Re: [oauth] draft-dehora-farrell-oauth-accesstoken-creds-00.txt an= d OAUTH Extensions in the Charter Hannes Tschofenig wrote: > Stephen ask me how their document > draft-dehora-farrell-oauth-accesstoken-creds-00.txt is reflected in > the charter text. Actually, I sent a mail to you and Blaine off list. I guess we should now d= iscuss it on the list, now that you've gone ahead here instead of respondin= g to the off list mail. Also I didn't ask how "its reflected" I suggested a way to include it, whic= h is quite different. My suggestion is to add the following: "The WG will develop an oauth extension suited for use on challenged device= s and by aggregators that allows for the client to directly acquire an acce= ss token from a set of credentials. One such scheme is defined in draft-deh= ora-farrell-oauth-accesstoken-creds" I'd still like to see that included and will certainly suggest it again in = SF, as I did in MSP, and without anyone (that I recall) disagreeing with co= nsidering the use case. > Independent of this particular document, I believe that we should > focus our initial efforts on the Base OAUTH specification rather than > working on extensions. Agreed. I never asked that our use case be worked before the spec work is d= one and have no idea how you formed that impression. > As such, I would say that (depending on the progress of the work with > the main specification) we should discuss extensions in the summer > timeframe. I think its fair enough to mention the AFAIK only proposed extension that's= documented as an I-D in the charter. I don't read your current charter pro= posal as encompassing our draft without rechartering. > Regarding this specific extension: I read through > draft-dehora-farrell-oauth-accesstoken-creds-00.txt and wanted to make > sure that I understood the extension correctly. Here is a message flow > that Jeff created some time ago. This document suggests to skip the > message exchanges marked as (2.*). This means that the redirect from > the Service Provider to the Customer and the subsequent steps of user > authentication and authorization are replaced with the ability to > carry some username/password in the Access token when the Consumer > sends the request to the Service Provider. Right. > My personal view is that this goes a bit against the OAUTH idea. > Unless the username/password is again created using some other > mechanism (which the document does not describe) then there are > vulnerability that OAUTH was initially meant to deal with. That's sort-of correct, however the point is that its necessary to deploy O= Auth for existing mobile devices and some aggregation use cases. > Additionally, the result is less likely to be easy to deploy. I think you're 100% wrong there...for the use cases we're considering. On w= hat basis do you say that? Do you think that HTTP redirects on mobiles are = just fine? > As a justification for the work the following argument is provided: > "HTTP redirection to a browser is unavailable or unsuitable, such as > intermediary aggregators and mobile or settop devices." I wonder > whether this is really a problem in today's mobile devices to justify thi= s optimization. You can wonder, but it is. Stephen. _______________________________________________ oauth mailing list oauth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Tue Feb 17 13:07: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 9787E3A6849 for ; Tue, 17 Feb 2009 13:07:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 Z9DZRJX5cJS8 for ; Tue, 17 Feb 2009 13:06:57 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 11E9E3A67A4 for ; Tue, 17 Feb 2009 13:06:57 -0800 (PST) Received: (qmail 30044 invoked from network); 17 Feb 2009 21:07:08 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 17 Feb 2009 21:07:08 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 17 Feb 2009 14:07:07 -0700 From: Eran Hammer-Lahav To: "Dorothy.Gellert@nokia.com" , "stephen.farrell@cs.tcd.ie" , "Hannes.Tschofenig@gmx.net" Date: Tue, 17 Feb 2009 14:07:07 -0700 Thread-Topic: [oauth] draft-dehora-farrell-oauth-accesstoken-creds-00.txt and OAUTH Extensions in the Charter Thread-Index: AcmRGpgtNrUn/IH9T5uk5JjrmOw72AAJKJ+gAAEdgjo= Message-ID: In-Reply-To: <26A704E322043948902DFFDD2CB493DB27E8CED2FE@NOK-EUMSG-01.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C5C066FB12B6Aeranhueniversecom_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [oauth] draft-dehora-farrell-oauth-accesstoken-creds-00.txt and OAUTH Extensions in the Charter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 21:07:06 -0000 --_000_C5C066FB12B6Aeranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I don't understand why we need to add this. There is nothing to stop people from proposing and developing such ideas. S= o far we have little implementation experience with much of these suggestio= ns. The fact is, everyone here is correctly referring to these ideas as *ex= tensions*. The purpose of this working group is to figure out the 'core' fr= amework. Error handling is crucial to interop. Internationalization is impo= rtant when dealing with user interfaces which OAuth does even in its core c= omponents. These make sense to *consider*. But why go and single out one extension just because it has an I-D? I could= have stood up at the BoF and listed at least 10 other extensions with wide= interest. Yahoo cares a lot about its Session extension. Google cares a lo= t about a few OpenSocial extensions related to gadgets. We have known limit= ations with the use of OAuth consumer credentials in desktop applications. = Many people asked for a standard way of consumer registration. Discovery ha= s been a big topic for the past year and a half. The choice of signature me= thod hash functions have been an issue in the past due to lack to support f= or some on limited devices. The list goes on and on. OAuth Core represents a compromise that allowed a wide range of use cases t= o agree on something that provided a good foundation and was based on imple= mentation experience. For the most part this WG must have the narrow focus = of taking draft-hammer-oauth and bringing it to IETF proposed standard leve= l. That means focusing on security and interop. Anything else should come l= ater. EHL On 2/17/09 12:43 PM, "Dorothy.Gellert@nokia.com" wrote: I recall there was a lot of support in Minneapolis for extension targeted f= or devices as Stephen suggests. I would support adding the text proposed b= y Stephen to the OAUTH charter: "The WG will develop an oauth extension suited for use on challenged device= s and by aggregators that allows for the client to directly acquire an acce= ss token from a set of credentials. One such scheme is defined in draft-deh= ora-farrell-oauth-accesstoken-creds" I don't believe the last sentence precludes any other proposed drafts that = meet this goal, if there are other approaches that may be developing in the= WG. Best Regards, Dorothy -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of e= xt Stephen Farrell Sent: Tuesday, February 17, 2009 8:15 AM To: Hannes Tschofenig Cc: oauth@ietf.org Subject: Re: [oauth] draft-dehora-farrell-oauth-accesstoken-creds-00.txt an= d OAUTH Extensions in the Charter Hannes Tschofenig wrote: > Stephen ask me how their document > draft-dehora-farrell-oauth-accesstoken-creds-00.txt is reflected in > the charter text. Actually, I sent a mail to you and Blaine off list. I guess we should now d= iscuss it on the list, now that you've gone ahead here instead of respondin= g to the off list mail. Also I didn't ask how "its reflected" I suggested a way to include it, whic= h is quite different. My suggestion is to add the following: "The WG will develop an oauth extension suited for use on challenged device= s and by aggregators that allows for the client to directly acquire an acce= ss token from a set of credentials. One such scheme is defined in draft-deh= ora-farrell-oauth-accesstoken-creds" I'd still like to see that included and will certainly suggest it again in = SF, as I did in MSP, and without anyone (that I recall) disagreeing with co= nsidering the use case. > Independent of this particular document, I believe that we should > focus our initial efforts on the Base OAUTH specification rather than > working on extensions. Agreed. I never asked that our use case be worked before the spec work is d= one and have no idea how you formed that impression. > As such, I would say that (depending on the progress of the work with > the main specification) we should discuss extensions in the summer > timeframe. I think its fair enough to mention the AFAIK only proposed extension that's= documented as an I-D in the charter. I don't read your current charter pro= posal as encompassing our draft without rechartering. > Regarding this specific extension: I read through > draft-dehora-farrell-oauth-accesstoken-creds-00.txt and wanted to make > sure that I understood the extension correctly. Here is a message flow > that Jeff created some time ago. This document suggests to skip the > message exchanges marked as (2.*). This means that the redirect from > the Service Provider to the Customer and the subsequent steps of user > authentication and authorization are replaced with the ability to > carry some username/password in the Access token when the Consumer > sends the request to the Service Provider. Right. > My personal view is that this goes a bit against the OAUTH idea. > Unless the username/password is again created using some other > mechanism (which the document does not describe) then there are > vulnerability that OAUTH was initially meant to deal with. That's sort-of correct, however the point is that its necessary to deploy O= Auth for existing mobile devices and some aggregation use cases. > Additionally, the result is less likely to be easy to deploy. I think you're 100% wrong there...for the use cases we're considering. On w= hat basis do you say that? Do you think that HTTP redirects on mobiles are = just fine? > As a justification for the work the following argument is provided: > "HTTP redirection to a browser is unavailable or unsuitable, such as > intermediary aggregators and mobile or settop devices." I wonder > whether this is really a problem in today's mobile devices to justify thi= s optimization. You can wonder, but it is. Stephen. _______________________________________________ oauth mailing list oauth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ oauth mailing list oauth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_C5C066FB12B6Aeranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [oauth] draft-dehora-farrell-oauth-accesstoken-creds-00.txt and = OAUTH Extensions in the Charter I don’t understand why we need to add this.

There is nothing to stop people from proposing and developing such ideas. S= o far we have little implementation experience with much of these suggestio= ns. The fact is, everyone here is correctly referring to these ideas as *ex= tensions*. The purpose of this working group is to figure out the ‘co= re’ framework. Error handling is crucial to interop. Internationaliza= tion is important when dealing with user interfaces which OAuth does even i= n its core components. These make sense to *consider*.

But why go and single out one extension just because it has an I-D? I could= have stood up at the BoF and listed at least 10 other extensions with wide= interest. Yahoo cares a lot about its Session extension. Google cares a lo= t about a few OpenSocial extensions related to gadgets. We have known limit= ations with the use of OAuth consumer credentials in desktop applications. = Many people asked for a standard way of consumer registration. Discovery ha= s been a big topic for the past year and a half. The choice of signature me= thod hash functions have been an issue in the past due to lack to support f= or some on limited devices. The list goes on and on.

OAuth Core represents a compromise that allowed a wide range of use cases t= o agree on something that provided a good foundation and was based on imple= mentation experience. For the most part this WG must have the narrow focus = of taking draft-hammer-oauth and bringing it to IETF proposed standard leve= l. That means focusing on security and interop. Anything else should come l= ater.

EHL


On 2/17/09 12:43 PM, "Dorothy.Ge= llert@nokia.com" <Dorothy= .Gellert@nokia.com> wrote:



I recall there was a lot of support in Minneapolis for extension targeted f= or devices as Stephen suggests.  I would support adding the text propo= sed by Stephen to the OAUTH charter:

"The WG will develop an oauth extension suited for use on challenged d= evices and by aggregators that allows for the client to directly acquire an= access token from a set of credentials. One such scheme is defined in draf= t-dehora-farrell-oauth-accesstoken-creds"

I don't believe the last sentence precludes any other proposed drafts that = meet this goal, if there are other approaches that may be developing in the= WG.

Best Regards,
Dorothy


-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On B= ehalf Of ext Stephen Farrell
Sent: Tuesday, February 17, 2009 8:15 AM
To: Hannes Tschofenig
Cc: oauth@ietf.org
Subject: Re: [oauth] draft-dehora-farrell-oauth-accesstoken-creds-00.txt an= d OAUTH Extensions in the Charter



Hannes Tschofenig wrote:
> Stephen ask me how their document
> draft-dehora-farrell-oauth-accesstoken-creds-00.txt is reflected in > the charter text.

Actually, I sent a mail to you and Blaine off list. I guess we should now d= iscuss it on the list, now that you've gone ahead here instead of respondin= g to the off list mail.

Also I didn't ask how "its reflected" I suggested a way to includ= e it, which is quite different.

My suggestion is to add the following:

"The WG will develop an oauth extension suited for use on challenged d= evices and by aggregators that allows for the client to directly acquire an= access token from a set of credentials. One such scheme is defined in draf= t-dehora-farrell-oauth-accesstoken-creds"

I'd still like to see that included and will certainly suggest it again in = SF, as I did in MSP, and without anyone (that I recall) disagreeing with co= nsidering the use case.

> Independent of this particular document, I believe that we should
> focus our initial efforts on the Base OAUTH specification rather than<= BR> > working on extensions.

Agreed. I never asked that our use case be worked before the spec work is d= one and have no idea how you formed that impression.

> As such, I would say that (depending on the progress of the work with<= BR> > the main specification) we should discuss extensions in the summer
> timeframe.

I think its fair enough to mention the AFAIK only proposed extension that's= documented as an I-D in the charter. I don't read your current charter pro= posal as encompassing our draft without rechartering.

> Regarding this specific extension: I read through
> draft-dehora-farrell-oauth-accesstoken-creds-00.txt and wanted to make=
> sure that I understood the extension correctly. Here is a message flow=
> that Jeff created some time ago. This document suggests to skip the > message exchanges marked as (2.*). This means that the redirect from > the Service Provider to the Customer and the subsequent steps of user<= BR> > authentication and authorization are replaced with the ability to
> carry some username/password in the Access token when the Consumer
> sends the request to the Service Provider.

Right.

> My personal view is that this goes a bit against the OAUTH idea.
> Unless the username/password is again created using some other
> mechanism (which the document does not describe) then there are
> vulnerability that OAUTH was initially meant to deal with.

That's sort-of correct, however the point is that its necessary to deploy O= Auth for existing mobile devices and some aggregation use cases.

> Additionally, the result is less likely to be easy to deploy.

I think you're 100% wrong there...for the use cases we're considering. On w= hat basis do you say that? Do you think that HTTP redirects on mobiles are = just fine?

> As a justification for the work the following argument is provided: > "HTTP redirection to a browser is unavailable or unsuitable, such= as
> intermediary aggregators and mobile or settop devices." I wonder<= BR> > whether this is really a problem in today's mobile devices to justify = this optimization.

You can wonder, but it is.

Stephen.

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

--_000_C5C066FB12B6Aeranhueniversecom_-- From john@jkemp.net Tue Feb 17 13:20: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 617503A69C2 for ; Tue, 17 Feb 2009 13:20:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fDpLZkZJzgdY for ; Tue, 17 Feb 2009 13:20:53 -0800 (PST) Received: from outbound-mail-04.bluehost.com (outbound-mail-04.bluehost.com [69.89.21.14]) by core3.amsl.com (Postfix) with SMTP id 16DCA3A6990 for ; Tue, 17 Feb 2009 13:20:53 -0800 (PST) Received: (qmail 3841 invoked by uid 0); 17 Feb 2009 21:20:00 -0000 Received: from unknown (HELO box320.bluehost.com) (69.89.31.120) by outboundproxy1.bluehost.com with SMTP; 17 Feb 2009 21:20:00 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=jkemp.net; h=Received:Cc:Message-Id:From:To:In-Reply-To:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:References:X-Mailer:X-Identified-User; b=XDM4bw4ZiuZUZ7goJIU7dQUTgODOwqAFp7PTNXbLNDJoSxFfrqrp5LYfP94mGRAkTnSrZhCovqiM7UvbRyLZO2495gQhUf3vEeG4PaBQeJvxD6nrNOuIJuhKi6VWOdeY; Received: from cpe-69-205-56-47.nycap.res.rr.com ([69.205.56.47] helo=mztrcscn117.americas.nokia.com) by box320.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1LZXNG-0002XR-Os; Tue, 17 Feb 2009 14:21:03 -0700 Message-Id: From: John Kemp To: Eran Hammer-Lahav In-Reply-To: Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 17 Feb 2009 16:21:00 -0500 References: X-Mailer: Apple Mail (2.930.3) X-Identified-User: {1122:box320.bluehost.com:jkempnet:jkemp.net} {sentby:smtp auth 69.205.56.47 authed with john+jkemp.net} Cc: "Hannes.Tschofenig@gmx.net" , "Dorothy.Gellert@nokia.com" , "oauth@ietf.org" Subject: Re: [oauth] draft-dehora-farrell-oauth-accesstoken-creds-00.txt and OAUTH Extensions in the Charter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 21:20:54 -0000 On Feb 17, 2009, at 4:07 PM, Eran Hammer-Lahav wrote: > I don=92t understand why we need to add this. > > There is nothing to stop people from proposing and developing such =20 > ideas. So far we have little implementation experience with much of =20= > these suggestions. The fact is, everyone here is correctly referring =20= > to these ideas as *extensions*. The purpose of this working group is =20= > to figure out the =91core=92 framework. Error handling is crucial to =20= > interop. Internationalization is important when dealing with user =20 > interfaces which OAuth does even in its core components. These make =20= > sense to *consider*. > > But why go and single out one extension just because it has an I-D? My answer would be simply that a list of proposed "extensions" is =20 listed in the current charter text (taken from my previous email): > =46rom the charter text in [1] > >> "After delivering OAuth, the Working Group may consider defining >> additional functions and/or extensions, for example (but not limited >> to): >> * Discovery of authentication configuration. >> * Message integrity. >> * Recommendations regarding the structure of the token." I could be persuaded that this text doesn't prevent the development of =20= any extensions, but once you list one, you run the risk of people =20 asking "why don't you list XYZ too?" > I could have stood up at the BoF and listed at least 10 other =20 > extensions with wide interest. Yahoo cares a lot about its Session =20 > extension. Google cares a lot about a few OpenSocial extensions =20 > related to gadgets. We have known limitations with the use of OAuth =20= > consumer credentials in desktop applications. Many people asked for =20= > a standard way of consumer registration. Discovery has been a big =20 > topic for the past year and a half. The choice of signature method =20 > hash functions have been an issue in the past due to lack to support =20= > for some on limited devices. The list goes on and on. > > OAuth Core represents a compromise that allowed a wide range of use =20= > cases to agree on something that provided a good foundation and was =20= > based on implementation experience. For the most part this WG must =20 > have the narrow focus of taking draft-hammer-oauth and bringing it =20 > to IETF proposed standard level. That means focusing on security and =20= > interop. Anything else should come later. I don't think timing is so much the issue. Regards, - johnk [1] http://www.ietf.org/mail-archive/web/oauth/current/msg00085.html > > > EHL > > > On 2/17/09 12:43 PM, "Dorothy.Gellert@nokia.com" = > wrote: > > > > I recall there was a lot of support in Minneapolis for extension =20 > targeted for devices as Stephen suggests. I would support adding =20 > the text proposed by Stephen to the OAUTH charter: > > "The WG will develop an oauth extension suited for use on challenged =20= > devices and by aggregators that allows for the client to directly =20 > acquire an access token from a set of credentials. One such scheme =20 > is defined in draft-dehora-farrell-oauth-accesstoken-creds" > > I don't believe the last sentence precludes any other proposed =20 > drafts that meet this goal, if there are other approaches that may =20 > be developing in the WG. > > Best Regards, > Dorothy > > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On =20 > Behalf Of ext Stephen Farrell > Sent: Tuesday, February 17, 2009 8:15 AM > To: Hannes Tschofenig > Cc: oauth@ietf.org > Subject: Re: [oauth] draft-dehora-farrell-oauth-accesstoken-=20 > creds-00.txt and OAUTH Extensions in the Charter > > > > Hannes Tschofenig wrote: > > Stephen ask me how their document > > draft-dehora-farrell-oauth-accesstoken-creds-00.txt is reflected in > > the charter text. > > Actually, I sent a mail to you and Blaine off list. I guess we =20 > should now discuss it on the list, now that you've gone ahead here =20 > instead of responding to the off list mail. > > Also I didn't ask how "its reflected" I suggested a way to include =20 > it, which is quite different. > > My suggestion is to add the following: > > "The WG will develop an oauth extension suited for use on challenged =20= > devices and by aggregators that allows for the client to directly =20 > acquire an access token from a set of credentials. One such scheme =20 > is defined in draft-dehora-farrell-oauth-accesstoken-creds" > > I'd still like to see that included and will certainly suggest it =20 > again in SF, as I did in MSP, and without anyone (that I recall) =20 > disagreeing with considering the use case. > > > Independent of this particular document, I believe that we should > > focus our initial efforts on the Base OAUTH specification rather =20 > than > > working on extensions. > > Agreed. I never asked that our use case be worked before the spec =20 > work is done and have no idea how you formed that impression. > > > As such, I would say that (depending on the progress of the work =20 > with > > the main specification) we should discuss extensions in the summer > > timeframe. > > I think its fair enough to mention the AFAIK only proposed extension =20= > that's documented as an I-D in the charter. I don't read your =20 > current charter proposal as encompassing our draft without =20 > rechartering. > > > Regarding this specific extension: I read through > > draft-dehora-farrell-oauth-accesstoken-creds-00.txt and wanted to =20= > make > > sure that I understood the extension correctly. Here is a message =20= > flow > > that Jeff created some time ago. This document suggests to skip the > > message exchanges marked as (2.*). This means that the redirect from > > the Service Provider to the Customer and the subsequent steps of =20 > user > > authentication and authorization are replaced with the ability to > > carry some username/password in the Access token when the Consumer > > sends the request to the Service Provider. > > Right. > > > My personal view is that this goes a bit against the OAUTH idea. > > Unless the username/password is again created using some other > > mechanism (which the document does not describe) then there are > > vulnerability that OAUTH was initially meant to deal with. > > That's sort-of correct, however the point is that its necessary to =20 > deploy OAuth for existing mobile devices and some aggregation use =20 > cases. > > > Additionally, the result is less likely to be easy to deploy. > > I think you're 100% wrong there...for the use cases we're =20 > considering. On what basis do you say that? Do you think that HTTP =20 > redirects on mobiles are just fine? > > > As a justification for the work the following argument is provided: > > "HTTP redirection to a browser is unavailable or unsuitable, such as > > intermediary aggregators and mobile or settop devices." I wonder > > whether this is really a problem in today's mobile devices to =20 > justify this optimization. > > You can wonder, but it is. > > Stephen. > > _______________________________________________ > oauth mailing list > oauth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > oauth mailing list > oauth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > oauth mailing list > oauth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Tue Feb 17 13:33:00 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3F0628C130 for ; Tue, 17 Feb 2009 13:33:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 Ryc-7r3F1lKZ for ; Tue, 17 Feb 2009 13:32:53 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 66A193A6849 for ; Tue, 17 Feb 2009 13:32:53 -0800 (PST) Received: (qmail 13895 invoked from network); 17 Feb 2009 21:33:04 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 17 Feb 2009 21:33:04 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Tue, 17 Feb 2009 14:33:03 -0700 From: Eran Hammer-Lahav To: John Kemp Date: Tue, 17 Feb 2009 14:33:02 -0700 Thread-Topic: [oauth] draft-dehora-farrell-oauth-accesstoken-creds-00.txt and OAUTH Extensions in the Charter Thread-Index: AcmRRadjXgknfXOyQSWN2D6AuAej4AAAagqq Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C5C06D0E12B7Eeranhueniversecom_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [oauth] draft-dehora-farrell-oauth-accesstoken-creds-00.txt and OAUTH Extensions in the Charter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 21:33:00 -0000 --_000_C5C06D0E12B7Eeranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Listing a bunch of ideas the WG might want to consider later on is fine by = me (and pretty useless). The charter is suppose to help us focus... EHL On 2/17/09 1:21 PM, "John Kemp" wrote: On Feb 17, 2009, at 4:07 PM, Eran Hammer-Lahav wrote: > I don't understand why we need to add this. > > There is nothing to stop people from proposing and developing such > ideas. So far we have little implementation experience with much of > these suggestions. The fact is, everyone here is correctly referring > to these ideas as *extensions*. The purpose of this working group is > to figure out the 'core' framework. Error handling is crucial to > interop. Internationalization is important when dealing with user > interfaces which OAuth does even in its core components. These make > sense to *consider*. > > But why go and single out one extension just because it has an I-D? My answer would be simply that a list of proposed "extensions" is listed in the current charter text (taken from my previous email): > From the charter text in [1] > >> "After delivering OAuth, the Working Group may consider defining >> additional functions and/or extensions, for example (but not limited >> to): >> * Discovery of authentication configuration. >> * Message integrity. >> * Recommendations regarding the structure of the token." I could be persuaded that this text doesn't prevent the development of any extensions, but once you list one, you run the risk of people asking "why don't you list XYZ too?" > I could have stood up at the BoF and listed at least 10 other > extensions with wide interest. Yahoo cares a lot about its Session > extension. Google cares a lot about a few OpenSocial extensions > related to gadgets. We have known limitations with the use of OAuth > consumer credentials in desktop applications. Many people asked for > a standard way of consumer registration. Discovery has been a big > topic for the past year and a half. The choice of signature method > hash functions have been an issue in the past due to lack to support > for some on limited devices. The list goes on and on. > > OAuth Core represents a compromise that allowed a wide range of use > cases to agree on something that provided a good foundation and was > based on implementation experience. For the most part this WG must > have the narrow focus of taking draft-hammer-oauth and bringing it > to IETF proposed standard level. That means focusing on security and > interop. Anything else should come later. I don't think timing is so much the issue. Regards, - johnk [1] http://www.ietf.org/mail-archive/web/oauth/current/msg00085.html > > > EHL > > > On 2/17/09 12:43 PM, "Dorothy.Gellert@nokia.com" > wrote: > > > > I recall there was a lot of support in Minneapolis for extension > targeted for devices as Stephen suggests. I would support adding > the text proposed by Stephen to the OAUTH charter: > > "The WG will develop an oauth extension suited for use on challenged > devices and by aggregators that allows for the client to directly > acquire an access token from a set of credentials. One such scheme > is defined in draft-dehora-farrell-oauth-accesstoken-creds" > > I don't believe the last sentence precludes any other proposed > drafts that meet this goal, if there are other approaches that may > be developing in the WG. > > Best Regards, > Dorothy > > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > Behalf Of ext Stephen Farrell > Sent: Tuesday, February 17, 2009 8:15 AM > To: Hannes Tschofenig > Cc: oauth@ietf.org > Subject: Re: [oauth] draft-dehora-farrell-oauth-accesstoken- > creds-00.txt and OAUTH Extensions in the Charter > > > > Hannes Tschofenig wrote: > > Stephen ask me how their document > > draft-dehora-farrell-oauth-accesstoken-creds-00.txt is reflected in > > the charter text. > > Actually, I sent a mail to you and Blaine off list. I guess we > should now discuss it on the list, now that you've gone ahead here > instead of responding to the off list mail. > > Also I didn't ask how "its reflected" I suggested a way to include > it, which is quite different. > > My suggestion is to add the following: > > "The WG will develop an oauth extension suited for use on challenged > devices and by aggregators that allows for the client to directly > acquire an access token from a set of credentials. One such scheme > is defined in draft-dehora-farrell-oauth-accesstoken-creds" > > I'd still like to see that included and will certainly suggest it > again in SF, as I did in MSP, and without anyone (that I recall) > disagreeing with considering the use case. > > > Independent of this particular document, I believe that we should > > focus our initial efforts on the Base OAUTH specification rather > than > > working on extensions. > > Agreed. I never asked that our use case be worked before the spec > work is done and have no idea how you formed that impression. > > > As such, I would say that (depending on the progress of the work > with > > the main specification) we should discuss extensions in the summer > > timeframe. > > I think its fair enough to mention the AFAIK only proposed extension > that's documented as an I-D in the charter. I don't read your > current charter proposal as encompassing our draft without > rechartering. > > > Regarding this specific extension: I read through > > draft-dehora-farrell-oauth-accesstoken-creds-00.txt and wanted to > make > > sure that I understood the extension correctly. Here is a message > flow > > that Jeff created some time ago. This document suggests to skip the > > message exchanges marked as (2.*). This means that the redirect from > > the Service Provider to the Customer and the subsequent steps of > user > > authentication and authorization are replaced with the ability to > > carry some username/password in the Access token when the Consumer > > sends the request to the Service Provider. > > Right. > > > My personal view is that this goes a bit against the OAUTH idea. > > Unless the username/password is again created using some other > > mechanism (which the document does not describe) then there are > > vulnerability that OAUTH was initially meant to deal with. > > That's sort-of correct, however the point is that its necessary to > deploy OAuth for existing mobile devices and some aggregation use > cases. > > > Additionally, the result is less likely to be easy to deploy. > > I think you're 100% wrong there...for the use cases we're > considering. On what basis do you say that? Do you think that HTTP > redirects on mobiles are just fine? > > > As a justification for the work the following argument is provided: > > "HTTP redirection to a browser is unavailable or unsuitable, such as > > intermediary aggregators and mobile or settop devices." I wonder > > whether this is really a problem in today's mobile devices to > justify this optimization. > > You can wonder, but it is. > > Stephen. > > _______________________________________________ > oauth mailing list > oauth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > oauth mailing list > oauth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > oauth mailing list > oauth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --_000_C5C06D0E12B7Eeranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [oauth] draft-dehora-farrell-oauth-accesstoken-creds-00.txt and = OAUTH Extensions in the Charter Listing a bunch of ideas the WG might want to consider later on is fi= ne by me (and pretty useless). The charter is suppose to help us focus...
EHL


On 2/17/09 1:21 PM, "John Kemp" <jo= hn@jkemp.net> wrote:

On Feb 17, 2009, at 4:07 PM, Eran Hammer-La= hav wrote:

> I don’t understand why we need to add this.
>
> There is nothing to stop people from proposing and developing such
> ideas. So far we have little implementation experience with much of > these suggestions. The fact is, everyone here is correctly referring > to these ideas as *extensions*. The purpose of this working group is > to figure out the ‘core’ framework. Error handling is cruc= ial to
> interop. Internationalization is important when dealing with user
> interfaces which OAuth does even in its core components. These make > sense to *consider*.
>
> But why go and single out one extension just because it has an I-D?
My answer would be simply that a list of proposed "extensions" is=
listed in the current charter text (taken from my previous email):

> From the charter text in [1]
>
>> "After delivering OAuth, the Working Group may consider defin= ing
>> additional functions and/or extensions, for example (but not limit= ed
>> to):
>> * Discovery of authentication configuration.
>> * Message integrity.
>> * Recommendations regarding the structure of the token."


I could be persuaded that this text doesn't prevent the development of
any extensions, but once you list one, you run the risk of people
asking "why don't you list XYZ too?"

> I could have stood up at the BoF and listed at least 10 other
> extensions with wide interest. Yahoo cares a lot about its Session
> extension. Google cares a lot about a few OpenSocial extensions
> related to gadgets. We have known limitations with the use of OAuth > consumer credentials in desktop applications. Many people asked for > a standard way of consumer registration. Discovery has been a big
> topic for the past year and a half. The choice of signature method
> hash functions have been an issue in the past due to lack to support > for some on limited devices. The list goes on and on.
>
> OAuth Core represents a compromise that allowed a wide range of use > cases to agree on something that provided a good foundation and was > based on implementation experience. For the most part this WG must
> have the narrow focus of taking draft-hammer-oauth and bringing it
> to IETF proposed standard level. That means focusing on security and > interop. Anything else should come later.

I don't think timing is so much the issue.

Regards,

- johnk

[1] http://www.ietf.org/mail-archive/web/oauth/current/msg00085.html<= BR>
>
>
> EHL
>
>
> On 2/17/09 12:43 PM, "Dorot= hy.Gellert@nokia.com" <Do= rothy.Gellert@nokia.com
> > wrote:
>
>
>
> I recall there was a lot of support in Minneapolis for extension
> targeted for devices as Stephen suggests.  I would support adding=
> the text proposed by Stephen to the OAUTH charter:
>
> "The WG will develop an oauth extension suited for use on challen= ged
> devices and by aggregators that allows for the client to directly
> acquire an access token from a set of credentials. One such scheme
> is defined in draft-dehora-farrell-oauth-accesstoken-creds"
>
> I don't believe the last sentence precludes any other proposed
> drafts that meet this goal, if there are other approaches that may
> be developing in the WG.
>
> Best Regards,
> Dorothy
>
>
> -----Original Message-----
> From: oauth-bounces@ietf.org [<= a href=3D"mailto:oauth-bounces@ietf.org">mailto:oauth-bounces@ietf.org]= On
> Behalf Of ext Stephen Farrell
> Sent: Tuesday, February 17, 2009 8:15 AM
> To: Hannes Tschofenig
> Cc: oauth@ietf.org
> Subject: Re: [oauth] draft-dehora-farrell-oauth-accesstoken-
> creds-00.txt and OAUTH Extensions in the Charter
>
>
>
> Hannes Tschofenig wrote:
> > Stephen ask me how their document
> > draft-dehora-farrell-oauth-accesstoken-creds-00.txt is reflected = in
> > the charter text.
>
> Actually, I sent a mail to you and Blaine off list. I guess we
> should now discuss it on the list, now that you've gone ahead here
> instead of responding to the off list mail.
>
> Also I didn't ask how "its reflected" I suggested a way to i= nclude
> it, which is quite different.
>
> My suggestion is to add the following:
>
> "The WG will develop an oauth extension suited for use on challen= ged
> devices and by aggregators that allows for the client to directly
> acquire an access token from a set of credentials. One such scheme
> is defined in draft-dehora-farrell-oauth-accesstoken-creds"
>
> I'd still like to see that included and will certainly suggest it
> again in SF, as I did in MSP, and without anyone (that I recall)
> disagreeing with considering the use case.
>
> > Independent of this particular document, I believe that we should=
> > focus our initial efforts on the Base OAUTH specification rather<= BR> > than
> > working on extensions.
>
> Agreed. I never asked that our use case be worked before the spec
> work is done and have no idea how you formed that impression.
>
> > As such, I would say that (depending on the progress of the work<= BR> > with
> > the main specification) we should discuss extensions in the summe= r
> > timeframe.
>
> I think its fair enough to mention the AFAIK only proposed extension > that's documented as an I-D in the charter. I don't read your
> current charter proposal as encompassing our draft without
> rechartering.
>
> > Regarding this specific extension: I read through
> > draft-dehora-farrell-oauth-accesstoken-creds-00.txt and wanted to=
> make
> > sure that I understood the extension correctly. Here is a message=
> flow
> > that Jeff created some time ago. This document suggests to skip t= he
> > message exchanges marked as (2.*). This means that the redirect f= rom
> > the Service Provider to the Customer and the subsequent steps of<= BR> > user
> > authentication and authorization are replaced with the ability to=
> > carry some username/password in the Access token when the Consume= r
> > sends the request to the Service Provider.
>
> Right.
>
> > My personal view is that this goes a bit against the OAUTH idea.<= BR> > > Unless the username/password is again created using some other > > mechanism (which the document does not describe) then there are > > vulnerability that OAUTH was initially meant to deal with.
>
> That's sort-of correct, however the point is that its necessary to
> deploy OAuth for existing mobile devices and some aggregation use
> cases.
>
> > Additionally, the result is less likely to be easy to deploy.
>
> I think you're 100% wrong there...for the use cases we're
> considering. On what basis do you say that? Do you think that HTTP
> redirects on mobiles are just fine?
>
> > As a justification for the work the following argument is provide= d:
> > "HTTP redirection to a browser is unavailable or unsuitable,= such as
> > intermediary aggregators and mobile or settop devices." I wo= nder
> > whether this is really a problem in today's mobile devices to
> justify this optimization.
>
> You can wonder, but it is.
>
> Stephen.
>
> _______________________________________________
> oauth mailing list
> oauth@ietf.org
> https://www.ie= tf.org/mailman/listinfo/oauth
> _______________________________________________
> oauth mailing list
> oauth@ietf.org
> https://www.ie= tf.org/mailman/listinfo/oauth
>
> _______________________________________________
> oauth mailing list
> oauth@ietf.org
> https://www.ie= tf.org/mailman/listinfo/oauth


--_000_C5C06D0E12B7Eeranhueniversecom_-- From Hannes.Tschofenig@gmx.net Tue Feb 17 13:35: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 811D83A6849 for ; Tue, 17 Feb 2009 13:35:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.276 X-Spam-Level: X-Spam-Status: No, score=-2.276 tagged_above=-999 required=5 tests=[AWL=0.323, 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 YTJF7Lu+CTZM for ; Tue, 17 Feb 2009 13:35:32 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id E190C3A67FB for ; Tue, 17 Feb 2009 13:35:31 -0800 (PST) Received: (qmail invoked by alias); 17 Feb 2009 21:35:42 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp045) with SMTP; 17 Feb 2009 22:35:42 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX189YRgZ5Ts99TXs5kS7G+0QXwU+o9WZS90IeNxhHW uSj24kkDmUMcZR From: "Hannes Tschofenig" To: "'Eran Hammer-Lahav'" , , References: <26A704E322043948902DFFDD2CB493DB27E8CED2FE@NOK-EUMSG-01.mgdnok.nokia.com> Date: Tue, 17 Feb 2009 23:36:46 +0200 Message-ID: <004601c99147$d612c670$0201a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcmRGpgtNrUn/IH9T5uk5JjrmOw72AAJKJ+gAAEdgjoAAFXogA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: X-Y-GMX-Trusted: 0 X-FuHaFi: 0.71 Cc: oauth@ietf.org Subject: Re: [oauth] draft-dehora-farrell-oauth-accesstoken-creds-00.txt and OAUTH Extensions in the Charter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 21:35:33 -0000 Hi Eran, I understand your concerns. We started to add examples to the initial charter text: " After delivering OAuth, the Working Group may consider defining additional functions and/or extensions, for example (but not limited to): * Discovery of authentication configuration. * Message integrity. * Recommendations regarding the structure of the token. " I understand why Stephen asks for getting text about his extension added. I can imagine that someone else comes up with their favorite extension, simililarly as you listed in your mail. In some sense it would be fair to add text about the other examples added as well, if someone cares. I wonder what other folks in the group think about this topic? Ciao Hannes ________________________________ From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Eran Hammer-Lahav Sent: 17 February, 2009 23:07 To: Dorothy.Gellert@nokia.com; stephen.farrell@cs.tcd.ie; Hannes.Tschofenig@gmx.net Cc: oauth@ietf.org Subject: Re: [oauth] draft-dehora-farrell-oauth-accesstoken-creds-00.txt and OAUTH Extensions in the Charter I don't understand why we need to add this. There is nothing to stop people from proposing and developing such ideas. So far we have little implementation experience with much of these suggestions. The fact is, everyone here is correctly referring to these ideas as *extensions*. The purpose of this working group is to figure out the 'core' framework. Error handling is crucial to interop. Internationalization is important when dealing with user interfaces which OAuth does even in its core components. These make sense to *consider*. But why go and single out one extension just because it has an I-D? I could have stood up at the BoF and listed at least 10 other extensions with wide interest. Yahoo cares a lot about its Session extension. Google cares a lot about a few OpenSocial extensions related to gadgets. We have known limitations with the use of OAuth consumer credentials in desktop applications. Many people asked for a standard way of consumer registration. Discovery has been a big topic for the past year and a half. The choice of signature method hash functions have been an issue in the past due to lack to support for some on limited devices. The list goes on and on. OAuth Core represents a compromise that allowed a wide range of use cases to agree on something that provided a good foundation and was based on implementation experience. For the most part this WG must have the narrow focus of taking draft-hammer-oauth and bringing it to IETF proposed standard level. That means focusing on security and interop. Anything else should come later. EHL On 2/17/09 12:43 PM, "Dorothy.Gellert@nokia.com" wrote: I recall there was a lot of support in Minneapolis for extension targeted for devices as Stephen suggests. I would support adding the text proposed by Stephen to the OAUTH charter: "The WG will develop an oauth extension suited for use on challenged devices and by aggregators that allows for the client to directly acquire an access token from a set of credentials. One such scheme is defined in draft-dehora-farrell-oauth-accesstoken-creds" I don't believe the last sentence precludes any other proposed drafts that meet this goal, if there are other approaches that may be developing in the WG. Best Regards, Dorothy -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of ext Stephen Farrell Sent: Tuesday, February 17, 2009 8:15 AM To: Hannes Tschofenig Cc: oauth@ietf.org Subject: Re: [oauth] draft-dehora-farrell-oauth-accesstoken-creds-00.txt and OAUTH Extensions in the Charter Hannes Tschofenig wrote: > Stephen ask me how their document > draft-dehora-farrell-oauth-accesstoken-creds-00.txt is reflected in > the charter text. Actually, I sent a mail to you and Blaine off list. I guess we should now discuss it on the list, now that you've gone ahead here instead of responding to the off list mail. Also I didn't ask how "its reflected" I suggested a way to include it, which is quite different. My suggestion is to add the following: "The WG will develop an oauth extension suited for use on challenged devices and by aggregators that allows for the client to directly acquire an access token from a set of credentials. One such scheme is defined in draft-dehora-farrell-oauth-accesstoken-creds" I'd still like to see that included and will certainly suggest it again in SF, as I did in MSP, and without anyone (that I recall) disagreeing with considering the use case. > Independent of this particular document, I believe that we should > focus our initial efforts on the Base OAUTH specification rather than > working on extensions. Agreed. I never asked that our use case be worked before the spec work is done and have no idea how you formed that impression. > As such, I would say that (depending on the progress of the work with > the main specification) we should discuss extensions in the summer > timeframe. I think its fair enough to mention the AFAIK only proposed extension that's documented as an I-D in the charter. I don't read your current charter proposal as encompassing our draft without rechartering. > Regarding this specific extension: I read through > draft-dehora-farrell-oauth-accesstoken-creds-00.txt and wanted to make > sure that I understood the extension correctly. Here is a message flow > that Jeff created some time ago. This document suggests to skip the > message exchanges marked as (2.*). This means that the redirect from > the Service Provider to the Customer and the subsequent steps of user > authentication and authorization are replaced with the ability to > carry some username/password in the Access token when the Consumer > sends the request to the Service Provider. Right. > My personal view is that this goes a bit against the OAUTH idea. > Unless the username/password is again created using some other > mechanism (which the document does not describe) then there are > vulnerability that OAUTH was initially meant to deal with. That's sort-of correct, however the point is that its necessary to deploy OAuth for existing mobile devices and some aggregation use cases. > Additionally, the result is less likely to be easy to deploy. I think you're 100% wrong there...for the use cases we're considering. On what basis do you say that? Do you think that HTTP redirects on mobiles are just fine? > As a justification for the work the following argument is provided: > "HTTP redirection to a browser is unavailable or unsuitable, such as > intermediary aggregators and mobile or settop devices." I wonder > whether this is really a problem in today's mobile devices to justify this optimization. You can wonder, but it is. Stephen. _______________________________________________ oauth mailing 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 romeda@gmail.com Tue Feb 17 13:57: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 7383D3A6964 for ; Tue, 17 Feb 2009 13:57:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Rfe1J7rFiEQ for ; Tue, 17 Feb 2009 13:57:45 -0800 (PST) Received: from mail-ew0-f21.google.com (mail-ew0-f21.google.com [209.85.219.21]) by core3.amsl.com (Postfix) with ESMTP id E636F3A6911 for ; Tue, 17 Feb 2009 13:57:44 -0800 (PST) Received: by ewy14 with SMTP id 14so2458900ewy.13 for ; Tue, 17 Feb 2009 13:57:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=s2yiauRrVrtj5cdyLuHIBUn9Ysv+qHqCpl/lSKGWbpQ=; b=XGWobZAbg8nSTy7EEIIMVlcir7CaX5bPsKLD8a9lOXuPC3MwA9xrNGWK5drK8ok29U NxXmI5GY57T1LHgyaH0N/ZXn/9fe4BKtsqCslnPb3ARHyA0sZZJEe5heZbuylvsyP6s/ O05XVYaJv6syFiMla1z+TfJAZs69Nukf31uVU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=pae37rK725kfQ3nhNBSq5+39bNx9BHSAnDWtk9IuPIJ/42hpGJiO2PL2lmg6bPxlH9 jtOZgtS27IgKCZzf9oS8CyM7AyZrczvot3nr+RlP/F4KWfjxHqvTRWcsMS8Hf1vLCzuO pA9j3G+5A7F1xDQpO5IxxqRljKbi1iRwpCvgE= MIME-Version: 1.0 Received: by 10.210.44.19 with SMTP id r19mr2638904ebr.53.1234907875066; Tue, 17 Feb 2009 13:57:55 -0800 (PST) In-Reply-To: <26A704E322043948902DFFDD2CB493DB27E8CED2FE@NOK-EUMSG-01.mgdnok.nokia.com> References: <009e01c99070$11d33100$0201a8c0@nsnintra.net> <499AE273.1010609@cs.tcd.ie> <26A704E322043948902DFFDD2CB493DB27E8CED2FE@NOK-EUMSG-01.mgdnok.nokia.com> Date: Tue, 17 Feb 2009 21:57:55 +0000 Message-ID: From: Blaine Cook To: Dorothy.Gellert@nokia.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Hannes.Tschofenig@gmx.net, oauth@ietf.org Subject: Re: [oauth] draft-dehora-farrell-oauth-accesstoken-creds-00.txt and OAUTH Extensions in the Charter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 21:57:46 -0000 Can I suggest that we update the section of the charter before the Goals and Milestones that currently reads: After delivering OAuth, the Working Group MAY consider defining additional functions and/or extensions, for example (but not limited to): * Discovery of authentication configuration * Message integrity * Recommendations regarding the structure of the token to read: After delivering OAuth, the Working Group MAY consider defining additional functions and/or extensions, for example (but not limited to): * Discovery of OAuth configuration * Comprehensive message integrity * Recommendations regarding the structure of the token * Localization * Error reporting * Session-oriented tokens * Alternate token exchange profiles Note also that the list is not bounded, and I expect that any work done after the finalization of OAuth as per the charter will happen only insofar as running exemplar code exists and can serve as a basis for standardization driven by actual involvement from the community. Does that satisfy the requirements? I definitely echo Eran's concerns that our primary task is the Core specification, but want to make sure that everyone has clear expectations and feels that they can make valuable contributions going in. cheers, b. On Tue, Feb 17, 2009 at 8:43 PM, wrote: > > I recall there was a lot of support in Minneapolis for extension targeted= for devices as Stephen suggests. I would support adding the text proposed= by Stephen to the OAUTH charter: > > "The WG will develop an oauth extension suited for use on challenged devi= ces and by aggregators that allows for the client to directly acquire an ac= cess token from a set of credentials. One such scheme is defined in draft-d= ehora-farrell-oauth-accesstoken-creds" > > I don't believe the last sentence precludes any other proposed drafts tha= t meet this goal, if there are other approaches that may be developing in t= he WG. > > Best Regards, > Dorothy > > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of= ext Stephen Farrell > Sent: Tuesday, February 17, 2009 8:15 AM > To: Hannes Tschofenig > Cc: oauth@ietf.org > Subject: Re: [oauth] draft-dehora-farrell-oauth-accesstoken-creds-00.txt = and OAUTH Extensions in the Charter > > > > Hannes Tschofenig wrote: >> Stephen ask me how their document >> draft-dehora-farrell-oauth-accesstoken-creds-00.txt is reflected in >> the charter text. > > Actually, I sent a mail to you and Blaine off list. I guess we should now= discuss it on the list, now that you've gone ahead here instead of respond= ing to the off list mail. > > Also I didn't ask how "its reflected" I suggested a way to include it, wh= ich is quite different. > > My suggestion is to add the following: > > "The WG will develop an oauth extension suited for use on challenged devi= ces and by aggregators that allows for the client to directly acquire an ac= cess token from a set of credentials. One such scheme is defined in draft-d= ehora-farrell-oauth-accesstoken-creds" > > I'd still like to see that included and will certainly suggest it again i= n SF, as I did in MSP, and without anyone (that I recall) disagreeing with = considering the use case. > >> Independent of this particular document, I believe that we should >> focus our initial efforts on the Base OAUTH specification rather than >> working on extensions. > > Agreed. I never asked that our use case be worked before the spec work is= done and have no idea how you formed that impression. > >> As such, I would say that (depending on the progress of the work with >> the main specification) we should discuss extensions in the summer >> timeframe. > > I think its fair enough to mention the AFAIK only proposed extension that= 's documented as an I-D in the charter. I don't read your current charter p= roposal as encompassing our draft without rechartering. > >> Regarding this specific extension: I read through >> draft-dehora-farrell-oauth-accesstoken-creds-00.txt and wanted to make >> sure that I understood the extension correctly. Here is a message flow >> that Jeff created some time ago. This document suggests to skip the >> message exchanges marked as (2.*). This means that the redirect from >> the Service Provider to the Customer and the subsequent steps of user >> authentication and authorization are replaced with the ability to >> carry some username/password in the Access token when the Consumer >> sends the request to the Service Provider. > > Right. > >> My personal view is that this goes a bit against the OAUTH idea. >> Unless the username/password is again created using some other >> mechanism (which the document does not describe) then there are >> vulnerability that OAUTH was initially meant to deal with. > > That's sort-of correct, however the point is that its necessary to deploy= OAuth for existing mobile devices and some aggregation use cases. > >> Additionally, the result is less likely to be easy to deploy. > > I think you're 100% wrong there...for the use cases we're considering. On= what basis do you say that? Do you think that HTTP redirects on mobiles ar= e just fine? > >> As a justification for the work the following argument is provided: >> "HTTP redirection to a browser is unavailable or unsuitable, such as >> intermediary aggregators and mobile or settop devices." I wonder >> whether this is really a problem in today's mobile devices to justify th= is optimization. > > You can wonder, but it is. > > Stephen. > > _______________________________________________ > oauth mailing 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 romeda@gmail.com Tue Feb 17 14:30:00 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C25E23A67D7 for ; Tue, 17 Feb 2009 14:30:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rrzwHGD5IHEq for ; Tue, 17 Feb 2009 14:29:59 -0800 (PST) Received: from mail-ew0-f21.google.com (mail-ew0-f21.google.com [209.85.219.21]) by core3.amsl.com (Postfix) with ESMTP id 3C3FC3A6964 for ; Tue, 17 Feb 2009 14:29:59 -0800 (PST) Received: by ewy14 with SMTP id 14so2468156ewy.13 for ; Tue, 17 Feb 2009 14:30:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=hUsBRoqeV8gVNW72UITghSTETg0I6T3rU2AuN4Rj0Cs=; b=vQKV+yqGQ9zi1fLmIE0hrmwqqcuZeXEfc4UWdi1MF31LuyKAASEfch0tQIj9a2ahn8 GcYiWFx9G5UhSh7h/HtwFYjiU3l0E6d+/6NwHetLqxKa9FlLhAlVVol8va28uniPGPQ5 rbLkON5chuDTceyOitxmfiCbKh+FLblmIjOwo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=X1IIyX9nsdUloqZVLeONNNuh+EQWNOrE1A8ommteLr0103ND9eUQ2icFFz+xP38la4 B2B+367xvxVQBe1XMQsyjCLZza4wAbsZaNg6f67G8NLqdEWYz3IlVd2pOLVfaoR7HaRg g5M2TpJONb/lLb/XK7CuwU2wTw1ukuxZ6wRTE= MIME-Version: 1.0 Received: by 10.210.19.7 with SMTP id 7mr3620388ebs.41.1234909808952; Tue, 17 Feb 2009 14:30:08 -0800 (PST) In-Reply-To: References: <009e01c99070$11d33100$0201a8c0@nsnintra.net> <499AE273.1010609@cs.tcd.ie> <26A704E322043948902DFFDD2CB493DB27E8CED2FE@NOK-EUMSG-01.mgdnok.nokia.com> Date: Tue, 17 Feb 2009 22:30:08 +0000 Message-ID: From: Blaine Cook To: Dorothy.Gellert@nokia.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Hannes.Tschofenig@gmx.net, oauth@ietf.org Subject: Re: [oauth] draft-dehora-farrell-oauth-accesstoken-creds-00.txt and OAUTH Extensions in the Charter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 22:30:00 -0000 One slight modification, as per an off-list conversation with Eran: move " * Error reporting" from extensions, and incorporate that work into the core spec, which I believe was agreed upon in principle several months ago at the start of this process. I don't think we need to modify the charter text, as error reporting would fall under the requirement to "promote interoperability", though we can add it explicitly if it makes sense. b. On Tue, Feb 17, 2009 at 9:57 PM, Blaine Cook wrote: > Can I suggest that we update the section of the charter before the > Goals and Milestones that currently reads: > > After delivering OAuth, the Working Group MAY consider defining > additional functions and/or extensions, for example (but not limited > to): > * Discovery of authentication configuration > * Message integrity > * Recommendations regarding the structure of the token > > > to read: > > After delivering OAuth, the Working Group MAY consider defining > additional functions and/or extensions, for example (but not limited > to): > * Discovery of OAuth configuration > * Comprehensive message integrity > * Recommendations regarding the structure of the token > * Localization > * Error reporting > * Session-oriented tokens > * Alternate token exchange profiles > > Note also that the list is not bounded, and I expect that any work > done after the finalization of OAuth as per the charter will happen > only insofar as running exemplar code exists and can serve as a basis > for standardization driven by actual involvement from the community. > > Does that satisfy the requirements? I definitely echo Eran's concerns > that our primary task is the Core specification, but want to make sure > that everyone has clear expectations and feels that they can make > valuable contributions going in. > > cheers, > > b. > > On Tue, Feb 17, 2009 at 8:43 PM, wrote: >> >> I recall there was a lot of support in Minneapolis for extension targete= d for devices as Stephen suggests. I would support adding the text propose= d by Stephen to the OAUTH charter: >> >> "The WG will develop an oauth extension suited for use on challenged dev= ices and by aggregators that allows for the client to directly acquire an a= ccess token from a set of credentials. One such scheme is defined in draft-= dehora-farrell-oauth-accesstoken-creds" >> >> I don't believe the last sentence precludes any other proposed drafts th= at meet this goal, if there are other approaches that may be developing in = the WG. >> >> Best Regards, >> Dorothy >> >> >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf O= f ext Stephen Farrell >> Sent: Tuesday, February 17, 2009 8:15 AM >> To: Hannes Tschofenig >> Cc: oauth@ietf.org >> Subject: Re: [oauth] draft-dehora-farrell-oauth-accesstoken-creds-00.txt= and OAUTH Extensions in the Charter >> >> >> >> Hannes Tschofenig wrote: >>> Stephen ask me how their document >>> draft-dehora-farrell-oauth-accesstoken-creds-00.txt is reflected in >>> the charter text. >> >> Actually, I sent a mail to you and Blaine off list. I guess we should no= w discuss it on the list, now that you've gone ahead here instead of respon= ding to the off list mail. >> >> Also I didn't ask how "its reflected" I suggested a way to include it, w= hich is quite different. >> >> My suggestion is to add the following: >> >> "The WG will develop an oauth extension suited for use on challenged dev= ices and by aggregators that allows for the client to directly acquire an a= ccess token from a set of credentials. One such scheme is defined in draft-= dehora-farrell-oauth-accesstoken-creds" >> >> I'd still like to see that included and will certainly suggest it again = in SF, as I did in MSP, and without anyone (that I recall) disagreeing with= considering the use case. >> >>> Independent of this particular document, I believe that we should >>> focus our initial efforts on the Base OAUTH specification rather than >>> working on extensions. >> >> Agreed. I never asked that our use case be worked before the spec work i= s done and have no idea how you formed that impression. >> >>> As such, I would say that (depending on the progress of the work with >>> the main specification) we should discuss extensions in the summer >>> timeframe. >> >> I think its fair enough to mention the AFAIK only proposed extension tha= t's documented as an I-D in the charter. I don't read your current charter = proposal as encompassing our draft without rechartering. >> >>> Regarding this specific extension: I read through >>> draft-dehora-farrell-oauth-accesstoken-creds-00.txt and wanted to make >>> sure that I understood the extension correctly. Here is a message flow >>> that Jeff created some time ago. This document suggests to skip the >>> message exchanges marked as (2.*). This means that the redirect from >>> the Service Provider to the Customer and the subsequent steps of user >>> authentication and authorization are replaced with the ability to >>> carry some username/password in the Access token when the Consumer >>> sends the request to the Service Provider. >> >> Right. >> >>> My personal view is that this goes a bit against the OAUTH idea. >>> Unless the username/password is again created using some other >>> mechanism (which the document does not describe) then there are >>> vulnerability that OAUTH was initially meant to deal with. >> >> That's sort-of correct, however the point is that its necessary to deplo= y OAuth for existing mobile devices and some aggregation use cases. >> >>> Additionally, the result is less likely to be easy to deploy. >> >> I think you're 100% wrong there...for the use cases we're considering. O= n what basis do you say that? Do you think that HTTP redirects on mobiles a= re just fine? >> >>> As a justification for the work the following argument is provided: >>> "HTTP redirection to a browser is unavailable or unsuitable, such as >>> intermediary aggregators and mobile or settop devices." I wonder >>> whether this is really a problem in today's mobile devices to justify t= his optimization. >> >> You can wonder, but it is. >> >> Stephen. >> >> _______________________________________________ >> oauth mailing list >> oauth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ >> oauth mailing list >> oauth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > From stephen.farrell@cs.tcd.ie Tue Feb 17 15:36: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 2318828C17F for ; Tue, 17 Feb 2009 15:36:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7SFeUUfgLviW for ; Tue, 17 Feb 2009 15:36:50 -0800 (PST) Received: from relay.imagine.ie (dns1.dns.imagine.ie [87.232.1.40]) by core3.amsl.com (Postfix) with ESMTP id 8A60F3A6A8A for ; Tue, 17 Feb 2009 15:36:49 -0800 (PST) Received: from mail1.int.imagine.ie (mail1 [87.232.1.152]) by relay.imagine.ie (Postfix) with ESMTP id 9689A3220B; Tue, 17 Feb 2009 23:36:59 +0000 (GMT) Received: from [10.87.48.9] (dsl-102-234.cust.imagine.ie [87.232.102.234]) by mail1.int.imagine.ie (8.13.4/8.13.4/Debian-3) with ESMTP id n1HNasRk009015 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 17 Feb 2009 23:36:55 GMT Message-ID: <499B4AC8.8070009@cs.tcd.ie> Date: Tue, 17 Feb 2009 23:39:52 +0000 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.16 (X11/20080707) MIME-Version: 1.0 To: Hannes Tschofenig References: <26A704E322043948902DFFDD2CB493DB27E8CED2FE@NOK-EUMSG-01.mgdnok.nokia.com> <004601c99147$d612c670$0201a8c0@nsnintra.net> In-Reply-To: <004601c99147$d612c670$0201a8c0@nsnintra.net> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0) X-Canit-Stats-ID: 37399557 - 543ec378124d (trained as not-spam) X-CanItPRO-Stream: outgoing X-Scanned-By: CanIt (www . roaringpenguin . com) on 87.232.1.52 Cc: Dorothy.Gellert@nokia.com, oauth@ietf.org Subject: Re: [oauth] draft-dehora-farrell-oauth-accesstoken-creds-00.txt and OAUTH Extensions in the Charter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 23:36:51 -0000 Hannes Tschofenig wrote: > I understand why Stephen asks for getting text about his extension added. I > can imagine that someone else comes up with their favorite extension, > simililarly as you listed in your mail. Right. This being the IETF, taking the trouble to write an I-D, boilerplate and all, counts, As does code. But one without the other is less good than having both. > In some sense it would be fair to add text about the other examples added as > well, if someone cares. Yes, folks writing drafts is a good idea. By all means include mention of topics with I-Ds. > I wonder what other folks in the group think about this topic? You can guess from the above - gate the list (for now) based on who's written up their stuff as an I-D. Doesn't preclude additions later but does require some work before getting on the list in the charter. Stephen. > > Ciao > Hannes > > > > ________________________________ > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > Behalf Of Eran Hammer-Lahav > Sent: 17 February, 2009 23:07 > To: Dorothy.Gellert@nokia.com; stephen.farrell@cs.tcd.ie; > Hannes.Tschofenig@gmx.net > Cc: oauth@ietf.org > Subject: Re: [oauth] > draft-dehora-farrell-oauth-accesstoken-creds-00.txt and OAUTH Extensions in > the Charter > > > I don't understand why we need to add this. > > There is nothing to stop people from proposing and developing such > ideas. So far we have little implementation experience with much of these > suggestions. The fact is, everyone here is correctly referring to these > ideas as *extensions*. The purpose of this working group is to figure out > the 'core' framework. Error handling is crucial to interop. > Internationalization is important when dealing with user interfaces which > OAuth does even in its core components. These make sense to *consider*. > > But why go and single out one extension just because it has an I-D? > I could have stood up at the BoF and listed at least 10 other extensions > with wide interest. Yahoo cares a lot about its Session extension. Google > cares a lot about a few OpenSocial extensions related to gadgets. We have > known limitations with the use of OAuth consumer credentials in desktop > applications. Many people asked for a standard way of consumer registration. > Discovery has been a big topic for the past year and a half. The choice of > signature method hash functions have been an issue in the past due to lack > to support for some on limited devices. The list goes on and on. > > OAuth Core represents a compromise that allowed a wide range of use > cases to agree on something that provided a good foundation and was based on > implementation experience. For the most part this WG must have the narrow > focus of taking draft-hammer-oauth and bringing it to IETF proposed standard > level. That means focusing on security and interop. Anything else should > come later. > > EHL > > > On 2/17/09 12:43 PM, "Dorothy.Gellert@nokia.com" > wrote: > > > > > > I recall there was a lot of support in Minneapolis for > extension targeted for devices as Stephen suggests. I would support adding > the text proposed by Stephen to the OAUTH charter: > > "The WG will develop an oauth extension suited for use on > challenged devices and by aggregators that allows for the client to directly > acquire an access token from a set of credentials. One such scheme is > defined in draft-dehora-farrell-oauth-accesstoken-creds" > > I don't believe the last sentence precludes any other > proposed drafts that meet this goal, if there are other approaches that may > be developing in the WG. > > Best Regards, > Dorothy > > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] > On Behalf Of ext Stephen Farrell > Sent: Tuesday, February 17, 2009 8:15 AM > To: Hannes Tschofenig > Cc: oauth@ietf.org > Subject: Re: [oauth] > draft-dehora-farrell-oauth-accesstoken-creds-00.txt and OAUTH Extensions in > the Charter > > > > Hannes Tschofenig wrote: > > Stephen ask me how their document > > draft-dehora-farrell-oauth-accesstoken-creds-00.txt is > reflected in > > the charter text. > > Actually, I sent a mail to you and Blaine off list. I guess > we should now discuss it on the list, now that you've gone ahead here > instead of responding to the off list mail. > > Also I didn't ask how "its reflected" I suggested a way to > include it, which is quite different. > > My suggestion is to add the following: > > "The WG will develop an oauth extension suited for use on > challenged devices and by aggregators that allows for the client to directly > acquire an access token from a set of credentials. One such scheme is > defined in draft-dehora-farrell-oauth-accesstoken-creds" > > I'd still like to see that included and will certainly > suggest it again in SF, as I did in MSP, and without anyone (that I recall) > disagreeing with considering the use case. > > > Independent of this particular document, I believe that we > should > > focus our initial efforts on the Base OAUTH specification > rather than > > working on extensions. > > Agreed. I never asked that our use case be worked before the > spec work is done and have no idea how you formed that impression. > > > As such, I would say that (depending on the progress of > the work with > > the main specification) we should discuss extensions in > the summer > > timeframe. > > I think its fair enough to mention the AFAIK only proposed > extension that's documented as an I-D in the charter. I don't read your > current charter proposal as encompassing our draft without rechartering. > > > Regarding this specific extension: I read through > > draft-dehora-farrell-oauth-accesstoken-creds-00.txt and > wanted to make > > sure that I understood the extension correctly. Here is a > message flow > > that Jeff created some time ago. This document suggests to > skip the > > message exchanges marked as (2.*). This means that the > redirect from > > the Service Provider to the Customer and the subsequent > steps of user > > authentication and authorization are replaced with the > ability to > > carry some username/password in the Access token when the > Consumer > > sends the request to the Service Provider. > > Right. > > > My personal view is that this goes a bit against the OAUTH > idea. > > Unless the username/password is again created using some > other > > mechanism (which the document does not describe) then > there are > > vulnerability that OAUTH was initially meant to deal with. > > That's sort-of correct, however the point is that its > necessary to deploy OAuth for existing mobile devices and some aggregation > use cases. > > > Additionally, the result is less likely to be easy to > deploy. > > I think you're 100% wrong there...for the use cases we're > considering. On what basis do you say that? Do you think that HTTP redirects > on mobiles are just fine? > > > As a justification for the work the following argument is > provided: > > "HTTP redirection to a browser is unavailable or > unsuitable, such as > > intermediary aggregators and mobile or settop devices." I > wonder > > whether this is really a problem in today's mobile devices > to justify this optimization. > > You can wonder, but it is. > > Stephen. > > _______________________________________________ > oauth mailing list > oauth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > oauth mailing list > oauth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > From stephen.farrell@cs.tcd.ie Tue Feb 17 15:40:58 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A9443A6AF9 for ; Tue, 17 Feb 2009 15:40:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 Ar+TUHIuA3X5 for ; Tue, 17 Feb 2009 15:40:57 -0800 (PST) Received: from relay.imagine.ie (relay.imagine.ie [87.232.1.40]) by core3.amsl.com (Postfix) with ESMTP id D6D483A6AFE for ; Tue, 17 Feb 2009 15:40:56 -0800 (PST) Received: from mail1.int.imagine.ie (mail1 [87.232.1.152]) by relay.imagine.ie (Postfix) with ESMTP id 5CC4A3222F; Tue, 17 Feb 2009 23:41:07 +0000 (GMT) Received: from [10.87.48.9] (dsl-102-234.cust.imagine.ie [87.232.102.234]) by mail1.int.imagine.ie (8.13.4/8.13.4/Debian-3) with ESMTP id n1HNf2Hj009617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 17 Feb 2009 23:41:04 GMT Message-ID: <499B4BC0.4050505@cs.tcd.ie> Date: Tue, 17 Feb 2009 23:44:00 +0000 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.16 (X11/20080707) MIME-Version: 1.0 To: Hannes Tschofenig References: <009e01c99070$11d33100$0201a8c0@nsnintra.net> <499AE273.1010609@cs.tcd.ie> <00ca01c9913c$1027aa30$0201a8c0@nsnintra.net> In-Reply-To: <00ca01c9913c$1027aa30$0201a8c0@nsnintra.net> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0) X-Canit-Stats-ID: 37399669 - c714820aabfd (trained as not-spam) X-CanItPRO-Stream: outgoing X-Scanned-By: CanIt (www . roaringpenguin . com) on 87.232.1.52 Cc: oauth@ietf.org Subject: Re: [oauth] draft-dehora-farrell-oauth-accesstoken-creds-00.txt and OAUTH Extensions in the Charter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 23:40:58 -0000 Sounds good. I'll see if we've the cycles to get a -01 out (and totally agree that -00 is missing an important applicability statement - we did however submit -00 in the 10 minutes before the MSP deadline, hence the omission:-) As to milestones, yes, I'd prefer that the charter have a milestone for draft-ietf-oauth-mobile-00 being 3-6 months after the WGLC on the base spec. But I can buy the idea of just mentioning the topic and re-doing the milestones after WGLC on the base spec. Stephen. Hannes Tschofenig wrote: > Hi Stephen, > > adding the text as an example of possible extensions the group should work > on is fine for me as we have already listed other possible extensions to the > charter text. I got the impression that you wanted to have a milestone added > already, which I believe would be premature given that the main focus of the > initial work should be spent on the main spec. As I can read from your > response you are agreeing with me on this issue. > > I still believe that the document needs to provide much more context about > the usage scenarios you have in mind and what the implications regarding > security area. The current version of the document is essentially only > describing the bare minimum. > > Can you ship an update for the IETF#74 cutoff date? > > Ciao > Hannes > > >> Hannes Tschofenig wrote: >>> Stephen ask me how their document >>> draft-dehora-farrell-oauth-accesstoken-creds-00.txt is reflected in >>> the charter text. >> Actually, I sent a mail to you and Blaine off list. I guess we >> should now discuss it on the list, now that you've gone ahead >> here instead of responding to the off list mail. >> >> Also I didn't ask how "its reflected" I suggested a way to >> include it, which is quite different. >> >> My suggestion is to add the following: >> >> "The WG will develop an oauth extension suited for use on >> challenged devices and by aggregators that allows for the >> client to directly acquire an access token from a set of >> credentials. One such scheme is defined in >> draft-dehora-farrell-oauth-accesstoken-creds" >> >> I'd still like to see that included and will certainly suggest >> it again in SF, as I did in MSP, and without anyone (that I >> recall) disagreeing with considering the use case. >> >>> Independent of this particular document, I believe that we should >>> focus our initial efforts on the Base OAUTH specification >> rather than >>> working on extensions. >> Agreed. I never asked that our use case be worked before the >> spec work is done and have no idea how you formed that impression. >> >>> As such, I would say that (depending on the progress of the >> work with >>> the main specification) we should discuss extensions in the summer >>> timeframe. >> I think its fair enough to mention the AFAIK only proposed >> extension that's documented as an I-D in the charter. I don't >> read your current charter proposal as encompassing our draft >> without rechartering. >> >>> Regarding this specific extension: I read through >>> draft-dehora-farrell-oauth-accesstoken-creds-00.txt and >> wanted to make >>> sure that I understood the extension correctly. Here is a >> message flow >>> that Jeff created some time ago. This document suggests to skip the >>> message exchanges marked as (2.*). This means that the redirect from >>> the Service Provider to the Customer and the subsequent >> steps of user >>> authentication and authorization are replaced with the ability to >>> carry some username/password in the Access token when the Consumer >>> sends the request to the Service Provider. >> Right. >> >>> My personal view is that this goes a bit against the OAUTH idea. >>> Unless the username/password is again created using some other >>> mechanism (which the document does not describe) then there are >>> vulnerability that OAUTH was initially meant to deal with. >> That's sort-of correct, however the point is that its >> necessary to deploy OAuth for existing mobile devices and some >> aggregation use cases. >> >>> Additionally, the result is less likely to be easy to deploy. >> I think you're 100% wrong there...for the use cases we're >> considering. On what basis do you say that? Do you think that >> HTTP redirects on mobiles are just fine? >> >>> As a justification for the work the following argument is provided: >>> "HTTP redirection to a browser is unavailable or unsuitable, such as >>> intermediary aggregators and mobile or settop devices." I wonder >>> whether this is really a problem in today's mobile devices >> to justify this optimization. >> >> You can wonder, but it is. >> >> Stephen. >> > > From hannes.tschofenig@nsn.com Tue Feb 17 23:51: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 6ECC928C1B8 for ; Tue, 17 Feb 2009 23:51:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.456 X-Spam-Level: X-Spam-Status: No, score=-3.456 tagged_above=-999 required=5 tests=[AWL=-0.857, 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 IkxWDoF2Rkej for ; Tue, 17 Feb 2009 23:51:05 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id F0F0428C1A3 for ; Tue, 17 Feb 2009 23:51:04 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n1I7pBvo026629 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 18 Feb 2009 08:51:11 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n1I7p139017780; Wed, 18 Feb 2009 08:51:09 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Feb 2009 08:50:25 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 18 Feb 2009 09:51:18 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4501102F36@FIESEXC015.nsn-intra.net> In-Reply-To: <30e8c781d5bc33846cf3f69ff4478632@serendipity.cx> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [oauth] Last Call for Comments: OAuth Charter Text Thread-Index: AcmRM8d+qio/gBR2S2iOKonxlHLQ+wAaTJcg References: <3D3C75174CB95F42AD6BCC56E5555B45010DB8F0@FIESEXC015.nsn-intra.net> <3D3C75174CB95F42AD6BCC56E5555B45010DB968@FIESEXC015.nsn-intra.net> <30e8c781d5bc33846cf3f69ff4478632@serendipity.cx> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Aaron Stone" X-OriginalArrivalTime: 18 Feb 2009 07:50:25.0095 (UTC) FILETIME=[8EF2F570:01C9919D] Cc: oauth@ietf.org Subject: Re: [oauth] Last Call for Comments: OAuth Charter Text X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 07:51:06 -0000 Hi Aaron,=20 I have considered your feedback in the charter.=20 A few minor comments below: =20 >-----Original Message----- >From: ext Aaron Stone [mailto:aaron@serendipity.cx]=20 >Sent: 17 February, 2009 21:18 >To: Tschofenig, Hannes (NSN - FI/Espoo) >Cc: oauth@ietf.org >Subject: Re: [oauth] Last Call for Comments: OAuth Charter Text > >Hi Hannes and WG, > >The middle paragraphs are pretty choppy and unclear to me. I=20 >think I get what's going on well enough not to complain (that=20 >is, "The Charter Looks Good Enough To Me (TM)"), but below are=20 >some suggested changes to clarify. > >Cheers, >Aaron > > >On Tue, 17 Feb 2009 11:35:17 +0200, "Tschofenig, Hannes (NSN -=20 >FI/Espoo)" > wrote: >> Btw, I should also indicate a deadline for providing comments.=20 >>=20 >> Please have your comments in no later than February 27th.=20 >>=20 >> Thanks.=20 > >[snip] >>>OAuth consists of: >>> * A mechanism for exchanging a user's credentials for a=20 >token-secret=20 >>>pair that can be used by a third party to access resources on their=20 >>>behalf. >>> * A mechanism for signing HTTP requests with the token-secret pair. >>> >>>The Working Group will produce one or more documents suitable for=20 >>>consideration as Proposed Standard, based upon the OAuth I-D, that=20 >>>will: > >Here we start with the OAuth I-D... > >Suggested replacement text: "The Working Group will produce=20 >one or more documents suitable for consideration as Proposed=20 >Standard. The Working Group will begin with the independently=20 >published OAuth 1.0 specification, and will:" I phrased it in the following way based on your and Stephen's feedback: " The Working Group will produce one or more documents suitable for consideration as Proposed Standard, based upon draft-hammer-oauth-00.txt, that will: " > >>> * Align OAuth with the Internet and Web architectures, best=20 >>>practices and terminology. >>> * Assure good security practice, or document gaps in its=20 >>>capabilities, and propose a path forward for addressing the gap. >>> * Promote interoperability. >>> * Provide guidelines for extensibility. >>> >>>This specifically means that as a starting point for the=20 >working group=20 >>>the OAuth 1.0 specification is used and the available=20 >extension points=20 >>>are going to be utilized. It seems > >What are "available extension points" ? -- Eran responded to this one.=20 > >>>desireable to profile OAuth 1.0 in a way that produces a=20 >specification=20 >>>that is a backwards compatible profile, i.e. an OAuth 1.0=20 >>>implementation and the specification produced by this group must=20 >>>support a basic set of features to guarantee interoperability. > >...here we talk about OAuth 1.0. What's the difference from=20 >the OAuth I-D in the previous paragraph? Nothing. I made this more clear in the text.=20 > >Suggested replacement paragraph: "As best as possible, the=20 >Working Group will produce a specification that is a backwards=20 >compatible profile of OAuth 1.0, i.e. an OAuth 1.0=20 >implementation and the specification(s) produced by this group=20 >will support a basic set of features to assure=20 >interoperability. The Working Group will also consider=20 >existing OAuth 1.0 extensions for interoperability with the=20 >updated specification(s)." I guess we cannot really write it that way based on the observation that we had a different understanding of what extension points would mean.=20 I believe that this issue got clarified in a separate discussion on the mailing list.=20 > >>>Furthermore, OAuth 1.0 defines three signature methods used=20 >to protect=20 >>>requests, namely PLAINTEXT, HMAC-SHA1, and RSA-SHA1. >>>The group will work on new signature methods and will describe the=20 >>>environments where new security requirements justify their usage.=20 >>>Existing signature methods will not be modified but may be=20 >dropped as=20 >>>part of the backwards compatible profiling activity. The=20 >applicability=20 >>>of existing and new signature methods to protocols other than HTTP=20 >>>will be investigated. >>> >>>In doing so, it should consider: > >s/ it / the Working Group / > >For me, "In doing so" refers to signature methods and=20 >applicability of signature methods to protocols other than=20 >HTTP. Is that correct? If not, let's replace "In doing so"=20 >with what we'd be so doing ;) You are right. The "in doing so" is an artifact from previous charter versions and now does not fit in there anymore. I removed it.=20 > >>> * Implementer experience. >>> * Existing uses of OAuth. >>> * Ability to achieve broad impementation. >>> * Ability to address broader use cases than may be contemplated by=20 >>>the original authors. >>> * Impact on the Internet and Web. >>> > >[cut] > Thanks for the feedback. Ciao Hannes From hannes.tschofenig@nsn.com Tue Feb 17 23:53: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 176D628C1A1 for ; Tue, 17 Feb 2009 23:53:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[AWL=1.200, 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 RWPMFCWPw9kq for ; Tue, 17 Feb 2009 23:53:20 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id D4BBA28C1AA for ; Tue, 17 Feb 2009 23:53:19 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n1I7rTJx023015 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 18 Feb 2009 08:53:29 +0100 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n1I7rReP014229 for ; Wed, 18 Feb 2009 08:53:29 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Feb 2009 08:52:34 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 18 Feb 2009 09:53:29 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4501102F3B@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updated Charter Text Thread-Index: AcmRnfy2jIv5/8wARU+hTph8bDCnyQ== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 18 Feb 2009 07:52:34.0717 (UTC) FILETIME=[DC35B4D0:01C9919D] Subject: [oauth] Updated Charter Text X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 07:53:21 -0000 Based on the feedback I have compiled another version of the charter text. =20 ------------------------------------------ Open Authentication Protocol (oauth) Last Modified: 2009-01-30 Chair(s): TBD Applications Area Director(s): Chris Newman Lisa Dusseault =20 Applications Area Advisor: TBD Mailing Lists: https://www.ietf.org/mailman/listinfo/oauth Description of Working Group: OAuth allows a user to grant a third-party Web site or application access to their resources, without necessarily revealing their credentials, or even their identity. For example, a photo-sharing site that supports OAuth would allow its users to use a third-party printing Web site to access their private pictures, without gaining full control of the user account. OAuth consists of: * A mechanism for exchanging a user's credentials for a token-secret pair which can be used by a third party to access resources on their behalf. * A mechanism for signing HTTP requests with the token-secret pair. The Working Group will produce one or more documents suitable for consideration as Proposed Standard, based upon draft-hammer-oauth-00.txt, that will: * Improve the terminology used. * Embody good security practice, or document gaps in its capabilities, and propose a path forward for addressing the gap. * Promote interoperability. * Provide guidelines for extensibility. This specifically means that as a starting point for the working group OAuth 1.0 (draft-hammer-oauth-00.txt) is used and the available extension points are going to be utilized. The WG will profile OAuth 1.0 in a way that produces a specification that is a backwards compatible profile, i.e. any OAuth 1.0 and the specification produced by this group must support a basic set of features to guarantee interoperability.=20 Furthermore, OAuth 1.0 defines three signature methods used to protect requests, namely PLAINTEXT, HMAC-SHA1, and RSA-SHA1. The group will work on new signature methods and will describe the environments where new security requirements justify their usage. Existing signature methods will not be modified but may be dropped as part of the backwards compatible profiling activity. The applicability of existing and new signature methods to protocols other than HTTP will be investigated. The Working Group should consider: * Implementer experience. * The end-user experience, including internationalization * Existing uses of OAuth. * Ability to achieve broad impementation. * Ability to address broader use cases than may be contemplated by the original authors. The Working Group is not tasked with defining a generally applicable HTTP Authentication mechanism (i.e., browser-based "2-leg" scenerio), and should consider this work out of scope in its discussions. However, if the deliverables are able to be factored in such a way that this is a byproduct, or such a scenario could be addressed by additional future work, the Working Group may choose to do so. After delivering OAuth, the Working Group may consider defining additional functions and/or extensions, for example (but not limited to): * Discovery of OAuth configuration. * Comprehensive message integrity. * Recommendations regarding the structure of the token. * Localization. * Session-oriented tokens. * Alternate token exchange profiles. Goals and Milestones: Apr 2009 Submit 'OAuth: HTTP Authorization Delegation Protocol' as working group item (draft-hammer-oauth will be used as a starting point for further work.) Jul 2009 Start of discussion about OAuth extensions the group should work on Oct 2009 Start Working Group Last Call on 'OAuth: HTTP Authorization Delegation Protocol' Nov 2009 Submit 'OAuth: HTTP Authorization Delegation Protocol' to the IESG for consideration as a Proposed Standard=20 Nov 2009 Prepare milestone update to start new work within the scope of the charter From stephen.farrell@cs.tcd.ie Wed Feb 18 03:07:16 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 466E628C1F0 for ; Wed, 18 Feb 2009 03:07:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.293 X-Spam-Level: X-Spam-Status: No, score=-0.293 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P3Py1gblhcgG for ; Wed, 18 Feb 2009 03:07:15 -0800 (PST) Received: from mail.newbay.com (87-198-172-198.ptr.magnet.ie [87.198.172.198]) by core3.amsl.com (Postfix) with ESMTP id 0F83B28C1DE for ; Wed, 18 Feb 2009 03:07:14 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.newbay.com (Postfix) with ESMTP id 6E0471003F4C7; Wed, 18 Feb 2009 11:07:25 +0000 (GMT) X-Virus-Scanned: amavisd-new at newbay.com Received: from mail.newbay.com ([127.0.0.1]) by localhost (mail.newbay.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-R4UQHVKxei; Wed, 18 Feb 2009 11:07:24 +0000 (GMT) Received: from [192.168.3.55] (unknown [192.168.3.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.newbay.com (Postfix) with ESMTP id 5274510040740; Wed, 18 Feb 2009 11:07:22 +0000 (GMT) Message-ID: <499BEC9E.10704@cs.tcd.ie> Date: Wed, 18 Feb 2009 11:10:22 +0000 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.16 (X11/20080707) MIME-Version: 1.0 To: "Tschofenig, Hannes (NSN - FI/Espoo)" References: <3D3C75174CB95F42AD6BCC56E5555B4501102F3B@FIESEXC015.nsn-intra.net> In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B4501102F3B@FIESEXC015.nsn-intra.net> 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] Updated Charter Text X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 11:07:16 -0000 Hate to keep banging the same drum, but I don't see how the mobile use case is included there, so I'd still suggest the addition below. (Other than that this charter is fine by me.) While I would like there to be a milestone associated with that, I'm ok if that's done later, so haven't suggested one. (If asked, I'd go for WGLC on a mobile draft 3-6 months after the WGLC starts on the base spec.) Stephen. Tschofenig, Hannes (NSN - FI/Espoo) wrote: > Based on the feedback I have compiled another version of the charter > text. > > ------------------------------------------ > > Open Authentication Protocol (oauth) > > Last Modified: 2009-01-30 > > Chair(s): > > TBD > > Applications Area Director(s): > > Chris Newman > Lisa Dusseault > > Applications Area Advisor: > > TBD > > Mailing Lists: > > https://www.ietf.org/mailman/listinfo/oauth > > Description of Working Group: > > OAuth allows a user to grant a third-party Web site or application > access to their resources, without necessarily revealing their > credentials, or even their identity. For example, a photo-sharing site > that supports OAuth would allow its users to use a third-party printing > Web site to access their private pictures, without gaining full control > of the user account. > > OAuth consists of: > * A mechanism for exchanging a user's credentials for a token-secret > pair which can be used by a third party to access resources on their > behalf. > * A mechanism for signing HTTP requests with the token-secret pair. > > The Working Group will produce one or more documents suitable for > consideration as Proposed Standard, based upon > draft-hammer-oauth-00.txt, that will: > * Improve the terminology used. > * Embody good security practice, or document gaps in its capabilities, > and propose a path forward for addressing the gap. > * Promote interoperability. > * Provide guidelines for extensibility. > > This specifically means that as a starting point for the working group > OAuth 1.0 (draft-hammer-oauth-00.txt) is used and the available > extension points are going to be utilized. The WG will profile OAuth > 1.0 in a way that produces a specification that is a backwards > compatible profile, i.e. any OAuth 1.0 and the specification produced > by this group must support a basic set of features to guarantee > interoperability. > > Furthermore, OAuth 1.0 defines three signature methods used to protect > requests, namely PLAINTEXT, HMAC-SHA1, and RSA-SHA1. The group will work > on new signature methods and will describe the environments where new > security requirements justify their usage. Existing signature methods > will not be modified but may be dropped as part of the backwards > compatible profiling activity. The applicability of existing and new > signature methods to protocols other than HTTP will be investigated. > > The Working Group should consider: > * Implementer experience. > * The end-user experience, including internationalization > * Existing uses of OAuth. > * Ability to achieve broad impementation. > * Ability to address broader use cases than may be contemplated by the > original authors. > > The Working Group is not tasked with defining a generally applicable > HTTP Authentication mechanism (i.e., browser-based "2-leg" scenerio), > and should consider this work out of scope in its discussions. However, > if the deliverables are able to be factored in such a way that this is a > byproduct, or such a scenario could be addressed by additional future > work, the Working Group may choose to do so. After delivering OAuth, the WG will, if necessary, develop an oauth extension suited for use on challenged devices and by aggregators that allows for the client to directly acquire an access token from a set of credentials. One such scheme is defined in draft-dehora-farrell-oauth-accesstoken-creds. > After delivering OAuth, the Working Group may consider defining > additional functions and/or extensions, for example (but not limited > to): > * Discovery of OAuth configuration. > * Comprehensive message integrity. > * Recommendations regarding the structure of the token. > * Localization. > * Session-oriented tokens. > * Alternate token exchange profiles. > > Goals and Milestones: > > Apr 2009 Submit 'OAuth: HTTP Authorization Delegation Protocol' as > working group item > (draft-hammer-oauth will be used as a starting point for > further work.) > Jul 2009 Start of discussion about OAuth extensions the group should > work on > Oct 2009 Start Working Group Last Call on 'OAuth: HTTP Authorization > Delegation Protocol' > Nov 2009 Submit 'OAuth: HTTP Authorization Delegation Protocol' to > the IESG for consideration as a Proposed Standard > Nov 2009 Prepare milestone update to start new work within the scope > of the charter > > > _______________________________________________ > oauth mailing list > oauth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From hannes.tschofenig@nsn.com Wed Feb 18 05:46: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 9D1B43A6A11 for ; Wed, 18 Feb 2009 05:46:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.474 X-Spam-Level: X-Spam-Status: No, score=-3.474 tagged_above=-999 required=5 tests=[AWL=-0.875, 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 VriVdYMTsIWl for ; Wed, 18 Feb 2009 05:46:43 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 13B733A6C66 for ; Wed, 18 Feb 2009 05:46:42 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n1IDkrIN014561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 18 Feb 2009 14:46:53 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n1IDkqe1013568; Wed, 18 Feb 2009 14:46:52 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Feb 2009 14:46:52 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 18 Feb 2009 15:47:48 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4501103309@FIESEXC015.nsn-intra.net> In-Reply-To: <499BEC9E.10704@cs.tcd.ie> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [oauth] Updated Charter Text Thread-Index: AcmRuRcY9A3k20maTNy9qcUC7OC1EAAFdQMg References: <3D3C75174CB95F42AD6BCC56E5555B4501102F3B@FIESEXC015.nsn-intra.net> <499BEC9E.10704@cs.tcd.ie> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Stephen Farrell" X-OriginalArrivalTime: 18 Feb 2009 13:46:52.0781 (UTC) FILETIME=[5B00D9D0:01C991CF] Cc: oauth@ietf.org Subject: Re: [oauth] Updated Charter Text X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 13:46:44 -0000 Hi Stephen,=20 you are a tough negotiator :-) I think Blaine tried to capture it with the following bullet: " * Alternate token exchange profiles. " Would adding something like the sentence below make you happier? " For example, profiles that take challenged devices and aggregators into account allowing for the client to directly acquire an access token from a set of credentials. " Ciao Hannes >-----Original Message----- >From: ext Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]=20 >Sent: 18 February, 2009 13:10 >To: Tschofenig, Hannes (NSN - FI/Espoo) >Cc: oauth@ietf.org >Subject: Re: [oauth] Updated Charter Text > > >Hate to keep banging the same drum, but I don't see how the=20 >mobile use case is included there, so I'd still suggest the=20 >addition below. (Other than that this charter is fine by me.) > >While I would like there to be a milestone associated with=20 >that, I'm ok if that's done later, so haven't suggested one. >(If asked, I'd go for WGLC on a mobile draft 3-6 months after=20 >the WGLC starts on the base spec.) > >Stephen. > >Tschofenig, Hannes (NSN - FI/Espoo) wrote: >> Based on the feedback I have compiled another version of the charter=20 >> text. >>=20 >> ------------------------------------------ >>=20 >> Open Authentication Protocol (oauth) >>=20 >> Last Modified: 2009-01-30 >>=20 >> Chair(s): >>=20 >> TBD >>=20 >> Applications Area Director(s): >>=20 >> Chris Newman >> Lisa Dusseault >>=20 >> Applications Area Advisor: >>=20 >> TBD >>=20 >> Mailing Lists: >>=20 >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> Description of Working Group: >>=20 >> OAuth allows a user to grant a third-party Web site or application=20 >> access to their resources, without necessarily revealing their=20 >> credentials, or even their identity. For example, a photo-sharing=20 >> site that supports OAuth would allow its users to use a third-party=20 >> printing Web site to access their private pictures, without gaining=20 >> full control of the user account. >>=20 >> OAuth consists of: >> * A mechanism for exchanging a user's credentials for a=20 >token-secret=20 >> pair which can be used by a third party to access resources on their=20 >> behalf. >> * A mechanism for signing HTTP requests with the token-secret pair. >>=20 >> The Working Group will produce one or more documents suitable for=20 >> consideration as Proposed Standard, based upon=20 >> draft-hammer-oauth-00.txt, that will: >> * Improve the terminology used. >> * Embody good security practice, or document gaps in its=20 >> capabilities, and propose a path forward for addressing the gap. >> * Promote interoperability. >> * Provide guidelines for extensibility. >>=20 >> This specifically means that as a starting point for the=20 >working group=20 >> OAuth 1.0 (draft-hammer-oauth-00.txt) is used and the available=20 >> extension points are going to be utilized. The WG will=20 >profile OAuth=20 >> 1.0 in a way that produces a specification that is a backwards=20 >> compatible profile, i.e. any OAuth 1.0 and the=20 >specification produced=20 >> by this group must support a basic set of features to guarantee=20 >> interoperability. >>=20 >> Furthermore, OAuth 1.0 defines three signature methods used=20 >to protect=20 >> requests, namely PLAINTEXT, HMAC-SHA1, and RSA-SHA1. The group will=20 >> work on new signature methods and will describe the=20 >environments where=20 >> new security requirements justify their usage. Existing signature=20 >> methods will not be modified but may be dropped as part of the=20 >> backwards compatible profiling activity. The applicability=20 >of existing=20 >> and new signature methods to protocols other than HTTP will=20 >be investigated. >>=20 >> The Working Group should consider: >> * Implementer experience. >> * The end-user experience, including internationalization >> * Existing uses of OAuth. >> * Ability to achieve broad impementation. >> * Ability to address broader use cases than may be contemplated by=20 >> the original authors. >>=20 >> The Working Group is not tasked with defining a generally applicable=20 >> HTTP Authentication mechanism (i.e., browser-based "2-leg"=20 >scenerio),=20 >> and should consider this work out of scope in its discussions.=20 >> However, if the deliverables are able to be factored in such a way=20 >> that this is a byproduct, or such a scenario could be addressed by=20 >> additional future work, the Working Group may choose to do so. > >After delivering OAuth, the WG will, if necessary, develop an=20 >oauth extension suited for use on challenged devices and by=20 >aggregators that allows for the client to directly acquire an=20 >access token from a set of credentials. One such scheme is=20 >defined in draft-dehora-farrell-oauth-accesstoken-creds. > > >> After delivering OAuth, the Working Group may consider defining=20 >> additional functions and/or extensions, for example (but not limited >> to): >> * Discovery of OAuth configuration. >> * Comprehensive message integrity. >> * Recommendations regarding the structure of the token. >> * Localization. >> * Session-oriented tokens. >> * Alternate token exchange profiles. >> >> Goals and Milestones: >>=20 >> Apr 2009 Submit 'OAuth: HTTP Authorization Delegation Protocol' as >> working group item >> (draft-hammer-oauth will be used as a starting point for=20 >> further work.) >> Jul 2009 Start of discussion about OAuth extensions the=20 >group should >> work on >> Oct 2009 Start Working Group Last Call on 'OAuth: HTTP=20 >Authorization >> Delegation Protocol' >> Nov 2009 Submit 'OAuth: HTTP Authorization Delegation Protocol' to >> the IESG for consideration as a Proposed Standard=20 >> Nov 2009 Prepare milestone update to start new work=20 >within the scope >> of the charter >>=20 >>=20 >> _______________________________________________ >> oauth mailing list >> oauth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 > From romeda@gmail.com Wed Feb 18 06:01:36 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAB9C3A6D26 for ; Wed, 18 Feb 2009 06:01:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F82Zr4lSaciB for ; Wed, 18 Feb 2009 06:01:36 -0800 (PST) Received: from mail-ew0-f21.google.com (mail-ew0-f21.google.com [209.85.219.21]) by core3.amsl.com (Postfix) with ESMTP id AE6863A6CC3 for ; Wed, 18 Feb 2009 06:01:35 -0800 (PST) Received: by ewy14 with SMTP id 14so2709958ewy.13 for ; Wed, 18 Feb 2009 06:01:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=UdVpaI9oD80c9W6lLP8HWPGV97p/RWKAhhLuIwzXTbQ=; b=drUMXJysV65VmtPQc6wgLXfj6LrIC7dvGdkEwP7hNKO0qvx+nqo0KZs0hIeWVEFkMX kl/Y3ArrP7ED543D/higFcHuisYZTtFL9MuFijSnNoxlqeQF1bsOAJt2Fj5fYI/00ggk Fh1duJD1n3pMyEWI0yGfOZohNS54F79db0WfM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=BaQ5601PYTGN+56nAFvlpk035F6V6dXOiNuAEEvF2xisfwrh8eZqNVuJzouo2tJwNA nq0IEdaoGrNt/qgh93+1WtkrhOS9sIbKb16wn5gAquA6Dyzc2uVpJtOgACWQE4cM3dE6 7TmQBpafOjXfl1vKnJDym+xzQg4Rxw9SvBhEI= MIME-Version: 1.0 Received: by 10.210.53.5 with SMTP id b5mr2486229eba.131.1234965706261; Wed, 18 Feb 2009 06:01:46 -0800 (PST) In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B4501103309@FIESEXC015.nsn-intra.net> References: <3D3C75174CB95F42AD6BCC56E5555B4501102F3B@FIESEXC015.nsn-intra.net> <499BEC9E.10704@cs.tcd.ie> <3D3C75174CB95F42AD6BCC56E5555B4501103309@FIESEXC015.nsn-intra.net> Date: Wed, 18 Feb 2009 14:01:46 +0000 Message-ID: From: Blaine Cook To: "Tschofenig, Hannes (NSN - FI/Espoo)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: oauth@ietf.org Subject: Re: [oauth] Updated Charter Text X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 14:01:36 -0000 On Wed, Feb 18, 2009 at 1:47 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > Hi Stephen, > > you are a tough negotiator :-) > > I think Blaine tried to capture it with the following bullet: > " > * Alternate token exchange profiles. > " Correct ;-) There are a few other approaches to exchanging tokens that may be useful in different contexts, and I don't want to close the door on those if people care about them. I absolutely consider the mobile/challenged device use case as critical to address either in the core spec or, if that's not possible, as an alternate token exchange profile. > Would adding something like the sentence below make you happier? > > " > For example, profiles that take challenged devices and aggregators into > account allowing for the client to directly acquire an access token from > a set of credentials. > " I'm weary about being too specific. I appreciate that there is an I-D, but there are also several OAuth extension specs that are well documented and in active use in the wild, but do not have specific attention in the charter. I also worry that we haven't properly evaluated the case history nor have we attempted to outline what other approaches are possible and discuss the various trade-offs. Committing to a single profile and use case without a proper discussion and clear consensus seems backwards to me. My current feeling on the matter is that we have a charter which provides ample room for discussion and implementation of the accesstoken-creds I-D, without explicitly committing to it (which is something I'm personally not prepared to do, and my impression is that few are or will be until we have the core OAuth work complete). b. From stephen.farrell@cs.tcd.ie Wed Feb 18 06:38: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 DBEC928C104 for ; Wed, 18 Feb 2009 06:38:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.293 X-Spam-Level: X-Spam-Status: No, score=-0.293 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7lEuh4iwZ8e7 for ; Wed, 18 Feb 2009 06:38:48 -0800 (PST) Received: from mail.newbay.com (87-198-172-198.ptr.magnet.ie [87.198.172.198]) by core3.amsl.com (Postfix) with ESMTP id C45A63A6D2A for ; Wed, 18 Feb 2009 06:38:47 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.newbay.com (Postfix) with ESMTP id D434E1004159B; Wed, 18 Feb 2009 14:38:58 +0000 (GMT) X-Virus-Scanned: amavisd-new at newbay.com Received: from mail.newbay.com ([127.0.0.1]) by localhost (mail.newbay.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6NcPMdm6nQFM; Wed, 18 Feb 2009 14:38:58 +0000 (GMT) Received: from [192.168.3.55] (unknown [192.168.3.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.newbay.com (Postfix) with ESMTP id B5F921003F4C7; Wed, 18 Feb 2009 14:38:55 +0000 (GMT) Message-ID: <499C1E37.6030105@cs.tcd.ie> Date: Wed, 18 Feb 2009 14:41:59 +0000 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.16 (X11/20080707) MIME-Version: 1.0 To: Blaine Cook References: <3D3C75174CB95F42AD6BCC56E5555B4501102F3B@FIESEXC015.nsn-intra.net> <499BEC9E.10704@cs.tcd.ie> <3D3C75174CB95F42AD6BCC56E5555B4501103309@FIESEXC015.nsn-intra.net> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , oauth@ietf.org Subject: Re: [oauth] Updated Charter Text X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 14:38:49 -0000 Blaine Cook wrote: > On Wed, Feb 18, 2009 at 1:47 PM, Tschofenig, Hannes (NSN - FI/Espoo) > wrote: >> Hi Stephen, >> >> you are a tough negotiator :-) >> >> I think Blaine tried to capture it with the following bullet: >> " >> * Alternate token exchange profiles. >> " I didn't get that when I read it. > Correct ;-) There are a few other approaches to exchanging tokens that > may be useful in different contexts, and I don't want to close the > door on those if people care about them. I absolutely consider the > mobile/challenged device use case as critical to address either in the > core spec or, if that's not possible, as an alternate token exchange > profile. Good. Me too:-) >> Would adding something like the sentence below make you happier? >> >> " >> For example, profiles that take challenged devices and aggregators into >> account allowing for the client to directly acquire an access token from >> a set of credentials. >> " That'd do it for me. If you're both ok with adding that you can stop reading now:-) > I'm weary about being too specific. I appreciate that there is an I-D, > but there are also several OAuth extension specs that are well > documented and in active use in the wild, but do not have specific > attention in the charter. Sure. OTOH, anyone can write an I-D and that is the IETF process, so one shouldn't be penalised for actually doing the right thing, right? I'll be interested in seeing how many of those other extensions get pushed into the IETF process. As of now, that's zero. So there's a justification for this use case (which we agree is critical) to be called out up front. (And to be clear, the reason I'm hammering on this is so that the WG can choose to adopt an I-D on the topic without first rechartering.) > I also worry that we haven't properly > evaluated the case history nor have we attempted to outline what other > approaches are possible and discuss the various trade-offs. Committing > to a single profile and use case without a proper discussion and clear > consensus seems backwards to me. I've no problem with that. Even if our I-D is named in the charter, there's no guarantee that it gets adopted by the WG and the proposed charter text I sent doesn't assume that it will be adopted. Its quite common for there to be a number of draft-author-foo drafts only one of which becomes draft-ietf-wg-foo and that's just fine. From my POV the important thing is that the WG is chartered to address the use case. Our I-D is currently just one approach. > My current feeling on the matter is that we have a charter which > provides ample room for discussion and implementation of the > accesstoken-creds I-D, without explicitly committing to it (which is > something I'm personally not prepared to do, and my impression is that > few are or will be until we have the core OAuth work complete). And I wouldn't, and didn't, ask for that. Stephen. > > b. > From lisa.dusseault@gmail.com Thu Feb 19 13:59: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 954A23A6ABF for ; Thu, 19 Feb 2009 13:59:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.019 X-Spam-Level: X-Spam-Status: No, score=-1.019 tagged_above=-999 required=5 tests=[AWL=-1.021, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uruD60WAh2Dp for ; Thu, 19 Feb 2009 13:59:48 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235]) by core3.amsl.com (Postfix) with ESMTP id 9D34E3A6807 for ; Thu, 19 Feb 2009 13:59:36 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so570920rvb.49 for ; Thu, 19 Feb 2009 13:59:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=dV/+7UsOGATRSo2LBlzuhQmSbMbO3jLHyUksHOFbh1E=; b=EteIyyYcYdaTV1CY5mOPF+x5SsDTzKwaoqJd0QGZSCZCTK7YpUPa6pQHWySli1zs0n XQ9O0nvsfGv79cAUr65ngLQ5Hvafh3wikGpFcTtrCXL9g4aojj+CXCN+1lkGBHq3Hg2+ 9eolaDHsRN+Qshu+z0+9q71K3ZTgy0XDpvfHg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=HKtgPZey97VYjsyg/AsTM7G5ORjrWWyeCwCVpLZPQdoZYqwdqf1100QADKhepsu2q5 6vUQ2JOfR/sEQqgGMBhAWs2hLAdovATT2K+1+H8kOLOryAAMEbCf64JUYvqihqERrI4u mJrQeuNB9s65w6n4ctQprtCEV1CeWg14y8vHI= MIME-Version: 1.0 Received: by 10.141.122.20 with SMTP id z20mr17405rvm.171.1235080789682; Thu, 19 Feb 2009 13:59:49 -0800 (PST) Date: Thu, 19 Feb 2009 13:59:49 -0800 Message-ID: From: Lisa Dusseault To: oauth Content-Type: multipart/alternative; boundary=000e0cd21528bcebb404634ca740 Subject: [oauth] "Fixing OAuth" blog post X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 21:59:49 -0000 --000e0cd21528bcebb404634ca740 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit >From http://blog.atebits.com/2009/02/fixing-oauth/ ... a few years from now when OAuth is *finally* integrated sensibly, I think it actually will be *quite* nice. "Integrated sensibly" is key. Today is an opportunityto get it right. [...] I think the ultimate goal is to have a single, global, native-looking, "blessed" authentication gateway on every device. This gateway could be expressed on different devices in different ways. On the iPhone for example, it could be represented as a special OS-provided window (running in a protected process) that slid up over an app, allowing the user to enter a password (or authenticate via something else like OpenID). The sheet would then slide back down revealing the app after authentication was complete. The requesting app would never need to quit. There would be no need for any web pages, and the authentication experience would be completely standardized across *every* app on that device that used OAuth. --000e0cd21528bcebb404634ca740 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
From http://b= log.atebits.com/2009/02/fixing-oauth/

 ... a few years from now when OAuth is finally integ= rated sensibly, I think it actually will be quite nice.  "Int= egrated sensibly" is key. Today is an opportunity to get it right.<= br> [...]

I think the ultimate g= oal is to have a single, global, native-looking, "blessed" authentication gateway on every device. This gateway could be expressed on different devices in different ways. On the iPhone for example, it could be represented as a special OS-provided window (running in a protected process) that slid up over an app, allowing the user to enter a password (or authenticate via something else like OpenID). The sheet would then slide back down revealing the app after authentication was complete. The requesting app would never need to quit. There would be no need for any web pages, and the authentication experience would be completely standardized across every app on th= at device that used OAuth.
--000e0cd21528bcebb404634ca740-- From kellan@gmail.com Thu Feb 19 14:12: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 0BCD728C13A for ; Thu, 19 Feb 2009 14:12:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GcVkAiIG+Af3 for ; Thu, 19 Feb 2009 14:12:48 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.233]) by core3.amsl.com (Postfix) with ESMTP id 09CE83A6C26 for ; Thu, 19 Feb 2009 14:12:48 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id g9so493029rvb.5 for ; Thu, 19 Feb 2009 14:13:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=q3xogBUB5pNSM65D3I8dkK/QMLXiNf4v2a/Mm5g8rKo=; b=MyMDyeCObDBphWIdXm9l7pJDIOnkWyr3+MJpM12fAk92k3Lc+/darUfs009uQBn44i TTdCKQ+eA/piB2ofh6q48QhUN8f/S9ct0FnY81xa+z1sor+T7D2ZvrksSOJ3eQ1wB5ha 2u3qzXLR6RfQ5zscqH5++e49mNtSoQgx9uBAc= 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=ir6+phdiDGIQKA8qKp7kgdvQHPpY3RwzhbEafOam41VcLZrVPRvDsrHU00ZT/utkYf h6Jk4RWnSred8RtDjPqQYXNo74GUbQrX9MLrp32tCi3No3O4b3iKNVWBz/vyXi642PvZ mQSpFZv3TUjeTSrB7myQjd75oi+v3NridqINQ= MIME-Version: 1.0 Sender: kellan@gmail.com Received: by 10.142.156.2 with SMTP id d2mr31314wfe.64.1235081581043; Thu, 19 Feb 2009 14:13:01 -0800 (PST) In-Reply-To: References: Date: Thu, 19 Feb 2009 17:13:01 -0500 X-Google-Sender-Auth: 787f9878252f85d2 Message-ID: <422b9b380902191413g24573f20h1ba086fbce835c41@mail.gmail.com> From: kellan To: Lisa Dusseault Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: oauth Subject: Re: [oauth] "Fixing OAuth" blog post X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 22:12:49 -0000 I think we're seeing this sort of push back in the context of Twitter API community for several reasons. 1. The developers which have been successful are naturally comfortable, and change is painful. 2. The security concerns around rogue access to your Twitter account are *comparatively* minor. 3. There isn't much in the way of a meaningful gradient of access for Twitter, though even allowing a differentiation of read/write access is going to be a huge win for the community (if not particularly exciting to developers of Twitter clients, like atebit) Additionally its natural for API consumers to tend to think in terms of convenience, with possible concessions to the issue of rogue operators, where the real challenges for an API provider are control, predictability, and bumbling/misguided operators. I think the disaster of the delegated auth as a viable user experience as rather spectacularly failed to prove itself in the field. Which is not to say the experience can't and shouldn't be improved as the nature of our devices shift, and it was with an eye to flexibility and allowing that kind of improvement to emerge that we struggled to keep the core spec simple. -kellan On Thu, Feb 19, 2009 at 4:59 PM, Lisa Dusseault wrote: > > From http://blog.atebits.com/2009/02/fixing-oauth/ > > ... a few years from now when OAuth is finally integrated sensibly, I think > it actually will be quite nice. "Integrated sensibly" is key. Today is an > opportunity to get it right. > [...] > > I think the ultimate goal is to have a single, global, native-looking, > "blessed" authentication gateway on every device. This gateway could be > expressed on different devices in different ways. On the iPhone for example, > it could be represented as a special OS-provided window (running in a > protected process) that slid up over an app, allowing the user to enter a > password (or authenticate via something else like OpenID). The sheet would > then slide back down revealing the app after authentication was complete. > The requesting app would never need to quit. There would be no need for any > web pages, and the authentication experience would be completely > standardized across every app on that device that used OAuth. > > _______________________________________________ > oauth mailing list > oauth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From john@jkemp.net Thu Feb 19 14:13:13 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E82063A6C2C for ; Thu, 19 Feb 2009 14:13:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.521 X-Spam-Level: X-Spam-Status: No, score=-1.521 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UU5D1Fflk0xD for ; Thu, 19 Feb 2009 14:13:13 -0800 (PST) Received: from outbound-mail-144.bluehost.com (outbound-mail-144.bluehost.com [67.222.38.34]) by core3.amsl.com (Postfix) with SMTP id F2A503A68EC for ; Thu, 19 Feb 2009 14:13:12 -0800 (PST) Received: (qmail 15307 invoked by uid 0); 19 Feb 2009 22:11:00 -0000 Received: from unknown (HELO box320.bluehost.com) (69.89.31.120) by outboundproxy5.bluehost.com with SMTP; 19 Feb 2009 22:11:00 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=jkemp.net; h=Received:Cc:Message-Id:From:To:In-Reply-To:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:References:X-Mailer:X-Identified-User; b=wxw6oDxBCM6xi9rI7eLTrxy4+folaY4KodULFlnE78FtQpbJDPHAfKbq7OGRZEOjZUtRE+o2GQ66lz8aEJut7K0ki26eDEEh2qJKPJlFeMNIB0wryP0HBrQtnU0vbcxw; Received: from cpe-69-205-56-47.nycap.res.rr.com ([69.205.56.47] helo=mztrcscn117.americas.nokia.com) by box320.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1LaH94-0001J6-I6; Thu, 19 Feb 2009 15:13:26 -0700 Message-Id: From: John Kemp To: Lisa Dusseault 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 v930.3) Date: Thu, 19 Feb 2009 17:13:24 -0500 References: X-Mailer: Apple Mail (2.930.3) X-Identified-User: {1122:box320.bluehost.com:jkempnet:jkemp.net} {sentby:smtp auth 69.205.56.47 authed with john+jkemp.net} Cc: oauth Subject: Re: [oauth] "Fixing OAuth" blog post X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 22:13:14 -0000 On Feb 19, 2009, at 4:59 PM, Lisa Dusseault wrote: > From http://blog.atebits.com/2009/02/fixing-oauth/ > > ... a few years from now when OAuth is finally integrated sensibly, > I think it actually will be quite nice. "Integrated sensibly" is > key. Today is an opportunity to get it right. > [...] > > I think the ultimate goal is to have a single, global, native- > looking, "blessed" authentication gateway on every device. This > gateway could be expressed on different devices in different ways. > On the iPhone for example, it could be represented as a special OS- > provided window (running in a protected process) that slid up over > an app, allowing the user to enter a password (or authenticate via > something else like OpenID). The sheet would then slide back down > revealing the app after authentication was complete. The requesting > app would never need to quit. There would be no need for any web > pages, and the authentication experience would be completely > standardized across every app on that device that used OAuth. http://tools.ietf.org/html/draft-dehora-farrell-oauth-accesstoken-creds-00 is perhaps a good start. Regards, - johnk From romeda@gmail.com Thu Feb 19 17:18: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 A27B33A68C8 for ; Thu, 19 Feb 2009 17:18:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 PbwKjHWuYD7e for ; Thu, 19 Feb 2009 17:18:55 -0800 (PST) Received: from mail-ew0-f21.google.com (mail-ew0-f21.google.com [209.85.219.21]) by core3.amsl.com (Postfix) with ESMTP id 181EF3A68B4 for ; Thu, 19 Feb 2009 17:18:54 -0800 (PST) Received: by ewy14 with SMTP id 14so649837ewy.13 for ; Thu, 19 Feb 2009 17:19:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=kKK9rHZyFZxj+ALLhE9+O+hXzTOJlCTxP/1Fi2qGWG0=; b=OXGSQjokAPX6w/I4ZDAE5Tbl14XXVtda4aio7PGTXyK+/bS3p/wi9t3QHEVTfeI7W9 Q1ZNudTvfwsvulF+PUnJvlf6ufdwMtvegeBg4ZbZxiMvhmUTMi+/0Y2XWg5KuRcbb9Gq fpTXuW87kPvc2PcoxOruQjz25fRECv0EEWzMI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=s5pBfseA9+nGfdIQ5fxH9y0y1xIhivphcNT6ATxLXPAN3dzovlvkvJS/R3qH628UQv vNDe7vmSyHg11wiYkXkL6CzX08YGDMVwk6yaV1oZd1CvQoYbgx8RY/TDmZdwpgRViqbR vLNIAgxBx+PiBUG75gDORQz8Bn2ZbdjJiRY7o= MIME-Version: 1.0 Received: by 10.210.105.20 with SMTP id d20mr154933ebc.142.1235092747252; Thu, 19 Feb 2009 17:19:07 -0800 (PST) In-Reply-To: <499C1E37.6030105@cs.tcd.ie> References: <3D3C75174CB95F42AD6BCC56E5555B4501102F3B@FIESEXC015.nsn-intra.net> <499BEC9E.10704@cs.tcd.ie> <3D3C75174CB95F42AD6BCC56E5555B4501103309@FIESEXC015.nsn-intra.net> <499C1E37.6030105@cs.tcd.ie> Date: Fri, 20 Feb 2009 01:19:07 +0000 Message-ID: From: Blaine Cook To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , oauth@ietf.org Subject: Re: [oauth] Updated Charter Text X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 01:18:56 -0000 Ok, proposed text, disambiguating the sorts of extensions we're interested in addressing: After delivering OAuth, the Working Group may consider defining additional functions and/or extensions, for example (but not limited to): * Discovery of OAuth configuration. e.g., http://oauth.net/discovery/1.0 * Comprehensive message integrity e.g., http://oauth.googlecode.com/svn/spec/ext/body_hash/1.0/drafts/1/spec.html. * Recommendations regarding the structure of the token. * Localization e.g., http://oauth.googlecode.com/svn/spec/ext/language_preference/1.0/drafts/2/spec.html * Session-oriented tokens e.g., http://oauth.googlecode.com/svn/spec/ext/session/1.0/drafts/1/spec.html * Alternate token exchange profiles e.g., draft-dehora-farrell-oauth-accesstoken-creds-00 b. On Wed, Feb 18, 2009 at 2:41 PM, Stephen Farrell wrote: > > > Blaine Cook wrote: >> On Wed, Feb 18, 2009 at 1:47 PM, Tschofenig, Hannes (NSN - FI/Espoo) >> wrote: >>> Hi Stephen, >>> >>> you are a tough negotiator :-) >>> >>> I think Blaine tried to capture it with the following bullet: >>> " >>> * Alternate token exchange profiles. >>> " > > I didn't get that when I read it. > >> Correct ;-) There are a few other approaches to exchanging tokens that >> may be useful in different contexts, and I don't want to close the >> door on those if people care about them. I absolutely consider the >> mobile/challenged device use case as critical to address either in the >> core spec or, if that's not possible, as an alternate token exchange >> profile. > > Good. Me too:-) > >>> Would adding something like the sentence below make you happier? >>> >>> " >>> For example, profiles that take challenged devices and aggregators into >>> account allowing for the client to directly acquire an access token from >>> a set of credentials. >>> " > > That'd do it for me. If you're both ok with adding that you > can stop reading now:-) > >> I'm weary about being too specific. I appreciate that there is an I-D, >> but there are also several OAuth extension specs that are well >> documented and in active use in the wild, but do not have specific >> attention in the charter. > > Sure. OTOH, anyone can write an I-D and that is the IETF > process, so one shouldn't be penalised for actually doing > the right thing, right? > > I'll be interested in seeing how many of those other > extensions get pushed into the IETF process. As of now, > that's zero. So there's a justification for this use > case (which we agree is critical) to be called out > up front. (And to be clear, the reason I'm hammering > on this is so that the WG can choose to adopt an > I-D on the topic without first rechartering.) > >> I also worry that we haven't properly >> evaluated the case history nor have we attempted to outline what other >> approaches are possible and discuss the various trade-offs. Committing >> to a single profile and use case without a proper discussion and clear >> consensus seems backwards to me. > > I've no problem with that. Even if our I-D is named in > the charter, there's no guarantee that it gets adopted by > the WG and the proposed charter text I sent doesn't > assume that it will be adopted. Its quite common for > there to be a number of draft-author-foo drafts only > one of which becomes draft-ietf-wg-foo and that's > just fine. From my POV the important thing is that the > WG is chartered to address the use case. Our I-D > is currently just one approach. > >> My current feeling on the matter is that we have a charter which >> provides ample room for discussion and implementation of the >> accesstoken-creds I-D, without explicitly committing to it (which is >> something I'm personally not prepared to do, and my impression is that >> few are or will be until we have the core OAuth work complete). > > And I wouldn't, and didn't, ask for that. > > Stephen. > >> >> b. >> > From stephen.farrell@cs.tcd.ie Fri Feb 20 02:46: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 8670F3A69D4 for ; Fri, 20 Feb 2009 02:46:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 bOGMk0tKbN1i for ; Fri, 20 Feb 2009 02:46:27 -0800 (PST) Received: from relay.imagine.ie (dns2.dns.imagine.ie [87.232.1.41]) by core3.amsl.com (Postfix) with ESMTP id 1AE503A6AF7 for ; Fri, 20 Feb 2009 02:46:26 -0800 (PST) Received: from mail2.int.imagine.ie (mail2 [87.232.1.153]) by relay.imagine.ie (Postfix) with ESMTP id D98E146E0; Fri, 20 Feb 2009 10:46:39 +0000 (GMT) Received: from [10.87.48.2] (dsl-102-234.cust.imagine.ie [87.232.102.234]) by mail2.int.imagine.ie (8.13.4/8.13.4/Debian-3) with ESMTP id n1KAkbpo031346; Fri, 20 Feb 2009 10:46:37 GMT References: <3D3C75174CB95F42AD6BCC56E5555B4501102F3B@FIESEXC015.nsn-intra.net> <499BEC9E.10704@cs.tcd.ie> <3D3C75174CB95F42AD6BCC56E5555B4501103309@FIESEXC015.nsn-intra.net> <499C1E37.6030105@cs.tcd.ie> Message-Id: <1FE0F60B-C2B3-4A84-8088-A0C14A313288@cs.tcd.ie> From: Stephen Farrell To: Blaine Cook In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (5G77) Mime-Version: 1.0 (iPhone Mail 5G77) Date: Fri, 20 Feb 2009 10:42:58 +0000 X-Bayes-Prob: 0.0001 (Score 0) X-Canit-Stats-ID: 37492561 - c0021128fa92 (trained as not-spam) X-CanItPRO-Stream: outgoing X-Scanned-By: CanIt (www . roaringpenguin . com) on 87.232.1.53 Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , "oauth@ietf.org" Subject: Re: [oauth] Updated Charter Text X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 10:46:28 -0000 Works for me, Stephen On 20 Feb 2009, at 01:19, Blaine Cook wrote: > Ok, proposed text, disambiguating the sorts of extensions we're > interested in addressing: > > After delivering OAuth, the Working Group may consider defining > additional functions and/or extensions, for example (but not limited > to): > * Discovery of OAuth configuration. e.g., http://oauth.net/discovery/1.0 > * Comprehensive message integrity e.g., > http://oauth.googlecode.com/svn/spec/ext/body_hash/1.0/drafts/1/spec.html > . > * Recommendations regarding the structure of the token. > * Localization e.g., > http://oauth.googlecode.com/svn/spec/ext/language_preference/1.0/drafts/2/spec.html > * Session-oriented tokens e.g., > http://oauth.googlecode.com/svn/spec/ext/session/1.0/drafts/1/ > spec.html > * Alternate token exchange profiles e.g., > draft-dehora-farrell-oauth-accesstoken-creds-00 > > b. > > On Wed, Feb 18, 2009 at 2:41 PM, Stephen Farrell > wrote: >> >> >> Blaine Cook wrote: >>> On Wed, Feb 18, 2009 at 1:47 PM, Tschofenig, Hannes (NSN - FI/Espoo) >>> wrote: >>>> Hi Stephen, >>>> >>>> you are a tough negotiator :-) >>>> >>>> I think Blaine tried to capture it with the following bullet: >>>> " >>>> * Alternate token exchange profiles. >>>> " >> >> I didn't get that when I read it. >> >>> Correct ;-) There are a few other approaches to exchanging tokens >>> that >>> may be useful in different contexts, and I don't want to close the >>> door on those if people care about them. I absolutely consider the >>> mobile/challenged device use case as critical to address either in >>> the >>> core spec or, if that's not possible, as an alternate token exchange >>> profile. >> >> Good. Me too:-) >> >>>> Would adding something like the sentence below make you happier? >>>> >>>> " >>>> For example, profiles that take challenged devices and >>>> aggregators into >>>> account allowing for the client to directly acquire an access >>>> token from >>>> a set of credentials. >>>> " >> >> That'd do it for me. If you're both ok with adding that you >> can stop reading now:-) >> >>> I'm weary about being too specific. I appreciate that there is an >>> I-D, >>> but there are also several OAuth extension specs that are well >>> documented and in active use in the wild, but do not have specific >>> attention in the charter. >> >> Sure. OTOH, anyone can write an I-D and that is the IETF >> process, so one shouldn't be penalised for actually doing >> the right thing, right? >> >> I'll be interested in seeing how many of those other >> extensions get pushed into the IETF process. As of now, >> that's zero. So there's a justification for this use >> case (which we agree is critical) to be called out >> up front. (And to be clear, the reason I'm hammering >> on this is so that the WG can choose to adopt an >> I-D on the topic without first rechartering.) >> >>> I also worry that we haven't properly >>> evaluated the case history nor have we attempted to outline what >>> other >>> approaches are possible and discuss the various trade-offs. >>> Committing >>> to a single profile and use case without a proper discussion and >>> clear >>> consensus seems backwards to me. >> >> I've no problem with that. Even if our I-D is named in >> the charter, there's no guarantee that it gets adopted by >> the WG and the proposed charter text I sent doesn't >> assume that it will be adopted. Its quite common for >> there to be a number of draft-author-foo drafts only >> one of which becomes draft-ietf-wg-foo and that's >> just fine. From my POV the important thing is that the >> WG is chartered to address the use case. Our I-D >> is currently just one approach. >> >>> My current feeling on the matter is that we have a charter which >>> provides ample room for discussion and implementation of the >>> accesstoken-creds I-D, without explicitly committing to it (which is >>> something I'm personally not prepared to do, and my impression is >>> that >>> few are or will be until we have the core OAuth work complete). >> >> And I wouldn't, and didn't, ask for that. >> >> Stephen. >> >>> >>> b. >>> >> From hannes.tschofenig@nsn.com Mon Feb 23 05:09:37 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D57623A69A7 for ; Mon, 23 Feb 2009 05:09:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=1.000, 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 4IAqujPMPrqt for ; Mon, 23 Feb 2009 05:09:36 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 6C1C73A68AD for ; Mon, 23 Feb 2009 05:09:32 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n1ND9nVX024178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 23 Feb 2009 14:09:49 +0100 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n1ND9mcu013504 for ; Mon, 23 Feb 2009 14:09:48 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Feb 2009 14:09:48 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 23 Feb 2009 15:10:46 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B450112E54B@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Another Charter Text Update Thread-Index: AcmVuCOwCiDwflmeRRKT4iAw7lez2g== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 23 Feb 2009 13:09:48.0303 (UTC) FILETIME=[012D31F0:01C995B8] Subject: [oauth] Another Charter Text Update X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 13:09:37 -0000 Only a few more days to provide your comments on the charter text! The deadline is February 27th. =20 ----------------------------------------------------------------- Open Authentication Protocol (oauth) Last Modified: 2009-02-23 Chair(s): TBD Applications Area Director(s): Chris Newman Lisa Dusseault =20 Applications Area Advisor: TBD Mailing Lists: https://www.ietf.org/mailman/listinfo/oauth Description of Working Group: OAuth allows a user to grant a third-party Web site or application access to their resources, without necessarily revealing their credentials, or even their identity. For example, a photo-sharing site that supports OAuth would allow its users to use a third-party printing Web site to access their private pictures, without gaining full control of the user account. OAuth consists of: * A mechanism for exchanging a user's credentials for a token-secret pair which can be used by a third party to access resources on their behalf. * A mechanism for signing HTTP requests with the token-secret pair. The Working Group will produce one or more documents suitable for consideration as Proposed Standard, based upon draft-hammer-oauth-00.txt, that will: * Improve the terminology used. * Embody good security practice, or document gaps in its capabilities, and propose a path forward for addressing the gap. * Promote interoperability. * Provide guidelines for extensibility. This specifically means that as a starting point for the working group OAuth 1.0 (draft-hammer-oauth-00.txt) is used and the available extension points are going to be utilized. The WG will profile OAuth 1.0 in a way that produces a specification that is a backwards compatible profile, i.e. any OAuth 1.0 and the specification produced by this group must support a basic set of features to guarantee interoperability.=20 Furthermore, OAuth 1.0 defines three signature methods used to protect requests, namely PLAINTEXT, HMAC-SHA1, and RSA-SHA1. The group will work on new signature methods and will describe the environments where new security requirements justify their usage. Existing signature methods will not be modified but may be dropped as part of the backwards compatible profiling activity. The applicability of existing and new signature methods to protocols other than HTTP will be investigated. The Working Group should consider: * Implementer experience. * The end-user experience, including internationalization * Existing uses of OAuth. * Ability to achieve broad impementation. * Ability to address broader use cases than may be contemplated by the original authors. The Working Group is not tasked with defining a generally applicable HTTP Authentication mechanism (i.e., browser-based "2-leg" scenerio), and should consider this work out of scope in its discussions. However, if the deliverables are able to be factored in such a way that this is a byproduct, or such a scenario could be addressed by additional future work, the Working Group may choose to do so. After delivering OAuth, the Working Group may consider defining additional functions and/or extensions, for example (but not limited to): * Discovery of OAuth configuration. e.g., http://oauth.net/discovery/1.0. * Comprehensive message integrity e.g., http://oauth.googlecode.com/svn/spec/ext/body_hash/1.0/drafts/1/spec.htm l. * Recommendations regarding the structure of the token. * Localization e.g., http://oauth.googlecode.com/svn/spec/ext/language_preference/1.0/drafts/ 2/spec.html. * Session-oriented tokens e.g., http://oauth.googlecode.com/svn/spec/ext/session/1.0/drafts/1/spec.html. * Alternate token exchange profiles e.g., draft-dehora-farrell-oauth-accesstoken-creds-00. Goals and Milestones: Apr 2009 Submit 'OAuth: HTTP Authorization Delegation Protocol' as working group item (draft-hammer-oauth will be used as a starting point for further work.) Jul 2009 Start of discussion about OAuth extensions the group should work on Oct 2009 Start Working Group Last Call on 'OAuth: HTTP Authorization Delegation Protocol' Nov 2009 Submit 'OAuth: HTTP Authorization Delegation Protocol' to the IESG for consideration as a Proposed Standard=20 Nov 2009 Prepare milestone update to start new work within the scope of the charter From stephen.farrell@cs.tcd.ie Mon Feb 23 07:37: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 49CCF3A6952 for ; Mon, 23 Feb 2009 07:37:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oY5SLj9GH0Jg for ; Mon, 23 Feb 2009 07:37:19 -0800 (PST) Received: from WA4EHSOBE002.bigfish.com (wa4ehsobe002.messaging.microsoft.com [216.32.181.12]) by core3.amsl.com (Postfix) with ESMTP id 074093A6877 for ; Mon, 23 Feb 2009 07:37:19 -0800 (PST) Received: from mail186-wa4-R.bigfish.com (10.8.14.248) by WA4EHSOBE002.bigfish.com (10.8.40.22) with Microsoft SMTP Server id 8.1.340.0; Mon, 23 Feb 2009 15:37:36 +0000 Received: from mail186-wa4 (localhost.localdomain [127.0.0.1]) by mail186-wa4-R.bigfish.com (Postfix) with ESMTP id 2E7F7C781CB; Mon, 23 Feb 2009 15:37:36 +0000 (UTC) X-BigFish: VPS-39(z5edJz1432R98dR936eQ1805M936fKzzzz1033ILz2dh6bh87il61h) X-Spam-TCS-SCL: 0:0 X-FB-SS: 5, X-FB-DOMAIN-IP-MATCH: fail Received: by mail186-wa4 (MessageSwitch) id 1235403453664205_2000; Mon, 23 Feb 2009 15:37:33 +0000 (UCT) Received: from imx1.tcd.ie (imx1.tcd.ie [134.226.17.160]) by mail186-wa4.bigfish.com (Postfix) with ESMTP id 3997E53005C; Mon, 23 Feb 2009 15:37:33 +0000 (UTC) Received: from Vams.imx1 (imx1.tcd.ie [134.226.17.160]) by imx1.tcd.ie (Postfix) with SMTP id 9A32D497D; Mon, 23 Feb 2009 15:37:32 +0000 (GMT) Received: from imx1.tcd.ie ([134.226.17.160]) by imx1 ([127.0.0.1]) with SMTP (gateway) id A077DA8E84B; Mon, 23 Feb 2009 15:37:32 +0000 Received: from [134.226.62.18] (cswireless62-18.cs.tcd.ie [134.226.62.18]) by imx1.tcd.ie (Postfix) with ESMTP id 6622B497D; Mon, 23 Feb 2009 15:37:32 +0000 (GMT) Message-ID: <49A2C2BF.6020903@cs.tcd.ie> Date: Mon, 23 Feb 2009 15:37:35 +0000 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.16 (X11/20080707) MIME-Version: 1.0 To: "Tschofenig, Hannes (NSN - FI/Espoo)" References: <3D3C75174CB95F42AD6BCC56E5555B450112E54B@FIESEXC015.nsn-intra.net> In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B450112E54B@FIESEXC015.nsn-intra.net> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-AntiVirus-Status: MessageID = A177DA8E84B X-AntiVirus-Status: Host: imx1.tcd.ie X-AntiVirus-Status: Action Taken: X-AntiVirus-Status: NONE X-AntiVirus-Status: Checked by TCD Vexira. (version=1.60.2 VDF=10.101.21) Cc: oauth@ietf.org Subject: Re: [oauth] Another Charter Text Update X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 15:37:20 -0000 I think this is good to go as-is. One possible nit is the use of the term "sign," which may generate a bit of discussion somewhere along the line if not explained. One could add a sentence as done below if that was considered useful. S. Tschofenig, Hannes (NSN - FI/Espoo) wrote: > Only a few more days to provide your comments on the charter text! > The deadline is February 27th. > > ----------------------------------------------------------------- > > Open Authentication Protocol (oauth) > > Last Modified: 2009-02-23 > > Chair(s): > > TBD > > Applications Area Director(s): > > Chris Newman > Lisa Dusseault > > Applications Area Advisor: > > TBD > > Mailing Lists: > > https://www.ietf.org/mailman/listinfo/oauth > > Description of Working Group: > > OAuth allows a user to grant a third-party Web site or application > access to their resources, without necessarily revealing their > credentials, or even their identity. For example, a photo-sharing site > that supports OAuth would allow its users to use a third-party printing > Web site to access their private pictures, without gaining full control > of the user account. > > OAuth consists of: > * A mechanism for exchanging a user's credentials for a token-secret > pair which can be used by a third party to access resources on their > behalf. > * A mechanism for signing HTTP requests with the token-secret pair. > > The Working Group will produce one or more documents suitable for > consideration as Proposed Standard, based upon > draft-hammer-oauth-00.txt, that will: > * Improve the terminology used. > * Embody good security practice, or document gaps in its capabilities, > and propose a path forward for addressing the gap. > * Promote interoperability. > * Provide guidelines for extensibility. > > This specifically means that as a starting point for the working group > OAuth 1.0 (draft-hammer-oauth-00.txt) is used and the available > extension points are going to be utilized. The WG will profile OAuth > 1.0 in a way that produces a specification that is a backwards > compatible profile, i.e. any OAuth 1.0 and the specification produced > by this group must support a basic set of features to guarantee > interoperability. > > Furthermore, OAuth 1.0 defines three signature methods used to protect > requests, namely PLAINTEXT, HMAC-SHA1, and RSA-SHA1. The group will work > on new signature methods and will describe the environments where new > security requirements justify their usage. Existing signature methods > will not be modified but may be dropped as part of the backwards > compatible profiling activity. The applicability of existing and new > signature methods to protocols other than HTTP will be investigated. Note that the term "signature" here is used consistently with OAuth 1.0 and encompasses both asymmetric digital signatures, symmetric authentication and even use of a plaintext secret. The WG may decide to modify this terminology as part of its work, so keeping the existing usage is correct at this point in time. > The Working Group should consider: > * Implementer experience. > * The end-user experience, including internationalization > * Existing uses of OAuth. > * Ability to achieve broad impementation. > * Ability to address broader use cases than may be contemplated by the > original authors. > > The Working Group is not tasked with defining a generally applicable > HTTP Authentication mechanism (i.e., browser-based "2-leg" scenerio), > and should consider this work out of scope in its discussions. However, > if the deliverables are able to be factored in such a way that this is a > byproduct, or such a scenario could be addressed by additional future > work, the Working Group may choose to do so. > > After delivering OAuth, the Working Group may consider defining > additional functions and/or extensions, for example (but not limited > to): > * Discovery of OAuth configuration. e.g., > http://oauth.net/discovery/1.0. > * Comprehensive message integrity e.g., > http://oauth.googlecode.com/svn/spec/ext/body_hash/1.0/drafts/1/spec.htm > l. > * Recommendations regarding the structure of the token. > * Localization e.g., > http://oauth.googlecode.com/svn/spec/ext/language_preference/1.0/drafts/ > 2/spec.html. > * Session-oriented tokens e.g., > http://oauth.googlecode.com/svn/spec/ext/session/1.0/drafts/1/spec.html. > * Alternate token exchange profiles e.g., > draft-dehora-farrell-oauth-accesstoken-creds-00. > > > Goals and Milestones: > > Apr 2009 Submit 'OAuth: HTTP Authorization Delegation Protocol' as > working group item > (draft-hammer-oauth will be used as a starting point for > further work.) > Jul 2009 Start of discussion about OAuth extensions the group should > work on > Oct 2009 Start Working Group Last Call on 'OAuth: HTTP Authorization > Delegation Protocol' > Nov 2009 Submit 'OAuth: HTTP Authorization Delegation Protocol' to > the IESG for consideration as a Proposed Standard > Nov 2009 Prepare milestone update to start new work within the scope > of the charter > _______________________________________________ > oauth mailing list > oauth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From aaron@serendipity.cx Mon Feb 23 10:55:25 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65EAD3A695C for ; Mon, 23 Feb 2009 10:55:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id okOCrySEZo8S for ; Mon, 23 Feb 2009 10:55:24 -0800 (PST) Received: from mail.serendipity.cx (serendipity.palo-alto.ca.us [66.92.2.87]) by core3.amsl.com (Postfix) with ESMTP id 354293A68B2 for ; Mon, 23 Feb 2009 10:55:24 -0800 (PST) Received: from serendipity.cx (unknown [10.10.10.34]) by mail.serendipity.cx (Postfix) with ESMTP id C55862936; Mon, 23 Feb 2009 11:02:09 -0800 (PST) MIME-Version: 1.0 Date: Mon, 23 Feb 2009 11:01:07 -0800 From: Aaron Stone To: "Tschofenig, Hannes (NSN - FI/Espoo)" In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B450112E54B@FIESEXC015.nsn-intra.net> References: <3D3C75174CB95F42AD6BCC56E5555B450112E54B@FIESEXC015.nsn-intra.net> Message-ID: <8311c4a72e55e6e7b5961ca8e1f89ba4@serendipity.cx> X-Sender: aaron@serendipity.cx User-Agent: RoundCube Webmail/0.2 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="UTF-8" Cc: oauth@ietf.org Subject: Re: [oauth] Another Charter Text Update X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 18:55:25 -0000 Looks good to me! On Mon, 23 Feb 2009 15:10:46 +0200, "Tschofenig, Hannes (NSN - FI/Espoo)" wrote: > Only a few more days to provide your comments on the charter text! > The deadline is February 27th. > > ----------------------------------------------------------------- > > Open Authentication Protocol (oauth) > > Last Modified: 2009-02-23 > > Chair(s): > > TBD > > Applications Area Director(s): > > Chris Newman > Lisa Dusseault > > Applications Area Advisor: > > TBD > > Mailing Lists: > > https://www.ietf.org/mailman/listinfo/oauth > > Description of Working Group: > > OAuth allows a user to grant a third-party Web site or application > access to their resources, without necessarily revealing their > credentials, or even their identity. For example, a photo-sharing site > that supports OAuth would allow its users to use a third-party printing > Web site to access their private pictures, without gaining full control > of the user account. > > OAuth consists of: > * A mechanism for exchanging a user's credentials for a token-secret > pair which can be used by a third party to access resources on their > behalf. > * A mechanism for signing HTTP requests with the token-secret pair. > > The Working Group will produce one or more documents suitable for > consideration as Proposed Standard, based upon > draft-hammer-oauth-00.txt, that will: > * Improve the terminology used. > * Embody good security practice, or document gaps in its capabilities, > and propose a path forward for addressing the gap. > * Promote interoperability. > * Provide guidelines for extensibility. > > This specifically means that as a starting point for the working group > OAuth 1.0 (draft-hammer-oauth-00.txt) is used and the available > extension points are going to be utilized. The WG will profile OAuth > 1.0 in a way that produces a specification that is a backwards > compatible profile, i.e. any OAuth 1.0 and the specification produced > by this group must support a basic set of features to guarantee > interoperability. > > Furthermore, OAuth 1.0 defines three signature methods used to protect > requests, namely PLAINTEXT, HMAC-SHA1, and RSA-SHA1. The group will work > on new signature methods and will describe the environments where new > security requirements justify their usage. Existing signature methods > will not be modified but may be dropped as part of the backwards > compatible profiling activity. The applicability of existing and new > signature methods to protocols other than HTTP will be investigated. > > The Working Group should consider: > * Implementer experience. > * The end-user experience, including internationalization > * Existing uses of OAuth. > * Ability to achieve broad impementation. > * Ability to address broader use cases than may be contemplated by the > original authors. > > The Working Group is not tasked with defining a generally applicable > HTTP Authentication mechanism (i.e., browser-based "2-leg" scenerio), > and should consider this work out of scope in its discussions. However, > if the deliverables are able to be factored in such a way that this is a > byproduct, or such a scenario could be addressed by additional future > work, the Working Group may choose to do so. > > After delivering OAuth, the Working Group may consider defining > additional functions and/or extensions, for example (but not limited > to): > * Discovery of OAuth configuration. e.g., > http://oauth.net/discovery/1.0. > * Comprehensive message integrity e.g., > http://oauth.googlecode.com/svn/spec/ext/body_hash/1.0/drafts/1/spec.htm > l. > * Recommendations regarding the structure of the token. > * Localization e.g., > http://oauth.googlecode.com/svn/spec/ext/language_preference/1.0/drafts/ > 2/spec.html. > * Session-oriented tokens e.g., > http://oauth.googlecode.com/svn/spec/ext/session/1.0/drafts/1/spec.html. > * Alternate token exchange profiles e.g., > draft-dehora-farrell-oauth-accesstoken-creds-00. > > > Goals and Milestones: > > Apr 2009 Submit 'OAuth: HTTP Authorization Delegation Protocol' as > working group item > (draft-hammer-oauth will be used as a starting point for > further work.) > Jul 2009 Start of discussion about OAuth extensions the group should > work on > Oct 2009 Start Working Group Last Call on 'OAuth: HTTP Authorization > Delegation Protocol' > Nov 2009 Submit 'OAuth: HTTP Authorization Delegation Protocol' to > the IESG for consideration as a Proposed Standard > Nov 2009 Prepare milestone update to start new work within the scope > of the charter > _______________________________________________ > oauth mailing list > oauth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From Hannes.Tschofenig@gmx.net Mon Feb 23 12:16: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 BF0903A67E2 for ; Mon, 23 Feb 2009 12:16:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.271 X-Spam-Level: X-Spam-Status: No, score=-2.271 tagged_above=-999 required=5 tests=[AWL=0.328, 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 aYGCQFcpqt6p for ; Mon, 23 Feb 2009 12:16:44 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id AD3843A67DD for ; Mon, 23 Feb 2009 12:16:42 -0800 (PST) Received: (qmail invoked by alias); 23 Feb 2009 20:16:56 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp071) with SMTP; 23 Feb 2009 21:16:56 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+3yS4Qd0O3fYPkxT60pi6+msLnZx8gRbDH0m8Ksr J963YF+ahcXirQ From: "Hannes Tschofenig" To: "'Stephen Farrell'" , "Tschofenig, Hannes \(NSN - FI/Espoo\)" References: <3D3C75174CB95F42AD6BCC56E5555B450112E54B@FIESEXC015.nsn-intra.net> <49A2C2BF.6020903@cs.tcd.ie> Date: Mon, 23 Feb 2009 22:17:53 +0200 Message-ID: <011901c995f3$cf2cc8a0$0201a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <49A2C2BF.6020903@cs.tcd.ie> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcmVzKm3cKVoY+dMS9eJ/9zw+X8YtQAEXa+w X-Y-GMX-Trusted: 0 X-FuHaFi: 0.67 Cc: oauth@ietf.org Subject: Re: [oauth] Another Charter Text Update X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 20:16:44 -0000 Hi Stephen, >> Furthermore, OAuth 1.0 defines three signature methods used >to protect >> requests, namely PLAINTEXT, HMAC-SHA1, and RSA-SHA1. The group will >> work on new signature methods and will describe the >environments where >> new security requirements justify their usage. Existing signature >> methods will not be modified but may be dropped as part of the >> backwards compatible profiling activity. The applicability >of existing >> and new signature methods to protocols other than HTTP will >be investigated. > >Note that the term "signature" here is used consistently with >OAuth 1.0 and encompasses both asymmetric digital signatures, >symmetric authentication and even use of a plaintext secret. >The WG may decide to modify this terminology as part of its >work, so keeping the existing usage is correct at this point in time. Do you think that the term "signature" needs to be clarified given that I mention the three signature methods available in OAuth 1.0 the same paragraph? Ciao Hannes From ben@benramsey.com Tue Feb 24 19:02: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 2DBC33A67AF for ; Tue, 24 Feb 2009 19:02:26 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "In-Reply-To" X-Spam-Flag: NO X-Spam-Score: -0.36 X-Spam-Level: X-Spam-Status: No, score=-0.36 tagged_above=-999 required=5 tests=[AWL=1.110, 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 zj5rkCUnZzqC for ; Tue, 24 Feb 2009 19:02:25 -0800 (PST) Received: from mail-gx0-f174.google.com (mail-gx0-f174.google.com [209.85.217.174]) by core3.amsl.com (Postfix) with ESMTP id 50AFE3A6874 for ; Tue, 24 Feb 2009 19:02:22 -0800 (PST) Received: by gxk22 with SMTP id 22so8014096gxk.13 for ; Tue, 24 Feb 2009 19:02:41 -0800 (PST) Received: by 10.100.37.20 with SMTP id k20mr433268ank.5.1235530960979; Tue, 24 Feb 2009 19:02:40 -0800 (PST) Received: from pippin.local (c-76-97-7-151.hsd1.ga.comcast.net [76.97.7.151]) by mx.google.com with ESMTPS id b7sm12440638ana.39.2009.02.24.19.02.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 24 Feb 2009 19:02:40 -0800 (PST) Message-ID: <49A4B4CF.6020503@benramsey.com> Date: Tue, 24 Feb 2009 22:02:39 -0500 From: Ben Ramsey User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.19) Gecko/20081209 Thunderbird/2.0.0.19 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: "Tschofenig, Hannes (NSN - FI/Espoo)" References: <49A4B307.9050906@schematic.com> In-Reply-To: <49A4B307.9050906@schematic.com> References: <3D3C75174CB95F42AD6BCC56E5555B450112E54B@FIESEXC015.nsn-intra.net> In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B450112E54B@FIESEXC015.nsn-intra.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: oauth@ietf.org Subject: Re: [oauth] Another Charter Text Update X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Oauth bof discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 03:04:14 -0000 Just a nit: > * Ability to achieve broad impementation. Should be "implementation." :-) -Ben