The Case for OAuth 3.0: Why a new working group?
If we’re going to build OAuth 3.0, we need to do the work somewhere. We could do this in the existing OAuth working group in the IETF, or we could start up a new working group. I have been thinking about these options, and I believe this work should be in its own separate standards space.
How We Got To 2.0
OAuth 1.0 started its life as an independent specification cooked up by a handful of really bright engineers (mostly in the back rooms of OSCON if I have my history right). Only later was it brought into the IETF to be made into a standard by the newly-formed OAuth Working Group. OAuth 2.0 started several years later as the WRAP protocol, which was submitted to the OAuth Working Group as a starting point for the next generation of the protocol. WRAP was not compatible with OAuth 1.0, but it represented a radical improvement over the limitations of OAuth 1.0. The group decided that all of its work would go toward a backwards-incompatible 2.0 version instead of extending 1.0 or creating a mostly-compatible 1.1 version.
But why drop OAuth 1.0? It had found great success, but developers quickly found limitations with it. It was inflexible in problematic ways, and the extensions that people were trying broke the underlying model. It did things well for one small set of situations, but it was hard to move outside of those initial assumptions. The changes made in 2.0 brought in more use cases, more users, and capabilities that OAuth 1.0 could never hope to address.
As a consequence, OAuth 2.0 has found success far beyond what OAuth 1.0 had ever seen. This success is partially due to the auspicious timing of the protocol’s introduction right when the web was really becoming API-driven. The combination of OAuth 2.0’s prevalence and its flexibility has created a web of extensions and profiles for a vast array of deployments and application patterns available to developers today. That ecosystem isn’t going to go away, even though an even larger ecosystem awaits in the wings.
I’ve previously said that I believe we should work on a 3.0 version, and I also believe that it’s a good time to do this work. Now, I’m proposing that we start a new working group to do this in the IETF instead of working in the existing OAuth Working Group.
Let It Run, Or Build It Out?
There’s an old metaphor that I believe applies here, and it comes from the world of model trains.
In any model railroad community, you’ll find two main groups of people who love trains but are very interested in very different things. One group will want to keep building, expanding, and redesigning the world. They’re fine with pulling up some tracks or gluing down a new mountain regardless of what that does to existing routes because of what it’s going to be when they’re done with this round of changes. The building process is the engagement point: they have a vision and they want to see it realized. The other group wants to play with the trains. They want rails that connect to each other, mountains that will be in the same place they were yesterday, and trains that fit where they’re supposed to. Running the trains is the engagement point: they just want things to work.
If these two groups are given the same space to work with, there is going to be constant conflict and confusion. The group trying to build something new is going to disrupt the group that wants things to just work like they did before, and the group that wants to run the trains is going to stop the builders from changing things that they don’t like. Ultimately, these groups are happiest when each has its own space, especially when there are members that go back and forth between spaces, bringing their ideas, knowledge, and experience across the border.
Getting The Right Attention
Any major revision to a protocol as foundational to today’s systems as OAuth 2.0 will take a lot of time, attention, and effort. What we’re looking at is not going to be quick or simple to execute, even with the wealth of experience and expertise we can bring to the table.
The OAuth WG is already working on a lot of important things, including several security BCP’s, a possible 2.1 revision, extensions to the core protocol, and profiles of existing work. That’s a lot of work to track and agree on. The OAuth list is huge, and the OAuth WG already takes up two meeting slots at every IETF in-person meeting — and has for years. We still have much to do with OAuth 2.0, and it’s important work that I personally support.
I think it’s just not reasonable for this working group to take on such a monumental effort on top of everything that it’s already doing. The split in attention would always pull back on the new work and confuse the legacy work, and I fully believe that important innovations could be killed on the altar of “that’s not how we’ve always done it”. OAuth 2.0 took the concepts and best pieces of OAuth 1.0 and adapted it both in the ways that people were already using it as well as the ways that people wanted to use it, but couldn’t. It’s time that we do that again, but since we shouldn’t stop work on 2.0, as we previously did with 1.0, we should have a dedicated space to focus on the new version.
Getting The Right People
A major revision to a key security protocol is going to require the right experts to be engaged in the process. It’s true that many of those people are already in the OAuth WG, but many are not. External groups like the User Managed Access community, the Decentralized Identifier community, and even commercial providers with proprietary solutions all have deep experience in use cases that OAuth 2.0 nearly addresses but doesn’t quite cover. We need these people at the table if we’re to build a better system.
In addition, the existing OAuth WG is very, very large. In fact, it’s one of the largest lists in the IETF today. OAuth 2.0 has been around long enough that there’s a large and stable community of implementors and vendors that have little interest in something new until it’s done. If we’re to avoid the pitfalls that have already been discovered, we need this experience at the table as well — but for a large part of the OAuth 2.0 world, OAuth 2.0 does just what they need it to, and they should be able to follow that space alone.
By moving the work on the next generation protocol to its own group, we can create a focused community made up of the right group of people for this new work. Legacy work can continue in its own space, and those that want to do both can still do both. After all, there’s a lot of overlap between these groups, and I count myself in that overlap. I think that creating this space and getting the right combination of people into that space is key to avoiding the second system syndrome that plagues major revisions. Sure, we need to move the train tunnels around, but we still need to make sure those tunnels end in places that people want to actually go.
I’ve heard the argument that creating a new group would lose the expertise gained in the world of OAuth 2.0, but the truth is that it’s trivial to join a mailing list in the IETF. Having a focused list would allow people on both lists to distribute their time and attention more efficiently, and at the very least make email filters easier to write! Instead of having to manually go through every message in the OAuth list to figure out what side of the problem space it was attached to, the two working groups would create a natural fence for attention and effort. Of course, there will be aspects that needs to be coordinated across the efforts, but that’s where those of us who sit in between the spaces come in, to cross-post and cross-present at the meetings. This kind of bridge happens all the time, and has even happened with the OAuth WG in the past and its adoption of JWT. JWT is an application of JOSE, which was its own separate group. There was significant overlap between the two communities, but there was also significant disconnect between them.
We can encourage the right people to join the conversation, no matter where they’re coming from, no matter where the conversation is occurring. If someone’s not paying attention that should be, then it’s up to the working group to engage them. This aspect doesn’t go away if the work is kept in an established group, as there’s zero guarantee that the right people are already in the OAuth WG. In fact, I think it’s dangerous to presume that the people interested in OAuth 2.0 are going to be exactly the ones interested in OAuth 3.0. After all, we don’t need another OAuth 2.0, we already have that! This work needs to be something new.
Sending The Right Message
The OAuth 2.0 working group is, today, a group that wants to play with its trains, and to be honest that’s a very good thing. Such an important security layer for the internet needs stability and predictability. Some have expressed worry that by working on OAuth 3.0, we’re telling developers that OAuth 2.0 is no good and they shouldn’t use it. The truth is that OAuth 2.0 exists today, and if it solves your use case, there’s no reason you shouldn’t deploy it right now. You can even hire companies like mine to come help you do that! But if OAuth 2.0 isn’t doing what you need, then come join the conversation and figure out if OAuth 3.0 might fit better with its new base and new underlying assumptions.
I have a firm conviction that we shouldn’t be shackled by the way we’ve always done things in the past in our efforts to build something better. We now have an opportunity to do something new that fixes a lot of our mistakes, most of which we didn’t realize were mistakes at the time. I’m not naive enough to think that we’ve got all the parts figured out, or that it’s going to be a quick process. Even so, we’ve learned a lot of important lessons and it would be terrible to ignore them. but it’s important that in understanding these lessons we don’t presume we’ll reach the same conclusions.
The interesting thing is that we can effectively build out a new train system without necessarily tearing up the old one in the process. Working on OAuth 3.0 does not mean that we, as a community, should stop using OAuth 2.0, nor that we should even stop building on it. Those who want to keep running OAuth 2.0 can, and will, keep doing so. Those selling OAuth 2.0 systems and services have a long business life ahead of them. Hopefully people will keep buying my book about OAuth 2.0, and as a security architect I’m going to continue to encourage people to use OAuth 2.0 in the many places where it makes sense.
But for those for whom OAuth 3.0 would work better, now is a great opportunity to design the aspects of the new system from the ground up. We can start addressing the hangups of OAuth 2.0 and the use cases it can’t handle, and make a simpler underlying system in the process. Perhaps at the end of the building phase, when all the mountains are where we think they should be and things move to a stable world of supporting existing technologies and deployments, the OAuth group can take over maintenance of the 3.0 version. This exact thing is happening with the HTTP and QUIC working groups today, and I think it’s a good pattern to emulate.
Therefore, I contend that we should form a new working group to work on OAuth 3.0, and I think we should start with the TxAuth mailing list. Come join the conversation, help us figure out the charter text, and get things started.
