Subject: [OAUTH-WG] Issue: Authorization endpoint parameter extension policy

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 15 Apr 2010 11:27:10 -0700

OAuth 2.0 flows use a single authorization endpoint (with 'type' parameter).
This endpoint is OAuth-specific but must allow for extension parameters
(standard or vendor-specific).

The issue is how to best allow for extensions defining new parameters. The
danger is common parameter names ('scope', 'language', 'permission') being
used differently by different vendors, creating interop issues with
libraries.

Prefix alone (for the core or extensions) does not solve the problem since
extensions still suffer from potential namespace collision. 'oauth_' prefix
makes all the parameter names longer, but doesn't add real value - defining
new parameters, with or without the 'oauth_' prefix is still the same
problem.

The typical solution is to define an extension policy, using a registry or
domain-namespace for new names.

Proposal:

Plain parameter names (names without '.' character) require registration
(IANA registry with a published specification). This will encourage people
to share their parameters and improve interop beyond the core protocol
parameters.

Vendor specific names will require a prefix using either registered vendor
names (e.g. 'google', 'fb', 'yahoo'). Alternatively, use the same extension
policy as OpenID where extensions use any prefix and include a prefix URI
identifier (e.g. 
http://example.com?etx.language=en&ns:ext=http://example.com/spec1).

EHL

---

From: David Recordon <[email-masked]>
Date: Thu, 15 Apr 2010 11:37:01 -0700

I prefer no extension URIs since they make requests longer and really
have never taken off in OpenID.

On Thu, Apr 15, 2010 at 11:27 AM, Eran Hammer-Lahav <[email-masked]> wrote:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 15 Apr 2010 11:46:10 -0700

Me too. I think a vendor-name prefix will work just fine. By definition anything with a prefix-period will be defined as vendor-specific and not for interop. As long as we keep the registration lightweight people should register new parameters and increase interop.

EHL

On 4/15/10 11:37 AM, "[email-masked]" <[email-masked]> wrote:

---

From: David Recordon <[email-masked]>
Date: Thu, 15 Apr 2010 11:48:48 -0700

I think there will be a warming up period though as vendors prototype
with parameters before any sort of registry is setup. This should be
manageable given that we have a fairly small community right now
working on the spec.

On Thu, Apr 15, 2010 at 11:46 AM, Eran Hammer-Lahav <[email-masked]> wrote:
> Me too. I think a vendor-name prefix will work just fine. By definition
> anything with a prefix-period will be defined as vendor-specific and not for
> interop. As long as we keep the registration lightweight people should
> register new parameters and increase interop.
>
> EHL
>
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 15 Apr 2010 11:58:29 -0700

We can setup a wiki page as a starting point while people wait for the IANA registry.

EHL

On 4/15/10 11:48 AM, "[email-masked]" <[email-masked]> wrote:

---

From: John Kemp <[email-masked]>
Date: Thu, 15 Apr 2010 15:08:27 -0400

Hello,

> used differently by different vendors, creating interop issues with

If the OAuth specification defines the name for a parameter, and people claim to implement the specification, they must use those parameter names according to the specified usage. In other words, implementations of OAuth should all do the same thing, and use the same names for the OAuth-specific parameters. But, deployments of OAuth will use OAuth implementations and possibly have additional requirements (such as passing other query string parameters which may collide with the OAuth ones). And particular OAuth vendors may add other extension parameters (agreed between particular implementations but not perhaps within the entire community) to the query string. All of that might be covered by "conformance to the specification" - conformant implementations MUST not define parameters with names that clash with the agreed OAuth names.

> extensions still suffer from potential namespace collision.

Right. You cannot solve this problem. The danger is for those who don't read the spec. (because they don't have to - they are buying a product, or using a library). 

> 'oauth_' prefix

It will - how?

> names (e.g. 'google', 'fb', 'yahoo').

How will you *require* this - will there be a statement to that effect in the specification - "conformant implementations MUST NOT define query parameters that clash withe names int he OAuth registry "? What will you do about deployments which include an OAuth library and do not know anything at all about the OAuth requirements?

> Alternatively, use the same extension

What do you consider an "extension" for this purpose (some parameter agreed on by two or more conforming OAuth implementations)?

- johnk

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 15 Apr 2010 12:15:30 -0700

