WRAP, and the Demise of the OAuth Community

oauth-sunsetThe road to hell is paved with good intentions.

A few weeks ago at IIW, Dick Hardt of Microsoft, Brian Eaton of Google, and Allen Tom of Yahoo! presented WRAP, a competing specification to OAuth. WRAP is a smart specification that includes a lot of good and useful ideas. If it was presented as a white paper on how OAuth could be made better, I would be singing a very different tune. It is a very good protocol draft which has clearly learned many lessons from two years of hands-on OAuth experience. I encourage anyone working in this space to read and study WRAP.

WRAP started as an effort to create a profile of OAuth based on the OAuth Session extension (which has never matured beyond a first draft). It had two main requirements: make it easier for client developers to use the protocol, and make large scale deployment easier and more efficient. Their effort was based on a simple fact, that OAuth does not adequately support large providers. While many people disagree with this statement, I tend to agree with it. I also agree that many people are struggling with the protocol, but the solution is better libraries not a new protocol (have you tried to implement TLS on your own lately?).

From conversations I had with the WRAP authors, it was clear that their intention was not to replace OAuth, but to supplement it until (and if) OAuth is changed to support their use cases. At the end, due to internal corporate politics and product release schedule, Microsoft and Google decided to ship WRAP implementations and positioned it as a complete solution available as an OAuth replacement. As of now, they intend to focus on enterprise products, an area OAuth is not widely deployed in.

The problem with pointing fingers here is that no one was doing it out of malice, but out of a combination of convenience and ignoring the big picture. The bottom line is that the OAuth community who created the original specification doesn’t exist anymore. Instead, we have a few individuals who carry enough recognition to make others follow them as if they represent a community. I have fought against associating WRAP with the OAuth brand for the past 6 months, but all it took was for me to leave the IIW session early for ‘OAuth WRAP’ to emerge.

I can only guess that the decision to assign the OAuth brand to WRAP was made in haste in light of the warm reception WRAP received at IIW (because as I stated earlier, it is a smart proposal). It looks like those in the room feared that WRAP might damage the accomplishments of the OAuth community and undermine its adoption. For the companies behind WRAP this was a clear win as it positioned their proprietary (even if open) technology as an extension of a well-recognized community brand.

To be clear, WRAP cannot be considered a profile of OAuth no matter how hard one tries. WRAP is closer to proprietary protocols from Microsoft, Google, and Yahoo! than it is to OAuth. On top of that, existing OAuth libraries are completely useless for implementing WRAP. It is a different protocol, not a profile. In addition, the last remaining artifact of the OAuth community, the Google group, was never included in the discussions or decisions around WRAP, only informed of it.

It is important to note that the WRAP authors have recognized that their work is not an OAuth profile and did not push for it. Brian Eaton is the second most active contributor to the IETF work , Dick Hardt clearly communicated his employer’s needs and the reason why OAuth is not suitable for them at this time, and Allen Tom has reinforced Yahoo!’s commitment to OAuth and its plan to deploy OAuth 2.0 when a stable draft is published. And as I stated earlier, WRAP is a worthy protocol, just not suitable for the OAuth label.

One of the questions I am asked repeatedly is how to make an OAuth extension official. My answer is that there is no such thing, but if you are looking for recognition and quicker adoption, try to convince someone with streetspec-cred to put their name on it. In OAuth’s case, it means Blaine Cook, Chris Messina, or me. I am not trying to dismiss the important work of the many people who made significant contribution to the specification, but am only pointing out that as far as the developer community is concerned, these are the three people “running” OAuth. And contrary to popular believe, the three of us are not that well-coordinated.

Needless to say, associating WRAP with OAuth was not a good decision. Beside the confusion it created among developers, it also diverted critical resources away from the current work being done by the IETF OAuth Working Group on OAuth 2.0. It also made it more attractive for other companies to consider deploying WRAP to replace proprietary solutions. Now, with the OAuth brand attached, it offers an easy “Open” win, without having to help move the 2.0 effort forward.

OAuth WRAP is just one illustration of the demise of the OAuth community.

The community has disintegrated shortly after the specification was completed. Lately, it was evident in the lack of participation in the IETF effort, and the fact that only a single named author from the original OAuth Core 1.0 specification has bothered to read the draft of the upcoming OAuth 1.0 Protocol RFC. This informational RFC is being published to provide a better specification for OAuth 1.0, as well as a more durable historical record and a point of reference for the upcoming OAuth 2.0.

Over the past 2 years I have received many comments and complaints about the quality of the OAuth Core 1.0 specification, and I completely agree that it is a poorly written document. I have also collected a list of errors and omissions which make implementation difficult. For the past 9 months I have spent many hours working on a brand new version of the specification, written from scratch. This was originally published as the Editor’s Cut edition. This draft has now gone through 7 revisions and matured into a document I am very proud of. It is without a doubt a superior write-up of the OAuth Core 1.0 protocol.

And yet, out of 20 listed authors (excluding myself), only one read the draft and provided feedback.

I started writing this post because I was frustrated at how my hard work is being abused in one case, and ignored in another. But as I was writing, it became clear to me that being angry is really pointless when that anger is directed at something that no longer exists.

The IETF will move forward and work on a replacement for OAuth Core 1.0. If the OAuth brand holds over the next few months and continues to offer value, the new work will emerge as OAuth 2.0, and with an ‘Internet Standard’ label, should be able to counter any negative impact as well as compete with proprietary solutions like WRAP. I am also encouraged by the promise made by the WRAP authors to submit the specification as input for the IETF WG, for incorporation into OAuth 2.0, and am looking forward to it.

