> -----Original Message-----
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] 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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to