Re: [oauth] draft-dehora-farrell-oauth-accesstoken-creds-00.txt and OAUTH Extensions in the Charter

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

Hi Eran, 
 
I understand your concerns. We started to add examples to the initial
charter text: 
 
"
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.
"

I understand why Stephen asks for getting text about his extension added. I
can imagine that someone else comes up with their favorite extension,
simililarly as you listed in your mail. 

In some sense it would be fair to add text about the other examples added as
well, if someone cares. 

I wonder what other folks in the group think about this topic? 

Ciao
Hannes
 


________________________________

	From: [e-mail] [mailto:[e-mail]] On
Behalf Of Eran Hammer-Lahav
	Sent: 17 February, 2009 23:07
	To: [e-mail]; [e-mail];
[e-mail]
	Cc: [e-mail]
	Subject: Re: [oauth]
draft-dehora-farrell-oauth-accesstoken-creds-00.txt and OAUTH Extensions in
the Charter
	
	
	I don't understand why we need to add this.
	
	There is nothing to stop people from proposing and developing such
ideas. So far we have little implementation experience with much of these
suggestions. The fact is, everyone here is correctly referring to these
ideas as *extensions*. The purpose of this working group is to figure out
the 'core' framework. Error handling is crucial to interop.
Internationalization is important when dealing with user interfaces which
OAuth does even in its core components. These make sense to *consider*.
	
	But why go and single out one extension just because it has an I-D?
I could have stood up at the BoF and listed at least 10 other extensions
with wide interest. Yahoo cares a lot about its Session extension. Google
cares a lot about a few OpenSocial extensions related to gadgets. We have
known limitations with the use of OAuth consumer credentials in desktop
applications. Many people asked for a standard way of consumer registration.
Discovery has been a big topic for the past year and a half. The choice of
signature method hash functions have been an issue in the past due to lack
to support for some on limited devices. The list goes on and on.
	
	OAuth Core represents a compromise that allowed a wide range of use
cases to agree on something that provided a good foundation and was based on
implementation experience. For the most part this WG must have the narrow
focus of taking draft-hammer-oauth and bringing it to IETF proposed standard
level. That means focusing on security and interop. Anything else should
come later.
	
	EHL
	
	
	On 2/17/09 12:43 PM, "[e-mail]"
<[e-mail]> wrote:
	
	

		
		
		I recall there was a lot of support in Minneapolis for
extension targeted for devices as Stephen suggests.  I would support adding
the text proposed by Stephen to the OAUTH charter:
		
		"The WG will develop an oauth extension suited for use on
challenged devices and by aggregators that allows for the client to directly
acquire an access token from a set of credentials. One such scheme is
defined in draft-dehora-farrell-oauth-accesstoken-creds"
		
		I don't believe the last sentence precludes any other
proposed drafts that meet this goal, if there are other approaches that may
be developing in the WG.
		
		Best Regards,
		Dorothy
		
		
		-----Original Message-----
		From: [e-mail] [mailto:[e-mail]]
On Behalf Of ext Stephen Farrell
		Sent: Tuesday, February 17, 2009 8:15 AM
		To: Hannes Tschofenig
		Cc: [e-mail]
		Subject: Re: [oauth]
draft-dehora-farrell-oauth-accesstoken-creds-00.txt and OAUTH Extensions in
the Charter
		
		
		
		Hannes Tschofenig wrote:
		> Stephen ask me how their document
		> draft-dehora-farrell-oauth-accesstoken-creds-00.txt is
reflected in
		> the charter text.
		
		Actually, I sent a mail to you and Blaine off list. I guess
we should now discuss it on the list, now that you've gone ahead here
instead of responding to the off list mail.
		
		Also I didn't ask how "its reflected" I suggested a way to
include it, which is quite different.
		
		My suggestion is to add the following:
		
		"The WG will develop an oauth extension suited for use on
challenged devices and by aggregators that allows for the client to directly
acquire an access token from a set of credentials. One such scheme is
defined in draft-dehora-farrell-oauth-accesstoken-creds"
		
		I'd still like to see that included and will certainly
suggest it again in SF, as I did in MSP, and without anyone (that I recall)
disagreeing with considering the use case.
		
		> Independent of this particular document, I believe that we
should
		> focus our initial efforts on the Base OAUTH specification
rather than
		> working on extensions.
		
		Agreed. I never asked that our use case be worked before the
spec work is done and have no idea how you formed that impression.
		
		> As such, I would say that (depending on the progress of
the work with
		> the main specification) we should discuss extensions in
the summer
		> timeframe.
		
		I think its fair enough to mention the AFAIK only proposed
extension that's documented as an I-D in the charter. I don't read your
current charter proposal as encompassing our draft without rechartering.
		
		> Regarding this specific extension: I read through
		> draft-dehora-farrell-oauth-accesstoken-creds-00.txt and
wanted to make
		> sure that I understood the extension correctly. Here is a
message flow
		> that Jeff created some time ago. This document suggests to
skip the
		> message exchanges marked as (2.*). This means that the
redirect from
		> the Service Provider to the Customer and the subsequent
steps of user
		> authentication and authorization are replaced with the
ability to
		> carry some username/password in the Access token when the
Consumer
		> sends the request to the Service Provider.
		
		Right.
		
		> My personal view is that this goes a bit against the OAUTH
idea.
		> Unless the username/password is again created using some
other
		> mechanism (which the document does not describe) then
there are
		> vulnerability that OAUTH was initially meant to deal with.
		
		That's sort-of correct, however the point is that its
necessary to deploy OAuth for existing mobile devices and some aggregation
use cases.
		
		> Additionally, the result is less likely to be easy to
deploy.
		
		I think you're 100% wrong there...for the use cases we're
considering. On what basis do you say that? Do you think that HTTP redirects
on mobiles are just fine?
		
		> As a justification for the work the following argument is
provided:
		> "HTTP redirection to a browser is unavailable or
unsuitable, such as
		> intermediary aggregators and mobile or settop devices." I
wonder
		> whether this is really a problem in today's mobile devices
to justify this optimization.
		
		You can wonder, but it is.
		
		Stephen.
		
		_______________________________________________
		oauth mailing list
		[e-mail]
		https://www.ietf.org/mailman/listinfo/oauth
		_______________________________________________
		oauth mailing list
		[e-mail]
		https://www.ietf.org/mailman/listinfo/oauth