Re: [oauth] pointer to latest charter?

Hubert Le Van Gong <hubertlvg@gmail.com> Mon, 02 February 2009 15:17 UTC

Return-Path: <oauth-bounces@ietf.org>
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 <oauth@core3.amsl.com>; 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 <oauth@core3.amsl.com>; 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 <oauth@ietf.org>; Mon, 2 Feb 2009 07:17:13 -0800 (PST)
Received: by qyk4 with SMTP id 4so1942052qyk.13 for <oauth@ietf.org>; 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: <e7e278330902020651x5fbc8e1cje23cab25b4f3e256@mail.gmail.com>
References: <e7e278330902020651x5fbc8e1cje23cab25b4f3e256@mail.gmail.com>
Date: Mon, 02 Feb 2009 16:16:47 +0100
Message-ID: <6c0fd2bc0902020716s1b207f4bi1c1c47410d4c609@mail.gmail.com>
From: Hubert Le Van Gong <hubertlvg@gmail.com>
To: Brett McDowell <email@brettmcdowell.com>
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 <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/pipermail/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>
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 <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.

_______________________________________________






On Mon, Feb 2, 2009 at 3:51 PM, Brett McDowell <email@brettmcdowell.com> 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