Subject: [OAUTH-WG] Revised OAuth Charter Text

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 9 May 2011 14:25:29 +0300

I did a few minor updates; I believe Barry had missed a few comments in the version he sent out earlier today. 

---- 

Web Authorization Protocol Working Group

Description of Working Group

The Web Authorization (OAuth) protocol allows a user to grant
a third-party Web site or application access to the user's protected
resources, without necessarily revealing their long-term credentials,
or even their identity. For example, a photo-sharing site that supports
OAuth could allow its users to use a third-party printing Web site to
print their private pictures, without allowing the printing site to
gain full control of the user's account.

OAuth encompasses
* a mechanism for a user to authorize issuance of credentials that
  a third party can use to access resources on the user's behalf and
* a mechanism for using the issued credentials to authenticate
  HTTP requests.

In April 2010 the OAuth 1.0 specification, documenting pre-IETF work,
was published as an informational document (RFC 5849). The working
group has since been developing OAuth 2.0, a standards-track version
that will reflect IETF consensus.  Version 2.0 will consider the
implementation experience with version 1.0, a discovered security 
vulnerability (session fixation attack), the use cases and 
functionality proposed with OAuth WRAP [draft-hardt-oauth-01] and will
* improve the terminology used,
* consider broader use cases,
* embody good security practices,
* improve interoperability, and
* provide guidelines for extensibility.

The working group will develop authentication schemes for
peers/servers taking part in OAuth (accessing protected resources). 
This includes

* an HMAC-based authentication mechanism

This document aims to provide a general purpose MAC authentication 
scheme that can be used both with OAuth 2.0 but also with other use case. 
The WG will work with the security and applications area directors to 
ensure that this work gets appropriate review, e.g. via additional last 
calls in other relevant working groups such as HTTPBIS],

* a specification for access protected by Transport Layer Security 
(bearer tokens),

* an extension to OAuth 2.0 to allow access tokens to be requested 
when a client is in possession of a SAML assertion.

A separate informational description will be produced to provide
additional security analysis for audiences beyond the community
protocol implementers.

Milestones will be added for the later items after the near-term work
has been completed.

Goals and Milestones
May 2011    Submit 'HTTP Authentication: MAC Authentication' as a
working group item

May 2011    Submit 'OAuth 2.0 Threat Model and Security Considerations'
as a working group item

Jul 2011    Submit 'The OAuth 2.0 Authorization Protocol' to the
IESG for consideration as a Proposed Standard

Jul 2011    Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the
IESG for consideration as a Proposed Standard

Aug 2011    Submit 'HTTP Authentication: MAC Authentication' to the
IESG for consideration as a Proposed Standard

Oct 2011    Submit 'SAML 2.0 Bearer Assertion Grant Type Profile for
OAuth 2.0' to the IESG for consideration as a Proposed Standard

Oct 2011    Re-chartering working group

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 9 May 2011 10:01:26 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Hannes Tschofenig
> Sent: Monday, May 09, 2011 4:25 AM

> May 2011    Submit 'HTTP Authentication: MAC Authentication' as a

I am still not convinced this is the right working group for this document. This is an active document with a pending -04 version coming this week. Out of 26 pages, only 1 discusses OAuth 2.0 (and 2 more pages handle the registration requirements). My two co-authors, Adam Barth and Ben Adida are not members of this working group. In addition, this working group have shown little to no interest this document to date, offering very limited feedback.

I much rather keep this document as an individual submission discussed on apps-discuss, and make sure it includes the HTTPbis, HTTP-State, and OAuth working groups in its last call process.

I would like to hear what the Stephen (security AD) and Peter (application AD) think about the right venue for this draft.

EHL

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 10 May 2011 11:24:51 +0100

Hi Eran, all,

> I would like to hear what the Stephen (security AD) and Peter (application AD) think about the right venue for this draft.

