Subject: [oauth] Another Charter Text Update

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 23 Feb 2009 15:10:46 +0200

Only a few more days to provide your comments on the charter text!
The deadline is February 27th.
 
-----------------------------------------------------------------

Open Authentication Protocol (oauth)

Last Modified: 2009-02-23

Chair(s):

TBD

Applications Area Director(s):

Chris Newman <[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 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 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.htm
l.
 * Recommendations regarding the structure of the token.
 * Localization e.g.,
http://oauth.googlecode.com/svn/spec/ext/language_preference/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.

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

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 23 Feb 2009 15:37:35 +0000

I think this is good to go as-is.

One possible nit is the use of the term "sign," which may generate
a bit of discussion somewhere along the line if not explained.

One could add a sentence as done below if that was considered
useful.

S.

> The deadline is February 27th.

Note that the term "signature" here is used consistently with OAuth 1.0
and encompasses both asymmetric digital signatures, symmetric
authentication and even use of a plaintext secret. The WG may decide
to modify this terminology as part of its work, so keeping the
existing usage is correct at this point in time.

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

---

From: Aaron Stone <[email-masked]>
Date: Mon, 23 Feb 2009 11:01:07 -0800

Looks good to me!

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Mon, 23 Feb 2009 22:17:53 +0200

Hi Stephen, 

>> 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.
>
>Note that the term "signature" here is used consistently with 
>OAuth 1.0 and encompasses both asymmetric digital signatures, 
>symmetric authentication and even use of a plaintext secret. 
>The WG may decide to modify this terminology as part of its 
>work, so keeping the existing usage is correct at this point in time.

Do you think that the term "signature" needs to be clarified given that I
mention the three signature methods available in OAuth 1.0 the same
paragraph? 

Ciao
Hannes