Re: [OAUTH-WG] native app support (was: Next draft)

[Torsten Lodderstedt <[e-mail]>]

1) +1
2) +1 - Oauth 1.0a had "oob", why not for that purpose
3) I would rather add the user_code as optional URL parameter to the 
device flow.
4) What about an additional best practices document?

regards,
Torsten.

Am 08.06.2010 19:46, schrieb Marius Scurtescu:
> In order to properly support native applications I suggest the
> following changes:
>
> 1. client_name
>
> In all flows when client_id is sent also allow for an optional
> client_name. This optional parameter is meant as a display name for
> the client, and it is useful in all unregistered cases, not only for
> native apps.
>
> If the client is unregistered then most likely the authz server will
> require that client_id be set to a predefined value like "anonymous".
> The approval page does need a client name so it can tell the user who
> it is granting access for.
>
>
> 2. optional redirect_uri (default result page)
>
> Some native apps do not have a redirect_uri, as a result two things are needed:
>
> 2.1 Either make redirect_uri optional or define a standard value that
> signals that the client does not have such a page.
>
> 2.2 The authz server must supply a default result page, if there is no
> redirect_uri. Also, this page should put the verification code and the
> client state (code and state) in the page title in a standard way such
> that the native app can extract them from the window title. WRAP
> defined how the title should be formed.
>
>
> 3. device flow should be able to start user-agent
>
> The device flow can be used by native apps in which case there is a
> browser on the device. This flow should be able to start a browser and
> directly take the user to the end-user verification URI with the user
> code added as a query parameter (so the user is not required to do any
> manual entry). This is sort of possible right now, but the handler
> behind verification_uri must expect an optional user_code (in which
> case it should not prompt the user).
>
>
> 4. section with guidance for native apps
>
> I think the spec needs a section that explains how native apps can be
> used with OAuth 2. Not sure if it is worth getting into pros and cons
> for each flow, but all flows can be used.
>
>
> Marius
>
>
>
> On Mon, Jun 7, 2010 at 8:44 AM, Eran Hammer-Lahav<[e-mail]>  wrote:
>    
>> I still need to catch up on the list (I took a little break). I plan to post a new draft this week incorporating many editorial changes discussed at the interim meeting. I am also planning of removing some non-stable features (such as discovery and signatures) from the draft and moving them to new drafts. As soon as -06 is published, I plan to issue informal last-calls for each section so that we can lock down the normative portions of the draft.
>>
>> If you have any must-happen changes for -05 that were not already posted to the list, please let me know.
>>
>> EHL
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>      
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>