Subject: [oauth] OAUTH Charter Proposal

From: "Hannes Tschofenig" <[email-masked]>
Date: Fri, 30 Jan 2009 19:55:13 +0200

Hi all, 

After a chat with Lisa I got in touch with Eran to slightly revise the
charter text that Sam and Mark put together for the last IETF meeting.

It should addresses some of the comments provided during the BOF. Your
feedback is welcome. 

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 consist 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 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
  * Promote interoperability

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. 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 in case the existing mechanisms do not fulfill the
security requirements. Existing signature methods will not be modified but
may be dropped as part of the backwards compatible profiling activity.

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:

12/2009     Submit document(s) suitable for publication as standards-track
RFCs.

_______________________________________________
oauth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Blaine Cook <[email-masked]>
Date: Fri, 30 Jan 2009 19:03:35 +0000

+1. This looks awesome, thanks Hannes. What are the next steps? My
understanding is that first we need some kind of consensus on this
charter, and then ??

b.

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Sat, 31 Jan 2009 00:32:48 +0200

We need a couple of folks agreeing the charter proposals.  

Next, there is the question whether a meeting slot at the next IETF meeting
(in San Francisco) should be requested (e.g., in the form of a BOF). This
would give some discussion time for the details of the BOF or if everyone
likes the charter till then already one could disuss the technical details
instead. 

The Area Directors are then requested to charter a working group. They
discuss it within the IESG and get feedback from the IAB. They also need to
find chairs for the group. 

Ciao
Hannes

>-----Original Message-----
>From: Blaine Cook [mailto:[email-masked]] 
>Sent: 30 January, 2009 21:04
>To: Hannes Tschofenig
>Cc: [email-masked]
>Subject: Re: [oauth] OAUTH Charter Proposal
>
>understanding is that first we need some kind of consensus on 
>this charter, and then ??
>
>b.
>
>> 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 consist 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
>>  * Align OAuth with the Internet and Web architectures, best 
>practices 
>> and terminology
>> 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. any OAUTH 1.0 and the specification produced by this 
>> group must support a basic set of features to guarantee 
>> interoperability.
>>
>> requests, namely PLAINTEXT, HMAC-SHA1, and RSA-SHA1. The group will 
>> work on new signature methods in case the existing mechanisms do not 
>> fulfill the security requirements. Existing signature 
>methods will not 
>> be modified but may be dropped as part of the backwards 
>compatible profiling activity.
>>
>>  * 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):

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 30 Jan 2009 15:35:15 -0700

I like the proposed charter. I think it offers enough flexibility for changes while maintaining the spirit and framework of the OAuth Core 1.0 spec.

EHL

On 1/30/09 2:32 PM, "Hannes Tschofenig" <[email-masked]> wrote:

Ciao
Hannes

---

From: Krishna Sankar <[email-masked]>
Date: Fri, 30 Jan 2009 20:42:47 -0800

+1. We bounded with enough flexibility.

Should we mention anything about extensions or any extensibility framework ?

Cheers
<k/>
Eran Hammer-Lahav wrote:
> I like the proposed charter. I think it offers enough flexibility for 
> changes while maintaining the spirit and framework of the OAuth Core 
> 1.0 spec.
>
> EHL
>
>
> ------------------------------------------------------------------------
>

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Sat, 31 Jan 2009 13:36:48 +0200

>extensibility framework ?

What specifically do you have in mind? 
A document that describes an extensibility framework?
Highlighting in the charter what extension points could/should be used?

Ciao
Hannes

---

From: Krishna Sankar <[email-masked]>
Date: Sat, 31 Jan 2009 10:52:45 -0800

Three vectors:

a)   While we cannot legislate extensibility, an extensibility guideline 
document need to be part of the deliverables. When the main OAuth 
discussions occur, there will be things we will say "this is not core 
but belongs to extensions" or we might make certain assumptions that we 
need to explicitly state or we might have certain insights. This 
document can systemically capture all these artifacts. We also might 
need to add security considerations as well as interoperability and 
conformance for extensions.

b) As a part of the charter we should add :

* Promote interoperability
* Provide guidelines for extensibility

The group should think about extensibility & document the results of the 
deliberations

c)   While I like an extensibility framework, it might prove to be too 
much and might not be practical. So am happy at the level of guidelines, 
insights and suggestions.

Cheers
<k/>
Hannes Tschofenig wrote:
>  >Should we mention anything about extensions or any 
>   
>> extensibility framework ?
>>
>> Cheers
>> <k/>
>>     
>

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Sat, 31 Jan 2009 23:37:27 +0200

Hi Krishna, 

Thanks for your quick response. 

>document need to be part of the deliverables. When the main 
>OAuth discussions occur, there will be things we will say 
>"this is not core but belongs to extensions" or we might make 
>certain assumptions that we need to explicitly state or we 
>might have certain insights. This document can systemically 
>capture all these artifacts. We also might need to add 
>security considerations as well as interoperability and 

A description on how OAUTH can (or should) be extended is certainly useful
(better explicit than implicit). This could, for example, be part of the
main specification. I have also seen separate documents that illustrate how
a protocol (or a set of protocols) can be extended. Example: Design
Guidelines for RADIUS
http://www.ietf.org/internet-drafts/draft-ietf-radext-design-05.txt
This document has been written some time after the deployment happened and
provides a sort of best current practice on how to build RADIUS extensions.
I believe it is a bit early for these type of documents. 

So, my proposal would be to capture the most important extensibility aspects
within the main specification itself. Later, when some expertise can be
gained with OAUTH extensions one can start thinking about capturing the
design experience in a document. 

I guess we are doing fine with the security considerations as every IETF
document needs to contain a section describing them. 

In any case, if you already have some ideas for text (or already a text
proposal) for the OAUTH draft feel free to post something to the list (even
though it is not directly related to the charter discussion itself). 

>The group should think about extensibility & document the 
>results of the deliberations

Explicitly stating extensibility in the charter sounds useful to me. 
I added it to the charter text. 
 
>much and might not be practical. So am happy at the level of 
>guidelines, insights and suggestions.

Ok.

Ciao
Hannes

---

From: Krishna Sankar <[email-masked]>
Date: Sat, 31 Jan 2009 18:28:33 -0800

Hannes,
    Thank you. Agreed on all.
Cheers & have a nice weekend
<k/>
Hannes Tschofenig wrote:
>>> Highlighting in the charter what extension points 
>>>       
>> could/should be used?
>>     
>>> Ciao
>>> Hannes
>>>
>>>
>>>   
>>>       
>
>
>