Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer

A useful distinction that I had not previously understood, thanks.

On Apr 18, 2012, at 8:50 AM, William Mills wrote:

> OAuth 2.0 is different from 1.0(and a) in that it's an auth framework that deals with getting the tokens, but leaves the use of them to the companion specs.  I think this is what Eran is driving at, in the purest semantic sense.  The OAuth 2.0 API doesn't deal with protected resources at all though, and the discussion about query parameters is all about the protected resource.
> 
> 
> From: Dick Hardt <dick.hardt@gmail.com>
> To: Eran Hammer <eran@hueniverse.com> 
> Cc: Ned Freed <ned.freed@mrochek.com>; Apps Discuss <apps-discuss@ietf.org>; "draft-ietf-oauth-v2-bearer.all@tools.ietf.org" <draft-ietf-oauth-v2-bearer.all@tools.ietf.org>; Mark Nottingham <mnot@mnot.net>; Pete Resnick <presnick@qualcomm.com>; Dick Hardt <dick.hardt@gmail.com> 
> Sent: Tuesday, April 17, 2012 12:31 PM
> Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer
> 
> Please elaborate on what the issue is then as protecting API resources is what OAuth is all about. 
> 
> On Apr 17, 2012, at 12:19 PM, Eran Hammer wrote:
> 
>> That has nothing to do with this issue. The protected resources API format was never part of OAuth at any time.
>>  
>> EH
>>  
>> From: Dick Hardt [mailto:dick.hardt@gmail.com] 
>> Sent: Tuesday, April 17, 2012 9:50 AM
>> To: Eran Hammer
>> Cc: Stephen Farrell; Mark Nottingham; Pete Resnick; Ned Freed; draft-ietf-oauth-v2-bearer.all@tools.ietf.org; Apps Discuss
>> Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer
>>  
>>  
>> On Apr 14, 2012, at 11:31 PM, Eran Hammer wrote:
>> 
>> 
>> (Sticking with the naivety:-) So, what's different there from how the base
>> oauth draft registers client_id and shows how that can be used in a GET
>> request? [1]
>> 
>> Big difference. The base draft specifies its own endpoints as part of a complete API package for obtaining authorization. These parameters are scoped only for the endpoints defined and not for any others. There is no possibility of conflict because the specification defines the entire namespace.
>> 
>> OTOH, the bearer spec is applied to *any* web resources using OAuth authentication where some other namespace definition must exist.
>>  
>>  
>> If we had kept it all in one spec as it had originally been drafted, this would not be an issue, and it would be easier for implementers to understand. I don't know of anyone looking to implement the bearer spec independent of the base spec. (would be interested if anyone does know of an implementation)
> 
> 
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
> 
> 