I know we are all identity geeks and love to know the protocol we're using, but most developers will just want to get the auth token and be done with it. They don't care that they are using OAuth. There's no reason to beat them over the head with it all over the place.
Having just implemented this, and now writing docs for it, I can say that I have a pretty strong preference for no prefix. It makes things so much easier to read. From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Joseph Smarr Sent: Tuesday, April 20, 2010 9:08 AM To: Eran Hammer-Lahav Cc: Marius Scurtescu; OAuth WG Subject: Re: [OAUTH-WG] Issue: prefixing parameters with oauth_ I'm normally no fan of namespaces or other forms of needless complexity, and it's true that PoCo dropped the pdata_ prefixes to all its query parameters that we'd originally proposed, but I do think there's something helpful and and clear about oauth_ because it makes it so clear which parameters are part of OAuth--it's visually concise and readable, without the mechanical headaches of say XML namespaces. I'll agree that we can probably all learn to live without it (assuming collisions are empirically rare and there isn't code that needs to easily glob "all oauth parameters, including any future ones", e.g. the way OpenID does for signing), but I still feel a bit queasy doing so, and it's not obvious to me how much simplicity/performance/etc we buy for dropping them, so my (weak) preference would be to keep them, but I won't fight too hard if there are lots of people passionate about dropping them. :) Thanks, js On Tue, Apr 20, 2010 at 7:55 AM, Eran Hammer-Lahav <e...@hueniverse.com<mailto:e...@hueniverse.com>> wrote: > -----Original Message----- > From: oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org> > [mailto: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<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
