I think it should still use the existing 'token' and 'code' values, but with a special redirect_uri value (preferably something like a urn: to make it clear). This way, there is no need to add a new mechanism for extending parameter *values* (though such an extension *can* update the registration of the 'response_type' parameter), no need for special rules about the redirect_uri parameters, and the urn: can be used to indicate the style of the delivery (title, custom scheme, etc.). It also allows using both redirection-based flows.
EHL > -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Richer, Justin P. > Sent: Thursday, January 27, 2011 11:40 AM > To: Skylar Woodward; Marius Scurtescu > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Native Client Extension > > +1 on out of band auth being moved to a more fully-specified extension. It > can (and likely should) still use mechanisms such as auth codes, but with > different requirements such as no return URL. This is where things like the > <title>code</title> hack can live, as well. > > -- Justin > ________________________________________ > From: oauth-boun...@ietf.org [oauth-boun...@ietf.org] On Behalf Of > Skylar Woodward [sky...@kiva.org] > Sent: Thursday, January 27, 2011 6:00 AM > To: Marius Scurtescu > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Native Client Extension > > Marius, > > I support the extension (as per my previous letter, as I missed this thread > over the holidays) and Kiva is/was planning to support this as well. Given > the > unpredictable technology environments of many of our customers, this flow > is essential for our implementation. > > However, now reviewing language in draft-12, I wonder if it isn't more clear > to define the extension as using a different response_type (eg, oob_code). > In the past, the use of "oob" has been more of hack to work with existing > specs. In truth, it is a unique flow of its own compared to Implict and Auth > Code as they are currently defined. Such a flow would not accept a > redirect_url and could use "oob_code" for both response_type and > grant_type. > > skylar > > > On Jan 4, 2011, at 11:58 PM, Marius Scurtescu wrote: > > > On Tue, Jan 4, 2011 at 2:23 PM, Torsten Lodderstedt > > <tors...@lodderstedt.net> wrote: > >> +1 > >> > >> I have asked myself all the time why "oob" disappeared in OAuth 2.0? > >> Does Google use this feature? > > > > Yes, we are planning to support this, exactly as described in the extension. > > > > Marius > > _______________________________________________ > > 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
