Perspectives from 10 years of OpenID Connect

So I'm Mike Jones. We're here on the occasion of Open Id Connect having been approved a little over 10 years ago, and what a ride it's been. We've done celebrations of this now on the Asian continent in Japan. We did one in America last week at Iver, and thank you for joining us for this one. So we wanna take this time to both look back and look forward. Open ID Connect became final in February, a decade ago. And I want to talk about how we created it, what we achieved together, and what we've learned. So in the beginning we thought we would build an artifact binding for open ID two O.

Those of you who know SAML may know what that is. Otherwise it doesn't matter because we pivoted and decided, oh, rather than doing more open ID two O work, developers were voting with their feet towards Jason and rest, maybe we could create an identity protocol using those building blocks. We did five rounds of interrupt testing between 2011 and 2013. And that was critical to getting the developer feedback that helped us refine the specification as we went. And we were aggressive about when developers told us that something worked or something didn't, we would change the spec. We made changes.

We even took features out because people said, you don't need that. So the early developer feedback was completely priceless. So there's a delight design philosophy that guided us, which is keep simple things simple.

In Japan, it was notable that all the presenters said this, and we hadn't coordinated our presentations in advance. Now, there are some complex things we wanted to make possible, such as encrypted claims, but not at the expense of keeping the simple things simple.

In fact, there was a person on the panel with us in Tokyo in JA, January, no Maki, a friend of ours, that we actually applied what we called the NOV Maki Test. He's a prolific Ruby developer. And we asked ourselves, if we spec this feature, will Nove like it? And will he build it into his implementation? In the afternoon, a a lot of people and companies participated in developing this together. This is by no means a comprehensive list, but it nonetheless gives a sense of the breadth of participation that led to open Id connect.

So we did have a lot of experience already with SAML and with Open ID two O, and we were aggressive about borrowing ideas that worked, things like metadata authentication contexts, but we also added things that were previously missing from some of those specs, such as support for native applications. It was extensible by design, as was OAuth on which we built, and that was critical to the longevity and health of the ecosystems. It's not like when we were done with Connect in 2014, we were done developing the Open Id connect ecosystems, quite the contrary.

Extensions continue to this day for particular use cases we built using modular components among them, Jason Web signature, Jason Web Token, the ID token. So what did we achieve? We didn't necessarily expect this, but this became the most widely deployed identity protocol in use today. There's thousands of interoperable implementations in every conceivable language, and the certification program continues making interoperation a reality. There's something like 800 open Id connect certifications to date. There's innumerable interoperable implementations.

While it's not a consumer brand, you're using it every time you use your phone, certainly. So what have we learned? Developers choose things that are simple and developer choice is critical to adoption. Interoperability and security require rigorous testing. And the Open ID certification program has really helped us achieve that. Extensibility is critical to long-term success. I think we got that right. And deployments have to be easy to use or they won't be used.

There's plenty of systems, some of which I've worked on that just because normal people found them too hard to use or didn't know why they wanted to use them, they didn't. Now the asterisk is not everything works out the way you plan. We planned for an open system where people had choice of identity providers. And indeed the protocol supports that as it actually got deployed of most relying parties found it easier to put up an ASCAR screen with three choices or maybe only one choice of identity provider. And the user experience of that was better, even though the user control was less.

And I will say in closing, developer and deployer feedback is gold. All the stuff we're doing currently, we wanna listen to developers just as we did with Open Id Connect, Mr. Sura. Thank you very much.

So yeah, so, so it's not really a debate, but we completely agree on those steps, but I'll give some more spin onto it. OIDC.

Oh, it's done complex, right? So my contact details are there, and I put that not consulting, et cetera, ETC, because I've got many hats like O Open, I Foundation chair, the Digital special advisor to Japanese Fair Trade Commission, and so on and so forth, right? So here it is. And I'm the external board member for All Fleet as well. So Open 90 Connect what it is and what is it? It isn't. So open 90 Connect is online selective Claims disclosure Protocol. A lot of people say that it is a centralized two party model. It isn't. It's much more complex than that.

