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

[Stephen Farrell <[e-mail]>]

Sounds good. I'll see if we've the cycles to get a -01 out (and
totally agree that -00 is missing an important applicability
statement - we did however submit -00 in the 10 minutes before
the MSP deadline, hence the omission:-)

As to milestones, yes, I'd prefer that the charter have a
milestone for draft-ietf-oauth-mobile-00 being 3-6 months
after the WGLC on the base spec. But I can buy the idea of
just mentioning the topic and re-doing the milestones after
WGLC on the base spec.

Stephen.

Hannes Tschofenig wrote:
> Hi Stephen, 
> 
> adding the text as an example of possible extensions the group should work
> on is fine for me as we have already listed other possible extensions to the
> charter text. I got the impression that you wanted to have a milestone added
> already, which I believe would be premature given that the main focus of the
> initial work should be spent on the main spec. As I can read from your
> response you are agreeing with me on this issue. 
> 
> I still believe that the document needs to provide much more context about
> the usage scenarios you have in mind and what the implications regarding
> security area. The current version of the document is essentially only
> describing the bare minimum. 
> 
> Can you ship an update for the IETF#74 cutoff date?  
> 
> Ciao
> Hannes
> 
> 
>> 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.
>>
> 
>