I really think we should keep a standard parameter prefix like
"oauth_". What are the issue with having a prefix?

Not having such a prefix will lead to collisions with query parameter
on the authz server endpoints or on the callback URL. Even if state is
not passed with additional parameters on callbacks. This also leads to
adding further limitations on these URLs, by not allowing query
parameters.

Marius

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 15 Apr 2010 12:18:25 -0700

Hey John,

On 4/15/10 12:08 PM, "John Kemp" <[email-masked]> wrote:

> If the OAuth specification defines the name for a parameter, and people claim
> to implement the specification, they must use those parameter names according
> to the specified usage. In other words, implementations of OAuth should all do
> the same thing, and use the same names for the OAuth-specific parameters. But,
> deployments of OAuth will use OAuth implementations and possibly have
> additional requirements (such as passing other query string parameters which
> may collide with the OAuth ones). And particular OAuth vendors may add other
> extension parameters (agreed between particular implementations but not
> perhaps within the entire community) to the query string. All of that might be
> covered by "conformance to the specification" - conformant implementations
> MUST not define parameters with names that clash with the agreed OAuth names.
> 
>> 
> Right. You cannot solve this problem. The danger is for those who don't read
> the spec. (because they don't have to - they are buying a product, or using a
> library).
> 
>> 'oauth_' prefix

People like short and general parameter names (see link relation types
registry discussion). If you make it easy for them to register these short
names, they usually do.

> How will you *require* this - will there be a statement to that effect in the
> specification - "conformant implementations MUST NOT define query parameters
> that clash withe names int he OAuth registry "? What will you do about
> deployments which include an OAuth library and do not know anything at all
> about the OAuth requirements?

Yes. The spec will define a set of reserved parameter names (no one is
allowed to change these), and rules for using new parameters without a
period in the name (common extension) and parameter with a period (vendor
specific extensions).

There is nothing I can do about people who do not read the spec and choose
to implement it differently.

> What do you consider an "extension" for this purpose (some parameter agreed on
> by two or more conforming OAuth implementations)?

Any parameter not defined by the core spec.

EHL

---

From: David Recordon <[email-masked]>
Date: Thu, 15 Apr 2010 12:22:24 -0700

I thought we already settled this (though am having a hard time
finding the specific thread).  Either we spec for interop or for
vendors being able to twist the spec in their own ways. I vote for
interop. :)

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 15 Apr 2010 12:27:21 -0700

> "oauth_". What are the issue with having a prefix?

I really think we shouldn't. :-)

Requests are longer for no reason. You need to show how a prefix actually
helps. Otherwise, it is the same as adding an 'protocol=oauth' to every
request just for fun.

> on the authz server endpoints

Having a prefix without an extension policy does not help at all to prevent
collisions. This is a false expectation. There is no difference between
saying 'don't add new parameters with the oauth_ prefix' or 'don't add new
parameters with names already used by this specification'.

> or on the callback URL. Even if state is

Callback parameters are a bit different. We still need to solve the issue of
how to allow client state in callbacks (state parameter or free-for-all).
But here too, a prefix does not solve collisions. You have the same
extension policy issue.

A prefix just "solves" potential collision between the core spec and other
specs using the same parameter names. It does not help how to avoid
collisions between extensions and vendors. OAuth 1.0a had a prefix and then
we spent weeks discussion who else can define oauth_ parameters. It just
moved the problem somewhere else - the extension policy.

>> to the specified usage. In other words, implementations of OAuth should all
>> do the same thing, and use the same names for the OAuth-specific parameters.
>> But, deployments of OAuth will use OAuth implementations and possibly have
>> perhaps within the entire community) to the query string. All of that might
>> be covered by "conformance to the specification" - conformant implementations
>> What do you consider an "extension" for this purpose (some parameter agreed
>> on by two or more conforming OAuth implementations)?
>> 
>> - johnk
>> 
>>> EHL
>>>

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 15 Apr 2010 12:27:43 -0700

> vendors being able to twist the spec in their own ways. I vote for

Lost you. Where do I argue for twisting anything?

If vendors want to add custom parameters and avoid collisions they can
always create their own prefix.

Why exactly is a standard prefix a problem?

Marius

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 15 Apr 2010 12:36:02 -0700

On Thu, Apr 15, 2010 at 12:27 PM, Eran Hammer-Lahav <[email-masked]> wrote:
> Requests are longer for no reason.

