Re: [oauth] OAUTH Charter Proposal

Blaine Cook <romeda@gmail.com> Fri, 30 January 2009 19:03 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 93AAF3A6B4A; Fri, 30 Jan 2009 11:03:59 -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 90A9828C132 for <oauth@core3.amsl.com>; Fri, 30 Jan 2009 11:03: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 SjEiKUB6zId9 for <oauth@core3.amsl.com>; Fri, 30 Jan 2009 11:03:56 -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 46C643A68E5 for <oauth@ietf.org>; Fri, 30 Jan 2009 11:03:56 -0800 (PST)
Received: by ey-out-2122.google.com with SMTP id 25so114354eya.31 for <oauth@ietf.org>; Fri, 30 Jan 2009 11:03:36 -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=47TJt/lbjeH3IGk4z/8Ktbi8jiwG0NUv8N1nguZS4So=; b=O2LrijbF/ERWYv/kEQqXdna8Dcq8iK8DLgOqEotsfEbIUcZg2FBQSwB2vFK5zaSj0Q Uq+3r6AX+6FI6LnLCCzbhchFtmJ745HqSryGL7IDLFpneTamGyfXPbGbJfSaWkAFuQUi j4OG4cfD3e3O40Xo+BPAh1Vy6pejWUo4hOAQM=
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=pNlReXSKaljfJwWJx6i9nwe9Ued+rWNqQVmW9U6k2EK+P0Fy7K4jANMlOq68CyGj+i FMHA9PZxnXBxG/I1+huRfZtt6cwMstwkVyIIj2fEUhtD6J4Khvw3lTMoUtuobnged+U+ U1x0S87io3EnQH4vNG9arIArr/kPBntRviMQ4=
MIME-Version: 1.0
Received: by 10.210.105.2 with SMTP id d2mr1738371ebc.67.1233342216026; Fri, 30 Jan 2009 11:03:36 -0800 (PST)
In-Reply-To: <033101c98303$e6fde7f0$0201a8c0@nsnintra.net>
References: <033101c98303$e6fde7f0$0201a8c0@nsnintra.net>
Date: Fri, 30 Jan 2009 19:03:35 +0000
Message-ID: <d37b4b430901301103te5aa986m4d9bb22e03cb5831@mail.gmail.com>
From: Blaine Cook <romeda@gmail.com>
To: Hannes Tschofenig <Hannes.Tschofenig@gmx.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 <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

+1. This looks awesome, thanks Hannes. What are the next steps? My
understanding is that first we need some kind of consensus on this
charter, and then ??

b.

On Fri, Jan 30, 2009 at 5:55 PM, Hannes Tschofenig
<Hannes.Tschofenig@gmx.net> 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