Welcome all. Thank you for being here. What I'm gonna do today is tell some stories. I was talking with Rachel yesterday who won the Kim Cameron award saying, I don't really think of giving presentations. I just think of telling stories cuz that's something I can do one-on-one, I can do it in a small group, I can do it with you. And the stories I'm gonna tell are about the identity journey I've been on for the past number of years. I'll say some things about things that worked, things that failed horribly. Try to learn lessons or take lessons away from why things worked, why things failed. But most importantly, it's also about the people on the journey and the way we work together and what we do.
So in 2005 I ran across this guy named Kim Cameron and he was very excited about digital identity, which I knew almost nothing about. Prior to that I'd been a researcher in operating systems and networking in real time systems. And he said, well this matters. You should come work on this with me. And he was convincing enough that in fact I did. And so I, you know, it's due to Kim that I'm here with all of you in the first place. And Kim told me early on that doing identity work, yes there's protocols and data structures and algorithms and cryptography, but ultimately it's something you do with other people. And so working well with them, getting along with them, even though you may have technical disagreements, you can still respect each other and learn from each other.
So when I talk to people, often non-technical people about what I love about what I do, I'll say I love that In the same day, sometimes in the same conversation, topics will range everywhere from cryptography to business models to privacy, to usability and everything in between. And one of the themes along this journey is, unless you've considered all the possibilities, unless the whole system works well together for everyone, it's not gonna work. And as I'll talk about in a minute, there has to be incentives for every necessary participant to actually wanna participate in an identity system or they just won't.
So there's a number of episodes on this journey. The first episode is information cards, which was Kim's new project at the time. He was very excited about it. And you know a lot of, you know the punchline which is coming. But I'll point out that you know, there's an identity wallet containing identities, credentials, if you will in today's terminology that you controlled and you decided when to release to who. This is strangely present in today's systems that are being built. These are actual information cards, which I still have. On the left is a self issued card, a card where I filled in all the claims. It sits in my wallet, I decide when to use it. Now they're all self-assertive. Self issued, but that's fine for an awful lot of use cases. That's just as good as doing web form fill.
And the model here was that sign-in happened using a public-private key pair that was held in the card. The private key was used to sign a statement that I intended to release these claims and I'm the holder of that key. Well that's a lot like web off in and Fido two except that there were claims, which is different. I'm, I'm not saying that there's an equivalence, but many of the same ideas have fast forwarded into the future and are succeeding, which is great. The card on the right is what we called a managed card where I am not my own identity provider. Some other party is, in this case it was occurred backed by Kros in active directory. And the fact that I was signed into active directory would let me use this card to assert claims. There were other kinds of managed cards.
What was good about that, you couldn't fish it. There was no secret, no password being leaked. And so we had implemented fishing resistant authentication in, you know, 2005, 2007 and it was in production, it worked. Again, fast forward to the journey, we're doing that still now and it's good. There was huge industry investment in the information card work. These are banners that were present at, for instance, the 2007 Burton Group, catalyst Interop. You had ibm, you had Sun Novell, startups like Uau that John Bradley was at at the time. A lot of projects. Similarly at the RSA security conference we did another interop. There was even an android selector that Tony Nalan helped build when Android was a thing most people had never heard of. And heck, we even won the best new standard award here in 2009.
I also had a huge personal investment in this work. These are my twin daughters when they were teenagers, they're no longer teenagers. And we were on vacation in the Kona coast of Hawaii and people made things out of coral. And I thought, what the heck? Let's, let's make an information card logo in Coral. I still have the GPS coordinates of where that is. I doubt it's still there. This was 2009. But you know, we, we thought we were doing something that really mattered. But building ecosystems is hard. As I said earlier, every necessary party has to have an incentive, a reason that they wanna participate or they won't. It has to be solving a problem that they feel like they have and it has to actually solve it. So you know, in this case, and this diagram should look familiar, there was an identity provider, a wallet, a relying party, what we would call a verifier sometimes now. And the person and all those parties had to want to be there. Usability is everything. Rachel talked about that in her presentation yesterday afternoon. In a user study of a representative population, fewer than 3% of the subjects got through the initial info card flows less than 3%. They had no idea what they were trying to do. They had no mental model of what it was. And they would say things afterwards like, well how can I sign in? I didn't use a password.
They didn't get it. That's part of why this was not ultimately a success.
Another failure mode in the card space system was that there were dead ends, bad ones. And those of you building wallets, please don't do this. There were cases where you would go to a site, it would want you to present a card, an identity. You didn't have one in your wallet that satisfied the requirements of the site and you couldn't get one in the flow. You were stuck. You had to back out, you had to know enough to go get the card and then try again. How many normal people will do that? Very few do not build dead ends into your user experiences. So in 2011, my then employer Microsoft pulled the plug on its identity selector. It didn't take the rest of the industry very long to likewise. And you know, I did write a blog at that juncture to talk about what my takeaways were from this journey that I'd been on for six years. And the two main points were that info cards were not solving an immediate perceived problem. They were solving real problems but people didn't perceive that they needed them. And it was not drop dead simple to use. You and I could probably figure it out cuz we have a mental model now, but people didn't get it. It was not a success.
Next episode, open ID 2.0 and the in internet identity workshop, which are very closely linked. There was a protocol called Open ID two. Oh, it is not open, ID connect. It's a precursor, which was invented at the first internet identity workshop. And no, it wasn't at the Computer History Museum in Mountain View, it was at the Hillside Club in Berkeley, California. And there are people like Dick Hart and Dave Recording and Drummond Reed and Johannes Ernst and a number of others got together and they all had kind of similar identity protocols that would prove that you controlled a url. And they said, well let's not have a bunch of these. Let's have one. And that became open ID 20.
That spec was finished in two years in 2007. And it was identity by and for bloggers, the identity or the identifiers you would use were URLs. Mine is self issued.info, it still works, but most normal people don't think of their identity as a url. So this had limited applicability other than in the blogging world where it really worked. I could make a blog comment on Kim's blog, on anybody's blog, and it was authoritatively identified as being from me. Well, we had a protocol, but the I P R was really unclear. So some of the big players, including Sun Microsystems and ibm, Microsoft said, well we like this. We can't use it unless we know that it's IPR safe. And so the Open ID Foundation was created to be an IPR container for those protocols. And it's still going today now in 2011. Now, Sacara, John Bradley, I several others noticed that developers were voting with their feet in the enterprises.
People were pushing XML on soap and web services and all of which worked and still works. But like average developers did not want all the angle brackets. They wanted to use Jason and REST APIs, which was the new up and coming thing. And so while we'd started doing what we called an artifact binding of open ID two, oh we pivoted hard and instead decided to do an OAuth based Jason Rest identity protocol, which came to be known as Open Id connect. And we won an award for that before it was done by two years. So think about that. Once again, we made design decisions at i w some of the key ones.
This is a standard slide I use when talking about the history of connect. A lot of players got together voluntarily and contributed to this. This is by no means an exclusive list, but it does give a sense of how broad this work was still is. One of the lessons that we tried to apply was keep simple things simple. And in fact we had a person behind that in our mind. There's a developer prolific Ruby developer in Japan who's a friend named Nov Maki. And when we would design a new feature, if it was cool, he would just build it one afternoon and it would be in his code base. And if he thought it was complicated, it might not get built. And so we applied the NOV Maki test in our thinking, which is Will NOV think this is cool and will he build it? That served us well. It's not one monolithic speck. It's a whole bunch of pieces that fit together well above the line. And this is a 2014 diagram we're coming up on. 10 years above the line are the specs that were done in the Open ID Foundation in the Connect working group. Below the line, there's a bunch of ITF specs that were being developed concurrently, all of which we knew were gonna work together. They're all also used for other things at this point.
Next episode in some sense was a reaction to OAuth one, which was too hard for most developers to get right? It had message signing and proof of possession and stuff that we're bringing back. But that's a whole nother story. You've all heard of it, you all use it. You may not even know when you're using it. We won an award for that in 2014. Part of this set of data structures was what was called the Jason Web Token, which is a Jason based, signed and or encrypted data structure for claims that's used for all kinds of things. It's even used for like provable caller ID to fight spam calls, at least in the United States and I think some other jurisdictions. Yes, we designed it for identity tokens, but it's used for all kinds of things now, which is cool. We won an award for that.
Interrupt testing really matters. If you have 10 developers who build implementations purportedly of the same thing, you will have at least 10 different interpretations of what the specs say. They will make some different choices around the margins and it often won't work together. There might be parts that do, there will be parts that don't. And until you try it, you actually don't really know. So part of the Open ID connect journey is we did five, five rounds of interrupt testing before we went final. And each time we changed the spec as a result of the features, the feedback that developers gave us, we added stuff, we removed stuff, we simplified stuff, we broke stuff and we did so intentionally because we wanted to get it right and not just say we're done on a timeline.
Well, interop testing led to final specs and you still want people to make sure that they're doing the right things. So we took a page out of Sam's playbook where the Liberty Alliance ran a certification program for SAML two implementations. I helped Microsoft do that for adfs. And our code got better because of it. We found stuff and we thought in the Open ID foundation, well we should do the same. Now we did it a little differently. We let you run your own tests and that way you don't have to pay a big fee. You don't have to wait for a third party to do it. You do it yourself. It worked. Ecosystems can be built. This is one of the successes is open. Id connect, this is my then vice president of Identity, Alexei Simons. I think talking at IDEN or maybe the Cloud Identity summit at the time saying by that point, 92% of all authentications that happened at Microsoft were using Open Id connect, I think it's every 97 at this point. Not that SAML and WS Fed and all the rest aren't still there. They are, but developers have voted with their feet.
Fast forward to recent times. Remember fishing resistant authentication. Well that still really matters. If you can steal a password, you can take over the account in general, unless there's multifactor authentication. But even an OTP can be fished. Whereas if you're never releasing a secret, there's no channel by which to steal it. And so I've done some work in the W three C in Weblo then and the Fido Alliance for FI oh two, which go hand in hand to enable fishing resistant authentication. They want an award for that is the working group that keeps giving. There's a lot of specs. That's a good thing cuz we're solving real problems. It's a problem because there's a lot of specs. It turns out the spec. That's probably next gonna clear the RFC editor is something called Depop Demonstration of Proof of Possession. And it was named retroactively because we were at the OAuth security workshop in Stuttgart. And Brian Campbell, who's in the pink mask, found a poster for Deutsche Pop and thought Depop, we should use that name. And as we were exiting working group last call at I T F in Vienna in 2022, he, he's in the espon and he sees another Deutscha Pop poster. We figured it was a sign.
Vittorio showed a picture of the issuer holder verifier model. There's a lot of work there. And as Vittorio said, one of the cool things is you can release some of these identities as verifiable credentials in their general form without calling home to the issuer. I don't have to go to the Washington Department of Licensing to use my driver's license in an in-person or eventually online interaction. There'll be a session at noon about selective disclosure that a number of folks here and a few folks that are remote are gonna talk about, we reformed the Jose Working Group, Jason Object, signing an encryption to do some of that work. And again, some of it's happening in oa. That's some of the cast of characters that helped create or motivate the recreation of the working group. I gave a presentation yesterday on Federation where the key question is how do you know who to trust? And you not only have to know the identity of the party, you have to know in general whether they share legal agreements with you and they agree to comply with the rules of the federation.
So those are some stories from my identity journey. Hopefully you've been at least amused, maybe you brought away, you can take away some things that are useful when thinking about the systems that you're currently building and deploying, what are my takeaways? Solve real problems. I don't wanna work on stuff that I can just publish. I want it to be used, otherwise it's not worth my time. I wanna build things that get used. Keep simple things, simple, other th otherwise they're complicated and that gets in your way. Usability is everything. If people can't use the artifacts that get built and deployed, they won't. And as Kim said very early on, it's all about the people and the relationships. Thank you for sharing this journey with me. We are still building the Internet's missing identity layer and I'm glad that you're doing it with me. Thank you very much.