Not much longer, the number of parameters is small. Why is this a problem?

> You need to show how a prefix actually

I think I did.

> parameters with names already used by this specification'.

I agree this is not perfect, but that does not mean it does not help.

It is one thing to say to implementors to stay away from parameters
stating with "oauth_" and a totally different thing to say stay away
from "scope", "mode", "callback", ... and whatever we will add to
newer versions to the spec. All these are very common words and
chances for collision are high.

> But here too, a prefix does not solve collisions. You have the same

State aside, the callback may want to have query parameters, even in
the registered version. Why disallow that?

> moved the problem somewhere else - the extension policy.

Not trying to solve the extension issue at all.

Marius

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 15 Apr 2010 12:44:19 -0700

> Not much longer, the number of parameters is small. Why is this a problem?

It's longer for no reason.

>> helps. Otherwise, it is the same as adding an 'protocol=oauth' to every

Say it helps isn't proof, just an argument.

> chances for collision are high.

So what happens when someone wants to add a language parameter? Do they call
is 'language' or 'oauth_language'? The prefix just doesn't solve anything
without a policy, and once you write a policy it is no longer needed.

> the registered version. Why disallow that?

I don't think it should, but I am opposed to both random parameters and a
client state parameter. Either way, that's a different issue - let's try to
keep this focused on one issue at a time.

> Not trying to solve the extension issue at all.

This is all about extensions (common or vendor specific)!

EHL

---

From: John Kemp <[email-masked]>
Date: Thu, 15 Apr 2010 16:48:50 -0400

> "oauth_". What are the issue with having a prefix?

I think the downside is the extra bytes on the wire.

The upside is that this might prevent accidental collision with OAuth parameters by people who haven't read the spec. or looked at the registry. 

I don't think it solves all collision problems, which is probably why people don't see it as a high-value thing to do.

> adding further limitations on these URLs, by not allowing query

Having a prefix doesn't solve ALL collision possibilities. There is some limited utility in preventing accidental collision by people outside of the OAuth community. The question is whether that is worth the extra bytes. Or are there some other good arguments for or against?

I can see both points of view. Is a possible compromise to make a shorter prefix than 'oauth_' (how about 'oa_' - 3 bytes instead of 6)?

- johnk

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 15 Apr 2010 18:31:35 -0700

OK, here is a concrete example:

A Drupal (popular PHP based CMS) based web site wants to become an
OAuth 2 client. Among other things it needs to implement a callback
endpoint.

Ideally this endpoint would look something like:
http://example.com/oauth/back

Depending on what web server is used and how it is configured, the
above URL may not be possible. Drupal is dispatching all requests
through the main script and the path of the endpoint is passed as a
query parameter. Normally the above URL is seen as:
http://example.com/index.php?q=oauth/back

The cleaner http://example.com/oauth/back is achieved with Apache URl
rewriting, but if Apache is not available or configured to support
that, you are stuck with the ugly query parameters.

In the unlucky case the registered callback, and the actual callback
used in messages, is "http://example.com/index.php?q=oauth/back". This
callback has a query parameter, it is not used for state, and it is
not an extension.

It so happens that "q" will not conflict with any of the existing
OAuth 2 parameters, but you can see the potential issue.

Now, even if Apache is available and URL rewrites work, so the nice
callback is used, a collision would still happen if "q" was used by
OAuth 2. Apache rewrites "/oauth/back", but the Drupal dispatcher
always sees "/index.php?q=oauth/back", so another q parameter would
break things.

I do realize that a prefix will not solve ALL collisions and it is
also not solving the extension question, but I still think makes a big
difference.

Hope this helps,
Marius

---

From: Evan Gilbert <[email-masked]>
Date: Thu, 15 Apr 2010 18:39:41 -0700

> always sees "/index.php?q=oauth/back", so another q parameter would

We should ask Drupal to change their query parameter to drupal_q.

> also not solving the extension question, but I still think makes a big

This use case makes sense, but do we know of any existing conflicts?

Very few web servers have this restrictive a URL parameter policy - I think
I'm OK losing compatibility with future web servers that reserve the
"callback" parameter for other purposes.

