Re: [oauth] Updated Charter Text

["Tschofenig, Hannes (NSN - FI/Espoo)" <[e-mail]>]

Hi Stephen, 

you are a tough negotiator :-)

I think Blaine tried to capture it with the following bullet:
"
* Alternate token exchange profiles.
"

Would adding something like the sentence below make you happier?

"
For example, profiles that take challenged devices and aggregators into
account allowing for the client to directly acquire an access token from
a set of credentials.
"

Ciao
Hannes



>-----Original Message-----
>From: ext Stephen Farrell [mailto:[e-mail]] 
>Sent: 18 February, 2009 13:10
>To: Tschofenig, Hannes (NSN - FI/Espoo)
>Cc: [e-mail]
>Subject: Re: [oauth] Updated Charter Text
>
>
>Hate to keep banging the same drum, but I don't see how the 
>mobile use case is included there, so I'd still suggest the 
>addition below. (Other than that this charter is fine by me.)
>
>While I would like there to be a milestone associated with 
>that, I'm ok if that's done later, so haven't suggested one.
>(If asked, I'd go for WGLC on a mobile draft 3-6 months after 
>the WGLC starts on the base spec.)
>
>Stephen.
>
>Tschofenig, Hannes (NSN - FI/Espoo) wrote:
>> Based on the feedback I have compiled another version of the charter 
>> text.
>> 
>> ------------------------------------------
>> 
>> Open Authentication Protocol (oauth)
>> 
>> Last Modified: 2009-01-30
>> 
>> Chair(s):
>> 
>> TBD
>> 
>> Applications Area Director(s):
>> 
>> Chris Newman <[e-mail]>
>> Lisa Dusseault <[e-mail]>
>> 
>> 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 necessarily 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 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 
>> draft-hammer-oauth-00.txt, that  will:
>>   * Improve the terminology used.
>>   * Embody 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 
>> OAuth 1.0 (draft-hammer-oauth-00.txt) is used and the available 
>> extension  points are going to be utilized. The WG will 
>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 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.
>> 
>> The Working Group should consider:
>>   * Implementer experience.
>>   * The end-user experience, including internationalization
>>   * Existing uses of OAuth.
>>   * Ability to achieve broad impementation.
>>   * Ability to address broader use cases than may be contemplated by 
>> the original authors.
>> 
>> 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 WG will, if necessary, develop an 
>oauth extension suited for use on challenged devices and by 
>aggregators that allows for the client to directly acquire an 
>access token from a set of credentials. One such scheme is 
>defined in draft-dehora-farrell-oauth-accesstoken-creds.
>
>
>> After delivering OAuth, the Working Group may consider defining 
>> additional functions and/or extensions, for example (but not limited
>> to):
>>   * Discovery of OAuth configuration.
>>   * Comprehensive message integrity.
>>   * Recommendations regarding the structure of the token.
>>   * Localization.
>>   * Session-oriented tokens.
>>   * Alternate token exchange profiles.
>>
>> 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.)
>> Jul 2009    Start of discussion about OAuth extensions the 
>group should
>> work on
>> Oct 2009    Start Working Group Last Call on 'OAuth: HTTP 
>Authorization
>> Delegation Protocol'
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>