Why not: urn:ietf:wg:oauth:2.0:oob
Can you can add more flavors for different ways of floating the token/code up to the application. This requires no changes at all to -12 to allow this special case. EHL > -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Skylar Woodward > Sent: Friday, January 28, 2011 4:09 AM > To: Marius Scurtescu > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Native Client Extension > > I agree in terms of simplicity, but the language in 4.1 and in the definition > of > redirect_url conflicts with group consensus. So it seems a single exception > should be called out for the case where redirect_url=oob (or some compliant > absolute url like x-oauth-oob:), or there should be an extension defined that > makes this exceptional case clearly defined to co-exist with the core > language of MUST, REQUIRED, and absolute. > > On Jan 28, 2011, at 1:44 AM, Marius Scurtescu wrote: > > > On Thu, Jan 27, 2011 at 3:00 AM, Skylar Woodward <sky...@kiva.org> > wrote: > >> 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. > > > > I still think that "oob" applies only to the mechanism to return a > > result, and not to the whole flow. Theoretically redirect_uri=oob > > should work with both response_type=code and response_type=token, > but > > I had in mind only code. > > > > Also, I don't see a reason to do anything special with the grant_type, > > once the client has an authorization code it is all the same. > > > > 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