> >> On Thu, Apr 15, 2010 at 12:27 PM, Eran Hammer-Lahav <
> [email-masked]>
> >> wrote:
> >>>
> >>>>> If the OAuth specification defines the name for a parameter, and
> people
> >>>>> claim
> >>>>> additional requirements (such as passing other query string
> parameters
> >>>>> which
> >>>>> may collide with the OAuth ones). And particular OAuth vendors may
> add
> >>>>> other
> >>>>> MUST not define parameters with names that clash with the agreed
> OAuth
> >>>>> names.
> >>>>>
> >>>>>>
> >>>>> Right. You cannot solve this problem. The danger is for those who
> don't
> >>>>> read
> >>>>> the spec. (because they don't have to - they are buying a product, or
> using
> >>>>> a
> >>>>> library).
> >>>>>
> >>>>>> 'oauth_' prefix
> >>>>> How will you *require* this - will there be a statement to that
> effect in
> >>>>> the

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 15 Apr 2010 21:10:56 -0700

> We should ask Drupal to change their query parameter to drupal_q.

And every single framework that does dispatching based on query parameters :-)

> "callback" parameter for other purposes.

My guess is that most PHP frameworks will have a similar problem, they
will require query parameters.  This is not a web server issue, but a
framework issue.

Not only "callback" can cause a collision, but every single OAuth 2 parameter.

Marius

---

From: "Manger, James H" <[email-masked]>
Date: Sat, 17 Apr 2010 00:33:30 +1000

A partial solution to colliding parameter names and long URIS would be to use URI templates.

For instance, in a 401 response when a client app tries to access a protected resource, instead of an authz URI, return a template for an authz URI. The template would include OAuth field names in squiggly brackets, to be replaced by the field’s value when building an actual authz URI. The template could also be provided in documentation.

Example:

C<-S 401

        WWW-Authenticate: OAuth u=”http://as.com/{type}/{client_id}?cb={callback}&no_ui={immediate}&oe=utf-8”

There are a couple of benefits:

1. The parts of the template outside the {…} placeholders can be chosen however the service wants. There is no worry about clashes between proprietary query params (like “oe=utf=8” above) and OAuth fields. There is no need for the restrictions on URI that are in the current draft.

2. The constructed URI will be shorter as it doesn’t have to include the OAuth field names, just their values. The field names could include an oauth_ prefix without affecting URI sizes. The template itself will be longer than a base authz URI to which query params are added, but that is a less important issue.

3. It provides a little bit of discovery automatically. The field names that appear in placeholders (or their absence) tell the client app which features are (or are not) supported. For instance, the example above shows that the service supports the “immediate” mode, otherwise it wouldn’t include the {immediate} placeholder. This may be enough for most feature negotiation needs.

There are disadvantages:

-1. Templates are a more complicated than always using query parameters. Just {name} adds a little complexity. A more flexible placeholder syntax being very slowly speced by the W3C (eg with defaults) adds more complexity -- but doesn’t have to be adopted here.

With this proposal the {callback} placeholder in the authz template would be filled by a client with its own template, with a placeholder for the auth code.

A service could still introduce its own placeholder field that clashed with a subsequent OAuth definition. I think that is less of a concern.

--

James Manger

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 16 Apr 2010 07:34:43 -0700

First, this argument only holds for callbacks, not for the authorization endpoint. Since this problem is easily solved with a simple web server configuration, I don't think it is as bad as you make it sound. I'm sure that the Drupal community will find a solution if there are valuable OAuth 2.0 resources they want to access.

However, I don't have an objection to a prefix for callback parameters since those are not purely protocol endpoints but client endpoints with potential existing semantics. We already have oauth_token for accessing a protected resource using query parameters (for the same reason).

But this argument does not extent to the authorization endpoint.

EHL

On 4/15/10 9:10 PM, "Marius Scurtescu" <[email-masked]> wrote:

Marius

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 16 Apr 2010 07:42:07 -0700

I really like it, but it is too complicated and requires a standard template format (which will need to be profiled to be practical). This is going in the wrong direction...

EHL

On 4/16/10 7:33 AM, "James Manger" <[email-masked]> wrote:

For instance, in a 401 response when a client app tries to access a protected resource, instead of an authz URI, return a template for an authz URI. The template would include OAuth field names in squiggly brackets, to be replaced by the field's value when building an actual authz URI. The template could also be provided in documentation.

