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

[Eran Hammer <[e-mail]>]

A site has a bunch of APIs. They want to use OAuth with Bearer tokens. They can no longer use the access_token parameter for their own use cases because the Bearer token specification creates a conflict. This conflict does not exist with the use of the header. It does exist with the use of the body if they have an access_token parameter already in use.

The API format has nothing to do with OAuth, but the use of a query parameter leaks into that namespace.

This isn't a critical issue. It is a hack - it has always been since it was introduced in OAuth 1.0. The issue raised was about web architecture in general and setting a precedence. I don't think it will likely to create real-world problems, but the same goes for not supporting this use case anymore (or at least explicitly marking it as deprecated, maybe even demoted to an appendix documenting historical use).

While the violation of the provider namespace is a significant principal, I want to make sure my view isn't coming off as some severe warning. Either way, it is not a big deal IMO.

EH

From: Dick Hardt [mailto:[e-mail]]
Sent: Tuesday, April 17, 2012 12:32 PM
To: Eran Hammer
Cc: Dick Hardt; Stephen Farrell; Mark Nottingham; Pete Resnick; Ned Freed; [e-mail]; Apps Discuss
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:[e-mail]]<mailto:[mailto:[e-mail]]>
Sent: Tuesday, April 17, 2012 9:50 AM
To: Eran Hammer
Cc: Stephen Farrell; Mark Nottingham; Pete Resnick; Ned Freed; [e-mail]<mailto:[e-mail]>; 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)