And it was out of our desire to make the dis decentralized identity possible. And the security principles was based on AAC and ISO 24 7 60, and we took the privacy principles from ISO 29 100. So it's pretty comprehensively thought through, but the reality is that complex part didn't get used. You still can use it and you, you still can achieve a lot of things with it, but it is not being used. The same applies for the use cases. The the top on top, your top left is the nasca sign in with Apple, Google and Facebook and things like that.

So that's a social logging, which got pretty good traction in no time. And by the time we actually published the final specification, Google, Yahoo, whole bunch of telcos, they were already supporting OpenNet Connect and Apple started supporting OpenNet Connect back in 2018 or something like that, right? And Facebook dropped off on the, in the middle, but they are now supporting Open 90 Connect as well. So it's pretty well deployed in nasca user interface with social networks.

It's not only for social networks, it, I've just depicted Europe here, but there are a whole bunch of national implementations that use Open OpenID Connect. That's the same in Asia, and same in South South America.

Like John, which country? Chile has CLA Unica as the, for the civil registry, Argentina, the municipal A, the Buenos Aires has a regional ID system based on open ID connect, and I think there's some stuff in Brazil, but I don't speak Portuguese.

So Yeah, right. And then the, the bill didn't work, but the, we also had account URI, the web finger thing, you know, so that you could actually input your domain to it so that you could use your own identity server like I do, right?

I, I'm running my own personal open I provider as well. And there was a SYOP called, which was used with Open 90 colon slash slash for the, you know, smartphone based open ID providers.

But again, while the, the NASCA user interface was really well used account, URI and the Open ID column slash slash didn't get used. So there are features, complex features, which are left out from being used. We also took a lot of learning from the history.

And so, so one, one of the thing is that 1, 1, 1 of the takeaways that, you know, if we had only those complex things, then we didn't achieve this success. I mean, the complex features actually you would have achieved all the feature set that simple implementation could do, but we left simple thing to be done simply and only made the complex thing possible. And that was one of the approach that led to Open 90 Connect Success. I think we also learned a lot from IT history. We say today we are celebrating 10th year of Open 90 Connect after it's been published as a final.

But there are so much history before that, you know, it goes back until 1999. So it's actually 25th year of making it. And we took learning from all of them, like Open 90 Connect is sometimes said to be open it, you know, 3.0, but it's actually closer to saml. We took a lot of learning from saml. We knew that XML D six doesn't work, so we corrected that and so on and so forth. So you could think of OpenID Connect as ML 3.0 in some respect as well. So Ali Design decisions, we are pretty lonely.

When we started, you know, it was me, John Breno and a couple of Japanese guys and the Chuck, Chuck Mortimore. That was all we had in the working group. But at that point we were pretty, pretty clear that we will not do the canonical because we are banned so much so badly by XML DZ. And we do ask Armoring because we didn't, there were a whole bunch of, it's gotten better, but there were whole bunch of Middlewares who meddle with the, you know, the high beat characters and things like that.

So we decided to ask Armoring and then we decided to use REST as a, in instead of soap in the, you know, sample model. And instead of xml, we decided to use Jason, but to use Jason, we had to come up with a new signature format, and that was Jason Webb's signature at, at the end.

But we, we had three competing stand, you know, drafts at the time. Jason Simple sign, a magic signature, and Jason, what was the Golan Yolan Golans one.

He, He built something that he called Jason Webb Token that he hadn't separated the signature, The original Jason Webb token had the signature built into it. It wasn't a separate draft. Yeah. So all those three were taken together, and Mike took the penmanship to do the, all the hard work of bringing it to ITF and standardized as JWX. And then initially we thought of doing it over all, I mean, OpenID to the au but quickly we found that signature scheme that it had was completely redundant, and we didn't want to do that.

So when, you Know, Dick Hart and Lanam on the bottom came up with something called Auth Wrap, we decided to use it. And by the way, do, do you guys know, right? It has become O2 0.0 liter. So people say that O Open 90 Connect was built as an extension to all 3.0, but it, that's actually not the case. We were building it in parallel together. So features, but as I told you, there are a lot of features that are not being used in OpenID Connect because oh, it's done complex, right? Aggregated and distributed claims.

I hear that some, some implementations actually does use it and support, but it's not widely seen Granular claims request. It, it allows on the fly selective disclosure, but it's not seen in the world.

