Subject: [OAUTH-WG] register prefixes as opposed to full parameter names

From: Marius Scurtescu <[email-masked]>
Date: Thu, 1 Jul 2010 12:51:43 -0700

For section 6.2, and possibly 6.3, I would suggest to register a
prefix for all the parameters defined by an extension.

Pros:

1. Simpler registration, only one element needs to be registered, the
prefix, and not every single parameter name. Once an extension has a
prefix registered it can evolve and change the parameters it is using
much easier.

2. Greatly reduce the chances of a conflict with a query parameter
used by an authz server endpoint or client redirect_uri.

3. Consistent with the generic vendor specific extension space ("x_").

4. Allows strict validation of OAuth parameters. Unknown extensions
will be ignored, but the known ones can be strictly validated.

5. Easy to determine what parameter is core and what is part of an extension.

Cons:

1. Slightly longer parameter names.

Underscore or dot could be used to separate the prefix from the name.

Marius

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 1 Jul 2010 13:35:56 -0700

I don't think this is necessary.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Marius Scurtescu
> Sent: Thursday, July 01, 2010 12:52 PM
> To: OAuth WG
> Subject: [OAUTH-WG] register prefixes as opposed to full parameter names
> 
> For section 6.2, and possibly 6.3, I would suggest to register a prefix for all the
> parameters defined by an extension.
> 
> Pros:
> 
> 1. Simpler registration, only one element needs to be registered, the prefix,
> and not every single parameter name. Once an extension has a prefix
> registered it can evolve and change the parameters it is using much easier.

The registration is pretty simple and only requires reserving the name. All other information is defined in a specification. There is no limit on the number of records the registry can have, and mandating review for all registered parameters is a good thing. Note that review is mostly used to make sure people are not doing something really really stupid. It is not a process for obtaining rough consensus over any extension. This is why it uses Specification required and not RFC required.
 
> 2. Greatly reduce the chances of a conflict with a query parameter used by an
> authz server endpoint or client redirect_uri.

There should not be any conflict. Either it has been registered or uses x_.

> 4. Allows strict validation of OAuth parameters. Unknown extensions will be
> ignored, but the known ones can be strictly validated.

I don't see how this is any different. If you know an extension "set" you still need to hardcode all the possible parameter part of that set.
 
> 5. Easy to determine what parameter is core and what is part of an

How is that important? The point of extensibility is to extend the protocol without looking like patches or hacks. I think allowing new parameters to live as equal to core parameters is a good thing and is how protocols such as HTTP work.

> 1. Slightly longer parameter names.

Also, messy, ugly, opens the door to extensions without review.

EHL

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 1 Jul 2010 14:21:08 -0700

> There should not be any conflict. Either it has been registered or uses x_.

There can be. Here is the example I gave earlier in another thread.
MediaWiki uses the 'title' parameter. Some OAuth extension may
register and use this same name and this will prevent MediWiki from
being able to support that extension.

> I don't see how this is any different. If you know an extension "set" you still need to hardcode all the possible parameter part of that set.

I guess you are right. This will work only if some special char is
used to delimit the prefix.

> Also, messy, ugly, opens the door to extensions without review.

I don't get the last part, skipping reviews. As for beauty, that's relative ;-)

Marius

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 1 Jul 2010 14:52:40 -0700

> From: Marius Scurtescu [mailto:[email-masked]]
> Sent: Thursday, July 01, 2010 2:21 PM

> MediaWiki uses the 'title' parameter. Some OAuth extension may register
> and use this same name and this will prevent MediWiki from being able to
> support that extension.

I think this discussion (which we spent many days on already) boils down to a philosophical approach to the level a new protocol should accommodate the broken environment in which it is expected to be deployed.
 
I think MediaWiki should change the way it treats the OAuth endpoints to isolate them from the rest of the platform. When receiving an OAuth request (with such an OAuth 'title' parameter), the platform can rename all the OAuth parameters to oauth_ internally and proceed to add its own parameters without conflicts.

While this approach might not be trivial, it is clearly possible. I think there is a larger question of how OAuth is used in a MediaWiki installation, and how it can accommodate some of the other requirements such as SSL.

I do not consider making MediaWiki's deployment of 2.0 easier an important consideration.

> I don't get the last part, skipping reviews. As for beauty, that's relative ;-)

If we approve a blanket "prefix_" extension, we lose the ability to review individual parameters within that prefix.

EHL

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 1 Jul 2010 14:58:59 -0700

> I think MediaWiki should change the way it treats the OAuth endpoints to isolate them from the rest of the platform. When receiving an OAuth request (with such an OAuth 'title' parameter), the plat…

