Re: [oauth] Last Call for Comments: OAuth Charter Text

I missed them and I will incorporate them.

Thanks for pointing me to them. 

Ciao
Hannes

>-----Original Message-----
>From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] 
>On Behalf Of Stephen Farrell
>Sent: 17 February, 2009 18:15
>To: Tschofenig, Hannes (NSN - FI/Espoo)
>Cc: oauth@ietf.org
>Subject: Re: [oauth] Last Call for Comments: OAuth Charter Text
>
>
>I made some comments before [1] that don't seem to have been 
>included here - was that deliberate or did they get missed?
>
>S.
>
>[1] http://www.ietf.org/mail-archive/web/oauth/current/msg00061.html
>
>Tschofenig, Hannes (NSN - FI/Espoo) wrote:
>> Hi all,
>> 
>> we have now discussed the charter text for some time and we got good 
>> feedback. I have tried to reflect it in an appropriate way.
>> 
>> I think it is about time to finish this part of the story. Please 
>> review the current charter text and make a judgement whether we can 
>> move forward with it.
>> 
>> 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 consists of:
>>   * A mechanism for exchanging a user's credentials for a 
>token-secret 
>> pair that 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, 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 
>> 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. an OAuth 1.0 implementation 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 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.
>> 
>> 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:
>> 
>> 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.)
>> Sep 2009    Start Working Group Last Call on 'OAuth: HTTP 
>Authorization
>> Delegation Protocol'
>> Sep 2009    Discusion about OAUTH extensions the group should work on
>> Nov 2009    Submit 'OAuth: HTTP Authorization Delegation Protocol' to
>> the IESG for consideration as a Proposed Standard 
>> Nov 2009    Prepare milestone update to start new work 
>within the scope
>> of the charter
>> _______________________________________________
>> 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
>