Re: [OAUTH-WG] Native Client Extension

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-bounces@ietf.org [mailto:oauth-bounces@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 <skylar@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