There is an important lesson here, one that should be learned by other open communities developing specifications. Without a lasting governance structure these communities cease to exists, and their brand becomes a free-for-all to exploit. This is something I hope the Open Web Foundation will attempt to improve, to avoid the need to duplicate the OpenID and OpenSocial experiences and create a foundation for each specification community.

11 thoughts on “WRAP, and the Demise of the OAuth Community

  1. I started to write a post (which I might still publish), but wanted to focus on one aspect here.

    Those good intentions at IIW were focused on not having a year long standards battle between WRAP and OAuth before OAuth 2.0 is finished.

    It seems clear that the WRAP authors want it to influence OAuth 2.0 within the IETF. Calling it OAuth WRAP – based on that one of the best contributions of OAuth has been killing the password anti-pattern and socializing the idea of using tokens within APIs – should keep a consistant message to developers of “use OAuth”, provide the IETF working group with additional rough consensus and running code on a possible direction for OAuth 2.0, and will hopefully encourage companies deploying WRAP to migrate to 2.0 once it is finished. I’m willing to be convinced that I’m wrong, but it seems worse for OAuth to have Facebook, Google, Microsoft, and Yahoo! all deploy something which competes with it for developer mind share and marketing.

    • In practice, companies deploying WRAP in a large scale now are not likely to deploy OAuth 2.0 for at least another year, and it might take another year for their developer to show interest in migrating to another protocol without additional value (being a standard typically isn’t one).

      I think OAuth 2.0 will reach a stable draft in a couple of months. There really isn’t that much work there. It will move faster or slower based on the amount of feedback received and the quality of the implementations trying it out. While some people disagree with me about the value of the upcoming OAuth 1.0 RFC, that draft has significant editorial value for 2.0 as well as to cement the 1.0 protocol for some use cases 2.0 will no longer support. We would have had a first draft of 2.0 if I got more help to finish the 1.0 RFC.

      I think the way out of this is to move very fast with the OAuth authentication component and migrate WRAP to use that. Work on the flows will take a bit more time, but that is something WRAP is going to be a center component of, which will make future migrations much easier (most likely different, shorter parameter names).

      I would like to see anyone looking to adopt WRAP to join the IETF OAuth WG list. At least we will not fragment the mind share (any more).

      • I’m happy to turn this into an email on the IETF list if it would be useful. The largest issue in Facebook moving to OAuth 1.0 (and yes, your new RFC is awesome) is the increase in the number of HTTP requests that developers will need to make in comparison to our current authentication mechanism. We want to move to using OAuth, but for this reason and hearing strongly from other major implementors that OAuth has not been widely adopted by their developer communities because it is too difficult to correctly implement has us concerned.

        The most interesting part of WRAP are the various profiles. They currently map well to our existing authentication mechanisms and the username/password profile is an API we offer to whitelisted partners such as the XBox and Playstation 3. It would be great if OAuth 2.0 had a similar profile mechanism where each profile is optimized in terms of the number of steps (HTTP requests) required versus being combined together like OAuth 1.0.

        I’m not convinced that signatures are “too hard” for developers especially when libraries hide them away. That said, OAuth 1.0 implementations still requires that developers understand the different types of tokens in addition to when and how they’re generated.

        WRAP is intriguing in terms of really simplifying what developers need to understand. The first step being trading some set of credentials or asking the user to go somewhere results in an access token. The second step then being including that access token via HTTP headers, a GET arg, or a POST arg over SSL without needing to calculate any sort of signatures. The downside is that now all APIs need to be served over SSL, but that seems doable.

        I’m happy to participate in the IETF to help develop OAuth 2.0 and to encourage others from Facebook to do the same, but also want to be really pragmatic around having something we can ship (either WRAP or 2.0) sooner rather than later.

      • Yes, and Yes, (and was there a third question? I’ll say Yes anyway).

        Please go ahead and post this feedback to the IETF list. It is very useful. I would love to have your active contribution in the WG as well as others from Facebook. Facebook Connect and APIs are clearly winning adoption and provide an extremely valuable lesson.

        My criticism of WRAP isn’t actually about the specification but about process and names. I think it is going to be a cornerstone of the 2.0 standard. As soon as it is posted as an I-D (which is an annoying process requirement), we will be able to enter a detailed discussion of it various profiles.

  2. I tend to agree the message wasn’t clearly communicated – i’m still not sure. Makes it hard to communicate to others who are asking me.

    Would have made more sense to do something akin to recent OpenID discussions on how things could be taken forward irrespective of where things are now.

    The “wrap” name also needs to change. Perhaps it was supposed to be a Christmas present to people using oAuth but has left me confused and wondering whether i’ll have to implement both now.

  3. I agree completely with you Eran. I think one of the most important things for OAuth success is to focus on ease of use for developers. One part of that is avoiding confusion.

    Your draft is a great step towards clearing out many of the confusions found in the first version.

    Splintering like this is not a good idea and splintering is what it is. I would be happy to have something like it brought into OAuth 2.0 like you are working on if the resulting spec is still simple.

    I also just want to say thank you for your hard work in curating the spec.

    • Far from it. OAuth has been adopted by many web services and the number is growing. WRAP is simpler, yes, but provides far less security and is still in draft state. Note that Facebook will not use WRAP in its current form, they would like to see signatures added back in as well as using a protocol developed in the open. We are currently working on the next version of OAuth which will improve many of the limitations listed, but security is never easy and anyone expecting a secure protocol to be trivial to implement is just ignoring reality.

      If someone is finding the signature part hard to implement, it would be great if they can share why. Is it the specification? Lack of examples? Test cases? Saying something is hard without providing constructive feedback is useless.

Comments are closed.