Re: [oauth] Updated Charter Text

[Stephen Farrell <[e-mail]>]

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
>