Subject: [oauth] Last Call for Comments: OAuth Charter Text

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 17 Feb 2009 10:54:59 +0200

Hi all, 

we have now discussed the charter text for some time and we got good
feedback. I have tried to reflect it in an appropriate way. 

I think it is about time to finish this part of the story. Please review
the current charter text and make a judgement whether we can move
forward with it. 

Ciao
Hannes

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

Open Authentication Protocol (oauth)

Last Modified: 2009-01-30

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 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 that 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 the OAuth I-D, that will:
  * Align OAuth with the Internet and Web architectures, best practices
and terminology.
  * Assure 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
the OAuth 1.0 specification is used and the available extension points
are going to be utilized. It seems desireable to profile OAuth 1.0 in a
way that produces a specification that is a backwards compatible
profile, i.e. an OAuth 1.0 implementation 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.

In doing so, it should consider:
  * Implementer experience.
  * Existing uses of OAuth.
  * Ability to achieve broad impementation.
  * Ability to address broader use cases than may be contemplated by the
original authors.
  * Impact on the Internet and Web.

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 authentication configuration.
  * Message integrity.
  * Recommendations regarding the structure of the token.

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.)
Sep 2009    Start Working Group Last Call on 'OAuth: HTTP Authorization
Delegation Protocol'
Sep 2009    Discusion about OAUTH extensions the group should work on
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: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 17 Feb 2009 11:35:17 +0200

Btw, I should also indicate a deadline for providing comments. 

Please have your comments in no later than February 27th. 

Thanks. 

Ciao
Hannes

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of ext Tschofenig, Hannes (NSN - FI/Espoo)
>Sent: 17 February, 2009 10:55
>To: [email-masked]
>Subject: [oauth] Last Call for Comments: OAuth Charter Text
>
>Hi all, 
>
>we have now discussed the charter text for some time and we 
>got good feedback. I have tried to reflect it in an appropriate way. 
>
>I think it is about time to finish this part of the story. 
>Please review the current charter text and make a judgement 
>whether we can move forward with it. 
>
>Ciao
>Hannes
>
>OAuth allows a user to grant a third-party Web site or 
>application access to their resources, without 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 that can be used by a third party to access 
>resources on their behalf.
>The Working Group will produce one or more documents suitable 
>for consideration as Proposed Standard, based upon the OAuth 
>I-D, that will:
>  * Align OAuth with the Internet and Web architectures, best 
>practices and terminology.
>  * Assure good security practice, or document gaps in its 
>capabilities, and propose a path forward for addressing the gap.
>This specifically means that as a starting point for the 
>working group the OAuth 1.0 specification is used and the 
>available extension points are going to be utilized. It seems 
>desireable to profile OAuth 1.0 in a way that produces a 
>specification that is a backwards compatible profile, i.e. an 
>OAuth 1.0 implementation 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.
>
>  * 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):
>            (draft-hammer-oauth will be used as a starting 
>point for further work.)
>_______________________________________________
>oauth mailing list
>[email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 17 Feb 2009 16:14:48 +0000

I made some comments before [1] that don't seem to have been
included here - was that deliberate or did they get missed?

S.

[1] http://www.ietf.org/mail-archive/web/oauth/current/msg00061.html

---

From: George Fletcher <[email-masked]>
Date: Tue, 17 Feb 2009 12:17:45 -0500

Just to clarify... does the following quote from the charter...

"This specifically means that as a starting point for the working group
the OAuth 1.0 specification is used and the available extension points
are going to be utilized."

.... mean that all extensions either checked in at oauth.pbwiki.com, the 
svn repository, or the 
draft-dehora-farrell-oauth-accesstoken-creds-00.txt that Stephen 
mentions will all be considered?

Or will only certain extensions be considered for inclusion into the 1.0 
version?

Thanks,
George

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 17 Feb 2009 10:38:40 -0700

No. 'extension points' mean the spec allowing new signature methods, parameter methods, etc. The ways in which the spec allows it to be extended. Not extension proposals.

EHL

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of George Fletcher
> Sent: Tuesday, February 17, 2009 9:18 AM
> To: Tschofenig, Hannes (NSN - FI/Espoo)
> Cc: [email-masked]
> Subject: Re: [oauth] Last Call for Comments: OAuth Charter Text
>
> capabilities,
> protect

---

From: George Fletcher <[email-masked]>
Date: Tue, 17 Feb 2009 12:46:11 -0500

So what is the plan for existing extensions written against OAuth 1.0 
core? Will they be supported? or will they need to be re-written? Should 
the charter take into consideration the extensions that are already 
deployed? (e.g. Scalable OAuth?)

Thanks,
George

Eran Hammer-Lahav wrote:
>>> I think it is about time to finish this part of the story. Please
>>>       
>> review
>>     
>>> ---------------------------------------------------------------------
>>>       
>> ---
>>     
>>> -------------
>>>
>>> access to their resources, without revealing their credentials, or
>>>       
>> even
>>     
>>> would allow its users to use a third-party printing Web site to
>>>       
>> access
>>     
>>>   * A mechanism for exchanging a user's credentials for a token-
>>>       
>> secret
>>     
>>> consideration as Proposed Standard, based upon the OAuth I-D, that
>>>       
>> will:
>>     
>> practices
>>> This specifically means that as a starting point for the working
>>>       
>> group
>>     
>>> the OAuth 1.0 specification is used and the available extension
>>>       
>> points
>>     
>>> are going to be utilized. It seems desireable to profile OAuth 1.0 in
>>>       
>> a
>>     
>>> profile, i.e. an OAuth 1.0 implementation and the specification
>>>       
>> produced
>>     
>>> requests, namely PLAINTEXT, HMAC-SHA1, and RSA-SHA1. The group will
>>>       
>> work
>>     
>>>   * Ability to address broader use cases than may be contemplated by
>>>       
>> the
>>     
>>> original authors.
>>> 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
>>     
>>> Sep 2009    Start Working Group Last Call on 'OAuth: HTTP
>>>       
>> Authorization
>>     
>>> Delegation Protocol'
>>> Nov 2009    Prepare milestone update to start new work within the
>>>       
>> scope
>>     
>>> of the charter

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 17 Feb 2009 10:51:57 -0700

None of the extensions have been declared final. I expect the problem reporting to be incorporated (or replaced with something similar). Since this new work is likely to break some things, it would be better to first get it done and then consider its impact on deployed extensions. There is nothing in the charter that will prevent us from re-chartering the wg to do more work when this is done. But for now we should be focused on getting the core protocol into a standard status.

EHL

> From: George Fletcher [mailto:[email-masked]]
> Sent: Tuesday, February 17, 2009 9:46 AM
> To: Eran Hammer-Lahav
> Cc: Tschofenig, Hannes (NSN - FI/Espoo); [email-masked]
> > No. 'extension points' mean the spec allowing new signature methods,
> parameter methods, etc. The ways in which the spec allows it to be
> extended. Not extension proposals.
> >
> > EHL
> >
> >
> applicable

---

From: Aaron Stone <[email-masked]>
Date: Tue, 17 Feb 2009 11:17:50 -0800

Hi Hannes and WG,

The middle paragraphs are pretty choppy and unclear to me. I think I get
what's going on well enough not to complain (that is, "The Charter Looks
Good Enough To Me (TM)"), but below are some suggested changes to clarify.

Cheers,
Aaron

> Please have your comments in no later than February 27th. 

[snip]
>>for consideration as Proposed Standard, based upon the OAuth 

Here we start with the OAuth I-D...

Suggested replacement text: "The Working Group will produce one or more
documents suitable for consideration as Proposed Standard. The Working
Group will begin with the independently published OAuth 1.0 specification,
and will:"

>>available extension points are going to be utilized. It seems 

What are "available extension points" ?

>>this group must support a basic set of features to guarantee 

...here we talk about OAuth 1.0. What's the difference from the OAuth I-D
in the previous paragraph?

Suggested replacement paragraph: "As best as possible, the Working Group
will produce a specification that is a backwards compatible profile of
OAuth 1.0, i.e. an OAuth 1.0 implementation and the specification(s)
produced by this group will support a basic set of features to assure
interoperability. The Working Group will also consider existing OAuth 1.0
extensions for interoperability with the updated specification(s)."

>>In doing so, it should consider:

s/ it / the Working Group /

For me, "In doing so" refers to signature methods and applicability of
signature methods to protocols other than HTTP. Is that correct? If not,
let's replace "In doing so" with what we'd be so doing ;)