When receiving an OAuth request MediaWiki will have two title
parameters, the damage is already done.

> I do not consider making MediaWiki's deployment of 2.0 easier an important consideration.

MediaWiki is just an example. Drupal is another. My guess is that most
PHP frameworks have this issue.

> If we approve a blanket "prefix_" extension, we lose the ability to review individual parameters within that prefix.

I think you mentioned that the review is meant to prevent name
conflicts, nothing else.

Marius

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 1 Jul 2010 16:21:43 -0700

> Sent: Thursday, July 01, 2010 2:59 PM
> To: Eran Hammer-Lahav
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] register prefixes as opposed to full parameter
> names
> 
> > I think this discussion (which we spent many days on already) boils down to
> a philosophical approach to the level a new protocol should accommodate
> the broken environment in which it is expected to be deployed.
> >
> > I think MediaWiki should change the way it treats the OAuth endpoints to
> isolate them from the rest of the platform. When receiving an OAuth request
> (with such an OAuth 'title' parameter), the platform can rename all the
> OAuth parameters to oauth_ internally and proceed to add its own
> parameters without conflicts.
> 
> When receiving an OAuth request MediaWiki will have two title parameters,
> the damage is already done.

Yes, they might need to change their platform to support it. I'm ok with that.

> 
> > While this approach might not be trivial, it is clearly possible. I think there is
> a larger question of how OAuth is used in a MediaWiki installation, and how it
> can accommodate some of the other requirements such as SSL.
> >
> MediaWiki is just an example. Drupal is another. My guess is that most PHP
> frameworks have this issue.

And they will need to find ways to accommodate OAuth 2.0 endpoints. Every web server provides sufficient tools to rewrite requests. I don't have much sympathy for the $5 hosting user.

> > If we approve a blanket "prefix_" extension, we lose the ability to review
> individual parameters within that prefix.
> 
> I think you mentioned that the review is meant to prevent name conflicts,
> nothing else.

The review is meant to prevent name collision and people doing really stupid things. Part of name collision is also to make sure that people use proper names...

EHL

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 1 Jul 2010 16:31:54 -0700

> Yes, they might need to change their platform to support it. I'm ok with that.

That is not realistic.

> And they will need to find ways to accommodate OAuth 2.0 endpoints. Every web server provides sufficient tools to rewrite requests. I don't have much sympathy for the $5 hosting user.

This has nothing to do with the price of hosting. On dedicated servers
PHP frameworks have the same issue.

Chances for a collision are still small, so I am not saying that no
prefixes will break all PHP frameworks, just that the chances that
some of them will have collisions is getting higher.

Also, not only existing frameworks can potentially have problems. A
brand new OAuth 2 server implementation may decide to use query
parameters on the published endpoints, for whatever reason. They can
chose names so there are no collisions with core and existing
extensions but there is no guarantee that newer extension will no
introduce one.

We are going in circles. The only reason I brought this up again is
because of the extensions, feel free to ignore this thread.

Marius

---

From: Justin Richer <[email-masked]>
Date: Tue, 6 Jul 2010 14:10:15 -0400

> Yes, they might need to change their platform to support it. I'm ok with that.

I think this is an unfortunate hubris of the spec-defining community
here. For most people, if it comes down to "change my platform or don't
support oauth", the answer is going to be "don't support oauth". 

 -- Justin

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 6 Jul 2010 11:23:29 -0700

Platforms change over time. These platforms are not designed with providing APIs and web services in mind. They are also typically not capable of running over SSL (due to the self-hosted nature of most deployments). Using an apache rewrite rules might be hard for some developers, but it is a good solution when there are issues with platform limitations.

If there are actual requirements for using OAuth 2.0 with such systems, we should discuss these, but it would be silly for us to architect our work based on the limitations of random platforms.

EHL

 -- Justin

---

From: "William Mills" <[email-masked]>
Date: Tue, 6 Jul 2010 12:59:30 -0700

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Justin Richer
> Sent: Tuesday, July 06, 2010 11:10 AM
> To: Eran Hammer-Lahav
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] register prefixes as opposed to full 
> parameter names
> 
> I think this is an unfortunate hubris of the spec-defining 
> community here. For most people, if it comes down to "change 

+1

> my platform or don't support oauth", the answer is going to 
> be "don't support oauth". 
> 
>  -- Justin
>

---

From: Marius Scurtescu <[email-masked]>
Date: Tue, 6 Jul 2010 22:03:55 -0700

