Re: [OAUTH-WG] Native Client Extension

[Skylar Woodward <[e-mail]>]

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 <[e-mail]> 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