Re: [oauth] OAuth Charter Text (15th April 2009)

[Paul Madsen <[e-mail]>]

the wording of the example below seems to imply that the photo-sharing 
site would necessarily support OAuth, but not the printing site

paul

Hannes Tschofenig wrote:
> Open Authentication Protocol (oauth)
>
> Last Modified: 2009-04-15
>
> Chair(s):
>
> TBD
>
> Applications Area Director(s):
>
> Alexey Melnikov <[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
> the user's resources, without necessarily revealing the user's credentials,
> or even the user's identity. For example, a photo-sharing site that supports
> OAuth would allow its users to use a third-party printing Web site to access
> the user's 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 the user's 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 that will:
>   * Improve the terminology used.
>   * Embody good security practice, or document gaps in its capabilities, and
> propose a path forward for addressing the gaps.
>   * Promote interoperability.
>   * Provide guidelines for extensibility.
>
> This specifically means that as a starting point for the working group OAuth
> 1.0 (i.e., draft-hammer-oauth-00.txt), which is a copy of the original OAuth
> specification in IETF draft format, is used and the available extension
> points are going to be utilized. In completing its work to profile OAuth 1.0
> to become OAuth 1.1, the group will strive to retain backward compatibility
> with the OAuth 1.0 specification. However, changes that are not backward
> compatible might be accepted if the group determines that the changes are
> required to meet the group's technical objectives and the group clearly
> documents the reasons for making them.
>
> 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 backward 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 implementation.
>   * Ability to address broader use cases than may be contemplated by the
> original authors.
>
> After delivering OAuth 1.1, the Working Group may consider defining
> additional functions and/or extensions, for example (but not limited to):
>  * Discovery of OAuth configuration, e.g., http://oauth.net/discovery/1.0.
>  * Comprehensive message integrity, e.g.,
> http://oauth.googlecode.com/svn/spec/ext/body_hash/1.0/drafts/1/spec.html.
>  * Recommendations regarding the structure of the token.
>  * Localization, e.g.,
> http://oauth.googlecode.com/svn/spec/ext/language_preference/1.0/drafts/2/sp
> ec.html.
>  * Session-oriented tokens, e.g.,
> http://oauth.googlecode.com/svn/spec/ext/session/1.0/drafts/1/spec.html.
>  * Alternate token exchange profiles, e.g.,
> draft-dehora-farrell-oauth-accesstoken-creds-00.
>
> The work on extensions is within the scope of the working group charter, but
> requires consensus within the group to add new milestones. 
>
> The Working Group will also define a generally applicable HTTP
> authentication mechanism (i.e., browser-based "2-leg" scenario).
>
> 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    Submit a document as a working group item providing the
> functionality of the 2-legged HTTP authentication mechanism 
> 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    Start Working Group Last Call on the 2-legged HTTP
> authentication mechanism document
> Nov 2009    Prepare milestone update to start new work within the scope of
> the charter
> Dec 2009    Submit 2-legged HTTP authentication mechanism document to the
> IESG for consideration as a Proposed Standard 
>
> _______________________________________________
> oauth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>