Example:
C<-S 401
        WWW-Authenticate: OAuth u="http://as.com/{type}/{client_id}?cb={callback}&no_ui={immediate}&oe=utf-8"

1. The parts of the template outside the {...} placeholders can be chosen however the service wants. There is no worry about clashes between proprietary query params (like "oe=utf=8" above) and OAuth fields. There is no need for the restrictions on URI that are in the current draft.

2. The constructed URI will be shorter as it doesn't have to include the OAuth field names, just their values. The field names could include an oauth_ prefix without affecting URI sizes. The template itself will be longer than a base authz URI to which query params are added, but that is a less important issue.

3. It provides a little bit of discovery automatically. The field names that appear in placeholders (or their absence) tell the client app which features are (or are not) supported. For instance, the example above shows that the service supports the "immediate" mode, otherwise it wouldn't include the {immediate} placeholder. This may be enough for most feature negotiation needs.

There are disadvantages:

-1. Templates are a more complicated than always using query parameters. Just {name} adds a little complexity. A more flexible placeholder syntax being very slowly speced by the W3C (eg with defaults) adds more complexity -- but doesn't have to be adopted here.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 16 Apr 2010 07:44:36 -0700

BTW, making this change includes dropping the client state parameter and allowing clients to add their own state parameter to the callback.

EHL

On 4/16/10 7:34 AM, "Eran Hammer-Lahav" <[email-masked]> wrote:

EHL

Marius

---

From: Marius Scurtescu <[email-masked]>
Date: Fri, 16 Apr 2010 11:33:09 -0700

When replacing the placeholders with actual values, how do you know
what encoding should be used? Does URL encoding work in all cases?

Marius

On Fri, Apr 16, 2010 at 7:33 AM, Manger, James H
<[email-masked]> wrote:
> For instance, in a 401 response when a client app tries to access a
> protected resource, instead of an authz URI, return a template for an authz
> URI. The template would include OAuth field names in squiggly brackets, to
> be replaced by the field’s value when building an actual authz URI. The
> template could also be provided in documentation.
>
>
>
> Example:
>
> C<-S 401
>
>         WWW-Authenticate: OAuth
> u=”http://as.com/{type}/{client_id}?cb={callback}&no_ui={immediate}&oe=utf-8”
>
>
>
> 1. The parts of the template outside the {…} placeholders can be chosen
> however the service wants. There is no worry about clashes between
> proprietary query params (like “oe=utf=8” above) and OAuth fields. There is
> no need for the restrictions on URI that are in the current draft.
>
>
>
> 2. The constructed URI will be shorter as it doesn’t have to include the
> OAuth field names, just their values. The field names could include an
> oauth_ prefix without affecting URI sizes. The template itself will be
> longer than a base authz URI to which query params are added, but that is a
> less important issue.
>
>
>
> 3. It provides a little bit of discovery automatically. The field names that
> appear in placeholders (or their absence) tell the client app which features
> are (or are not) supported. For instance, the example above shows that the
> service supports the “immediate” mode, otherwise it wouldn’t include the
> {immediate} placeholder. This may be enough for most feature negotiation
> needs.
>
>
>
> There are disadvantages:
>
>
>
> -1. Templates are a more complicated than always using query parameters.
> Just {name} adds a little complexity. A more flexible placeholder syntax
> being very slowly speced by the W3C (eg with defaults) adds more complexity
> -- but doesn’t have to be adopted here.
>
>
>
> With this proposal the {callback} placeholder in the authz template would be
> filled by a client with its own template, with a placeholder for the auth
> code.
>
>
>
> A service could still introduce its own placeholder field that clashed with
> a subsequent OAuth definition. I think that is less of a concern.
>
>
>
> --
>
> James Manger
>
>
>

---

From: Marius Scurtescu <[email-masked]>
Date: Fri, 16 Apr 2010 17:58:39 -0700

On Fri, Apr 16, 2010 at 7:34 AM, Eran Hammer-Lahav <[email-masked]> wrote:
> First, this argument only holds for callbacks, not for the authorization
> endpoint.

And why is that? This argument applies exactly the same way to the
authorization endpoint. The same Drupal site can also be an OAuth 2.0
Authorization Server.

Basically any framework which does dispatching of requests based on
query parameters will require that endpoints (or callbacks) have query
parameters.

> Since this problem is easily solved with a simple web server
> configuration, I don’t think it is as bad as you make it sound.

