OAuth Extensions

The OAuth Protocol can be extended to provide additional functionality. Examples include:

• FlexibleDecoding
• ProblemReporting

This work is currently being discussed on the OAuth Extensions mailing list. Subscribe here.

Parameter Prefixes

OAuth extensions fall into two groups, those that require additional OAuth Protocol Parameters, and those that don't. The "don't"s are easy. It is the added parameters that needs to be discussed. There are 3 options (I can see):

1. Use the oauth_ prefix, even though not allowed by the 1.0 spec, with the rational that extensions are accepted standard.
2. Use a standard extension prefix such as xoauth_ or x-oauth_. This by itself will need to be a mini extension (or added to OAuth at some point).
3. Use extension specific prefix which might conflic with other Service Provider specific names.

Existing behavior

In the HTTP and SMTP, and many other internet RFC standards, the X- prefix is usually the way extensions are done. OpenID and other new protocols use namespaces which are a prefix separated by a period as in oauth.consumer_key. We opted not to go that route because some frameworks (PHP is one) are not really compliant with the URL standard which allows periods in parameter names unencoded.

The difference is that unlike HTTP and SMTP, which use anything that is not X- as part of the protocol and only X- as allowed extension, OAuth defined only stuff that starts with oauth_ as part of the protocol and anything else can be an extension.

I like the OpenID solution but that wasn't available to us given the very different audience we have to support as opposed to OpenID Providers (where most of the OpenID extension work is done).

Using some form of x OAuth is permitted by the spec, but also anything else other than oauth_. I think there is value in creating well defined categories of parameters:

1. OAuth 1.0
2. Published (open) extensions
3. Service Provider specific

Now, #3 can turn into #2, and #2 can turn into #1. This is the nice thing about letting a protocol evolve through implementation. But it would be nice for developers to be able to reuse extension work before it goes #1 in a future spec.

If we choose something like xoauth_, we should define an mechanism (such as the oauth.net site) for registering those open extension parameters so that there will not be conflict between competing extensions. It can be a simple service where you go and register your spec, assign it an identifier (used in the discovery protocol), and specify the xoauth parameters used. If they are taken you will be warned or even forced to change them.