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

[David Recordon <[e-mail]>]

Hey Marius,

1) Feels like this should be in an unregistered client spec.

3) Why would a device which intends to open a web browser use the
device flow to start? Wouldn't it just use the user agent flow?

4) Yes, but should be a separate document.

Thanks,
--David


On Tue, Jun 8, 2010 at 10:46 AM, Marius Scurtescu <[e-mail]> wrote:
> 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
>