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

[Blaine Cook <[e-mail]>]

One slight modification, as per an off-list conversation with Eran:

move " * Error reporting" from extensions, and incorporate that work
into the core spec, which I believe was agreed upon in principle
several months ago at the start of this process. I don't think we need
to modify the charter text, as error reporting would fall under the
requirement to "promote interoperability", though we can add it
explicitly if it makes sense.

b.

On Tue, Feb 17, 2009 at 9:57 PM, Blaine Cook <[e-mail]> wrote:
> Can I suggest that we update the section of the charter before the
> Goals and Milestones that currently reads:
>
> 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
>
>
> to read:
>
> After delivering OAuth, the Working Group MAY consider defining
> additional functions and/or extensions, for example (but not limited
> to):
> * Discovery of OAuth configuration
> * Comprehensive message integrity
> * Recommendations regarding the structure of the token
> * Localization
> * Error reporting
> * Session-oriented tokens
> * Alternate token exchange profiles
>
> Note also that the list is not bounded, and I expect that any work
> done after the finalization of OAuth as per the charter will happen
> only insofar as running exemplar code exists and can serve as a basis
> for standardization driven by actual involvement from the community.
>
> Does that satisfy the requirements? I definitely echo Eran's concerns
> that our primary task is the Core specification, but want to make sure
> that everyone has clear expectations and feels that they can make
> valuable contributions going in.
>
> cheers,
>
> b.
>
> On Tue, Feb 17, 2009 at 8:43 PM,  <[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
>>
>