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 <mscurte...@google.com> 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...@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
