[oauth] FW: OAUTH charter for consideration

["Hannes Tschofenig" <[e-mail]>]

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:[e-mail]]

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

	Begin forwarded message:


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

		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.