Re: [oauth] FW: OAUTH charter for consideration

["Thomas Hardjono" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf
> Of Hannes Tschofenig
> Sent: Wednesday, April 15, 2009 3:53 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: [oauth] FW: OAUTH charter for consideration
> 
> 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.htm
> l .
> 
> 
> 			* 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.
> 
> 
> _______________________________________________
> oauth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth