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

From: Dick Hardt <[email-masked]>
Date: Sun, 18 Apr 2010 17:46:27 -0700

(restarting discussion from
	http://groups.google.com/group/oauth-ietf-wg/browse_thread/thread/8aeb31817ead4c2a/f19773643e0a8ba3?pli=1
 with matching subject)

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.

Since calls to the token endpoint use POST, there can not be any confusion between the parameters in the body of the message and URI query parameters

Note this has nothing to do with differentiating between protocol extension parameters and core OAuth parameters.

-- Dick

---

From: David Recordon <[email-masked]>
Date: Sun, 18 Apr 2010 18:42:01 -0700

While Facebook platform engineers were quite dubios of no oauth_
prefix after hacking on a draft implementation their opinion has
changed. They're now really enjoying shorter and cleaner paramater
names and found them to be easier to document and no more difficult to
implement.

On Sun, Apr 18, 2010 at 5:46 PM, Dick Hardt <[email-masked]> 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.
> Since calls to the token endpoint use POST, there can not be any confusion
> between the parameters in the body of the message and URI query parameters
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: Dick Hardt <[email-masked]>
Date: Sun, 18 Apr 2010 18:49:42 -0700

I'm happy to hear that Facebook engineers are enjoying their job.

In choosing between long and ambiguous, I think we need to choose long. We could shorten the prefix to oa_. Would that help? :)

---

From: Marius Scurtescu <[email-masked]>
Date: Sun, 18 Apr 2010 21:04:54 -0700

> between the parameters in the body of the message and URI query parameters

Unfortunately in the Java world there is confusion between POST and
GET parameters. The servlet specification mixes parameters from both
sources and makes them available as one map.

Marius

---

From: Dick Hardt <[email-masked]>
Date: Sun, 18 Apr 2010 21:10:31 -0700

> sources and makes them available as one map.

Perhaps you should use a real web language like Perl? :)

Since the user user is not present in calls to the token endpoint, I don't see the same requirements for adding URI query parameters, but point taken.

-- Dick

---

From: Evan Gilbert <[email-masked]>
Date: Mon, 19 Apr 2010 07:28:58 -0700

I have a preference to *not* have the "oauth_" prefix on parameters when
redirecting back, but could be convinced.

The argument about collisions makes sense, but I think there are no known
conflicts and you can always add a redirection layer if a conflict arises in
the future and a web serving framework is unwilling to change.

(I've become less of a fan of namespacing over the years - my default has
switched to waiting until there is a known conflict to solve)

Evan

On Sun, Apr 18, 2010 at 9:10 PM, Dick Hardt <[email-masked]> wrote:

> Since the user user is not present in calls to the token endpoint, I don't
> see the same requirements for adding URI query parameters, but point taken.
>
> -- Dick
>

---

From: Marius Scurtescu <[email-masked]>
Date: Mon, 19 Apr 2010 10:19:43 -0700

> switched to waiting until there is a known conflict to solve)

If the conflict is found after the spec is defined then it is too late.

In many cases namespaces are needed, regardless if we like them or
not. A prefix is a very weak namespace, but in this case extremely
useful IMO.

Marius

---

From: Evan Gilbert <[email-masked]>
Date: Mon, 19 Apr 2010 10:24:12 -0700

> If the conflict is found after the spec is defined then it is too late.

As I mentioned, the client can just set up a redirect.

> not. A prefix is a very weak namespace, but in this case extremely

The question is whether this is a case in which namespaces are needed.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 19 Apr 2010 22:46:55 -0600

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?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Dick Hardt <[email-masked]>
Date: Mon, 19 Apr 2010 21:50:42 -0700

> names other than those already used in OAuth?

If changing the parameters is available to them. They may be trying to shimmy OAuth into an existing system. 

I don't know how common the issue is, just pointing out why the prefix was there in the past.

-- Dick

---

From: Marius Scurtescu <[email-masked]>
Date: Mon, 19 Apr 2010 22:01:15 -0700

> If changing the parameters is available to them. They may be trying to shimmy OAuth into an existing system.

Even if the developer can chose a parameter that is not used  by OAuth
right now, he/she has no guarantee that this parameter name will not
be introduced by a future version of the spec.

> I don't know how common the issue is, just pointing out why the prefix was there in the past.

Yes, chances for a collision are very small, but still, well worth
using the prefix IMO.

Marius

---

From: John Kemp <[email-masked]>
Date: Tue, 20 Apr 2010 06:37:59 -0400

> 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?

- johnk

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 20 Apr 2010 05:58:18 -0600

> be introduced by a future version of the spec.

True.

> Yes, chances for a collision are very small, but still, well worth

Sure, I see your point.

I have no deep objections to prefixing, and it does seem as if it would
make collisions less likely (although not impossible).

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 20 Apr 2010 07:55:10 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 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_
> 
> >> 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

---

From: Joseph Smarr <[email-masked]>
Date: Tue, 20 Apr 2010 09:08:25 -0700

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 <[email-masked]>wrote:

> 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
>
> [2]
> http://www.opensocial.org/Technical-Resources/opensocial-spec-v081/restful-protocol.html

---

From: Luke Shepard <[email-masked]>
Date: Tue, 20 Apr 2010 10:04:06 -0700

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: [email-masked] [mailto:[email-masked]] 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 <[email-masked]<mailto:[email-masked]>> wrote:

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf
> Of John Kemp

EHL

[email-masked]<mailto:[email-masked]>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 20 Apr 2010 10:11:03 -0700

In an effort to move one:

Does anyone have a *blocking* objection to not adding a parameter name prefix to the authorization and token endpoints? In other words, are you going to block the specification (ask the chairs not to issue a consensus call) if it doesn't have a prefix?

EHL

From: Luke Shepard [mailto:[email-masked]]
Sent: Tuesday, April 20, 2010 10:04 AM
To: [email-masked]; Eran Hammer-Lahav
Cc: Marius Scurtescu; OAuth WG
Subject: RE: [OAUTH-WG] Issue: prefixing parameters with oauth_

Thanks, js

EHL