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

[Eran Hammer-Lahav <[e-mail]>]

Listing a bunch of ideas the WG might want to consider later on is fine by me (and pretty useless). The charter is suppose to help us focus...

EHL


On 2/17/09 1:21 PM, "John Kemp" <[e-mail]> wrote:

On Feb 17, 2009, at 4:07 PM, Eran Hammer-Lahav wrote:

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

My answer would be simply that a list of proposed "extensions" is
listed in the current charter text (taken from my previous email):

> From the charter text in [1]
>
>> "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 could be persuaded that this text doesn't prevent the development of
any extensions, but once you list one, you run the risk of people
asking "why don't you list XYZ too?"

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

I don't think timing is so much the issue.

Regards,

- johnk

[1] http://www.ietf.org/mail-archive/web/oauth/current/msg00085.html

>
>
> 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
>
> _______________________________________________
> oauth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth