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

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: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of ext Stephen Farrell
Sent: Tuesday, February 17, 2009 8:15 AM
To: Hannes Tschofenig
Cc: oauth@ietf.org
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
oauth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth