Subject: [oauth] FW: OAUTH charter for consideration

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 15 Apr 2009 10:52:36 +0300

Hi Adrian, 
 
thanks for your feedback to the charter. I have addressed most of your
comments in the updated charter text. A few minor comments inline (search
for [hannes]).
 
I will distribute the updated charter text with a subsequent mail. 

Ciao
Hannes

________________________________

	From: Lisa Dusseault [mailto:[email-masked]]

	Sent: 11 April, 2009 23:39
	To: Blaine Cook; Hannes Tschofenig
	Subject: Fwd: OAUTH charter for consideration

	FYI

	Begin forwarded message:

		From: Adrian Farrel <[email-masked]>
		Date: April 10, 2009 1:08:27 PM PDT
		To: Lisa Dusseault <[email-masked]>
		Cc: [email-masked]
		Subject: Re: OAUTH charter for consideration
		Reply-To: Adrian Farrel <[email-masked]>

		Hi Lisa,
		
		Nits, but mainly that the third person has become confused.

			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.

		"their resources" == the user's resources?
		"their credentials" == the third party's credentials?
		"their identity" ==  the third party's identity?
		
		Would be neat to clean that up.

			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.

		Even in this example...
		"thier private pictures" == each user's private pictures?

			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.

		On the user's behalf or on behalf of the third party?

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

		s/gap/gaps/

			 * 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

		s/backwards/backward/ x2

			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

		s/modified/modified,/

			backwards compatible profiling activity. The
applicability of existing

		s/backwards/backward/

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

			* Recommendations regarding the structure of the
token.

			* Localization, e.g.,

http://oauth.googlecode.com/svn/spec/ext/language_preference/1.0/drafts/2/sp
ec.html .

			* Session-oriented tokens, e.g.,

http://oauth.googlecode.com/svn/spec/ext/session/1.0/drafts/1/spec.html.

		I find it a bit odd to see URLs in the charter like this
given that we don't feel very comfortable with URLs in RFCs.

[hannes] We put them in there since folks want to have a few examples of
possible extensions listed. The name of the extension, however, does not
really provide enough useful content and hence we added the pointers. 

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

		s/and/, but/ ???

			The Working Group will also define a generally
applicable HTTP authentication mechanism (i.e., browser-based "2-leg"
scenerio).

		s/i.e./e.g./  ???

[hannes] "i.e." is correct here since 2-legged scenario is the terminology
we are using for this type of exchange. 

			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

		Cheers,
		Adrian 

	--- Scanned by M+ Guardian Messaging Firewall --- Messaging
Architects sponsors The Spamhaus Project.

---

From: "Thomas Hardjono" <[email-masked]>
Date: Wed, 15 Apr 2009 09:05:14 -0400

Hi,

I just had a short question/suggestion. In the past every time a new WG is
to be proposed or created, the IETF usually insists that the new WG make-use
of existing protocols and/or mechanisms, which already exists in the IETF or
other Standards organization. (ie. don't re-invent the wheel).

Will this mandate also be observed in this new WG?

Thanks.

/thomas/

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Hannes Tschofenig
> Sent: Wednesday, April 15, 2009 3:53 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [oauth] FW: OAUTH charter for consideration
> 
> Hi Adrian,
> 
> 	From: Lisa Dusseault
> [mailto:[email-masked]]
> 
> _______________________________________________
> oauth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 15 Apr 2009 16:16:58 +0300

Hi Thomas, 

>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of ext Thomas Hardjono
>Sent: 15 April, 2009 16:05
>To: 'Hannes Tschofenig'; [email-masked]
>Cc: [email-masked]
>Subject: Re: [oauth] FW: OAUTH charter for consideration
>
>Hi,
>
>I just had a short question/suggestion. In the past every time 
>a new WG is to be proposed or created, the IETF usually 
>insists that the new WG make-use of existing protocols and/or 
>mechanisms, which already exists in the IETF or other 
>Standards organization. (ie. don't re-invent the wheel).

We re-use something that is already out there and try to improve
security (and other things). The stuff that is being re-used is the
OAuth protocol, see http://oauth.net/ (with code available here
http://oauth.net/code). 

Ciao
Hannes 

>> comments in the updated charter text. A few minor comments inline 
>> (search for [hannes]).
>> 
>> 			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.
>> 
>> 
>> 
>> 		Even in this example...
>> 			 * 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:
>> 
>> 
>> 			 * Embody good security practice, or 
>document gaps in its  
>> capabilities, and propose a path forward for addressing the gap.
>> 
>> 
>> 
>> 		s/gap/gaps/
>> 
>> 
>> 
>> 			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,
>> 			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.
>> signature  methods will not be modified but may be dropped 
>as part of 
>> the
>> 
>> 
>> 
>> 		s/modified/modified,/
>> 
>> 
>> 
>> 			backwards compatible profiling 
>activity. The applicability of 
>> existing
>> 
>> 
>> 
>> 		s/backwards/backward/
>> 
>> 
>> 
>> 			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.
>> 
>> 
>> 
>> 			After delivering OAuth 1.1, the Working 
>Group may consider defining 
>> additional functions and/or extensions, for example (but not limited
>> 
>> 
>> 			to):
>> 
>> 
>http://oauth.googlecode.com/svn/spec/ext/body_hash/1.0/drafts/1
>/spec.htm
>> l .
>> 
>> 
>http://oauth.googlecode.com/svn/spec/ext/language_preference/1.
>0/drafts/
>> 2/sp
>> ec.html .
>> 
>>