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
