[AAA-DOCTORS] FW: WG Review: Open Authentication Protocol (oauth)

"Romascanu, Dan (Dan)" <dromasca@avaya.com> Sun, 03 May 2009 16:19 UTC

Return-Path: <dromasca@avaya.com>
X-Original-To: aaa-doctors@core3.amsl.com
Delivered-To: aaa-doctors@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 762BA28C259; Sun, 3 May 2009 09:19:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.512
X-Spam-Level:
X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087, 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 k3UPOcyfBvpI; Sun, 3 May 2009 09:19:40 -0700 (PDT)
Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id C867728C274; Sun, 3 May 2009 09:19:39 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.40,287,1238990400"; d="scan'208";a="144739450"
Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 03 May 2009 12:21:03 -0400
Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 03 May 2009 12:21:02 -0400
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: Sun, 03 May 2009 18:20:40 +0200
Message-ID: <EDC652A26FB23C4EB6384A4584434A040165A16E@307622ANEX5.global.avaya.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: WG Review: Open Authentication Protocol (oauth)
Thread-Index: AcnILGcSDN8gCCJKSza09jx/FI/kXQD3qMUg
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: aaa-doctors@ietf.org, ops-dir@ietf.org
Subject: [AAA-DOCTORS] FW: WG Review: Open Authentication Protocol (oauth)
X-BeenThere: aaa-doctors@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: AAA Doctors E-mail List <aaa-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/aaa-doctors>, <mailto:aaa-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/aaa-doctors>
List-Post: <mailto:aaa-doctors@ietf.org>
List-Help: <mailto:aaa-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aaa-doctors>, <mailto:aaa-doctors-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 03 May 2009 16:19:41 -0000

 

-----Original Message-----
From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of
IESG Secretary
Sent: Tuesday, April 28, 2009 9:07 PM
To: new-work@ietf.org
Subject: WG Review: Open Authentication Protocol (oauth) 

A new IETF working group has been proposed in the Applications Area.
The IESG has not made any determination as yet.  The following draft
charter was submitted, and is provided for informational purposes only.
Please send your comments to the IESG mailing list (iesg@ietf.org) by
Tuesday, May 5, 2009.

Open Authentication Protocol (oauth)
-------------------------------------

Last Modified: 2009-04-06

Current Status: Proposed Working Group

Chair(s):

TBD

Applications Area Director(s):

Alexey Melnikov <alexey.melnikov@isode.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 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 ontheir
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 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 (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 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 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 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/draf
ts/1/spec.html.
* Recommendations regarding the structure of the token.
* Localization, e.g.,
http://oauth.googlecode.com/svn/spec/ext/language_preferenc
e/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.

The work on extensions is within the scope of the working group charter
and requires consensus within the group to add new milestones.

The Working Group will also define a generally applicable HTTP
authentication mechanism (i.e., browser-based "2-leg" 
scenerio).

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