Re: [oauth] OAUTH Charter Proposal

I like the proposed charter. I think it offers enough flexibility for changes while maintaining the spirit and framework of the OAuth Core 1.0 spec.

EHL

On 1/30/09 2:32 PM, "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net> wrote:

We need a couple of folks agreeing the charter proposals.

Next, there is the question whether a meeting slot at the next IETF meeting
(in San Francisco) should be requested (e.g., in the form of a BOF). This
would give some discussion time for the details of the BOF or if everyone
likes the charter till then already one could disuss the technical details
instead.

The Area Directors are then requested to charter a working group. They
discuss it within the IESG and get feedback from the IAB. They also need to
find chairs for the group.

Ciao
Hannes

>-----Original Message-----
>From: Blaine Cook [mailto:romeda@gmail.com]
>Sent: 30 January, 2009 21:04
>To: Hannes Tschofenig
>Cc: oauth@ietf.org
>Subject: Re: [oauth] OAUTH Charter Proposal
>
>+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