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

[Stephen Farrell <[e-mail]>]

Hannes Tschofenig wrote:
> 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. 

Right. This being the IETF, taking the trouble to write an
I-D, boilerplate and all, counts, As does code. But one
without the other is less good than having both.

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

Yes, folks writing drafts is a good idea. By all means include
mention of topics with I-Ds.

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

You can guess from the above - gate the list (for now) based on who's
written up their stuff as an I-D. Doesn't preclude additions later
but does require some work before getting on the list in the
charter.

Stephen.

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