Re: [oauth] OAUTH Charter Proposal

Sounds good to me. 

Thanks, George. 

>-----Original Message-----
>From: George Fletcher [mailto:gffletch@aol.com] 
>Sent: 02 February, 2009 15:47
>To: Hannes Tschofenig
>Cc: oauth@ietf.org
>Subject: Re: [oauth] OAUTH Charter Proposal
>
>Not wanting to start a huge debate... but within the OAuth 
>community we've made the distinction between Authentication 
>and Authorization, with OAuth being an API Authorization 
>protocol and leaving Authentication out of scope.
>
>Is this charter planning to tackle authentication as well as 
>authorization? The statement...
>> OAuth consist of:
>>   * A mechanism for exchanging a user's credentials for a 
>token-secret 
>> pair
>>   
>has me a little confused.  I would word this as...
>
>* A mechanism that allows a user to authorize API access via a 
>token-secret pair
>
>Thanks,
>George
>
>
>Hannes Tschofenig 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