Please read my example again. This *cannot* be solved with any kind of
web server configuration. Ideal server configuration will make it
appear that no query parameters are used, but behind the scene they
are. Query parameters are needed on all endpoints, visible or not.

> I’m sure
> that the Drupal community will find a solution if there are valuable OAuth
> 2.0 resources they want to access.

That's close to impossible. Do you really expect them to change the
fundamental architecture of Drupal just to support OAuth? And the main
reason for that architecture is how PHP works and what is available
with shared hosting, so I guess many other similar frameworks will
work like this.

> However, I don’t have an objection to a prefix for callback parameters since
> those are not purely protocol endpoints but client endpoints with potential
> existing semantics. We already have oauth_token for accessing a protected
> resource using query parameters (for the same reason).
>

Please read above, it does.

Marius

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 16 Apr 2010 18:08:05 -0700

We are going in circles. We are just not going to agree on this.

I don't think we should have a parameter prefix for OAuth-specific calls, you think we should. Time to let other people express their view on this. I'm sure both of us can live with both options.

EHL

On 4/16/10 5:58 PM, "Marius Scurtescu" <[email-masked]> wrote:

> configuration, I don't think it is as bad as you make it sound.

> I'm sure

> However, I don't have an objection to a prefix for callback parameters since

Marius

---

From: Luke Shepard <[email-masked]>
Date: Fri, 16 Apr 2010 18:23:24 -0700

So, I originally favored the prefix, as I couldn't see how you would not do it.

But I've recently implemented OAuth prototype and written some apps against it, and I have to say, I like not having the prefix. Most developers don't care that they are using OAuth - they just want to talk to a service. The prefix sort of beats them over the head with it, without much benefit. It's one less thing to scare new developers.

So, I'm in favor of no prefix.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Eran Hammer-Lahav
Sent: Friday, April 16, 2010 6:08 PM
To: Marius Scurtescu
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Issue: Authorization endpoint parameter extension policy

EHL

Marius

---

From: Luke Shepard <[email-masked]>
Date: Fri, 16 Apr 2010 18:24:19 -0700

Oh, and fwiw, we dropped the prefix EVERYWHERE. So even the protected resource just takes "access_token", not "oauth_access_token", for consistency.

From: Luke Shepard
Sent: Friday, April 16, 2010 6:23 PM
To: 'Eran Hammer-Lahav'; Marius Scurtescu
Cc: OAuth WG
Subject: RE: [OAUTH-WG] Issue: Authorization endpoint parameter extension policy

EHL

Marius

---

From: "Manger, James H" <[email-masked]>
Date: Sat, 17 Apr 2010 12:09:44 +1000

Marius

> what encoding should be used? Does URL encoding work in all cases?

%-escaping any chars outside the 66 <unreserved> chars works in (almost) all cases.

The only exception is if you want a non-ASCII value substituted into a domain name. That needs to use punycode. OAuth could ignore this case. Or say it is a IRI template, then use standard IRI-to-URI translation.

--
James Manger

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 16 Apr 2010 19:55:22 -0700

You should also accept 'oauth_token'. That's one place a prefix makes sense because there is no telling what a protected resource URI might look like.

EHL

On 4/16/10 6:24 PM, "Luke Shepard" <[email-masked]> wrote:

From: Luke Shepard

EHL

Marius

---

From: Marius Scurtescu <[email-masked]>
Date: Sun, 18 Apr 2010 13:30:27 -0700

On Fri, Apr 16, 2010 at 6:08 PM, Eran Hammer-Lahav <[email-masked]> wrote:
> I don’t think we should have a parameter prefix for OAuth-specific calls,
> you think we should. Time to let other people express their view on this.
> I’m sure both of us can live with both options.

Sure, but I think we are dealing with two different issues here. One
is allowing query parameters on callbacks and authz server endpoints,
and the other is parameter prefixes.

Do we agree on query parameters being allowed on all URLs?

Marius

---

From: Marius Scurtescu <[email-masked]>
Date: Sun, 18 Apr 2010 13:38:02 -0700