Well, it's, it was used before, but when we, you think of the data minimization, if you were able to check off some of the claims, then you are actually not complying to data minimization. So those, you know, checklist kind of capability was not needed.

And the, that comes to essential and optional claims and account ur, MRIs, the, you know, web finger stuff and policy URL to which you can, the running party can actually push the privacy policy to it. It's, we, we have started seeing to see some use of it recently, but it took us 10 years to actually get there. And the request object as well, when we were putting it in the request, you know, the spec, a lot of people said that it's not going to be used. Now we are using it in the open finance and things like that quite heavily.

But, and, but the, the, the, the moral of the story is that well request objects could have supported all the use cases, but we, if we only had that, we probably didn't get there, get here. So what lessons we learned that could be applied to other initiatives be persistent. You saw the timelines, it took long time, like, you know, 20 years and be persistent till you succeed.

You continue iterating it, learn from history, history tells you a lot of things, fix what was not done well and find the developer pain and solve it and make it simpler to read, simpler to implement for the minimum viable case. So that's my point. So I have exactly three minutes, right?

Oh, potentially two minutes in a bit. So Given that these guys have just overwhelmed you by a bunch of facts and history and stuff, I, I I, I really just mostly wanna make the point that Open id, you know, people say, oh, well talk about Open id.

Well, it isn't a thing, it's more of an idea. You know, we've had lots of specs under the Open ID umbrella and one of the things that's made us successful is that, you know, we created the Open ID Foundation where we can bring in new ideas, new use cases, and evolve this, evolve this specs.

So what, you know, what we, where we started off with Open ID one is not where we're at with Open ID for v verifiable credential issuance. You know, there's been a lot of evolution.

You know, we are open to new use cases. We have, we invented our own IPR policy, which I describe as mutual assured destruction, where essentially large companies like IBM, Microsoft, I guess IBM isn't actually big anymore. Sun Micro. But once Sun Micro Sun Microsystems, all, all the big guys we're able to come and participate. We don't have, you don't have to disclose patents the way that we, because you know, I hate lawyers.

Well, they're nice people, but you don't want to talk to them. The, I have to get the funk IPR thing signed is like crazy.

Anyways, the problem is that if you tell people that you have to go do a patent search and disclose all your patents that could be involved in this, essentially you bring everything to a grinding halt. So what we did was, we said, you don't have to disclose patents, but if anybody who's join, who's signed our IPR agreement asserts a patent against anybody who's implemented the open spec, we just all gang up on them and be, and do bad things to them. We have the Battle of the lawyer Titans, which no one wants, right?

So no, nobody to this point has actually tried to get a submarine patent into any of the Open ID specifications if they ever tried to assert it. Everyone, apple, Microsoft, Google and Sun Microsystems will come after them with their, their massive patent portfolios. And it's not just the patents that they've used in OpenID Connect, we'll get, we'll set Google on them to sue them for everything.

We'll, we're gonna assert all of Dirk's patents against anybody who tries to mess with Open ID Connect or any of the other Open ID specifications. So we are an open organization, you don't have to pay anything to work on the specifications.

You know, it's not $50,000 a year buy-in like some standards organizations. So people that have an interest in helping us develop the next generation of, of stuff, I mean, I'm getting old and not all the, the ideas can be mine anymore. So most of the bad ideas in Open ID connect. I'm to blame for things like well verifiable credentials, which everybody said would never kind of catch on, you know, wallets, whoever who would ever need one of those.

So yeah, after, after being roundly ridiculed for the, the last 10 years, now I come to a conference and that's all anybody's talking about. So yeah, it only takes 11 years to be an overnight success, I guess.

So that's, that's me. Now I, in the remaining negative, one minute I can do Torsten slides if anybody wants.

The, the one thing on Torsten slides, and I think he had a travel conflict that we haven't said that's really important, is the Open ID Foundation produces open specifications. Well, what does that mean? Anybody can read them without paying to do so Anybody can implement them without paying to do. So it's different than, for instance, the ISO specs where you have to pay, you know, some hundreds of Swiss francs to even read it. And we think that's been an important part of the ecosystem development as well. The slides will be available online. You can read Torsten points later.

Okay, thanks guys. Sorry we have run right out of time, but big hand for that discussion. Thank you.