Re: [OAUTH-WG] Issue: prefixing parameters with oauth_

[Eran Hammer-Lahav <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of John Kemp
> Sent: Tuesday, April 20, 2010 3:38 AM
> To: Peter Saint-Andre
> Cc: Marius Scurtescu; OAuth WG
> Subject: Re: [OAUTH-WG] Issue: prefixing parameters with oauth_
> 
> On Apr 20, 2010, at 12:46 AM, Peter Saint-Andre wrote:
> 
> > On 4/18/10 6:46 PM, Dick Hardt wrote:
> >
> >> Given the practice that the authorization endpoint and the
> >> redirect_uri can contain URI query parameters, then differentiating
> >> between application specific query parameters and OAuth protocol
> >> parameters by prefixing the OAuth parameters with oauth_ would seem
> a
> >> useful way to minimize conflicts.
> >
> > Can't application developers avoid conflicts by giving their
> > parameters names other than those already used in OAuth?
> 
> Is every application developer (those using an OAuth library, or product)
> familiar with the names that are used in the OAuth spec?

First, the must be or how else would they interact with it or support their developers. If they are installing a client and server products, their vendor should make sure to provide a fully working solution.

The OAuth flow endpoints (as opposed to protected resource endpoints) are an *application* endpoint. This is not some add-on protocol or an extension of existing framework, or a hack. This is a fully specified application API which requires and deserves treatment like a separate, standalone application. This is not the case when accessing a protected resource which belongs to another application.

It is odd to me that none of these arguments are made for other application APIs such as Portable Contacts [1], Open Social [2], and others, all meant to be implemented within the same platforms and servers as the OAuth flow endpoints. OpenSocial for example, is implemented by a wide range of different platforms, but yet does not have an opensocial_ prefix. Are there reports of conflicts and deployment problems because of that?

The argument made for a prefix is that is *seems* to be useful. However, experience seems to point the other way that a lack of prefix does not break the web. If "seems to be useful" is the bar this working group is setting, we are going to end up with a much bigger, more complex specification.

EHL

[1] http://portablecontacts.net/draft-spec.html
[2] http://www.opensocial.org/Technical-Resources/opensocial-spec-v081/restful-protocol.html