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...@hueniverse.com> 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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