>>  * Impact on the Internet and Web.

[cut]

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Tue, 17 Feb 2009 22:04:51 +0200

I missed them and I will incorporate them.

Thanks for pointing me to them. 

Ciao
Hannes

>On Behalf Of Stephen Farrell
>Sent: 17 February, 2009 18:15
>> review the current charter text and make a judgement whether we can 
>> move forward with it.
>> 
>> Ciao
>> Hannes
>> 
>> 
>> 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:
>token-secret 
>working group 
>> a way that produces a specification that is a backwards compatible 
>> produced by this group must support a basic set of features to 
>> guarantee interoperability.
>> 
>> 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 original authors.
>> 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.
>>

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 18 Feb 2009 09:51:18 +0200

Hi Aaron, 

I have considered your feedback in the charter. 
A few minor comments below:  

>From: ext Aaron Stone [mailto:[email-masked]] 
>Sent: 17 February, 2009 21:18
>The middle paragraphs are pretty choppy and unclear to me. I 
>think I get what's going on well enough not to complain (that 
>is, "The Charter Looks Good Enough To Me (TM)"), but below are 
>some suggested changes to clarify.
>
>Cheers,
>Aaron
>
>
>Suggested replacement text: "The Working Group will produce 
>one or more documents suitable for consideration as Proposed 
>Standard. The Working Group will begin with the independently 
>published OAuth 1.0 specification, and will:"

I phrased it in the following way based on your and Stephen's feedback:

"
The Working Group will produce one or more documents suitable for
consideration as Proposed Standard, based upon
draft-hammer-oauth-00.txt, that  will:
"

>>>are going to be utilized. It seems
>

-- Eran responded to this one. 

>specification 
>>>that is a backwards compatible profile, i.e. an OAuth 1.0 
>>>implementation and the specification produced by this group must 
>>>support a basic set of features to guarantee interoperability.
>
>...here we talk about OAuth 1.0. What's the difference from 
>the OAuth I-D in the previous paragraph?

Nothing. I made this more clear in the text. 

>
>Suggested replacement paragraph: "As best as possible, the 
>Working Group will produce a specification that is a backwards 
>compatible profile of OAuth 1.0, i.e. an OAuth 1.0 
>implementation and the specification(s) produced by this group 
>will support a basic set of features to assure 
>interoperability. The Working Group will also consider 
>existing OAuth 1.0 extensions for interoperability with the 
>updated specification(s)."

I guess we cannot really write it that way based on the observation that
we had a different understanding of what extension points would mean. 
I believe that this issue got clarified in a separate discussion on the
mailing list. 

>>>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.
>>>
>For me, "In doing so" refers to signature methods and 
>applicability of signature methods to protocols other than 
>HTTP. Is that correct? If not, let's replace "In doing so" 
>with what we'd be so doing ;)

You are right. The "in doing so" is an artifact from previous charter
versions and now does not fit in there anymore. I removed it. 

>>>  * Impact on the Internet and Web.
Thanks for the feedback.

Ciao
Hannes