On Fri, Apr 16, 2010 at 6:23 PM, Luke Shepard <[email-masked]> wrote:
> So, I originally favored the prefix, as I couldn’t see how you would not do
> it.
>
>
>
> But I’ve recently implemented OAuth prototype and written some apps against
> it, and I have to say, I like not having the prefix. Most developers don’t
> care that they are using OAuth – they just want to talk to a service. The
> prefix sort of beats them over the head with it, without much benefit. It’s
> one less thing to scare new developers.

I am not saying that I like prefixes, I am just worried that by not
having them some deployments will have conflicts.

I am sure that most implementations will work perfectly fine with out
the prefix, but that does not mean it will work in all cases.

Also, when implementing OAuth 2.0 people will take into account
existing parameters and will avoid them, they will chose other
parameter names (if possible). If the next version of OAuth, let's
call it 2.1, adds a few new parameters, how can we chose them so they
don't collide with extra parameters used by 2.0 implementations?

A prefix avoids all this.

But then again, I seem to be the only one worrying about this. I'll
let it be for now.

Marius

>
>
>
> So, I’m in favor of no prefix.
>
>
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 18 Apr 2010 23:07:12 -0700

> -----Original Message-----
> From: Marius Scurtescu [mailto:[email-masked]]
> Sent: Sunday, April 18, 2010 1:38 PM

> Also, when implementing OAuth 2.0 people will take into account existing
> parameters and will avoid them, they will chose other parameter names (if
> possible). If the next version of OAuth, let's call it 2.1, adds a few new
> parameters, how can we chose them so they don't collide with extra
> parameters used by 2.0 implementations?

By defining an extension policy. Anything that is not in the core spec is an extension.

How about we first figure this out? If we can agree on an extension policy, we can see if it mitigates your concerns.

EHL

---

From: Justin Richer <[email-masked]>
Date: Mon, 19 Apr 2010 11:14:46 -0400

> By defining an extension policy. Anything that is not in the core spec is an extension.

OAuth extensions are well and good, but there are cases (that Marius has
outlined, and I agree with) where the underlying system will simply add
more stuff to the pack of URL parameters. For two concrete examples,
let's talk MediaWiki and Elgg. To get a plugin to define an endpoint in
MediaWiki, you can define a Special page. This gets handled by the
redirect engine, and you end up with title=Special:OAuthEndpoint or
something as a parameter. This setup allows the extension of the URL
space by a plugin alone without mucking with the HTTP server
configuration. Elgg's system is similar, with a pageview handler turning
pg/oauth/requesttoken into something else on the inside. 

I don't think we can make the assumption that OAuth endpoints will be
single-purpose and pristine in the wild. There are too many frameworks
that behave similarly, especially in Apache/PHP land. I think we need to
assume that OAuth endpoints *will* have extra parameters, that these
parameters are out of our control, and that we should take reasonable
steps to namespace the OAuth parameters out of other peoples' way. Query
parameter URLs don't have their own namespacing schemes that we can use
to get stuff out of the way, so we need to use our own, like OpenID's
"openid." prefixing. It's pretentious to think that a framework will
change their API just to support OAuth. It's much more likely that a
framework will say that OAuth isn't compatible with them, and therefore
just not ever support it. If we want to facilitate adoption, we need to
keep in mind that OAuth is the outsider to most systems. 

I'm still not seeing the reasons for dropping the prefix in the first
place. I don't buy the argument that it's really a space saving device
by not defining the prefix. Were we hitting against size limits so
tightly that dropping a few characters per request is a big deal? I
agree that it's convenient to not have all of those extra characters,
but at the same time it immediately tells you which parts of the
protocol stack belong to core OAuth and which don't. 

Along those lines, I do think that an extension policy is needed as
well, since we'll end up with people adding their own oauth_ stuff and
pushing that part of the conflict problem there, as Eran said. I still
contend, though, that since OAuth is designed to work with other APIs
and within other frameworks, this is not the only collision space we
need to worry about.

 -- Justin

---

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

> How about we first figure this out? If we can agree on an extension policy, we can see if it mitigates your concerns.

As Justin mentioned in his reply, this has nothing to do with
extensions. Other parameters will be used just to deal with the
callback implementation, to specify controllers and such.

Maybe we should consider passing parameters some other way, and not
part of query strings. JSON?

Marius

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 19 Apr 2010 11:50:34 -0700

> Sent: Monday, April 19, 2010 10:25 AM

> Maybe we should consider passing parameters some other way, and not part
> of query strings. JSON?

Please propose text.

EHL