Subject: [OAUTH-WG] Revised Charter

From: Blaine Cook <[email-masked]>
Date: Wed, 27 Apr 2011 22:36:40 +0100

Hi all,

Now that the Easter holiday is over, please review the following
revised OAuth charter and provide feedback by May 5th (one week from
today). Thanks!

Description of Working Group

The Open Web Authentication (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 consists of
* 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 specifcation, 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, 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 [to the extent that the
OAuth wg produces specifications that could be used more generally
for HTTP authentication, 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 'HTTP Authentication: MAC Authentication' to the
IESG for consideration as a Proposed Standard

Aug 2011    Submit 'The OAuth 2.0 Protocol: Bearer Tokens' 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

Nov 2011    Prepare re-chartering

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 27 Apr 2011 23:42:57 +0100

FWIW, I'd have no problem proposing a re-charter along
these lines to the IESG, if that's what the WG want.
Thanks to the chairs for putting it together.

S.

On 27/04/11 22:36, Blaine Cook wrote:
> The Open Web Authentication (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 consists of * 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.
> 
> implementation experience with version 1.0, and will * improve the
> terminology used, * consider broader use cases, * embody good
> security practices, * improve interoperability, and * provide
> guidelines for extensibility.
> 
> 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],
> 
> * an extension to OAuth 2.0 to allow access tokens to be requested
> when a client is in possession of a SAML assertion.
> 
> 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
> 
> _______________________________________________ OAuth mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/oauth
> 
e

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 27 Apr 2011 18:01:37 -0700

Thanks for getting this started.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Blaine Cook
> Sent: Wednesday, April 27, 2011 2:37 PM

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

Please just call it OAuth and drop the silly 'Open Web Authentication' name. If you must, replace is with 'Web Authorization Protocol', and in no way keep the word 'Open'.
 
> In April 2010 the OAuth 1.0 specifcation, 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, and will

This should include a reference to WRAP given that 2.0 is a direct result of the combination of 1.0 and WRAP. I would also like this charter to limit the scope of the 2.0 protocol to that of the combined 1.0 RFC and WRAP. I'm pretty sure we're set to deliver exactly that.

> * consider broader use cases,

I think we're done considering. Please drop this.

> The working group will develop authentication schemes for peers/servers
> taking part in OAuth (accessing protected resources).
> This includes
> 
> * an HMAC-based authentication mechanism [to the extent that the OAuth
> wg produces specifications that could be used more generally for HTTP
> authentication, 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],

I might have an issue with placing this work primarily within this WG. It belongs equally between HTTPbis, HTTP-State, and OAuth. The upcoming revision of this draft moves the OAuth bits into a smaller section, and is mostly focused on a general purpose MAC authentication scheme. The new draft includes two bindings: HTTP Cookies and OAuth 2.0.

So far this WG has proved pretty irrelevant in helping move this work forward. This is especially true for the audience needed for the new bits.

> * a specification for access protected by Transport Layer Security (bearer
> tokens),
> 
> 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

See above.

> Nov 2011    Prepare re-chartering

I would like this removed.

I would like to see this WG closed when this list is complete and if there is further work with enough interest, a new working group can be created.

EHL

---

From: Thomas Hardjono <[email-masked]>
Date: Thu, 28 Apr 2011 10:19:56 -0400

Thanks Blaine,

This is a good start.  I have two suggestions and one request for an additional paragraph/bullet:

(a) Openness to future items: 

I would like to see language that is more open (ready) to accept future items (ie. those on the horizon and those unforeseen).

For example, the Kerberos WG has just completed its re-charter recently and had to address this same notion of limit/openness to future items.  The language that was finally chosen reflects this openness, I think.  Here are two examples:

    "Prepare and advance one or more standards-track specifications which...." (does XYZ).

    "Prepare, review, and advance standards-track and informational specifications that..." (that does XYZ)

(b) Date for re-charter completion:

Should you perhaps add a date for the completion of the re-chartering. Say March 2012 (to coincide with the March IETF). Otherwise re-chartering may drag on for sometime -- which is known to happen in the IETF :-)

(c) Profiles of OAUTH2.0:

I know that some folks want to use OAUTH2.0 as is (just the one spec), but other folks (including myself) see the need to build additional features on top the single OAUTH2.0 spec to make OAUTH2.0 work in other scenarios. For lack of a better term, I use the term "profile" (to mean clearly defined additions and narrowings of aspects listed in the main OAUTH2.0 spec).

As such, I would like request the addition of the following paragraph to the new charter:

      Prepare, review, and advance standards-track and informational specifications that define profiles of OAUTH2.0 for usage within certain well-defined environments. These profiles are adjunct to the OAUTH2.0 specification, and add optional capabilities to those already defined in the OAUTH2.0 main specification.

I will add more comments as we go along.

Thanks.

/thomas/

__________________________________________

> Sent: Wednesday, April 27, 2011 5:37 PM
> To: [email-masked]; [email-masked]
> Subject: [OAUTH-WG] Revised Charter
> 
> Hi all,
> 
> authentication, 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],
> 
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Igor Faynberg <[email-masked]>
Date: Thu, 28 Apr 2011 12:02:04 -0400

Blaine,

Looks very good to me.

A small editorial suggestion: Rather then say that "OAuth consists of" 
mechanisms, I would suggest saying "OAuth supports" these mechanisms.

I alsonote the omission of the use cases.  I suggest adding an item, 
"Submit OAuth Use Cases."    George, Torsten, and Zachary should provide 
the date they are comfortable with, but from the comments of the two 
reviewers that I had seen, it appears that the document is pretty much 
ready.

