Open Authentication Protocol (oauth)
------------------------------------

Charter
Last Modified: 2010-03-25

Current Status: Active Working Group

Chair(s):
    Blaine Cook  <[email protected]>
    Hannes Tschofenig  <[email protected]>

Applications Area Director(s):
    Alexey Melnikov  <[email protected]>
    Peter Saint-Andre  <[email protected]>

Applications Area Advisor:
    Peter Saint-Andre  <[email protected]>

Mailing Lists:
    General Discussion:[email protected]
    To Subscribe:      https://www.ietf.org/mailman/listinfo/oauth
    Archive:           http://www.ietf.org/mail-archive/web/oauth/current/maillist.html

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 a user to authorize issuance of credentials which
a third party can use to access resources on their behalf.
* Mechanism for using the issued credential to authenticate
HTTP requests (called "signatures" in current OAuth).

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
gap.
* 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),
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 update
OAuth 1.0 to become OAuth 1.1, the group will strive to
retain backwards compatibility with the OAuth 1.0
specification. However, changes that are not backwards
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 authentication ("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 authentication 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/draf
ts/1/spec.html.
* Recommendations regarding the structure of the token.
* Localization, e.g.,
http://oauth.googlecode.com/svn/spec/ext/language_preferenc
e/1.0/drafts/2/spec.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 and 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"
scenerio).

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


Internet-Drafts:

Posted Revised         I-D Title   <Filename>
------ ------- --------------------------------------------
Apr 2010 Jan 2011   <draft-ietf-oauth-v2-12.txt>
               The OAuth 2.0 Authorization Protocol

Dec 2010 Jan 2011   <draft-ietf-oauth-v2-bearer-02.txt>
               The OAuth 2.0 Protocol: Bearer Tokens

Jan 2011 Jan 2011   <draft-ietf-oauth-saml2-bearer-01.txt>
               SAML 2.0 Bearer Assertion Grant Type Profile for OAuth 2.0

Request For Comments:

 None to date.

You are viewing proxied material from ftp.icm.edu.pl. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.