State of the (OAuth) Union

PodiumOAuth Core 1.0 was declared as final specification almost a year and a half ago. The overall reception was incredible with almost overnight adoption from major web players like Google, Yahoo, and MySpace. We even got the attention of the major internet standard bodies, approaching us, some officially, some less so, to bring the work over. It has been a good year for community-driven specifications with OAuth leading the charge.

During the past year, we’ve also seen a lot of new ideas and new requirements coming up. Most people are not aware that there are about 15 proposed extensions for OAuth covering a wide range of topics. There is also a lot of confusion regarding what is going on with the specification, how should extension be proposed (and made “official”), and recent announcements.

This post will try to answer some of the questions I receive from people on a daily basis. If you care about OAuth, implemented it or plan to, or have any dependency on the specification, technology, or community, this should be a helpful read. If I missed an important question, please let me know in the comments.

  • What’s Up?
  • What is the Status of OAuth Core 1.0?
  • Is there a New Version Coming?
  • What is Being Done to Make the Current Specification Easier to Read?
  • Is OAuth Moving to the IETF?
  • Why the IETF?
  • Why does the IETF want OAuth?
  • Who Made You In Charge (to Bring OAuth to the IETF)?
  • Why isn’t the Current Specification Good Enough? Why Seek a Standard?
  • OAuth doesn’t Address My Use Case, How can I Extend it?
  • Any Upcoming OAuth Events?

What’s Up?

Good, and you? OAuth has been doing well with adoption spreading quickly. In a nutshell, OAuth Core 1.0 is now in maintenance mode. Extension are being proposed and implemented by various communities and companies. The IETF is considering creating a new internet standard based on the OAuth specification. The OpenID community is developing an OAuth extension. That’s the good news.

The not so good news is that the current quality of the open source libraries isn’t great. The libraries are not thoroughly tested or of consistent coverage or quality, and they are still not easy to use. We need people to step forward and help out.

What is the Status of OAuth Core 1.0?

OAuth Core 1.0 has been declared final on December 4th, 2007. This means it cannot (and will not) change without a new specification being published (with a new version number). OAuth Core 1.0 has been licensed by all its contributors and is available freely.

Is there a New Version Coming?

Yes and no. You are probably referring to the new IETF effort. The new effort to standardize OAuth will address some of its interoperability and security shortcomings but will not directly affect OAuth Core 1.0. It will likely produce a new specification and define a migration path for existing implementations.

If you are looking to implement OAuth today, go ahead – there is no reason to wait. The new work is almost guaranteed to stay close to the current spec, and either way, will take about a year to emerge.

What is Being Done to Make the Current Specification Easier to Read?

We have identified many issues with the current language of the specification and its overall clarity. Given the fact most of the words in it are mine (that is, in my capacity as editor), I am allowing myself a certain freedom to publish a revised version of the OAuth Core 1.0 specification.

The new revision will not change a single normative statement, that is, will not change how the protocol works in any way. There are two main reasons for that. First, it is not my specification, it is a community product and must remain so. I don’t have the moral rights to make changes. Second, I have worked too hard to secure the required legal rights for this specification, and making changes to it without a renewed commitment from the main contributors will undermine it.

However, I think it is possible, and desirable, to produce a new document that will be more accessible and easier to implement. Over the past year I have written many documents, guides, and posts about OAuth, trying to make it easier for people to use, but at the end, developers are forced to go back to the specification and figure it out. What we need is a better specification, editorially speaking.

OAuth was my first specification, so I’ve been learning on the job. Since then, I have gone through many other specifications, mentored others with their initiatives, and have partnered with editors far more experienced than me. I also have over a year of feedback coming from developers struggling with the specification and asking for clarifications. We now know what in the specification doesn’t communicate its message across.

In addition, the specification is going to be used as the basis for a new working group in the IETF. This means it will get a wider audience and will be used as the foundation of the new work. Given the amount of experience we have gained from working with it, I would rather enter into this new effort with a cleaner, clearer version. There is no reason to repeat the same feedback again and waste precious editorial cycles.

Do not expect this new revision to appear as the official version of the specification. Given existing legal agreements, the specification at will remain the same. But I will publish, and likely link to from the OAuth site, a new revision that will be a much better resource for developers. Given this limitation, I am allowing myself the freedom to produce this revision on my own, with little community process.

You should expect this new version published by March 9th (the deadline for IETF Internet Drafts updates for the 74th meeting in San Francisco). If you have concerns and would like to see them addressed in this editorial experiment, please post your comments to the OAuth FAIL thread.

Is OAuth Moving to the IETF?