On Tue, Jul 6, 2010 at 11:23 AM, Eran Hammer-Lahav <[email-masked]> wrote:
> Platforms change over time. These platforms are not designed with providing
> APIs and web services in mind. They are also typically not capable of
> running over SSL (due to the self-hosted nature of most deployments). Using
> an apache rewrite rules might be hard for some developers, but it is a good
> solution when there are issues with platform limitations.

Apache rewrite will not make a difference. Apache acts as a reverse
proxy, the user agent requests a URL without query parameters and
Apache is rewriting it by adding the query parameters. For the
endpoint running behind Apache there is no change, in all cases it
sees the query parameters.

Many of these platforms can and do provide APIs. Even if in most cases
these platforms act as clients only, the problem is still there
because of redirect_uri.

> If there are actual requirements for using OAuth 2.0 with such systems, we
> should discuss these, but it would be silly for us to architect our work
> based on the limitations of random platforms.

I don't think these are random at all. MediaWiki, Drupal, WordPress,
to name a few, are major platforms.

Marius

---

From: Michael D Adams <[email-masked]>
Date: Tue, 6 Jul 2010 22:18:39 -0700

> to name a few, are major platforms.

For section 6.2 (query parameters on the end-user authorization and
token endpoints), this should not be an issue for WordPress.

For section 6.3 (header parameters), this should not be an issue for WordPress.

The only place this could be problematic is adding query parameters on
the protected resources themselves.

Mike
--mdawaffe

---

From: Marius Scurtescu <[email-masked]>
Date: Tue, 6 Jul 2010 22:24:49 -0700

> For section 6.3 (header parameters), this should not be an issue for WordPress.

This is not an issue because whatever query parameter WordPress is
using does not collide with the core OAuth 2 parameters? Or because
WordPress is not using query parameters?

Marius

---

From: Michael D Adams <[email-masked]>
Date: Wed, 7 Jul 2010 00:57:04 -0700

> WordPress is not using query parameters?

Neither: because WordPress is extensible enough to allow for this kind
of functionality.

WordPress uses query parameters.  A WordPress plugin that enables
OAuth, though, would have to register new URL handlers with WordPress
to act as the token and end-user authorization endpoints.  Having done
so, the plugin would then have complete control over how to behave
under any query parameters, entity-body contents, or headers: core,
extension, site specific or otherwise.

As evidence, I have written such plugins for OAuth 1.0a, OAuth WRAP,
and OAuth 2.0-draft-05.

I would be surprised if the story were different for MediaWiki and
Drupal; I naively believe a similar plugin could be developed for each
of those platforms that would avoid query parameter collision.
"Naively" because I am unfamiliar with both of those platforms.

Mike
--mdawaffe

---

From: Michael D Adams <[email-masked]>
Date: Wed, 7 Jul 2010 01:10:10 -0700

> extension, site specific or otherwise.

Actually, for a small minority of WordPress sites wanting to enable
OAuth (those not supporting so called "pretty permalinks"), the
WordPress plugin would need to internally reserve one query parameter
to get the ball rolling.  Theoretically, that need leads to the
possibility of conflict, but I'm not worried about it.

Mike
--mdawaffe

---

From: Marius Scurtescu <[email-masked]>
Date: Wed, 7 Jul 2010 10:31:11 -0700

> possibility of conflict, but I'm not worried about it.

As far as I can tell pretty permalinks also use mod_rewrite so the PHP
code still sees the query parameter.

Yes, chances for conflict are very small, I agree.

Marius

---

From: Michael D Adams <[email-masked]>
Date: Wed, 7 Jul 2010 12:15:38 -0700

> code still sees the query parameter.

Yes.  The point is that the plugin can intercept the request early
enough that it doesn't matter.

There is a small chance for conflict, but the conflict is not inherent
to the core spec or to the spec of an extension, only to the
particular implementation of the plugin.  In the pretty permalink
case, the conflict can easily be addressed with a new release of the
plugin (developed, out the door, and pulled to all sites in a day)
without changing endpoints or otherwise breaking clients.  In the ugly
link case, you might need to change the endpoints' URLs.

Any "serious" site will be using pretty permalinks.

This situation seems acceptable to me.  With a new extension, you need
a new release of the plugin anyway (or the release of a plugin for the
plugin).  You're blocking deployment on development, which is always
true.

All of this to say: WordPress is flexible enough to implement the
current spec, and I predict that WordPress is flexible enough to
implement the final spec.  I believe no special consideration need be
given WordPress in the spec writing process.  If I see anything, I'll
raise the issue.

Mike
--mdawaffe