Igor

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 28 Apr 2011 09:48:29 -0700

-1 on all of these.

> Of Thomas Hardjono
> Sent: Thursday, April 28, 2011 7:20 AM
> To: Blaine Cook; [email-masked]; [email-masked]
> Subject: Re: [OAUTH-WG] Revised Charter
> 
> Thanks Blaine,
> 
> I would like to see language that is more open (ready) to accept future items
> (ie. those on the horizon and those unforeseen).
> 
> For example, the Kerberos WG has just completed its re-charter recently and
> had to address this same notion of limit/openness to future items.  The
> language that was finally chosen reflects this openness, I think.  Here are two
> examples:
> 

This defeats the purpose of a charter, which is meant to clearly define what the working group is scoped to do. I would like to see a charter as narrow as possible to help us focus on getting 2.0 done.

> Should you perhaps add a date for the completion of the re-chartering. Say
> March 2012 (to coincide with the March IETF). Otherwise re-chartering may
> drag on for sometime -- which is known to happen in the IETF :-)

I have serious doubts about the need for this WG to continue. I for one am going to push for closing this WG as soon as the list of deliverables are complete. If there is new work, it belongs in a new WG.

> I know that some folks want to use OAUTH2.0 as is (just the one spec), but
> other folks (including myself) see the need to build additional features on
> top the single OAUTH2.0 spec to make OAUTH2.0 work in other scenarios.
> For lack of a better term, I use the term "profile" (to mean clearly defined
> additions and narrowings of aspects listed in the main OAUTH2.0 spec).
> 
>       Prepare, review, and advance standards-track and informational
> specifications that define profiles of OAUTH2.0 for usage within certain well-
> defined environments. These profiles are adjunct to the OAUTH2.0
> specification, and add optional capabilities to those already defined in the
> OAUTH2.0 main specification.

This is just a distraction. If you can demonstrate sufficient interest, you should have no problem creating a new WG at the conclusion of this one, or just submit and individual submission, which is probably the only practical way to go with most of these extensions (given the lack or implementation experience and small number of people interested in them).

EHL

---

From: Thomas Hardjono <[email-masked]>
Date: Thu, 28 Apr 2011 13:11:20 -0400

Folks, Eran,

My apologies for jumping ahead to far.  I misunderstood Blaine's email. I took the words "Revised Charter" to mean "Re-charter".

And usually when a WG says "re-charter", it means a big overhaul (which is why I mentioned Profiles, etc. etc.).

This is not the case here. I believe what we are doing today is a just a charter "clarification", "firm-up" or "clean-up".

So please ignore my posting :)

Thanks.

/thomas/

> From: Eran Hammer-Lahav [mailto:[email-masked]]
> Sent: Thursday, April 28, 2011 12:48 PM
> To: Thomas Hardjono; Blaine Cook; [email-masked]; oauth-
> [email-masked]
> Subject: RE: [OAUTH-WG] Revised Charter
> 
> -1 on all of these.
> 
> > This is a good start.  I have two suggestions and one request for an
> > additional
> > paragraph/bullet:
> >
> > I would like to see language that is more open (ready) to accept
> > future items (ie. those on the horizon and those unforeseen).
> >
> > For example, the Kerberos WG has just completed its re-charter
> > recently and had to address this same notion of limit/openness to
> > future items.  The language that was finally chosen reflects this
> > openness, I think.  Here are two
> > examples:
> >
> >     "Prepare and advance one or more standards-track specifications
> which...."
> > (does XYZ).
> >
> This defeats the purpose of a charter, which is meant to clearly define
> what the working group is scoped to do. I would like to see a charter
> as narrow as possible to help us focus on getting 2.0 done.
> 
> >
> > Should you perhaps add a date for the completion of the re-
> chartering.
> > Say March 2012 (to coincide with the March IETF). Otherwise
> > re-chartering may drag on for sometime -- which is known to happen in
> > the IETF :-)
> 
> I have serious doubts about the need for this WG to continue. I for one
> am going to push for closing this WG as soon as the list of
> deliverables are complete. If there is new work, it belongs in a new
> WG.
> 
> > I know that some folks want to use OAUTH2.0 as is (just the one
> spec),
> > but other folks (including myself) see the need to build additional
> > features on top the single OAUTH2.0 spec to make OAUTH2.0 work in
> other scenarios.
> > For lack of a better term, I use the term "profile" (to mean clearly
> > defined additions and narrowings of aspects listed in the main
> OAUTH2.0 spec).
> >
> > specifications that define profiles of OAUTH2.0 for usage within
> > certain well- defined environments. These profiles are adjunct to the
> > OAUTH2.0 specification, and add optional capabilities to those
> already
> > defined in the
> This is just a distraction. If you can demonstrate sufficient interest,
> you should have no problem creating a new WG at the conclusion of this
> one, or just submit and individual submission, which is probably the
> only practical way to go with most of these extensions (given the lack
> or implementation experience and small number of people interested in
> them).
> 
> 
> EHL

---

From: David Recordon <[email-masked]>
Date: Thu, 28 Apr 2011 12:22:25 -0700

I agree with Eran as well that the focus should be on finalizing 2.0
and then future work can occur in new working groups. We're so close!
I keep telling people throughout the industry that the spec hasn't
changed technically in months but they keep asking when it's going to
be a final RFC.

---

From: Dick Hardt <[email-masked]>
Date: Thu, 28 Apr 2011 12:36:27 -0700

+1 to Eran and David's comments. Let's not get distracted when we are close to finalizing. I suggest revising the charter once we are done with 2.0 unless there is a process reason for revising the charter to complete 2.0.

-- Dick