[oauth] Last Call for Comments: OAuth Charter Text
"Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com> Tue, 17 February 2009 08:53 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 62CF43A6BEB for <oauth@core3.amsl.com>; 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 <oauth@core3.amsl.com>; 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 <oauth@ietf.org>; 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 <oauth@ietf.org>; 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 <oauth@ietf.org>; 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)" <hannes.tschofenig@nsn.com>
To: oauth@ietf.org
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 <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Feb 2009 08:53:58 -0000
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 <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 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] Last Call for Comments: OAuth Charter Text Tschofenig, Hannes (NSN - FI/Espoo)
- Re: [oauth] Last Call for Comments: OAuth Charter… Tschofenig, Hannes (NSN - FI/Espoo)
- Re: [oauth] Last Call for Comments: OAuth Charter… Stephen Farrell
- Re: [oauth] Last Call for Comments: OAuth Charter… George Fletcher
- Re: [oauth] Last Call for Comments: OAuth Charter… Eran Hammer-Lahav
- Re: [oauth] Last Call for Comments: OAuth Charter… George Fletcher
- Re: [oauth] Last Call for Comments: OAuth Charter… Eran Hammer-Lahav
- Re: [oauth] Last Call for Comments: OAuth Charter… Aaron Stone
- Re: [oauth] Last Call for Comments: OAuth Charter… Hannes Tschofenig
- Re: [oauth] Last Call for Comments: OAuth Charter… Tschofenig, Hannes (NSN - FI/Espoo)