Re: [OAUTH-WG] Native Client Extension

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-bounces@ietf.org [mailto:oauth-bounces@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-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of
> Skylar Woodward [skylar@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
> > <torsten@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