This article is part of a series about XYZ and how it works, also including articles on Handles, Interaction, Compatibility, and Cryptographic Agility.

It’s been about a year and a half since I started in earnest on the XYZ project. I’ve talked with a variety of different people and companies about how it fits and doesn’t fit their use cases, I’ve presented it at a number of different conferences, and I’ve submitted that work into the IETF in the hopes of starting a new standards working group based on what we’ve built and learned.

With that in mind, I wanted to take some time here to discuss a number of the core aspects of XYZ: why it has the engineering decisions it does and what the effects those decisions have on the resulting system. But I wanted to start this with a look at a more fundamental question: Why am I doing this?

Why Not Extend OAuth 2?

I’ve covered OAuth 2’s shortcomings in the past, and overcoming these shortcomings was a key motivation for starting this project. Many of these shortcomings can be overcome by patching the existing framework with new functions, new restrictions, and new techniques. OAuth 2 has a long and storied history of doing this, and I’ve been the editor for three such specifications myself along with a whole litany of proposed extensions, profiles, and other work. OAuth 2 is not going away, and in fact I do think that patching it up makes sense for those that want to or need to keep using it. I know I’m going to keep using it to solve problems, and I expect to keep teaching classes and doing engineering work on it for a long time yet.

But I still think we’ve come to the point where we’ve patched the framework so much that it’s becoming more fragile and less flexible. We need to start looking to the future before the future surprises us. We already have needs that OAuth 2 doesn’t solve very well, even with all its extensions. People are off inventing their own point solutions right now, but that doesn’t have to be the case forever. We stand a much better chance of success if we learn from the evolution of OAuth 2 and build from that, throwing away things that didn’t work out or didn’t age well.

Why Build XYZ?

I started XYZ as an exercise of stepping back from OAuth 2’s model of the world, and the assumptions that come with it, to see what the world could look like without those constraints. XYZ was my attempt of answering the question, “What if OAuth had been made today with what we know now?”

Some have described XYZ as “OAuth 2, if we knew better,” and I take that as a high compliment. But it’s important to know that it’s not a completely radical departure, and in fact XYZ has been designed to be layered into OAuth 2 based platforms and re-use many concepts in a new and consistent way.

Why Make a Standard?

This is always a hard question. The standards process is fraught with stress and peril, and you don’t always get the best results from it. If I had kept XYZ as a simple standalone project, life would almost certainly be easier. The handful of groups that are implementing the draft protocol would still be able to do so, and as an open source project it would continue to grow and be available for anyone who wanted to do with it.

And I would retain complete control. But therein lies a problem: there are a LOT of really smart people out there, and I think this idea is so much bigger than me. And so I set out to start the process of proposing a new working group in the IETF to both bring in smart people and provide a mixing bowl for all their good ideas, along with mine. If this is going to be robust and powerful, like I think it can be, then it needs a strong and diverse community to build it.

What’s In a Name?

The name XYZ is somewhat of an accident, since I bought the domain oauth.xyz simply because I saw it was available (and on sale!), and I didn’t have any plans for it right away. It became a place to host my writeup of “what-comes-after-OAuth-2” and therefore lent its name to the result. Since this wasn’t really OAuth, it became known as XYZ.

I’m the first to admit that XYZ is not a great name for a project. It’s not unique, it’s hard to search for, it doesn’t stand for anything in particular, and more importantly it’s a common way to say something is a stand-in. But that’s just it: it was always meant to be a functional placeholder for what would come next. An experiment in progress, one with real code and real systems working together, but far from a final product. You can deploy XYZ as a protocol today, but it’s going to change going forward as the work continues. I still think we could call the next big thing that we’re working on OAuth 3, but that’s for the wider OAuth community to decide when the time is right.

I think it’s likely that XYZ will live on as an implementation of what comes out of the standards process, even as that changes.

What’s In It For You?

I don’t usually like to get personal here on my professional blog, but some people have been positing why I’ve been doing this work myself. I’ve been accused of trying to subvert the OAuth 2 world and drive OAuth 2 implementors out of business by causing market confusion. This doesn’t make any sense to me considering several of my clients are OAuth 2 implementors. I want them to continue to succeed, and I think the fear of something new is unfounded and bad business sense. I’ve also been accused of doing this to get famous. To that I say I genuinely doubt that being a part of the creation process for a security protocol that most people won’t ever see is going to make me more well-known than I already am, at least in the circles that care about such things. At the moment, I’m lucky enough that my consulting company is fully booked — if not more than full — and I’m having to divert some incoming projects to others. I’ve also been accused of having some secret project that I’m trying to push onto the world, or a stealth start up that I’m trying to drive in a first-to-market situation. Simply put, I don’t have anything like that. All the prototype code and specifications are open source under liberal licenses. So no, I’m not doing this to get rich and/or famous.

The real reason is a lot more mundane and yet it still confuses people: I want the internet to be better, and I see this as an opportunity to make a difference. I started XYZ as a concept and prototype before any companies talked to me about building it. It was after I had shown that there was something real to this idea that people started to find me because it was a solution that fit the problems that they’re seeing. The feedback and experience of the last year and a half have radically changed the details of XYZ, but the core concepts are still there and still feel sound.

So what’s in it for me? The same thing that’s in it for you: more security, easier development, wider use cases, and a better internet. I don’t know why some think that this isn’t motivation enough, but I promise I’m not hiding ulterior motives.

What’s Next?

I hope that at this point it’s more clear why I started XYZ and why I am trying to start the TxAuth group at IETF. In the next few blog posts, I plan to go over some of the key features of the XYZ protocol and explain why they are important and what they bring that OAuth 2 was lacking. Things like passing by reference handles, proof of possession, interaction models, and extensibility all have key roles, and they’ve been explicitly designed into XYZ over the last year and a half. While all of this is covered in some depth on the XYZ website, I think it’s time to push the conversation even further.

Justin Richer is a security architect and freelance consultant living in the Boston area. To get in touch, contact his company: https://bspk.io/

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store