I chatted briefly with Peter and think that we're both happy
that the mac draft be done in oauth with additional last call(s)
in other relevant places, particularly httpbis. Figuring out which
places can be done just before wglc here.

Part of the logic for doing it here is that without the mac draft,
oauth2.0 would appear to be less secure than oauth1.0 which
is not an outcome I want to see. Taking the mac draft via some other
route would therefore likely result in delay in getting the mac
draft done, and hence delay in terms of getting an RFC for oauth2.0.
If I think the oauth2.0 spec (or set of specs) sent to me as
AD is less secure than oauth1.0 then I'll almost certainly send it
back to the wg to fix that.

In terms of rechartering this wg - as Barry said the time to discuss
that is *after* the current work is done, not now. I'm sure there'll
be the usual full and frank discussion on the list at that point:-)
Proposing that the wg close at that point is fine and the chairs
will I'm sure do a good job of establishing the rough consensus on
that then.

And finally, as to the use-cases document, the only, but significant,
reason to hold it for now, is so it doesn't get in the way of the
main work. Even the most innocuous and well-written draft can cause
plenty of mail and delay so let's just shelve that draft for a few
months and get done with the main goals of the wg.

I guess given the spurt of mail I'll wait a few days before pushing
the charter onwards in case the chairs want to tweak something.

S.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 10 May 2011 07:29:33 -0700

I can work with that. Thanks.

EHL

> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Tuesday, May 10, 2011 3:25 AM
> To: Eran Hammer-Lahav
> Cc: Hannes Tschofenig; [email-masked] WG; Peter Saint-Andre
> ([email-masked]); 'Adam Barth ([email-masked])'; Ben Adida
> Subject: Re: [OAUTH-WG] Revised OAuth Charter Text
> 
> 
> Hi Eran, all,
> 
> >> From: [email-masked] [mailto:[email-masked]] On
> >> Behalf Of Hannes Tschofenig
> > I am still not convinced this is the right working group for this document.
> This is an active document with a pending -04 version coming this week. Out
> of 26 pages, only 1 discusses OAuth 2.0 (and 2 more pages handle the
> registration requirements). My two co-authors, Adam Barth and Ben Adida
> are not members of this working group. In addition, this working group have
> shown little to no interest this document to date, offering very limited
> feedback.
> >
> > I much rather keep this document as an individual submission discussed on
> apps-discuss, and make sure it includes the HTTPbis, HTTP-State, and OAuth
> working groups in its last call process.
> >
> > I would like to hear what the Stephen (security AD) and Peter (application
> AD) think about the right venue for this draft.
> 
> I chatted briefly with Peter and think that we're both happy that the mac
> draft be done in oauth with additional last call(s) in other relevant places,
> particularly httpbis. Figuring out which places can be done just before wglc
> here.
> 
> oauth2.0 would appear to be less secure than oauth1.0 which is not an
> outcome I want to see. Taking the mac draft via some other route would
> therefore likely result in delay in getting the mac draft done, and hence delay
> in terms of getting an RFC for oauth2.0.
> If I think the oauth2.0 spec (or set of specs) sent to me as AD is less secure
> than oauth1.0 then I'll almost certainly send it back to the wg to fix that.
> 
> In terms of rechartering this wg - as Barry said the time to discuss that is
> *after* the current work is done, not now. I'm sure there'll be the usual full
> and frank discussion on the list at that point:-) Proposing that the wg close at
> that point is fine and the chairs will I'm sure do a good job of establishing the
> rough consensus on that then.
> 
> And finally, as to the use-cases document, the only, but significant, reason to
> hold it for now, is so it doesn't get in the way of the main work. Even the
> most innocuous and well-written draft can cause plenty of mail and delay so
> let's just shelve that draft for a few months and get done with the main goals
> of the wg.
> 
> I guess given the spurt of mail I'll wait a few days before pushing the charter
> onwards in case the chairs want to tweak something.
> 
> S.
>