+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
