[oauth] Charter Proposal v2

Based on the feedback I have updated the charter text proposal

----------

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 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
  * 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. 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