Re: [oauth] FW: OAUTH charter for consideration
"Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com> Wed, 15 April 2009 13:14 UTC
Return-Path: <hannes.tschofenig@nsn.com>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F077F28C17F for <oauth@core3.amsl.com>; Wed, 15 Apr 2009 06:14:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.541
X-Spam-Level:
X-Spam-Status: No, score=-5.541 tagged_above=-999 required=5 tests=[AWL=1.058, 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 LjR6ht8wqQWC for <oauth@core3.amsl.com>; Wed, 15 Apr 2009 06:14:39 -0700 (PDT)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 4409828C150 for <oauth@ietf.org>; Wed, 15 Apr 2009 06:14:38 -0700 (PDT)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n3FDFWr3028846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 15 Apr 2009 15:15:32 +0200
Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n3FDFWPp023088; Wed, 15 Apr 2009 15:15:32 +0200
Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Apr 2009 15:15:31 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 15 Apr 2009 16:16:58 +0300
Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4501448D52@FIESEXC015.nsn-intra.net>
In-Reply-To: <003201c9bdca$d152d580$73f88080$@edu>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [oauth] FW: OAUTH charter for consideration
Thread-Index: Acm65a7RhhoyCCO5TCqyz9HkG7yebQCuGqWQAAsM2dAAAF6pMA==
References: <010e01c9bd9f$26743710$0201a8c0@nsnintra.net> <003201c9bdca$d152d580$73f88080$@edu>
From: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>
To: ext Thomas Hardjono <hardjono@MIT.EDU>, Hannes Tschofenig <Hannes.Tschofenig@gmx.net>, Adrian.Farrel@huawei.com
X-OriginalArrivalTime: 15 Apr 2009 13:15:31.0965 (UTC) FILETIME=[41151AD0:01C9BDCC]
Cc: oauth@ietf.org
Subject: Re: [oauth] FW: OAUTH charter for consideration
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Oauth bof discussion <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Apr 2009 13:14:41 -0000
Hi Thomas, >-----Original Message----- >From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] >On Behalf Of ext Thomas Hardjono >Sent: 15 April, 2009 16:05 >To: 'Hannes Tschofenig'; Adrian.Farrel@huawei.com >Cc: oauth@ietf.org >Subject: Re: [oauth] FW: OAUTH charter for consideration > >Hi, > >I just had a short question/suggestion. In the past every time >a new WG is to be proposed or created, the IETF usually >insists that the new WG make-use of existing protocols and/or >mechanisms, which already exists in the IETF or other >Standards organization. (ie. don't re-invent the wheel). We re-use something that is already out there and try to improve security (and other things). The stuff that is being re-used is the OAuth protocol, see http://oauth.net/ (with code available here http://oauth.net/code). Ciao Hannes > >Will this mandate also be observed in this new WG? > >Thanks. > >/thomas/ > > > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] >On Behalf >> Of Hannes Tschofenig >> Sent: Wednesday, April 15, 2009 3:53 AM >> To: Adrian.Farrel@huawei.com >> Cc: oauth@ietf.org >> Subject: [oauth] FW: OAUTH charter for consideration >> >> Hi Adrian, >> >> thanks for your feedback to the charter. I have addressed >most of your >> comments in the updated charter text. A few minor comments inline >> (search for [hannes]). >> >> I will distribute the updated charter text with a subsequent mail. >> >> Ciao >> Hannes >> >> >> >> ________________________________ >> >> From: Lisa Dusseault >> [mailto:Lisa.Dusseault@messagingarchitects.com] >> >> Sent: 11 April, 2009 23:39 >> To: Blaine Cook; Hannes Tschofenig >> Subject: Fwd: OAUTH charter for consideration >> >> >> FYI >> >> >> Begin forwarded message: >> >> >> From: Adrian Farrel <Adrian.Farrel@huawei.com> >> Date: April 10, 2009 1:08:27 PM PDT >> To: Lisa Dusseault ><Lisa.Dusseault@messagingarchitects.com> >> Cc: iesg@ietf.org >> Subject: Re: OAUTH charter for consideration >> Reply-To: Adrian Farrel <Adrian.Farrel@huawei.com> >> >> Hi Lisa, >> >> Nits, but mainly that the third person has >become confused. >> >> >> >> 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. >> >> >> >> "their resources" == the user's resources? >> "their credentials" == the third party's credentials? >> "their identity" == the third party's identity? >> >> Would be neat to clean that up. >> >> >> >> 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. >> >> >> >> Even in this example... >> "thier private pictures" == each user's private >pictures? >> >> >> >> 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. >> >> >> >> On the user's behalf or on behalf of the third party? >> >> >> >> * 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 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. >> >> >> >> s/gap/gaps/ >> >> >> >> * Promote interoperability. >> >> >> * Provide guidelines for extensibility. >> >> >> >> This specifically means that as a >starting point for the working >> group OAuth 1.0 (i.e., draft-hammer-oauth-00.txt), which is >a copy of >> the original OAuth specification in IETF draft format, is >used and the >> available extension points are going to be utilized. In >completing its >> work to profile OAuth 1.0 to become OAuth 1.1, the group >will strive >> to retain backwards compatibility with the OAuth 1.0 specification. >> However, >> changes that are not backwards compatible might be accepted >> >> >> >> s/backwards/backward/ x2 >> >> >> >> if the group determines that the >changes are required to meet the >> group's technical objectives and the group clearly documents the >> reasons for making them. >> >> >> >> 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 >> >> >> >> s/modified/modified,/ >> >> >> >> backwards compatible profiling >activity. The applicability of >> existing >> >> >> >> s/backwards/backward/ >> >> >> >> 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 implementation. >> >> >> * Ability to address broader use cases >than may be contemplated by >> the original authors. >> >> >> >> After delivering OAuth 1.1, 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/sp >> ec.html . >> >> >> * Session-oriented tokens, e.g., >> >> >> >> >http://oauth.googlecode.com/svn/spec/ext/session/1.0/drafts/1/s >pec.html. >> >> >> >> I find it a bit odd to see URLs in the charter like this >> given that we don't feel very comfortable with URLs in RFCs. >> >> >> [hannes] We put them in there since folks want to have a few >examples of >> possible extensions listed. The name of the extension, >however, does not >> really provide enough useful content and hence we added the pointers. >> >> >> >> * Alternate token exchange profiles, e.g., >> draft-dehora-farrell- oauth-accesstoken-creds-00. >> >> >> >> The work on extensions is within the >scope of the >> working group charter and requires consensus within the group to add >> new >> milestones. >> >> >> >> s/and/, but/ ??? >> >> >> >> The Working Group will also define a generally >> applicable HTTP authentication mechanism (i.e., browser-based "2-leg" >> scenerio). >> >> >> >> s/i.e./e.g./ ??? >> >> >> [hannes] "i.e." is correct here since 2-legged scenario is the >> terminology >> we are using for this type of exchange. >> >> >> 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 Submit a document as a working group >> item providing the functionality of the 2-legged HTTP authentication >> mechanism >> >> >> 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 Start Working Group Last Call on the >> 2-legged HTTP authentication mechanism document >> >> >> Nov 2009 Prepare milestone update to >start new >> work within the scope of the charter >> >> >> Dec 2009 Submit 2-legged HTTP authentication >> mechanism document to the IESG for consideration as a >Proposed Standard >> >> >> >> Cheers, >> Adrian >> >> >> >> --- 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 >
- [oauth] FW: OAUTH charter for consideration Hannes Tschofenig
- Re: [oauth] FW: OAUTH charter for consideration Thomas Hardjono
- Re: [oauth] FW: OAUTH charter for consideration Tschofenig, Hannes (NSN - FI/Espoo)