OAuth is not moving anywhere. OAuth started as a community effort and will remain as such. But this community can live in multiple mailing lists. What we are doing is attempting to produce a new internet standard at the IETF based on the OAuth Core 1.0 specification. We expect the OAuth community to lead the charge, do most of the work, and to simply grow through this process. No one is excluded, but we are expecting and hoping for new participants to join the party.

Why the IETF?

Last year I was approached by Mark Nottingham, a prominent IETF editor and contributor. We talked about the recent efforts within the IETF to address similar use cases to what OAuth tries to solve, and that OAuth has been mentioned by people in recent IETF meetings as a very promising approach.

I have also been approached by people from other standards bodies, namely OASIS and the W3C. I chose the IETF as the place I want to attempt to standardize OAuth for one reason, free participation. IETF was the only venue where everyone is able to participate, and by everyone I mean us, the OAuth community. It comes at a cost which is the lack of any sensible or practical intellectual property policy, something I care deeply about, but that shortcoming cannot justify excluding current community members.

Another reason I chose the IETF is because I view OAuth as an extension of HTTP. It is a natural evolution of RFC 2617 and is closer to the HTTP layer than the application later. Since the most relevant knowledge base for HTTP is within the IETF, it is the natural place to seek advice.

Why does the IETF want OAuth?

The problem with solving the use cases OAuth addresses in a standard body is that people are generally unable to agree on how to address security-related use cases. The various cults in the security world are not very good at coming to an agreement with each other. This makes creating something new a very complex challenge, and hence the value of OAuth.

OAuth represents an existing effort with some good adoption. Starting a standardization process with OAuth as its foundation cuts through most of the issues of coming to an initial agreement.

Who Made You In Charge (to Bring OAuth to the IETF)?

No one, really. Since OAuth doesn’t have a governance model or contr
olling entity, anyone is free to take the specification and do with it as they please (as long as they are within the license). When I decided I wanted to turn OAuth into a standard (for the reasons stated below), I asked each past contributor for the extra legal rights to do so. I then approach the IETF with the request and helped plan for the OAuth BoF at the last meeting.

Why isn’t the Current Specification Good Enough? Why Seek a Standard?

My own reasons for seeking standardization (beside the childhood dream of publishing a standard-track RFC) include:

  • Widen the audience from web developers building (social) applications to other use cases. OAuth could use more HTTP-centric review and the place to obtain that is the IETF.
  • Address known interoperability issue with the spec. The current version added support for the HTTP Authorization header as an afterthought. I would like to make it the central interop mechanism.
  • Extend OAuth’s adoption beyond social web applications. The reality is, this brave new world of community-driven specifications is still young, and many large institutions still look for a seal of approval from well established bodies to adopt protocols. Academic institutions, governments, financial services, and other will not adopt a specification until it has won such approval.

OAuth doesn’t Address My Use Case, How can I Extend it?

This must be the most common question I’ve been asked. Over the past year I have been asked by companies and communities how they can get their proposed extension adopted as an official extension. Well, you can’t. Not because it is such an exclusive process, but simply because there is no such a thing.

In theory, if you get my name on your spec together with some other prominent OAuth authors like Blaine Cook, people will consider your extension official. But that is nothing more than perception. I don’t have any powers to make your specification any more official than it really is. But there is a way to make it stand out.

By doing it.

Write code and document what you have done. There are many people who will gladly help you turn that into a specification (myself included). Publish that draft on your own website or in the community depot. There is no such thing as an official extension. But we do have extensions with wide support from many key people in the OAuth community and to accomplish that, more than anything else, you need to produce running code.

The best place to propose and discuss extensions is where they belong. That is, within the community that is going to implement and use them. If the extension is generic enough, you can bring it up on the OAuth community extension mailing list.

Any Upcoming OAuth Events?

We have a session scheduled for March 23th (5:40pm PST) during the IETF 74th meeting in San Francisco. The goal of the meeting is to move closer to forming an IETF working group based on the final charter language. Some people suggested holding another OAuth summit but so far these are just suggestions. I do want to hold a public code review event for OAuth libraries, but more on that later.

2 thoughts on “State of the (OAuth) Union

  1. How can I participate freely in the OAuth session at the IETF meeting? When I go to register to attend, it seems that the IETF is charging $635 to come and participate in person.

  2. While considered bad form to show up to an IETF meeting unregistered, I doubt anyone will stop you from coming in… But the IETF registration fee is how the IETF pays for not just the event, but the entire organization, most notably the RFC editors.
    And as you know, since you did it last time when we had the OAuth BoF in MN, you can join the conversation using the Jabber room. You might not be aware of but your comments were read out loud to the whole room. Many people cannot attend these meetings in person and they make it easy to participate remotely.
    Hope this helps.

Comments are closed.