The IETF Journal meets with OAuth experts Hannes Tschofenig, Blaine Cook, and Eran Hammer-Lahav to discuss the decision to bring OAuth to the IETF and the future of the Internet’s latest security specification.
At IETF 74 in San Francisco, IETF Journal editor Mirjam Kühne and Trent Adams (Outreach Specialist, Identity Community, at the Internet Society) sat down with OAuth BoF cochairs Hannes Tschofenig and Blaine Cook as well as Eran Hammer-Lahav, who authored the OAuth specification document, to find out more about the decision to bring OAuth into the Internet Engineering Task Force, about how the specification compares with similar resources, and about next steps in its development and application.
IETF Journal: There are a number of resources available today that address the growing need to manage and protect a user’s identity on the Internet while making it possible for users to share information from one site to another. How is OAuth related to other work in the identity space?
Eran: There are a few different mechanisms. One is SAML [security assertion markup language], and the other two are OpenID and OAuth. There are a few others in the mix, but those are the main ones in the identity space.
IETF Journal: And what was each of them designed to do?
Eran: SAML was designed mainly for use within business enterprises, and it is perhaps the most complicated of the three because of its use of XML structures. It is also very robust and very powerful. OpenID is fundamentally about single sign-on, and it depends on Web redirections. OpenID is meant exclusively for Web usage and is designed for interactions between human beings. Because of its architecture, OpenID can communicate only what will fit in a URI. It is not capable of handling anything more sophisticated.
OAuth is a way to delegate both access and permission. It is very simple, and in many ways, it borrows from the culture of OpenID in terms of equal access, while at the same time learning from its mistakes. It is designed to be a generic access mechanism. So, if you have other authentication mechanisms on the Web, this is just one more option in that stack. However, it does provide more options: it can be used from server to server as well as from client to user.
Right now, OAuth is not really a standard; it is primarily a guide to best current practices. The next phase of its development will need to focus on interoperability, an area in which it is not strong at the moment.
IETF Journal: Is that primarily the reason for bringing this into the IETF?
Eran: There were a number of different reasons for doing so. I believe it started when Mark Nottingham, who is the chair of the httpbis WG [Hypertext Transfer Protocol Bis Working Group] and a world-renowned expert on caching and proxy, gave us feedback on the OAuth specification. He said, “You know, this is a really good start, but it doesn’t play well with the actual HTTP stack.”? We put it through a security review, but we did not have the full skill set of an IETF security review. Instead, we had two or three people from two different companies doing a security review. But two people doing a security review is not quite the same thing as a full-scale IETF security area review.
After that, we decided to publish it as an Internet-Draft, which was a way to get feedback from the IETF. Then we thought, maybe we should go to an IETF meeting and do a Bar-BoF. Then we thought, why not just do a BoF? After that, things happened very fast. When we published the Internet-Draft, we asked what track it should be put on. We were told, “Oh, just put it on the Standards track. You can always change it later.”? So, the original motivation to bring it to the IETF was to get some feedback from experts. That was really what all this was about.
As we started talking about it, we were hearing that the IETF has been trying to develop something like this for a long time-without much success, because it is very hard to develop a brand-new security protocol from scratch. In some ways, it is very difficult to get new things off the ground from within the IETF. A lot of work is developed outside and then brought into the IETF.
At IETF 74 in San Francisco, IETF Journal editor Mirjam Kühne and Trent Adams (Outreach Specialist, Identity Community, at the Internet Society) sat down with OAuth BoF cochairs Hannes Tschofenig and Blaine Cook as well as Eran Hammer-Lahav, who authored the OAuth specification document, to find out more about the decision to bring OAuth into the Internet Engineering Task Force, about how the specification compares with similar resources, and about next steps in its development and application.
IETF Journal: There are a number of resources available today that address the growing need to manage and protect a user’s identity on the Internet while making it possible for users to share information from one site to another. How is OAuth related to other work in the identity space?
Eran: There are a few different mechanisms. One is SAML [security assertion markup language], and the other two are OpenID and OAuth. There are a few others in the mix, but those are the main ones in the identity space.
IETF Journal: And what was each of them designed to do?
Eran: SAML was designed mainly for use within business enterprises, and it is perhaps the most complicated of the three because of its use of XML structures. It is also very robust and very powerful. OpenID is fundamentally about single sign-on, and it depends on Web redirections. OpenID is meant exclusively for Web usage and is designed for interactions between human beings. Because of its architecture, OpenID can communicate only what will fit in a URI. It is not capable of handling anything more sophisticated.
OAuth is a way to delegate both access and permission. It is very simple, and in many ways, it borrows from the culture of OpenID in terms of equal access, while at the same time learning from its mistakes. It is designed to be a generic access mechanism. So, if you have other authentication mechanisms on the Web, this is just one more option in that stack. However, it does provide more options: it can be used from server to server as well as from client to user.
Right now, OAuth is not really a standard; it is primarily a guide to best current practices. The next phase of its development will need to focus on interoperability, an area in which it is not strong at the moment.
IETF Journal: Is that primarily the reason for bringing this into the IETF?
Eran: There were a number of different reasons for doing so. I believe it started when Mark Nottingham, who is the chair of the httpbis WG [Hypertext Transfer Protocol Bis Working Group] and a world-renowned expert on caching and proxy, gave us feedback on the OAuth specification. He said, “You know, this is a really good start, but it doesn’t play well with the actual HTTP stack.”? We put it through a security review, but we did not have the full skill set of an IETF security review. Instead, we had two or three people from two different companies doing a security review. But two people doing a security review is not quite the same thing as a full-scale IETF security area review.
After that, we decided to publish it as an Internet-Draft, which was a way to get feedback from the IETF. Then we thought, maybe we should go to an IETF meeting and do a Bar-BoF. Then we thought, why not just do a BoF? After that, things happened very fast. When we published the Internet-Draft, we asked what track it should be put on. We were told, “Oh, just put it on the Standards track. You can always change it later.”? So, the original motivation to bring it to the IETF was to get some feedback from experts. That was really what all this was about.
As we started talking about it, we were hearing that the IETF has been trying to develop something like this for a long time-without much success, because it is very hard to develop a brand-new security protocol from scratch. In some ways, it is very difficult to get new things off the ground from within the IETF. A lot of work is developed outside and then brought into the IETF.
Blaine: For me there was another aspect: On the consumer side, the adoption was pretty good, but not so much with enterprise adoption. Businesses want to use it, but they are concerned because OAuth is not yet standardized. We would hear, “You guys are just a bunch of Web guys, so how can I trust you?”? And they want to do their own security release, because they don’t trust themselves [laughs]. I think with these types of protocols, there is a point at which engaging in a proper process with a standards body behind it is really important, especially when it involves things like being able to delegate access from a specific application to my bank, so that I can gain access to your checking account in order to deposit money.
Hannes: Many of the more conservative groups, such as government agencies, often require a standards-track RFC to exist before agreeing to adopt a particular protocol. And it often creates problems for them to come up with the mechanisms to achieve that.
IETF Journal: It sounds like there were two aspects: The first is the evaluation of the current specification and figuring out if there are any issues that might come up during the review, and then, on the backside, the second one is the issue of legitimacy. Therefore, when enterprises ask who has had a look at it, you can raise their comfort level by pointing to the work that has been done on the protocol within the IETF.
Blaine: Yes.
IETF Journal: It also sounds like what you want is not just to release version 1.0 but also to have something that is supported by a long-term process. Is that also a consideration?
Eran: Yes. On the other hand, we also understand that once something gets fed into a Standards track as an RFC, the community cannot expect a new version in six months.
IETF Journal: But what the community can expect is that people will have their eyes on the ball, and that when review is required-whatever the time frame-it will happen.
Eran: At the moment this is a community-driven specification. There are a small number of people who agree that OAuth is stable for now and that they are not going to do any more work on it. Apart from that, there is nothing to prevent anyone from changing it. That is why bigger companies are skeptical. It will take them six to eight months to incorporate the protocol into their development cycle. If the specification changes after six months, it will have been a waste of their effort and money.
I would not say we are bringing OAuth to the IETF; we are attempting to standardize one document as a trial for the community. We are taking this one very specific document to the IETF to have it standardized. We want a more complete security review; we want interoperability; and we want to improve the quality of the document by having more people look at it.
I envision that a lot of the work on OAuth will continue to happen outside the IETF, that fundamentally, it will remain a community-driven process. If at any time the community produces something that is stable and secure enough to be standardized, then we can come back and do the next step. If at that point the WG has completed its work, we can see if we want to recharter the group. Or we could start a new WG.
I am really careful of communicating that we are not moving OAuth into the IETF. There is the OAuth community and then there is the IETF. But I expect the same people who have worked on it so far will also be the people who will make the RFC happen. It really is not an us-versus-them situation. The OAuth WG will consist of whoever shows up, and I expect that 95 percent of the people who show up will be the same people who have already worked on it.
IETF Journal: With that in mind, are you concerned about the potential for bifurcation of the standard? For example, let’s say there is a group of people within the IETF who want to take the standard in one direction, and another group of people in the community who have a use case that they are trying to tackle, which might take them in another direction. How do you decide what direction to go?
Hannes: The decision will be made by rough consensus of the participants of the BoF or the WG.
Blaine: For me it really is about adoption. There are plenty of security standards that haven’t achieved adoption because they are designed from within security ivory towers. We are constantly being surveilled, surveilling each other, and surveilling ourselves. This idea of perfect security is imaginary. We are trying to enable people to take control over what they are doing and make sure that when they take an action there is not some other action happening that they don’t know about. And designing for that is really hard. So, we already have bifurcation of OAuth, because it is based on a number of different specifications. In the way it is written now, we hope it is pretty neutral and something that everyone can agree on.
IETF Journal: So, one could say that the IETF standardizes OAuth and then people can implement against that?
Eran: The biggest danger is standards shopping. I have no intention of doing standards shopping. I do not intend to standardize OAuth elsewhere if the IETF is taking a direction I don’t like. That is also reflected in the way we licensed the work originally and the way we brought it to the IETF: we basically took a snapshot of the document and pretty much said, “Now the IETF can do whatever it wants with it.”?
Today we already have an OAuth Core 1.0 specification. It may not be a standard, but it is there and companies are implementing it and using it. If the IETF produces a successful standard, it will still be called OAuth. After that, the market will decide if it likes it. It is our hope that the market will like it and that it will move toward adoption. And that the people who have already implemented OAuth Core 1.0 will say they will also want to support the new one. But let’s allow the market to decide.
It is also possible that the IETF will move OAuth into a more extreme direction, requiring that all kinds of things be parts of the standard. If that’s the case, what will probably happen is that a lot of the original OAuth authors will leave. The only thing we will probably take with us is the name, not the specification or anything else. We will just say, “Do whatever you want, but don’t call this OAuth anymore.”? Why confuse people? You will end up creating something that you think is better, but it will just be different and then we can let the market decide which one it wants.
IETF Journal: Have you given any thought to the intellectual property rights (IPR) issues that could arise from moving OAuth from its original development paradigm to the IETF?
Eran: Yes. I spent six months negotiating a set of very liberal IPR terms with all of the original contributors. So, if you take OAuth and you change it dramatically so that it does not any longer operate within the boundaries of the community-derived OAuth specification, then you’re on your own! If that’s the case, you need to go and get the IPR requirements you need. But we have actually found the IETF applications area to be very open-source friendly.
IETF Journal: Does that mean that basically there would be no issue if you choose to take the specification down another path at a later time?
Eran: If the IETF is interested in going in a different direction, and if Blaine and I and a few others are the minority voices in the room, and if we cannot raise our voices anymore, then we very likely will just choose to not participate anymore. But nobody is going to take it and bring it to another standards body, such as OASIS. There is no interest in that. If you look at the original goals we stated earlier, creating a standard is not our main objective; it’s more like a bonus.
IETF Journal: Do you agree with what Blaine said earlier about how, to some degree, having a standard opens up markets that you otherwise wouldn’t be able to reach?
Eran: Yes, sure, but only as long as that doesn’t mean selling out on what we were trying to do originally.
Blaine: I don’t have any financial interest in OAuth, and as far as I know, nobody in the community is interested in serving as OAuth advisors. No one has any intellectual property claim that would be of any value. I don’t need OAuth to go into the IETF. Twitter has OAuth, and Flickr has it, as do others. So, the specific properties I would like OAuth to have are already happening. As far as not having to give out my password on the Web in those applications that I wouldn’t really trust with that kind of thing, well, that is done. So, it is really about recognizing that it would be really cool if more enterprises started thinking about these kinds of lightweight but strong security mechanisms.
In terms of fragmentations of the specification and what might happen next, it’s important to remember that OAuth could not have happened 10 years ago. The culture on the Net was different. Even two years ago, when we started to write this up, we used MD5, not SHA-1. There were no libraries at the time. Things have changed significantly in this space. Things evolve, and as OAuth gets adopted, we can do more work on it. I fully expect that something better than OAuth will come along in 5 to 10 years, and then we will start to use that. The technology will be better and our comprehension of the problems as the wider community-not just the security community-will be better.
IETF Journal: Was there a moment when you had to decide which community could give you the best security review and the highest level of legitimacy? Were there other players on the table? Or did you just stumble onto the IETF?
Eran: I have been approached by a colleague who is active in the IETF, and then by Lisa Dusseault, who is one of the applications area directors to officially bring the question to the IETF to see if the IETF might be interested. We had a BoF in Minneapolis at IETF 73, where we asked ourselves if this is an area that may interest the IETF. After that, the question was, Is OAuth a good and reasonable solution to use as a starting point? Those were the two main questions we started off with, and then we started working on the charter. People have also approached me informally from both the W3C and OASIS.
IETF Journal: So, it sounds like you did not step back and say, “Here are the three things I need, let’s look at which standards organization would be the most appropriate, is that right?
Eran: That’s right. However, after I started talking to Lisa, I did look around a bit because this is something you want to do only once and you don’t want to discredit yourself. You don’t want to go to the IETF and then after the first BoF think, well, I don’t like the way this is going in the IETF. I’ll go to the W3C and see if they want it.
It was an easy decision based on one criterion-that is, that every single person who has been involved in OAuth until now could continue to work on it in the IETF. Participation at the IETF is open, and there is no membership fee. It is much more difficult to participate in other organizations, such as OASIS and the W3C. It is expensive to become a member.
Morally, I felt that was the right way to approach it. I felt that people might not agree on the need to standardize it or on the value of it or even that the IETF is the best place to do it. But at least they’re welcome to join. And all they have to do is join the mailing list. That’s the only barrier.
Blaine: If you compare the barriers, for instance, of the W3C or OASIS, it is much more difficult to participate.
Eran: That ruled them out immediately. The W3C membership model is really difficult. And joining OASIS is expensive.
Blaine: To some extent, that’s also a concern with the IETF. It may have no membership fees, but the costs of attending the meetings are pretty high. Many people do this in addition to their regular work. Eran is one of the few people who has an employer’s approval to be working on it.
IETF Journal: On the other hand, wouldn’t it be good to expand the weight of the WG and to broaden the participation? Right now it is pretty U.S.-centric.
Blaine: I agree. I think it’s important to meet in Stockholm at IETF 75, which will get more Europeans involved. It would also be a good time to push forward the work on its adoption. At the moment, not many people in Europe know about OAuth.
Hannes: All decisions have to be confirmed on the mailing list anyway. So, the meetings are more like social events.
IETF Journal: Yes, but meeting in person is a good way to overcome potential trust issues with other people.
Hannes: That’s true.
Photos by Peter Löthberg