Subject: [oauth] Updated OAuth Charter Text

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 7 Apr 2009 17:12:44 +0300

Based on the discussions during the IETF meeting we have updated the
charter text. 

There are two changes worth mentioning: 

** Backwards Compatibility ** 

I tried to clarify the term backwards compatibility based on text
provided by Peter Saint-Andre. Peter had some experience with this topic
already in the context of XMPP and I believe that the text they have
used in their original charter fits quite well. 

** 2-Legged Scenario **

Initially, the 2-legged scenario was out-of-scope. The opinion changed
and folks are now interested to also work on this use case within this
group. 

Here is the new version:

---------------------------

Open Authentication Protocol (oauth)

Last Modified: 2009-04-06

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

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 07 Apr 2009 09:33:46 -0600

Nits inline.

> and folks are now interested to also work on this use case within this

For clarity, I would change "their" to "the user's".

> and propose a path forward for addressing the gap.

I would change "the gap" to "those gaps".

>   * Promote interoperability.

Is this an actionable guideline?

> available extension points are going to be utilized. 

That's a somewhat long and confusing sentence. :) I'd be happy to
suggest something that might be a bit more readable.

We seem to be assuming that the result of the WG activity will be "OAuth
1.1", which further assumes that versioning is well-defined in OAuth. Is
that the case, or is definition of versioning in scope for the group?

Could we specify a bit more clearly what we mean by "the available
extension points"? Are those other documents, or places in OAuth 1.0
where extensibility can occur?

> In completing its
> on new signature methods 

Why? Because HMAC-SHA1 and RSA-SHA1 have known vulnerabilities, or
because agility is desiable here?

> and will describe the environments where new

I'm leery of this long list, which is only a list of *possible* work
items ("for example, but not limited to"). Perhaps it makes more sense
to not mention extensions until "OAuth 1.1" is complete? At time it
might be appropriate to recharter the group and work on new features and
extensions.

> and requires consensus within the group to add new milestones.

But which extensions are in scope? IMHO it's best to tightly define the
charter, especially the initial charter. The group can always be
rechartered later.

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

Is there a draft to refer to here? What is the 2-leg scenario? This
might be a term of art, but it is undefined in the charter.

>             (draft-hammer-oauth will be used as a starting point for

No need to say this here, since we said it above.

> functionality of the 2-legged HTTP authentication mechanism 

Undefined (see above). And now it is referred to as authentication. This
might lead some to think that work on authentication is being smuggled
in the back door ("doesn't the IETF already have some authentication
protocols defined in both HTTP and SASL?").

> Nov 2009    Prepare milestone update to start new work within the scope

Is that perhaps better as a recharter?

> the IESG for consideration as a Proposed Standard 

See above.

Thanks for the text!

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 7 Apr 2009 16:58:24 +0100

> charter, especially the initial charter. The group can always be

There was a longish thread on this a month or two ago so I'd be leery
of going back and re-doing all that discussion. I think the current
text is ok as-is on this point.

Stephen.

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 07 Apr 2009 10:18:08 -0600

> text is ok as-is on this point.

I defer to the list consensus, then.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 7 Apr 2009 19:51:46 -0700

Please change '1.1' with 'future version'.

EHL

On 4/7/09 7:12 AM, "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]> wrote:

** 2-Legged Scenario **

Here is the new version:

Chair(s):

TBD

TBD

Mailing Lists:

OAuth consists of:

Goals and Milestones:

_______________________________________________
oauth mailing list
[email-masked]