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

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 15 Apr 2009 10:52:43 +0300

Open Authentication Protocol (oauth)

Last Modified: 2009-04-15

Chair(s):

TBD

Applications Area Director(s):

Alexey Melnikov <[email-masked]>
Lisa Dusseault <[email-masked]> 

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

---

From: Richard Barnes <[email-masked]>
Date: Wed, 15 Apr 2009 10:29:01 -0400

Generally seems in pretty good shape.  Some comments below.
--Richard

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

Which credentials/identity, and to whom?  Also, why not align 
terminology with the draft?  Suggested text:
"
OAuth allows a resource owner to grant a "client" Web site or 
application access to resources stored at another "server" Web site. 
OAuth enables this access without requiring the user to reveal to the 
client site either the identity or credentials used with the server site.
"

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

I would frame this slightly differently:
"
OAuth consists of:
  * A mechanism for carrying credentials in HTTP requests and responses
  * A mechanism for signing an HTTP request URI and request parameters 
with these credentials
  * A framework for using these mechanisms to delegate authentication 
and authorization for access to HTTP resources
"
(These corresponding roughly to sections 3.4, 3.3, and 4 in 
draft-hammer-oauth)

> authentication mechanism (i.e., browser-based "2-leg" scenario).

Part of this goal should also be to define the applicability and 
trade-offs of this mechanism vis à vis the current HTTP authentication 
mechanisms, especially Digest.  (Also, I don't find the term 2-leg 
especially helpful.)

>  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

The milestones here seem really sketchy ("Start a discussion?").  It 
seems like this should be the place to list concrete deliverables that 
you want to acheive.  It looks like there's only really two of these 
right now:
1. OAuth core
2. 2-legged 	
I don't think there's a need for vague language about extensions in the 
milestones; just add milestones as the need for extensions becomes clear.

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 15 Apr 2009 18:54:23 +0300

Hi Richard, 

we could align the charter with the terminology of the latest OAuth I-D.
There is no guarantee that the terminology does not change again. I thought
that the current description is good enough to describe the basic idea what
the group is about. If you want to know more then you will have to read
through the latest drafts anyway. 

More inline:

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of Richard Barnes
>Sent: 15 April, 2009 17:29
>To: Hannes Tschofenig; [email-masked]
>Subject: Re: [oauth] OAuth Charter Text (15th April 2009)
>
>OAuth enables this access without requiring the user to reveal 
>to the client site either the identity or credentials used 
>with the server site.
>"
>
>
>  * A mechanism for signing an HTTP request URI and request 
>parameters with these credentials
>  * A framework for using these mechanisms to delegate 
>authentication and authorization for access to HTTP resources "
>Part of this goal should also be to define the applicability 
>and trade-offs of this mechanism vis à vis the current HTTP 
>authentication mechanisms, especially Digest.  (Also, I don't 
>find the term 2-leg especially helpful.)

I just used the term that other folks came up with. 

>The milestones here seem really sketchy ("Start a 
>discussion?").  It seems like this should be the place to list 
>concrete deliverables that you want to acheive.  It looks like 
>there's only really two of these right now:
>1. OAuth core
>2. 2-legged 	
>I don't think there's a need for vague language about 
>extensions in the milestones; just add milestones as the need 
>for extensions becomes clear.

Theoretically we can put there whatever we think is useful. 

Most of the milestones are pretty precise and easy to measure. 

I also wanted to provide some indications on when to start discussions about
extensions into the charter itself to have some sort of timeplan in the
group. In fact, the current GEOPRIV milestones list similar items :-)

Ciao
Hannes

>_______________________________________________
>oauth mailing list
>[email-masked]